O czym jest ten film
- Model to nie przewaga konkurencyjna — decyduje sposób, w jaki go instruujesz, oraz systemy i pętle, które wokół niego budujesz.
- Nie da się zatrzymać inteligencji modelu, ale można zatrzymać jego proces — i przenieść go na tańsze modele.
- Autor testował dynamiczne workflowy: Fable orkiestrujący Fable dawał podobne wyniki co Fable orkiestrujący Sonnet, ale kosztował wielokrotnie więcej.
- Warto traktować najsilniejszy model jak nauczyciela i „starszego inżyniera”, który spisuje swoją wiedzę dla tańszych „juniorów”, a nie jak konia roboczego.
- Kluczowe umiejętności na najbliższe lata to routing modeli (dobór modelu do zadania) oraz dobór właściwego poziomu wysiłku (effort).
- Wyższy poziom wysiłku nie zawsze jest lepszy — na maksymalnych ustawieniach model potrafi się „przekombinować” i dać gorszy efekt.
- Z przecieku promptów systemowych Fable 5 wynikają praktyczne zasady pracy (weryfikuj pamięć, sprawdzaj istnienie plików, odpowiadaj przed pytaniem o doprecyzowanie).
- Autor stworzył umiejętność „Fable mode” opartą na pięciu bramkach: scoping, evidence, attacking, verifying, reporting.
- Prawdziwa wartość „planowania” to nie tylko lista kroków, lecz adwersaryjne myślenie o tym, co może pójść nie tak.
- W czasach, gdy modele bywają odbierane, nie posiadamy modeli — posiadamy własne procesy, metodologie oraz lokalny sprzęt i modele.
Redakcyjne tłumaczenie
Model to nie jest przewaga konkurencyjna
Odkąd wszyscy dostaliśmy dostęp do Fable 5, wydałem kilka tysięcy dolarów na kredyty użytkowania, po prostu bawiąc się tym modelem, rozumiejąc, jak działa, a co ważniejsze — jak my, ludzie, możemy wycisnąć z tak potężnego modelu jak najwięcej. I jeden z najważniejszych wniosków, do jakich doszedłem, jest taki: owszem, Fable 5 to niesamowity model, nie zrozumcie mnie źle, ale sam model nie jest tak naprawdę przewagą konkurencyjną.
Pomyślcie o tym tak. Mamy początkującego użytkownika AI i mamy kogoś takiego jak Andrej Karpathy. Jeśli początkującemu dasz Fable 5, a Karpathy’emu dasz Sonnet 3.7, to Karpathy zbuduje coś lepszego niż początkujący — mimo że model początkującego jest nieporównywalnie lepszy.
(Informacja dodatkowa: Andrej Karpathy to znany badacz sztucznej inteligencji, współtwórca OpenAI i były dyrektor ds. AI w Tesli).
A dzieje się tak dlatego, że dużo ważniejszy jest sposób, w jaki model instruujesz, oraz systemy i pętle, które wokół niego budujesz.
Proces można zatrzymać, inteligencji nie
Podam wam jeszcze jeden przykład. Testowałem Fable 5 masę razy. Testowałem też intensywnie Opus i Sonnet. Jedną z moich ulubionych ostatnio rzeczy jest korzystanie z dynamicznych workflowów, które pozwala uruchamiać Claude Code.
(Informacja dodatkowa: „dynamiczny workflow” to tu proces, w którym jeden model-orkiestrator planuje pracę i rozdziela ją na wyspecjalizowane pod-agenty, które wykonują poszczególne zadania i raportują z powrotem).
Zrobiłem mnóstwo takich dynamicznych workflowów, w których mówiłem: „Fable, zaprojektuj workflow, a wszystkie twoje pod-agenty niech też będą Fable”. Potem robiłem dokładnie te same testy z Fable orkiestrującym gromadę pod-agentów Opus oraz z Fable orkiestrującym gromadę agentów Sonnet. I odkryłem, że gdy uruchamiam te dynamiczne workflowy, wyniki są mniej więcej takie same — mimo że przebiegi na samym Fable kosztowały mnie wielokrotnie więcej.
Sedno, które chcę przekazać, jest takie: nie da się zatrzymać inteligencji modelu, ale można zatrzymać jego proces. Dlatego dziś chcę pokrótce opowiedzieć, jak zamienić model taki jak Opus w coś, co bardziej przypomina Fable.
Traktuj najsilniejszy model jak nauczyciela, nie konia roboczego
Pierwsza rzecz: musisz myśleć o tym modelu bardziej jak o nauczycielu niż jak o koniu roboczym. Kiedy wszyscy dostaliśmy dostęp do Fable, w zasadzie po prostu pchaliśmy go do granic możliwości. Anthropic nawet opublikował materiały o tym, że jest naprawdę dobry w długich zadaniach — dąży do celu, planuje, wykonuje, a potem weryfikuje. I rzeczywiście robi to świetnie.
Ale cała idea routingu modeli polega na znalezieniu równowagi. To zadanie wymaga tyle a tyle inteligencji — po co więc używać modelu, który ma jej dużo więcej i kosztuje dużo więcej, skoro można sięgnąć po mniejszy, tańszy model i wykonać zadanie na tym samym poziomie jakości? To jest cała gra i będzie to bardzo ważna umiejętność do opanowania w kolejnych latach AI.
Zamiast więc pozwalać Fable wszystko planować i wszystko robić, próbujemy wydobyć sposób, w jaki Fable myśli, a następnie pozwolić mniejszym modelom myśleć i działać w ten sam sposób.
Miałem sytuacje, w których Fable przeglądał moje konfiguracje i wprowadzał ulepszenia, przeglądał moje umiejętności (skills) i je poprawiał. Uświadomiłem sobie, że traktowałem Fable trochę jak współzałożyciela albo raczej jak oficera w mojej firmie, a nie jak zwykłego pracownika. Trochę jak starszego inżyniera, który próbuje spakować całą swoją wiedzę i przekazać ją nowej fali juniorów, która ma przyjść i zająć jego miejsce.
Wnioski z przecieku promptów systemowych Fable 5
Niedawno wyciekły prompty systemowe z Claude Fable 5. Przeczytałem to w całości, dałem to również do przeczytania samemu Fable 5 i wyłuskaliśmy kilka ważnych rzeczy, które nam się rzuciły w oczy.
- „Częściowe rozpoznanie z treningu nie oznacza aktualnej wiedzy” — czyli sam fakt, że coś jest w twojej pamięci, powinien skłonić cię do weryfikacji.
- Bardzo podobnie: prompt sugerujący, że jakiś plik istnieje, nie oznacza, że rzeczywiście istnieje. Model dostaje polecenie, by sprawdzać, czy rzeczy faktycznie są. Chodzi więc o to, by na każdym kroku upewniać się, że to, co model robi i co już zrobił, jest zgodne z prawdą.
- „Zajmij się nawet niejednoznacznym zapytaniem, zanim poprosisz o doprecyzowanie” — czyli najpierw odpowiadaj, potem dopytuj. Maksymalnie jedno pytanie.
- „Przyznaj, co poszło nie tak, trzymaj się problemu, zachowaj szacunek do siebie”.
- Kwestia poziomu wysiłku: jedno przejście dla prostych faktów, trzy do pięciu dla zadań średnich, pięć do dziesięciu dla głębszych badań i porównań.
Mamy więc nie tylko dyskusję o tym, jaki model jest właściwy do zadania, ale też o tym, jaki poziom wysiłku jest do niego właściwy.
Poziom wysiłku: wyższy nie zawsze znaczy lepszy
Lubię przyglądać się pewnemu wykresowi, który pojawił się na blogu premierowym Claude Fable 5 i Mythos 5. Porównuje on Fable 5, Opus 4.8 oraz GPT 5.5 pod kątem wyniku (na osi Y), kosztu (na osi X) oraz różnych poziomów wysiłku dla każdego z modeli.
Jeśli należysz do osób, które po prostu włączyły Fable 5 i używają go na domyślnym poziomie wysiłku — tak samo z Opus — i nigdy tym nie majstrujesz, to zdecydowanie zacznij eksperymentować, bo robi się ciekawie. Zauważysz na przykład, że Fable 5 na niskim wysiłku jest dość zbliżony do Opus 4.8 na wysokim. Fable 5 jest przy tym trochę droższy i odrobinę wyższej jakości, ale są do siebie podobne.
To jednak nie znaczy, że wyższy wysiłek zawsze jest lepszy. Wiele razy z Fable pracuję po prostu na wysokim poziomie, bo gdy używam ustawienia „extra high” czy „max” — albo tak samo na Opus — model zaczyna działać znacznie dłużej, robi się znacznie droższy, a potem przekombinowuje, zaczyna się dwoić i troić, i ostatecznie produkuje coś gorszego, niż gdybym po prostu wybrał Opus 4.8 na wysokim albo Fable na wysokim.
Zadanie pierwsze: wydobądź „metodę Fable”
Po przeczytaniu promptów systemowych i po tak długim testowaniu modeli chcę, żebyście zrobili dwie rzeczy.
Pierwsza: weź sposób, w jaki bawiłeś się Fable — cały ten „rusztowanie” czy jak chcesz to nazwać, całą metodę, której używałeś — i zamień to w coś, co potrafi robić Opus i co potrafi robić Sonnet. Czyli wydobywamy metodę Fable.
Zachęcam cię do czegoś takiego: jeśli kiedykolwiek dostałeś od Fable rezultat, który po prostu pokochałeś, a nie potrafiłeś dokładnie wyjaśnić, co ci się w nim tak spodobało — każ Fable go przeanalizować, albo każ przeanalizować go Opus. A jeśli możesz zajrzeć wstecz do samej sesji, tym lepiej. O czym myślałeś, żeby tu dojść? Jak do tego doszedłeś? Co zrobiłeś, żeby udowodnić, że to działa? Jak udało ci się uzyskać tak dobry wynik? Wydobądź te informacje i zamień je w umiejętność (skill).
Umiejętność „Fable mode” i pięć bramek
Mam teraz taką umiejętność o nazwie „Fable mode”. Kiedy chcę, żeby Opus jej użył — albo gdy mamy przed sobą naprawdę trudny problem — próbowałem używać Opus 4.8 z „Fable mode” i czuję, że działa to naprawdę dobrze. Wydaje się, jakby model został trochę podniesiony na wyższy poziom, bo ma w siebie wstrzyknięty ten „prompt Fable”.
Umiejętność działa na pięciu bramkach: scoping (zakresowanie), evidence (dowody), attacking (atakowanie problemu), verifying (weryfikacja) i reporting (raportowanie). To trochę tak, jak ustawiasz swoje prompty typu /goal, używasz dynamicznych workflowów i budujesz te pętle — tylko że tutaj robimy to również jako plik umiejętności.
Jedna naprawdę ważna rzecz na temat zakresowania i tego, co ludzie nazywają planowaniem. Jest duża różnica między samym rozplanowaniem czegoś — „oto wszystkie kroki, rozpisz je i wykonaj” — a graniem roli adwokata diabła i zastanawianiem się: dobrze, a co ze wszystkim, co może pójść nie tak? Co, jeśli przyjrzymy się wszystkim niewiadomym w tym planie? To właśnie Fable robi bardzo dobrze.
Dlatego kiedy każę Fable uruchomić dynamiczny workflow do osiągnięcia jakiegoś celu, a on rozplanuje każdy możliwy krok, przemyśli każdą rzecz, która może pójść nie tak, a potem zaprojektuje workflow tak, że Sonnet może wykonać całą realizację i tylko raportować z powrotem do Fable — Fable może na tej podstawie projektować kolejne kroki procesu. I właśnie dlatego dynamiczne workflowy z Fable i Sonnet dają wyniki bardzo zbliżone do workflowów z Fable i Fable. Dla mnie to był moment olśnienia: dlaczego to jest równie dobre, a przy tym znacznie tańsze?
Możesz zacząć od czegoś takiego: „Napisz kompletny, instalowalny plik umiejętności, który sprawi, że Opus 4.8 będzie działał z twoim osądem, twoim planowaniem, weryfikacją i nawykami rozumowania, i aktywuj go czymś w rodzaju »Fable mode«”.
(Informacja dodatkowa: autor udostępnia gotową umiejętność „Fable mode” za darmo w swojej społeczności — link w opisie filmu — ale zaznacza, że można ją zbudować samodzielnie).
Ten plik przeprowadza przez roboczą dyscyplinę Fable, tak by mógł ją uruchomić dowolny model — mógłbyś go odpalić nawet na GPT 5.5, jeśli chcesz, albo nawet na modelach open source. Przechodzi przez tych pięć bramek: zakresowanie przed pracą, dowody przed rozumowaniem, rozumowanie adwersaryjne, weryfikacja przed ogłoszeniem, że coś jest gotowe, i wreszcie kalibracja. Do tego dochodzi kilka stałych nawyków i rzeczy do sprawdzenia. Danie tego Opus 4.8 sprawia, że Opus wydaje się trochę „podniesiony”.
Zadanie drugie: routing modeli i tabela narzędzi
Coś, co świetnie się z tym łączy, to znów idea routingu modeli — ustalenie, jak Fable, albo jakiś inny inteligentny model, może w razie potrzeby przekierować pracę do mniejszych.
Od jakiegoś czasu daję swojemu Claude tabelę różnych modeli w moim zestawie narzędzi i wskazówki, kiedy których używać. Mógłbyś dodać też opcję „deleguj do Codeksa” albo „deleguj do modeli open source”. To będzie bardzo, bardzo istotne, gdy firmy zaczną myśleć o ekonomii jednostkowej, o małych zespołach — a może i ty sam masz miesięczny budżet na AI. To właśnie ten rodzaj rzeczy oddzieli ludzi, którzy dostają dużo więcej za dużo mniej.
Dobry sposób, żeby to rozbić: oto różne modele w naszym zestawie. Oto ile kosztują — przy czym wyższa liczba oznacza lepszy wynik kosztowy, czyli taniej. Potem mamy inteligencję i „gust” (taste). Jeśli chcesz dorzucić inne kategorie oparte na twoim workflow, śmiało. Inteligencja to trochę to, jak bardzo dany model wydaje ci się mądry, jak dobrze cię rozumie, jak dobrze radzi sobie na przykład z przeglądaniem kodu. Gust to bardziej kreatywność, myślenie nieszablonowe, projektowanie UI/UX i tym podobne.
To naprawdę pomaga, gdy projektujesz zespoły agentów albo delegujesz do pod-agentów i uruchamiasz dynamiczne workflowy, bo czasem twój workflow może wykorzystywać wiele agentów Sonnet, kilka Haiku, a potem nawet kilka Opus.
Oto przykład rzeczywistego testu, który przeprowadziłem. Użyłem Opus jako orkiestratora, z tym promptem „Fable mode”, o którym mówiliśmy wcześniej, i wykorzystał on różnych pracowników: Sonnet, Opus i Haiku. To były trzy osobne testy. W tym, w którym orkiestrator Opus delegował zadania do samych zwiadowców Haiku, było około trzy razy taniej, a wynik był dokładnie taki sam. Podobnie jak w przykładzie z Fable — to jest coś, o czym naprawdę warto myśleć.
Nie posiadamy modeli — posiadamy procesy
Wiem, że ten odcinek był krótki i taki miał być. Ale widziałem mnóstwo komentarzy i wielu ludzi w społecznościach, którzy trochę panikują na myśl, że Fable zostanie nam odebrany. Ma wrócić do subskrypcji — tak przynajmniej twierdzi Anthropic. Nie wiemy kiedy, ale wróci.
To całe zamieszanie — wkraczanie rządu, odbieranie modeli — naprawdę skłania mnie do myśli, że my nic nie posiadamy. Nie posiadamy tych modeli. To, co możemy posiadać, to nasze procesy, nasze systemy, nasze metodologie, sposób, w jaki myślimy o używaniu tych modeli. A także sprzęt i lokalne modele.
Zdecydowanie będę zgłębiał znacznie więcej tego typu rzeczy. Dajcie znać, co chcielibyście zobaczyć wokół tych tematów. Jeśli nauczyłeś się czegoś nowego albo film ci się spodobał, zostaw łapkę w górę — bardzo mi to pomaga. Jak zawsze doceniam, że dotrwaliście do końca, i do zobaczenia w następnym. Dzięki, wszystkim.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Przewagą jest proces, nie model
Na czym polega: O jakości wyniku decyduje nie sama moc modelu, lecz to, jak go instruujesz oraz jakie systemy i pętle wokół niego budujesz. Doświadczony użytkownik na słabszym modelu bije nowicjusza na najsilniejszym.
Jak stosować: Inwestuj czas w budowę powtarzalnych szablonów, promptów i procesów pracy, a nie tylko w dostęp do najnowszego modelu. Dokumentuj, co działa.
Na co uważać: Nie myl chwilowego zachwytu nad silnym modelem z trwałą przewagą — gdy model zniknie lub podrożeje, zostaje ci tylko proces, który udało ci się zapisać.
2.Zatrzymaj proces, nie inteligencję
Na czym polega: Nie da się „zachować” inteligencji drogiego modelu, ale można wydobyć jego sposób myślenia i przenieść go na tańsze modele.
Jak stosować: Używaj silnego modelu do zaprojektowania sposobu rozwiązania, a następnie spisz ten sposób w formie instrukcji/umiejętności, którą wykonają tańsze modele.
Na co uważać: Przeniesienie procesu wymaga, by był naprawdę jawny i szczegółowy — mgliste „rób to jak Fable” nie zadziała, potrzebne są konkretne kroki i kryteria.
3.Dynamiczne workflowy: orkiestrator silny, wykonawcy tani
Na czym polega: W testach autora silny model orkiestrujący tanie pod-agenty (Sonnet, Haiku) dawał wyniki zbliżone do drogiej konfiguracji, przy koszcie nawet ~3 razy niższym.
Jak stosować: Powierz planowanie i nadzór silnemu modelowi, a wykonanie poszczególnych kroków tańszym pod-agentom, które raportują z powrotem do orkiestratora.
Na co uważać: Oszczędność pojawia się tylko wtedy, gdy plan jest naprawdę dobry — jeśli orkiestrator źle rozpisze zadania, tani wykonawcy powielą błędy. Zawsze porównaj koszt i jakość na własnym zadaniu, zanim uznasz konfigurację za optymalną.
4.Traktuj najsilniejszy model jak nauczyciela
Na czym polega: Zamiast wyciskać z topowego modelu maksymalną robotę, wykorzystaj go do „przeszkolenia” tańszych — niech spakuje swoją wiedzę i przekaże ją dalej.
Jak stosować: Każ silnemu modelowi przeglądać i ulepszać twoje konfiguracje, prompty i umiejętności, a potem opisywać, dlaczego dana wersja jest lepsza.
Na co uważać: To droższy tryb użycia — stosuj go świadomie do tworzenia trwałych aktywów (procesów, skilli), a nie do rutynowej, powtarzalnej pracy.
5.Ucz się z rezultatów, które pokochałeś
Na czym polega: Najlepsze rezultaty modelu można zamienić w wielokrotnie używalną umiejętność, jeśli wstecznie przeanalizujesz, jak powstały.
Jak stosować: Gdy dostaniesz wynik, który ci się podoba, każ modelowi (albo sobie na podstawie sesji) odpowiedzieć: o czym myślałeś, jak do tego doszedłeś, jak udowodniłeś, że działa? Wydobyte odpowiedzi zamień w plik umiejętności.
Na co uważać: Analiza „po fakcie” bywa zmyślona — model potrafi dorobić ładne uzasadnienie do przypadkowego sukcesu. Weryfikuj wnioski, uruchamiając umiejętność na nowych zadaniach.
6.Zbuduj tryb pracy oparty na pięciu bramkach
Na czym polega: Umiejętność „Fable mode” porządkuje pracę modelu w pięć etapów: zakresowanie, dowody, adwersaryjne atakowanie problemu, weryfikacja i raportowanie — dzięki czemu nawet słabszy model działa z dyscypliną silnego.
Jak stosować: Zapisz te bramki jako instalowalny plik umiejętności („napisz kompletny, instalowalny skill, który sprawi, że model będzie działał z twoim osądem i nawykami weryfikacji”) i aktywuj przy trudnych zadaniach.
Na co uważać: Sam plik to nie magia — każda bramka musi mieć realne kryteria (co znaczy „zweryfikowane”, jakie dowody wystarczą). Bez tego etapy staną się pustym rytuałem.
7.Planowanie to adwersaryjne szukanie ryzyk, nie lista kroków
Na czym polega: Prawdziwa wartość etapu planowania nie leży w rozpisaniu kroków, lecz w graniu adwokata diabła: co może pójść nie tak, jakie są niewiadome.
Jak stosować: Na etapie zakresowania wprost proś model o wypisanie ryzyk, założeń i punktów, w których plan może się załamać — dopiero potem projektuj wykonanie.
Na co uważać: Nie zatrzymaj się na samej liście „todo”. Jeśli model tylko rozpisuje kroki, dopytaj o scenariusze awaryjne, zanim uruchomisz kosztowne wykonanie.
8.Dobieraj poziom wysiłku (effort), nie tylko model
Na czym polega: Poza wyborem modelu istnieje wybór poziomu wysiłku. Fable na niskim wysiłku bywa porównywalny z Opus na wysokim, a różne poziomy mają różny koszt i jakość.
Jak stosować: Nie zostawaj przy domyślnym ustawieniu — eksperymentuj z poziomami wysiłku dla swoich typowych zadań i notuj, który daje najlepszy stosunek jakości do kosztu.
Na co uważać: Wyższy wysiłek potrafi zaszkodzić — na „max” model bywa rozwlekły, przekombinowuje i zaczyna się dwoić, dając gorszy efekt niż na „high”. Często „high” to rozsądny sufit.
9.Prowadź tabelę modeli: koszt, inteligencja, gust
Na czym polega: Routing modeli warto sformalizować w tabeli, w której każdy model ma ocenę kosztu, inteligencji i „gustu” (kreatywność, UI/UX), plus wskazówkę, kiedy go użyć.
Jak stosować: Podaj taką tabelę modelowi-orkiestratorowi, by świadomie delegował zadania: recenzję kodu do „inteligentnego”, projektowanie wizualne do „gustownego”, proste zwiady do taniego Haiku.
Na co uważać: Oceny są subiektywne i szybko się starzeją wraz z nowymi modelami — aktualizuj tabelę i dostosuj kategorie do własnego workflow, zamiast kopiować cudze.
10.Posiadasz procesy i lokalne modele, nie chmurowe
Na czym polega: Dostęp do modeli w chmurze bywa czasowy — mogą zostać wycofane lub zmienić warunki. Trwale należą do ciebie tylko twoje procesy, metodologie oraz własny sprzęt i lokalne modele.
Jak stosować: Zapisuj swoje metody w przenośnej formie (pliki umiejętności, prompty, dokumentacja) i rozważ eksperymenty z modelami open source oraz lokalnym uruchamianiem.
Na co uważać: Nie uzależniaj krytycznych procesów od jednego dostawcy ani jednego modelu — projektuj je tak, by dało się je przenieść na inny model, gdy zajdzie potrzeba.