O czym jest ten film
- Model Fable 5 wrócił, ale tylko na kilka dni — potem znika z planu Max i przechodzi na drogie rozliczenie za zużycie.
- Autor namawia, by nie marnować tego okna na przypadkowe eksperymenty, lecz wykorzystać je na trzy konkretne działania.
- Działanie pierwsze: audyt i dopracowanie własnych „skills” (umiejętności) — czyli narzędzi, których używa się na co dzień niezależnie od dostępu do Fable.
- Fable 5 wyraźnie lepiej niż Opus 4.8 rozumie kontekst i intencję oraz wyłapuje drobne detale, które w innych modelach umykają.
- Działanie drugie: audyt już zbudowanych funkcji i kodu — Fable diagnozuje przyczynę źródłową problemu, a nie łata pojedyncze objawy.
- Przykład z praktyki: błąd w pętli agenta w aplikacji mobilnej, którego Opus wielokrotnie nie potrafił poprawnie zdiagnozować.
- Sednem błędu okazała się bezstanowa pętla po stronie serwera — potrzebny jest „checkpointer” utrwalający stan na serwerze.
- Działanie trzecie: burza mózgów i planowanie zupełnie nowych, złożonych funkcji, gdzie trzeba scalić dużo kontekstu i badań.
- Porównanie „na ślepo”: przy tym samym poleceniu Opus wprowadzał ponownie już naprawione błędy i mylił się co do możliwości narzędzi (np. Supabase).
- Wniosek: implementację można oddać tańszemu modelowi (Opus), a Fable wykorzystać jako architekta planu i orkiestratora.
Redakcyjne tłumaczenie
Fable 5 wraca — ale tylko na chwilę
Fable 5 oficjalnie znów jest dostępny, ale realnie zostanie z nami tylko przez kilka dni, zanim zniknie z planu Max i trzeba będzie dopłacać za dodatkowe kredyty. W tej sytuacji można zrobić właściwie dwie rzeczy. Po pierwsze — bezmyślnie próbować „za jednym strzałem” generować projekty na przypadkowych, jednorazowych zadaniach. Albo po drugie — zrobić trzy rzeczy, które za chwilę pokażę.
(Informacja dodatkowa: „skill” w Claude Code to skonfigurowany zestaw instrukcji i zasad, który model uruchamia dla konkretnego typu zadania; autor traktuje je jak własne, wielokrotnie używane narzędzia).
Rzecz pierwsza: dopracuj swoje umiejętności („skills”)
Fable 5 świetnie rozumie kontekst i intencję — jest pod tym względem znacząco lepszy od Opusa 4.8. Tę moc — tak dużą, że rząd USA musiał ludziom odradzać jej używanie — warto skierować na dopracowanie tych narzędzi, których i tak używamy codziennie, także wtedy, gdy nie mamy już dostępu do Fable. Pytanie brzmi: jak wykorzystać go do ulepszenia naszych podstawowych, codziennych narzędzi?
Jako przykład pokazuję moją bibliotekę umiejętności „go-to-market” — reklamowo dodam, że dostajecie ją w mojej płatnej społeczności (link w opisie). W środku jest kilka umiejętności, które pomagają dobrać strategię wejścia na rynek: jaka jest realna strategia kanałów, jak pozycjonować się wobec konkurencji, jak ustalić cennik, jak zaprojektować strukturę strony docelowej i napisać do niej copy. Skoro daję to ludziom, chcę mieć pewność, że jest dopracowane maksymalnie.
W wierszu poleceń warto wiedzieć, że Fable domyślnie nie pojawia się w rozwijanej liście modeli — wystarczy wpisać /model fable, by ustawić go jako aktywny model. Uruchamiam własną umiejętność „skill audit”, która audytuje inne umiejętności — bardzo meta. Daję jej dość ogólne, otwarte polecenie: poszukaj obszarów do poprawy, zwłaszcza w kontekście copywritingu i stron docelowych, bo na tym wielu ludzi polega, jeśli nie mają zaplecza marketingowego. Zakodowałem tu całe swoje doświadczenie z prowadzenia agencji marketingowych oraz budowania i sprzedawania aplikacji — chcę mieć pewność, że te zasoby i reguły są rzeczywiście egzekwowane przez umiejętność, i że nie ma innych umiejętności zasilających tę, które powodują problemy.
To samo podejście stosuje się niemal do wszystkiego. Poprzednim razem, gdy Fable był dostępny, dopracowałem nim własne umiejętności deweloperskie. Mam prywatną wtyczkę łączącą spec-driven development z najlepszymi elementami bibliotek, których używam — Compound Engineering, Ora Superpowers i innych. Wziąłem z każdej to, co lubię, i połączyłem w jeden system dopasowany do mnie. Fable pomógł mi to poskładać i upewnić się, że wszystkie elementy łączą się poprawnie.
Umiejętność skonfigurowałem tak, by najpierw sama się „ugruntowała” w kontekście, więc zadaje mi mnóstwo pytań o to, co dokładnie chcę audytować. Odpowiedziałem na wszystkie na podstawie tego, co moim zdaniem da się poprawić — bo zawsze jest miejsce na ulepszenia — i uruchomiłem proces.
Co znalazł audyt
Gdy skończył, przeanalizowaliśmy wyniki. Sam proces i jego poszczególne elementy są naprawdę mocne — co ma sens, bo zbudowałem je na realnych procesach z pomocą Opusa. Problem tkwi w drobnych detalach — i to jest coś, w czym Fable jest naprawdę dobry. Rozumie szerszy obraz, ale potrafi też wyłapać te pozornie mniejsze przypadki brzegowe, gdzie ważne szczegóły inaczej wymknęłyby się przez palce.
W tym przykładzie mamy sporo wejść, które budowaliśmy z mozołem — głos marki, język klienta, szczegóły projektowe — a które nie są poprawnie przenoszone do kolejnych faz. To jeden duży problem. Drugi: umiejętność powinna podpowiadać, jakie sekcje ma zawierać strona, by była dobrze konwertującą stroną docelową SaaS-a czy aplikacji mobilnej — ale nie potrafi przełożyć tego na spec, który dałoby się po prostu podać Claude Code, by zbudował coś naprawdę zapadającego w pamięć. Copy tworzy świetnie, ale brakuje elementu, który pchnąłby to w stan „wow”.
Znalazł kilka przyczyn. Po pierwsze — wspomniane „szwy”, przez które ustalone detale nie przechodzą dalej. Po drugie — bardzo wartościowa konwencja, którą stosuję przy innych umiejętnościach do budowania, zwłaszcza pracując z Claude Design: budowanie systemów przekazania („handoff”). Narzędzia takie jak Claude Design, Google Stitch, Figma czy Pencil.dev mają różne sposoby promptowania, które sprawdzają się lepiej. Warto mieć małe adaptery, które biorą plan i konwertują go do formatu danego narzędzia. Jednym z trybów awarii było to, że wklejam do Claude Design mnóstwo kontekstu, którego to narzędzie nie potrzebuje — brakuje kroku adaptera, który sformatuje wszystko tak, jak potrzebują tego narzędzia projektowe.
Powód, dla którego to lepsze niż Opus: ten audyt uruchamiałem już wielokrotnie z Opusem i za każdym razem próbował optymalizować tylko kawałek „czy proces jest mocny?”. Nie schodził do poziomu wszystkich tych pozornie drobnych rzeczy, które wymuszają odejście od tego, czego użytkownik faktycznie chciał. Jeśli pomyślimy o „intencji motywacyjnej” albo o celu — Fable jest dużo lepszy w tym, by widzieć cel poprzez detale i doprowadzać je do końca.
To samo zastosowałbym do dowolnych narzędzi deweloperskich albo umiejętności, których używacie regularnie i o których myślicie „czasem jest dobrze, czasem nie, ale nigdy mnie nie zachwyca”. Ten typ pracy będzie dla was ogromnie wartościowy. Mamy teraz bardzo konkretny plan — i, co ważne, nie potrzebujemy Fable do jego wdrożenia. Można je zaimplementować w podagentach na Opusie, a Fable ustawić jako orkiestratora. Sky is the limit. Dla mnie umiejętności to podstawowe, codzienne narzędzie — używam ich chyba najczęściej, często tworzę własne wersje na bazie open source. Poświęcenie czasu na ich audyt i dopięcie to jedna z najbardziej wartościowych rzeczy, jakie można zrobić.
Rzecz druga: audytuj to, co już zbudowałeś
A co z funkcjami, które faktycznie budujemy przy pomocy tych umiejętności? Nawet jeśli nie jesteś z wykształcenia inżynierem — a właściwie nawet jeśli jesteś — audytowanie tymi narzędziami rzeczy już zbudowanych jest niesamowicie wartościowe. W tym projekcie coś doprowadzało mnie do szału. To projekt aplikacji mobilnej, nad którą pracuję. Zaczęło się od dodania pętli agentowych. Pierwsza iteracja wykonywała kilka wywołań modelu językowego, nic szalonego. Potem zacząłem dodawać i budować własną pętlę agenta — i tam zaczął się błąd. Próbowałem go naprawić, ale chcę mieć stuprocentową pewność, bo szykujemy się do wejścia na rynek i ta rzecz musi być kuloodporna. Idealny moment, by sprawdzić, jak Fable audytuje to, co zbudowaliśmy.
Uruchamiam własną komendę „zoom out and think” (oddal widok i pomyśl). Używam jej, gdy wpadamy w te same problemy raz za razem, gdy tkwimy zbyt głęboko w niuansach, a system musi spojrzeć z wyższego poziomu i zrozumieć, jaka jest przyczyna źródłowa na poziomie systemu. Zamiast patrzeć na konkretny błąd i wiecznie go łatać — po czym wyskakują kolejne — pytamy: biorąc pod uwagę, co próbuję osiągnąć w tym projekcie, jakie są kluczowe problemy, które trzeba przemyśleć i rozwiązać?
Diagnoza: bezstanowa pętla po stronie serwera
Gdy skończył, przeczytał cały projekt, a następnie wykonał wyszukiwanie w sieci, by znaleźć nowoczesne najlepsze praktyki dla tej konkretnej dziedziny — w tym przypadku budowania własnej pętli agenta, pętli typu ReAct.
(Informacja dodatkowa: pętla ReAct — Reason + Act — to wzorzec, w którym agent na przemian rozumuje i wykonuje działania z użyciem narzędzi).
Rozłożył precyzyjnie, jak działa system. Mamy domową pętlę ReAct, która przyjmuje wiadomość od użytkownika i ma zestaw narzędzi. Fundamentalny problem dotyczy stanu: w rozmowie z aplikacji do serwera stan żyje tak naprawdę tylko po stronie klienta — a to duży kłopot. Opus całkowicie to przeoczył. Przechodziłem przez wiele takich sesji debugowania tą samą komendą z Opusem i zawsze znajdował rozwiązania na plaster i taśmę klejącą. Dlatego mamy tyle commitów — za każdym razem łataliśmy jedną rzecz, po czym przy następnym problemie trzeba było łatać kolejną, bo nie rozwiązywaliśmy realnej, leżącej u podstaw przyczyny.
Fable najpierw ugruntowuje się w tym, jak system faktycznie działa, a potem przechodzi do tego, jaka jest nasza prawdziwa prośba. Chcę, by agent był spójny w całej rozmowie: potrafił zapisywać posiłki, poprawnie planować, dopytywać o niejednoznaczne prośby lub produkty, zatwierdzać zmiany i pozwalać użytkownikom je korygować — i to bez łatania w kółko przy każdej z tych czynności. Opus nie potrafił tego zdiagnozować nawet wtedy, gdy sam wskazywałem, że problemem jest pętla. Wielokrotnie zaczynałem czaty od słów: „Wydaje mi się, że to ta pętla jest fundamentalnym problemem — nie używa poprawnie narzędzi, nie pamięta, co powiedział użytkownik, nie reaguje właściwie na odpowiedź użytkownika” — a i tak nie znajdował tych problemów.
Sedno: pętla po stronie serwera jest bezstanowa — nie wie, co było wcześniej — podczas gdy rozmowa nie jest bezstanowa. To fundament problemu. Do wielu z tych wniosków doszliśmy już wcześniej w badaniach z Opusem — kiedy uruchamiałem rozległe agenty badawcze, trafiliśmy na wzorzec przerwania i na to, jak użytkownik musi wchodzić w interakcję z systemem. Ale nie można zwalać wszystkiego na model — człowiek prowadzący proces z Opusem nie zaimplementował wszystkich potrzebnych wzorców.
Jeśli jesteś użytkownikiem, który dużo rzeczy puszcza „bez rąk” — a bądźmy szczerzy, wielu tak robi — na tego typu problemy właśnie się natkniesz. Przy prostszych zadaniach albo się ich nie zauważa, albo są na tyle proste, że nie dają o sobie znać. Ale gdy wchodzisz we wzorce agentowe i budowanie skomplikowanych rzeczy — dlatego właśnie trzeba zwolnić przy procesach spec i upewnić się, że wszystkie bazy są pokryte.
Igła w stogu siana
Podsumowanie tego, co znalazł — a Fable jest w tym naprawdę dobry — czyli tego pozornie niejasnego, a w rzeczywistości kluczowego dla działania systemu elementu: potrzebujemy „checkpointera”, który utrwala stan na serwerze. Gdy proces zostaje przerwany i potrzebuje odpowiedzi użytkownika, ma pamiętać wszystko, co dotąd się wydarzyło; odpowiedź użytkownika staje się wtedy po prostu kontynuacją wykonania, z pełnym kontekstem tego, co było wcześniej.
(Informacja dodatkowa: checkpointer to mechanizm zapisujący stan agenta, by po przerwaniu można było wznowić wykonanie od zapamiętanego punktu, zamiast zaczynać od zera).
Fundamentalnie polegamy na kliencie, który wykonuje zbyt dużą część orkiestracji — a klient powinien ostatecznie odpowiadać tylko za renderowanie. To sytuacja, w której trzeba wprowadzić znaczącą zmianę, by była to porządna pętla agenta. Tu użyłbym Fable do zbudowania specyfikacji — i dokładnie to zrobię. Mówię mu: użyj OpenSpec propose, by stworzyć nowe specy naprawiające problemy 1, 2, 3. Implementację wykona słabszy model, np. Opus, więc zadbaj, by plan niósł dalej intencję motywacyjną i wszystkie krytyczne detale tego, co trzeba wdrożyć i dlaczego.
Reasumując tę część: Fable jest naprawdę dobry w audytowaniu. W moim projekcie próbowałem zbudować pętlę, będąc — szczerze — mniej „w pętli”, niż powinienem. Sprawy poszły trochę bokiem, ale nie tak daleko, by były nieodwracalne — trzeba będzie skasować sporo już wykonanej pracy, ale przynajmniej wiemy dokładnie, na czym polega problem. Czytając to, widzę jasno, że system rozumie problem. Uruchamiamy propozycje i systematycznie przez to przejdziemy — nawet jeśli do implementacji użyjemy Opusa, plan zbuduje nam Fable.
Rzecz trzecia: burza mózgów nad zupełnie nowymi funkcjami
A co, gdy chcemy zbudować coś zupełnie nowego — zwłaszcza w systemie z wieloma elementami, które muszą się dobrze zintegrować? To ostatnie zastosowanie, które uwielbiam w Fable — czy to przy budowaniu funkcji, czy przy pracy umysłowej. Gdy Fable się pojawił, wielu mówiło, że nie jest dobry w pracy umysłowej — moim zdaniem to kompletna bzdura, jest w tym naprawdę dobry. Świetnie przyjmuje dużo różnego kontekstu z różnych miejsc: twojej wiedzy o temacie, tego, co chcesz osiągnąć, wcześniejszych notatek, pomysłów na funkcję — cokolwiek to jest. Bierze to, rozumie cel i intencję, a potem wychodzi, prowadzi własne badania i właściwie żeni te dwie rzeczy.
Cały ten proces — badanie, eksploracja pomysłu, iterowanie wokół niego, przejście przez pełny cykl życia — robi naprawdę dobrze w porównaniu z Opusem. Gdybym miał robić to z Opusem albo nawet z Chatem, musiałbym rozbić rzecz na mnóstwo osobnych części — już na etapie badań i eksploracji trzeba by badać wszystko z osobna, a potem próbować to zebrać, co bywa żmudne. Zobaczmy, jak dobrze poradzi sobie Fable po prostu „z pudełka”.
Kontekst: jesteśmy przy pierwszym etapie burzy mózgów nad funkcjami. Chcemy rozwiązać, jak to wszystko działa po stronie serwera, po stronie backendu — ale musimy też umieć strumieniować te zdarzenia do frontendu w miarę, jak się dzieją, żeby w ogóle móc je pokazać. Budowany interfejs musi być ściśle sprzężony z tym, co backend potrafi wystawić, żeby wszystko renderowało się mądrze. To jedna z ostatnich rzeczy do dopięcia, zanim aplikacja trafi na rynek.
Żeby zobrazować, o czym mówię, wspominając o strumieniowaniu zdarzeń i tokenów: strumieniowanie tokenów oznacza, że tekst „wypisuje się” w miarę pojawiania, a nie wyskakuje jednym blokiem. Musimy też strumieniować zdarzenia dziejące się na serwerze — gdy wywoływane są narzędzia, gdy osiągane są ważne punkty — i wysyłać to na front.
Porównanie na ślepo: Fable kontra Opus
Gdy proces się skończył, zaplanował cały system — sporo ładnych badań, wyłapanie potencjalnych haczyków, realny, ugruntowany stan rzeczy. Chciałem jednak przemyśleć, gdzie realnie różni się to od tego, co dałby Opus. Uruchomiłem więc dokładnie to samo — z jedną różnicą: zabroniłem zaglądać do wcześniejszych czatów, bo nie chciałem, by po prostu odczytał gotowe rozwiązanie. Dałem mu ten sam prompt. Przeszedł przez to i wymyślił wszystko, co pewnie zaczęlibyśmy wdrażać, gdybyśmy naprawdę nie poświęcili czasu na zakwestionowanie tego.
Następnie kazałem Fable przejrzeć wynik i powiedzieć — na podstawie wniosków, do których właśnie doszliśmy — co ten drugi czat zrobił źle. Oba miały ten sam kontekst i to samo polecenie startowe; jedyna różnica to zakaz czytania innych czatów. To ważne, bo pokaże, gdzie Fable jest szczególnie wartościowy i na jakie trudne problemy warto go kierować, póki jeszcze można.
Kazałem to skategoryzować. Pierwsza kategoria: rzeczy niebezpiecznie błędne, które napędziłyby złą implementację. Po pierwsze, Opus miał właśnie ponownie wprowadzić całą klasę błędów, które już naprawiliśmy — kompletnie mylił się co do tego, jak zdarzenia mają być emitowane i pokazywane na froncie. To dokładnie ten scenariusz, w którym wiecznie wpadasz w te same błędy w lekko zmienionej formie. Ufamy Opusowi, że jest mądry, a on w kółko robi to samo w nieco innych wariantach, wprowadzając błędy na nowo.
Kolejna, dość poważna: sposób, w jaki planował to zrobić, po prostu by się wywalił. Co dzieje się, gdy użytkownik przerywa albo pauzuje — jak wtedy zachowują się odpowiedzi agenta? Miał to zaimplementować kompletnie na odwrót. Miał też rzeczy zwyczajnie faktycznie błędne co do tego, do czego Supabase jest, a do czego nie jest zdolny.
(Informacja dodatkowa: Supabase to platforma backendowa oparta na bazie PostgreSQL, oferująca m.in. bazę danych, uwierzytelnianie i funkcje czasu rzeczywistego).
W tej kategorii oczywiście dałoby się skierować model do narzędzi typu Context 7 albo zmusić go do zajrzenia do dokumentacji — ale Fable zrobił to sam, bez dodatkowego naprowadzania, bo „wie”, że naprawdę musi to rozstrzygnąć.
(Informacja dodatkowa: Context 7 to narzędzie dostarczające modelom aktualną dokumentację bibliotek, by ograniczyć zmyślanie faktów).
Znalazł jeszcze kilka rzeczy: problemy strukturalne w tym, co miał wdrożyć — element, który uznał za rdzeń i najbardziej autorytatywną część systemu, nie został potraktowany właściwie. Gdybyśmy wdrożyli to na ślepo, mielibyśmy problemy strukturalne. Były też drobniejsze rzeczy — nie zbadał innych istotnych fragmentów bazy kodu.
Podsumowując: przy tym, co zaliczyłbym do bardziej złożonej burzy mózgów — próba zaimplementowania strumieniowania po stronie serwera od zera w kontekście naszej aplikacji — Fable był znacząco lepszy. Po tym filmie zamierzam przejść przez to i wdrożyć całość.
Zakończenie
Mamy to tylko przez kilka dni. Nagrywam 2 lipca, a model ma być dostępny do 7 lipca — choć chyba widziałem gdzieś w interfejsie, że do 9 lipca, więc mogę się mylić. Potem przechodzi na rozliczenie za zużycie, a model jest bardzo drogi, więc raczej nie będzie rozsądny dla większości ludzi na kredytach za użycie. Gorąco zachęcam, byście przemyśleli jedną albo wszystkie trzy rzeczy z tego filmu: ulepszanie umiejętności, audyt istniejących funkcji, które trzeba uczynić solidniejszymi, oraz burzę mózgów nad ambitniejszymi funkcjami, które wydawały się zbyt skomplikowane — i sprawdzenie, czy Fable pomoże wam pokonać tę przepaść.
Jeśli chcecie pomocy przy którejś z tych rzeczy, mam rosnącą płatną społeczność z mnóstwem własnych umiejętności i wtyczek, gdzie ludzie budują świetne rzeczy i zarabiają na nich. Jeśli film się podobał, a jeszcze nie subskrybujesz — zasubskrybuj. To tyle, do zobaczenia w następnym.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Traktuj okno dostępu do drogiego modelu jak inwestycję, nie zabawkę
Na czym polega: Fable 5 jest dostępny tylko przez kilka dni w planie Max, potem przechodzi na kosztowne rozliczenie za zużycie. Autor odradza marnowanie go na przypadkowe „oneshoty” i proponuje trzy trwałe zastosowania.
Jak stosować: Zaplanuj z góry, na czym najbardziej ci zależy, i skieruj model na rzeczy, których owoce zostaną z tobą po wygaśnięciu dostępu (dopracowane skills, plany, specyfikacje) — a nie na jednorazowe wydruki.
Na co uważać: Daty (7 vs 9 lipca) bywają niepewne. Nie zostawiaj najważniejszej pracy na ostatnią chwilę i weryfikuj termin we własnym interfejsie.
2.Audytuj swoje „skills” samym modelem — meta-audyt
Na czym polega: Fable potrafi audytować twoje własne konfiguracje (skills), wskazując, gdzie ustalone reguły nie są egzekwowane. Autor używa do tego dedykowanej umiejętności „skill audit”.
Jak stosować: Uruchom audyt na narzędziach, których używasz najczęściej. W Claude Code ustaw model przez /model fable. Daj otwarte polecenie „znajdź obszary do poprawy”, ale wskaż domenę (np. copywriting, strony docelowe).
Na co uważać: Pozwól, by model najpierw dopytał o kontekst — pochopny audyt bez ugruntowania da powierzchowne uwagi. Sam odpowiadaj konkretnie na jego pytania.
3.Szukaj „szwów”, przez które detale nie przechodzą dalej
Na czym polega: Największą wartością Fable jest wyłapywanie drobnych przypadków brzegowych — np. tego, że głos marki czy język klienta nie są przenoszone do kolejnych faz procesu.
Jak stosować: Przy audycie wieloetapowych procesów poproś wprost o sprawdzenie, czy ustalone wcześniej wejścia (dane, reguły, styl) faktycznie docierają do etapów końcowych.
Na co uważać: Mocny „proces” na wysokim poziomie może maskować utratę szczegółów. Nie zakładaj, że skoro szkielet jest dobry, to detale też — to właśnie tam kryją się błędy.
4.Buduj adaptery „handoff” między narzędziami
Na czym polega: Różne narzędzia projektowe (Claude Design, Figma, Google Stitch, Pencil.dev) wymagają różnego promptowania. Wklejanie temu samego, surowego kontekstu zawodzi.
Jak stosować: Twórz małe kroki-adaptery, które biorą wspólny plan i formatują go pod konkretne narzędzie docelowe, zamiast przekazywać wszędzie ten sam blob kontekstu.
Na co uważać: Nadmiar kontekstu potrafi zaszkodzić — narzędziu projektowemu daj tylko to, czego potrzebuje w jego formacie, nie wszystko, co masz.
5.Diagnozuj przyczynę źródłową, a nie objawy — komenda „zoom out and think”
Na czym polega: Gdy w kółko wracają te same błędy, autor każe modelowi cofnąć się o krok i zbadać przyczynę na poziomie systemu, zamiast łatać pojedynczy bug.
Jak stosować: Miej gotowe polecenie, które zmusza model do opisania, jak system faktycznie działa, a dopiero potem do wskazania rdzennych problemów względem twojego realnego celu.
Na co uważać: Łatanie objawów mnoży commity i tworzy iluzję postępu. Lawina drobnych poprawek to sygnał, że problem leży głębiej.
6.Utrwalaj stan agenta po stronie serwera (checkpointer)
Na czym polega: Sednem błędu w aplikacji autora była bezstanowa pętla serwerowa przy stanowej rozmowie — stan żył tylko na kliencie. Rozwiązaniem jest checkpointer utrwalający stan na serwerze.
Jak stosować: Przy własnych pętlach agentowych zadbaj, by po przerwaniu i odpowiedzi użytkownika wykonanie wznawiało się z pełnym kontekstem. Klient ma renderować, nie orkiestrować.
Na co uważać: Przy prostych aplikacjach ten błąd się nie ujawni — pojawia się dopiero przy złożonych wzorcach agentowych. Dlatego przy procesach spec trzeba zwolnić i pokryć wszystkie przypadki.
7.Rozdziel role modeli: Fable planuje, tańszy model wdraża
Na czym polega: Nie trzeba używać drogiego modelu do implementacji. Fable może zbudować plan/spec i pełnić rolę orkiestratora, a kod napisze np. Opus w podagentach.
Jak stosować: Zlecając generowanie specyfikacji, wyraźnie zaznacz, że implementację wykona słabszy model — i każ przenieść do planu „intencję motywacyjną” oraz wszystkie krytyczne detale (co i dlaczego).
Na co uważać: Jeśli plan zgubi intencję i szczegóły, słabszy model wdroży go błędnie. Jakość planu decyduje o jakości implementacji.
8.Nie zwalaj wszystkiego na model — człowiek też prowadzi proces
Na czym polega: Autor przyznaje, że część problemów wynikała nie z Opusa, lecz z tego, że jako operator nie wdrożył wszystkich potrzebnych wzorców i był zbyt „hands off”.
Jak stosować: Zostań „w pętli” — kwestionuj plany, sprawdzaj, czy ustalone wzorce (np. przerwania, interakcja użytkownika) rzeczywiście trafiły do implementacji.
Na co uważać: Tryb „bez rąk” jest kuszący i częsty, ale przy złożonych systemach prowadzi do kosztownych, trudnych do cofnięcia błędów.
9.Testuj przewagę modelu w kontrolowanym porównaniu „na ślepo”
Na czym polega: Autor uruchomił to samo zadanie i prompt na Opusie z zakazem czytania wcześniejszych czatów, a potem kazał Fable wskazać, co tamten zrobił źle — by zobaczyć realną różnicę.
Jak stosować: By ocenić, gdzie dany model naprawdę pomaga, zrównaj warunki (ten sam kontekst i polecenie) i porównaj wyniki, kategoryzując błędy według wagi (np. „niebezpiecznie błędne”).
Na co uważać: Przewaga wynikająca z dostępu do wcześniejszych ustaleń to nie to samo co przewaga rozumowania — dlatego autor odciął jeden przebieg od historii, by porównanie było uczciwe.
10.Kieruj model na scalanie wielu źródeł kontekstu przy nowych funkcjach
Na czym polega: Fable dobrze przyjmuje dużo rozproszonego kontekstu (wiedza, notatki, pomysły, cel), łączy go z własnymi badaniami i prowadzi przez pełen cykl od eksploracji do planu — bez ręcznego rozbijania na kawałki.
Jak stosować: Przy ambitnych, wieloelementowych funkcjach (np. strumieniowanie zdarzeń serwer→front) podaj cały kontekst naraz i pozwól modelowi samodzielnie doszukać braków oraz zweryfikować fakty.
Na co uważać: Nawet dobry plan może zawierać błędy strukturalne lub pominięte fragmenty bazy kodu — przejrzyj wynik krytycznie, zwłaszcza „rdzeń” systemu, zanim zaczniesz wdrażać.