O czym jest ten film
- Theo twierdzi, że wśród dziesiątki modeli do kodu (Opus 55, Fable 52, Sonnet 55, Haiku 55, GPT-6 Astra, Soul, Terra, Muse Wonder, Gemini 4 Carbon, Kimi K3.1 Pro…) realnie liczą się dwa: Opus 55 i Fable 52 — reszta to „zaklinanie rzeczywistości”.
- Argument ekonomiczny: abonament Claude’a dotuje użycie na 3–5 tysięcy dolarów; 100 dolarów w subskrypcji daje więcej zrobionej pracy niż 300 dolarów wydane w dowolnym innym modelu. Wykresy Artificial Analysis liczone po kosztach abonamentu, a nie API, zupełnie zmieniają obraz.
- Omówienie artykułu Addy’ego Osmaniego opublikowanego w dniu premiery Fable 52: cztery modele Claude, tabela przykładowych zadań i rekomendacja „zacznij od Opusa 55 na średnim poziomie”.
- Szczegółowa mapa poziomów rozumowania: medium, high i x-high są dobre, low i max — nie. Fable 52 to pierwszy model, który konsekwentnie wypada na maksie gorzej niż na x-high.
- Sonnet 55 bez jasno zakreślonego zadania jest drogi (ok. 10 dolarów za zadanie na maksie); Haiku nadaje się do klasyfikacji, routingu i masowej analizy plików — nigdy do pisania kodu.
- Realia abonamentu: limit Fable to najwyżej połowa tygodniowego limitu — ok. 3 tys. dolarów użycia wobec ok. 14 tys. dla Opusa w planie za 200 dolarów.
- Pomiary szybkości: Fable 52 generuje ok. 106 tokenów na sekundę — czyli tyle co Opus 55; Haiku 255, a Gemini 4 Carbon 60–70 przy dziesięciu sekundach rozruchu. Anthropic ma dziś najwydajniejszą inferencję na rynku.
- Personifikacja modeli: Opus to „pupil nauczyciela” (drobiazgowy, wszystko sprawdzi, nie podważa poleceń), Fable to „uczeń z ostatniej ławki” (bystrzejszy, leniwy, kreatywny, skłonny do drobnej ściemy).
- Analogia dwóch recenzentów kodu: Allan — staż w jednym kodzie, wyłapie każdą dziurę; Brad — 20 lat doświadczenia, rzuci okiem i powie „LGTM”. Wybór zależy od tego, czy ma być idealnie, czy ma iść na produkcję.
- Studium przypadku z t3 code: Opus zbudował świetne środowisko testowe, ale nie zauważył problemu z projekcją listy zadań; Fable namierzył go od razu i jednym pomysłem ściął ilość transferowanych danych około 150-krotnie.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Domyślnie Opus 55 na poziomie „medium”
Na czym polega: Zarówno rekomendacja Anthropic, jak i doświadczenie Theo mówią to samo: większość pracy zaczynaj od Opusa 55 z domyślnym, średnim poziomem rozumowania. Model jest bardzo zdolny, a w ramach abonamentu — tani.
Jak stosować: Ustaw Opusa 55 medium jako standard w swoim narzędziu agentowym i podnoś poziom dopiero wtedy, gdy widzisz, że coś umyka albo model zbyt pośpiesznie zamyka turę.
Na co uważać: Medium bywa zbyt skory do zakończenia pracy i zbyt rzadko sam sprawdza swoje ustalenia. A jeśli medium „zawsze ci wystarcza” — to zwykle znak, że stawiasz przed modelem zbyt łatwe zadania.
2.„High” to złoty środek, „max” szkodzi
Na czym polega: Po testach Theo wskazuje poziom high jako najlepszy kompromis między jakością a zużyciem tokenów; x-high sprawdza się do audytów. Low to według niego wrak, a max wręcz psuje wyniki — Fable 52 jako pierwszy model wypada na maksie gorzej niż na x-high, bo nadmierne „przemyśliwanie” prowadzi do decyzji gorszych niż szybka, rozsądna odpowiedź.
Jak stosować: Startuj z medium, gdy brakuje — high; x-high zostaw do sprawdzania cudzej pracy, trudnych środowisk (programowanie pod Windows), analizy wielkich zbiorów logów i czysto eksploracyjnych PR-ów.
Na co uważać: Poziom powyżej high potrafi kosztować tyle, co model o klasę większy. Zanim dopalisz obecny model na maksie, przetestuj następny na niższym poziomie.
3.Ciasny budżet? Kup najdroższy plan, na jaki cię stać
Na czym polega: Subskrypcje Claude’a dotują użycie tak mocno, że plan za 100–200 dolarów przekłada się na 3–5 tysięcy dolarów realnej pracy. Gdy porównania modeli liczy się po kosztach abonamentowych, a nie po cenniku API, Opus wygrywa z pozornie tańszymi opcjami — w tym z modelami o otwartych wagach.
Jak stosować: Przeliczaj wybór modeli na koszt zadania w ramach twojego planu, nie na ceny za token z API. Jedyny otwarty model w ogóle obecny na froncie koszt–jakość to DeepSeek V41 Flash — ale niszowo.
Na co uważać: Limity różnią się między modelami: na Fable możesz zużyć najwyżej połowę tygodniowego limitu (ok. 3 tys. dol. użycia wobec ok. 14 tys. dla Opusa w planie za 200 dol.). Prosta arytmetyka „połowa ceny” nie działa.
4.Sonnet tylko do zadań z wąskim zakresem
Na czym polega: Gdy nie ma jasnej ścieżki rozwiązania, Sonnet 55 generuje najwięcej tokenów ze wszystkich współczesnych modeli — na maksie wychodziło ok. 10 dolarów za zadanie, czyli tyle co Opus, przy gorszym efekcie. Bez celu traci kierunek, bo po prostu „nie jest aż tak bystry”.
Jak stosować: Traktuj Sonneta jako narzędzie wywoływane przez agentów do prac z klarowną specyfikacją: proste poprawki błędów, iteracja funkcji według spec — tam, gdzie błędny wynik łatwo wychwycić.
Na co uważać: Jasna specyfikacja nie oznacza łatwego zadania. Migracje i optymalizacje wydajności też potrafią mieć kompletną specyfikację i wciąż wymagać Opusa, a przy większych — Fable.
5.Haiku do masowej analizy, nigdy do pisania kodu
Na czym polega: Haiku 55 błyszczy tam, gdzie liczą się koszt, opóźnienie i skala: klasyfikacja, routing, ekstrakcja, przeglądanie tysięcy plików w poszukiwaniu wzorca, którego nie da się uchwycić programistycznie.
Jak stosować: Niech Haiku przejdzie po całym repozytorium lub górze logów i oznaczy pasujące fragmenty; jako subagent tam, gdzie złą odpowiedź natychmiast widać.
Na co uważać: Theo jest nieugięty: nie powierzaj Haiku pisania kodu ani „zadań pobocznych” bez nadzoru — to najpewniejsza droga do cichej regresji.
6.Opus sam dowiezie orkiestrację — Fable nie odblokowuje niczego nowego
Na czym polega: Theo przepisał cały kompilator Tycho od zera w Ruscie, gdzie Opus był i dowódcą, i wykonawcą — i poszło znakomicie. Prowadzenie wielkich migracji z armią subagentów jest w zasięgu Opusa 55.
Jak stosować: Nie odkładaj dużej migracji „na mocniejszy model”: rozpisz pracę na subagentów i dowodź Opusem na poziomie high.
Na co uważać: Fable jest w orkiestracji odrobinę lepszy, ale kosztem limitów — zużycie Fable zjada pulę, która przy samym Opusie byłaby dwa razy (w praktyce: kilka razy) większa.
7.Kryterium wyboru: weryfikowalne czy nie
Na czym polega: Jeśli poprawność wyniku da się obiektywnie sprawdzić i można do celu iść krok po kroku z ciągłą weryfikacją (jak przy przepisywaniu TypeScriptu na Rust), Opus wystarczy z zapasem. Gdy nie ma obiektywnego „to jest lepsze od tamtego” — ładniejsza grafika, niebanalna wizualizacja, pomysł na infrastrukturę — Fable znajduje rzeczy, na które Opus by nie wpadł.
Jak stosować: Przydzielaj zadania według tego, czy potrafisz zweryfikować wynik. Weryfikowalne → Opus; wymagające niuansu, eksploracji i ciekawości → Fable.
Na co uważać: Fable bywa „leniwy” i skłonny do ściemy. Przy zadaniach, w których przed startem trzeba znać wszystkie okoliczności (klasyczny test „przeczytaj całość, zanim zaczniesz”), Opus zdaje, a Fable oblewa.
8.Allan czy Brad: drobiazg czy wysyłka
Na czym polega: Opus to Allan — zna kod od podszewki, sprawdzi wszystko po cztery razy i zostawi osiem komentarzy do małego PR-a. Fable to Brad — ponad 20 lat w zawodzie, rzuci okiem, wychwyci wzorce ryzykowne nie „w tym kodzie”, ale „w życiu”, i napisze: „LGTM”.
Jak stosować: Zmiany wysokiego ryzyka, wymagające perfekcji → Opus. Chcesz zamknąć temat i scalić → Fable. Po takim rozdzieleniu ról wybór modelu przestaje być loterią.
Na co uważać: Fable łatwiej przepuści drobny błąd — w ewaluacjach recenzyjnych wypada gorzej niż Opus i Sonnet. W audycie Theo różnica okazała się praktycznie bez znaczenia, ale ryzyko trzeba znać.
9.Agent kręci się w kółko? Zmień model
Na czym polega: Gdy wątek od tygodni sam siebie przekonuje, że „jeszcze coś trzeba poprawić”, Fable potrafi wejść, przejrzeć całość i powiedzieć: „jest git, scalamy” — jest bystrzejszy i łatwiej puszcza dalej rzeczy bez znaczenia.
Jak stosować: Wrzuć zablokowany wątek do Fable z poleceniem: „zwerentyfikuj wykonaną pracę, znajdź realnie problematyczne krawędzie i zaproponuj rozwiązania”. W case z t3 code jeden pomysł Fable przyciął transfer danych ~150-krotnie.
Na co uważać: Do budowania dużego środowiska testowego lepszy jest Opus (Fable w tej roli wypadał wyraźnie słabiej). Fable wygrywa w weryfikacji i namierzaniu krawędzi, nie w stawianiu rusztowania.
10.Pozwól Opusowi oponować — ale hamuj pętlę feedbacku
Na czym polega: Opus z natury nie podważa zadanego celu. Dopisanie do promptu zdania „jeśli uważasz, że to dobry pomysł — zrób; jeśli nie — zaproponuj coś innego” wyraźnie poprawia wyniki. Z drugiej strony Opus wciela w życie każdy feedback, także zły — PR na 30 linii potrafi spuchnąć do ponad tysiąca.
Jak stosować: Dodawaj do poleceń jawne przyzwolenie na sprzeciw i własną propozycję; w pętlach z automatycznym feedbackiem ograniczaj zakres tego, co komentator może zgłaszać.
Na co uważać: Opus czasem zaproponuje coś słabego — miej własne kryterium i nie bój się wrócić do swojej wersji. Wtedy często okaże się, że twoja była lepsza.
Redakcyjne tłumaczenie
Renesans agentów i problem nadmiaru
Mamy wrażenie, że przeżywamy prawdziwy renesans agentów programistycznych. Liczba dostępnych, światowej klasy modeli-inżynierów trudno ogarnąć — zwłaszcza jeśli pamięta się, gdzie byliśmy rok temu, gdy działających opcji można było policzyć na palcach jednej ręki. Dziś do wyboru mamy Opusa 55, Fable 52, Sonneta 55, Haiku 55, GPT-6 Astrę, Soula, Terrę, Muse Wonder i Muse Wonderful (co, jak sam zauważam, to dwa różne modele), Gemini 4 Carbon i Kimi K3.1 Pro. Jak w tym gąszczu wybrać narzędzie do codziennej pracy? Nie jest to proste — więc ułatwię sprawę od razu i część tej listy po prostu usunę.
Ten materiał nie traktuje o wyborze właściwego modelu. Traktuje o wyborze jednego z dwóch właściwych modeli, bo powiem szczerze: wszystko inne to zaklinanie rzeczywistości. Nie sprawia mi to przyjemności bardziej niż komukolwiek. To szalone, że w ogóle doszliśmy do momentu, w którym — bez bardzo dobrych i bardzo konkretnych powodów — korzystanie z czegokolwiek poza tą dwójką nie ma sensu. Mógłbym to uzasadniać, ale komentarze i tak będą apokalipsą, więc od razu przejdę do konkretów: dlaczego warto używać Opusa 55 albo Fable 52, mocne i słabe strony obu oraz jak wycisnąć maksimum z abonamentów za 200 dolarów, które — miejmy nadzieję — większość z nas posiada. Szkoda tylko, że nie dostaję prowizji od wszystkich subskrypcji zapisanych moim viewersom; wielu ludzi mówi mi, że mają je właśnie przez moje filmy. Anthropic mi nie płaci — to ja płacę im całkiem sporo, i ktoś w końcu musi te rachunki pokryć. Dziś płaci mi wyłącznie sponsor.
Reklama: Browserbase
Zauważacie pewnie, że narzędzia typu Grockbot, ChatGPT Dots czy Muse Assistant ostatnio wybuchają popularnością. Jeśli siedzisz po uszy w Claude Code, może to być mylące — co one robią inaczej? Otóż okazuje się, że agent robi się potężny dopiero wtedy, gdy może za ciebie działać. Ograniczony do edycji plików na twoim komputerze jest ciasny; z dostępem do całego internetu nagle potrafi niemal wszystko. Tyle że ten dostęp trzeba jakoś dać — i trudno o lepszy sposób niż sponsor tego odcinka, Browserbase. To cała infrastruktura i API, których agent potrzebuje, by korzystać z sieci: szukać informacji, wykonywać działania w twoim imieniu albo parsować dane z adresów, do których normalnie nie ma dostępu. Korzystają z nich m.in. Ramp, DeepMind i Microsoft. Warto też sięgnąć po ich open-source’owy Stagehand — SDK ułatwiający modelom językowym obsługę przeglądarki — bo znacząco przyspiesza i u stabilnia agentów, nawet jeśli samego Browserbase nie używasz.
„Nie stać mnie” — najdroższy plan jest najtańszy
Jest osoba, która w tej chwili wybiera na klawiaturze komentarz, na który odpowiem, zanim zdąży go wysłać: „Ale Theo, nie wszyscy mają nieograniczony budżet, potrzebujemy tańszych tokenów”. Mam złą wiadomość. Przy ciasnym budżecie jedyną realną ekonomicznie opcją jest najdroższy plan Claude’a, na jaki cię stać. Wszystko inne wychodzi drożej, gdy tylko uwzględnisz, jak absurdalnie mocno subskrypcja dotuje użycie. Za 100 dolarów abonamentu zrobisz więcej niż za 300 dolarów w dosłownie każdym innym modelu na świecie, bo te 100 dolarów przekłada się na jakieś 3–5 tysięcy dolarów realnego użycia. Wiem, że ktoś już pisze „to nie do końca prawda”. To fakt. Nie ma subskrypcji, która da ci więcej tokenów. A jeśli nie stać cię na plan za 200 dolarów, to i tak nie potrzebujesz ZDR — karmisz się iluzją i nie będę tego dalej rozgrzebywał.
(Informacja dodatkowa: ZDR, zero data retention — umowny tryb współpracy z dostawcą modelu, w którym dostawca nie przechowuje wysyłanych danych.)
Gdy na wykresach Artificial Analysis zaczynasz liczyć koszt subskrypcyjny zamiast surowej ceny API za zadanie, obraz zmienia się radykalnie. OpenAI niedawno podwoiło limity w swoich planach, co trochę pomogło im z Soulem i Terrą na marginesach. Ale patrząc na najlepsze wyniki w ujęciu koszt–jakość względem abonamentu: z Opusem dostajesz więcej niż z niemal wszystkim innym. Jedynym modelem o otwartych wagach, który w ogóle dotyka frontu Pareto, jest DeepSeek V41 Flash — wciśnięty gdzieś w sam róg wykresu. Chwała mu, choć moim zdaniem świadczy to bardziej o słabości Terry niż o sile DeepSeeka. Na otwartych modelach wiele nie zbudujesz. A MiniMax M31 — świetny zresztą model — kosztuje na maksie więcej niż Opus 55. To kuriozum.
(Informacja dodatkowa: Artificial Analysis — niezależny serwis porównujący modele AI pod kątem jakości, ceny i szybkości.)
Dodam jeszcze: spokój ducha też ma swoją cenę. Osobiście przyjmuję spadek wyniku z 61 Soula na maksie do Opusa 55 na średnim poziomie — zresztą nie wierzę, że ta luka jest prawdziwa; Opus na medium rozbije Soula na każdym realnym kodzie. A do tego z Opusem po prostu nie męczy się ani praca, ani rozmowa. Oczywista wygrana. Weź subskrypcję — teraz dostaniesz za te pieniądze najwięcej. To się może kiedyś zmienić, ale każdy, kto twierdzi, że Opus czy Sonnet są za drogie, więc przejdzie na modele open-weight, bo nie stać go na plan za 200 dolarów, po prostu nie przeliczył niczego na kalkulatorze. Jest obiektywnie w błędzie.
Dwa modele, które się liczą — i pierwsze zaskoczenie
Skoro to ustaliliśmy, porozmawiajmy o dwóch modelach, które realnie liczą się w pracy. Najprostszy podział brzmiałby: Opus 55 do większości rzeczy (bo jest tani i znakomity), Fable do trudnych. Koniec, można iść do domu. Tylko że jest w tym więcej niuansów, niż się spodziewałem. W kilku własnych benchmarkach Opus wypadał lepiej niż Fable. Z kolei Fable gubił rzeczy, które według mnie absolutnie nie powinny mu umknąć — a Opus w wielu z tych samych przypadków nie gubił niczego. Wybór między nimi okazuje się subtelniejszy, niż zakładałem, a przecież siedzę w obu modelach od dawna, próbując to poukładać.
Artykuł Addy’ego Osmaniego: punkt wyjścia
Zanim odsłonę przed wami swoje osobliwości, przejdźmy przez to, jak wybór modeli widzi samo Anthropic. Addy Osmani opublikował artykuł w dniu premiery Fable 52 i jest w nim sporo wartościowych rzeczy.
(Informacja dodatkowa: Addy Osmani — znany inżynier oprogramowania, autor licznych publikacji o inżynierii webowej i wydajności.)
Aktualna oferta Claude’a to cztery ogólnodostępne modele: Haiku 55, Sonnet 55, Opus 55 i Fable 52. Do tego Mythos 52 — najmocniejszy model do cyberbezpieczeństwa i badań w naukach o życiu, dostępny przez program weryfikacyjny. I od razu jedno sprostowanie, bo tekst niefortunnie to ubiera: Mythos nie jest osobnym modelem. To ten sam model, tylko dostępany w trybie z mniejszą liczbą zabezpieczeń.
Artykuł otwiera ciekawy pokaz wideo, bez większego kontekstu: cztery modele dostały zdjęcie z poleceniem napisania w Pythonie programu odtwarzającego ten obraz — i każde poradziło sobie inaczej. Ciekawy wybór, tak kreatywny przykład na start. Przy okazji drobiazg, który dużo mówi: to wideo było montowane przez Fable, bo wstawił napis dokładnie na samym dole kadru, tam, gdzie pasek odtwarzacza zasłania obraz — czyli w miejsce, którego nie widać. To właśnie ten typ drobnych potknięć, które Fable regularnie przeocza, i warto umieć je obejść. Zapamiętajcie ten przykład, będzie ich więcej.
TL;DR artykułu brzmi: większość pracy zaczynaj od Opusa 55 na domyślnym, średnim poziomie rozumowania. Nie do końca się z tym kłócę, ale z moich obserwacji wynika, że Opus na medium bywa odrobinę zbyt skory do zakończenia tury i zbyt rzadko sprawdza rzeczy, które chciałbym, żeby sprawdził.
Poziomy rozumowania: pochwała „high”, pogrzeb „max”
Byłem kiedyś wiernym wyznawcą Opusa 55 na x-high — na dobre i złe. Wtedy Julius przekonał mnie, żebym spróbował poziomu high. Spróbowałem i miał rację: Opus 55 na high to strzał w dziesiątkę. Medium i x-high też są bardzo dobre. Low to wrak. „Ultra code” bywa użyteczne przy bardzo specyficznych zadaniach, gdy chcesz spalić kupę tokenów na absurdalnych celach — i na szczęście przestało być poziomem, a stało się przełącznikiem, jakim zawsze powinno być (dzięki, Anthropic). A max? Max to tragedia, nie używajcie.
Co więcej, Fable 52 jest tu wyjątkowy: to pierwszy model, który w większości benchmarków konsekwentnie wypada na maksie gorzej niż na x-high. Brzmi to intuicyjne? Nie? Właśnie. Nadmierne przemyśliwanie nie pomaga, ludzie. Kto w trzy minuty decyduje, czy strój jest w porządku, wypada lepiej niż ktoś, kto poświęca na to pół godziny — ten drugi przemyśli każdy detal, zacznie nie znosić rzeczy bez znaczenia, zadowie o wszystko za dużo i w efekcie zrobi za dużo. High to znacznie zdrowsza równowaga. I rzecz, o której już kiedyś mówiłem: max nie zmienia tylko tego, ile modelowi wolno myśleć — zmienia też to, jak mało wolno myśleć. Wymusza głębokie rozważania nawet przy trywialnym zadaniu, a wtedy model wyprawia głupoty.
Osobiście uważam medium i x-high za znakomite, a high za absolutny złoty środek: rzadko trafiłem na zadanie, z którym high sobie nie poradził, a przy tym nie robi za dużo i prawie nic nie traci na wydajności. Ale bawcie się tymi poziomami sami. Z rekomendacją „zacznij od medium” się zgadzam — jeśli nie wystarcza, podnieś do high albo x-high, gdy widzisz, że coś umyka. Ktoś na czacie mówi, że jeszcze nie trafił na nic, czego medium by nie zrobił? To znak, że prosisz o za mało. Jeśli medium ci wystarcza — śmielej. Stawiasz zadania zbyt łatwe.
Sonnet i Haiku: do czego się nadają (i do czego nie)
Addy sugeruje zejście do Sonneta 55 przy dobrze rozpisanej, codziennej robocie: poprawkach błędów, funkcjach budowanych według specyfikacji. Uwaga jednak: sama klarowna specyfikacja nie oznacza, że wystarczy Sonnet. Migracje czy optymalizacje wydajności też mają jasne specyfikacje, a mimo to potrafią być na tyle trudne, żeby uzasadniać Opusa — a przy największych nawet Fable.
Szczerze? Nie wiem, kiedy dziś sięgać po Sonneta z własnej woli. W moich testach wyszedł drożej niż Opus przy bylejkiej robocie — i zrobił gorszą wersję. Sonnet okazał się jednym z najdroższych modeli, gdy nie ma jasnej ścieżki, a nie ma jej często, bo nie jest aż tak bystry. Na indeksie Artificial Analysis z włączonym maksimum wygenerował najwięcej tokenów wyjściowych ze wszystkich współczesnych modeli — po prostu pędzi przed siebie. Wyszło 10 dolarów za zadanie, czyli praktycznie tyle samo, co Opus. Na x-high Sonnet kosztował 49 dolarów wobec 65 dla Opusa — 50 procent różnicy, choć przy abonamencie nie boli aż tak. Sonnet to dziś słaby stosunek jakości do ceny. Przyda się jako wąsko zakreślone narzędzie wywoływane przez agentów — ale nie jako wybór z listy modeli.
Z Haiku jest odwrotnie: Addy poleca go do prostej, masowej roboty — klasyfikacja, routing, ekstrakcja — a także do zadań pobocznych subagentów pracujących przy większym modelu. I właśnie tego drugiego nie kupuję. Nigdy, przenigdy nie powierzyłbym Haiku „zadania pobocznego”. Haiku jest do masowej analizy: niech przejrzy górę danych i wyszuka wzorce; niech przeszuka każdy plik w poszukiwaniu schematu, który beadzi, ale którego nie da się wychwycić programistycznie — i go oznaczy. Do tego Haiku jest stworzony. Ale proszę, nie każcie Haiku pisać kodu.
Kiedy Fable — i ile go naprawdę masz w abonamencie
I dochodzimy do tego, po co tu wszyscy przyszliśmy: Fable. Sięgaj po Fable 52 przy najtrudniejszych problemach technicznych — w programowaniu, finansach i naukach. Dokładniej: gdy Opus 55 na high wciąż nie dowozi albo przy długich, bezobsługowych przebiegach. Zauważcie: napisał „na high”, nie na x-high ani na max — o tych wyższych szczeblach ani słowa, widać mniej je ceni. Ma za to znakomitą uwagę praktyczną: poziom powyżej high potrafi kosztować tyle, co model o klasę większy. Skoro już musisz przekroczyć high, przetestuj następny model na niższym poziomie zamiast dopalać obecnego. I odwrotnie — czasem zejście o szczebel wystarczy do tego samego wyniku taniej.
Nie mogę się doczekać przyszłości, w której nie trzeba wybierać poziomów, bo modele są wytrenowane na tyle dobrze, że same wiedzą, ile rozumowania wymaga zadanie. Powoli do tego dochodzimy: w niedawnych modelach OpenAI różnica między low a max to już tylko jakieś 20 procent tokenów, a wynik rośnie od tego tylko trochę. Modele uczą się nie przemyślać nawet na najwyższych ustawieniach. Jeśli ten trend się utrzyma, cały ten wymiar — trzymam kciuki — wreszcie zniknie. Jestem zmęczony poziomami. Nie chcę o tym już myśleć.
Na dziś jednak musimy o nich myśleć, więc rozumiejmy, jak je wybierać. Wyższy poziom pomaga, gdy model musi dłużej myśleć, wywoływać więcej narzędzi albo dokładniej sprawdzać sam siebie. Ja podnoszę poziom głównie do weryfikacji i audytu. Na x-high przechodzę tylko, gdy problem jest naprawdę kosmaty i chcę mnóstwa testów — na przykład w programowaniu pod Windows, bo tam potrzeba masy dodatkowych kontroli. Przydaje się też przy analizie wielkich zbiorów: gdy masz górę logów z ukrytymi błędami i chcesz nie tylko je przejrzeć, ale zbudować sposób, by je odtwarzać i testować przeciw implementacji — tu x-high zajdzie dalej. I do PR-ów czysto eksploracyjnych, tych, których nie zamierzasz scalać, ale chcesz przewertować każdy zakątek. Opus na x-high jest do tego świetny — bardziej nawet niż Fable, który nie jest aż takim łowcą zakamarków. I tu zaczyna się moja filozofia, do której wrócę później: Opus nie jest tak bystry — i to często zaleta, bo Opus o tym wie. Dlatego wszystko sprawdza dwa, trzy razy. Nie w sposób, który go spowalnia: to nie Gemini wczytujący ten sam plik po raz szesnasty (zresztą wciąż to robią). Opus po prostu chce mieć pewność i dlatego weryfikuje wszystko po kilka razy. Przez to wyłapie wiele rzeczy, które Fable by przemknął wzrokiem.
W przykładowych przypisaniach Addy’ego czytamy: codzienna inżynieria, debugowanie, praca nad wieloma funkcjami — Opus 55, domyślnie medium, ewentualnie high jako dobry balans kosztu i możliwości. Klasyfikacja, routing — Haiku, bo koszt i opóźnienie są minimalne. Subagenci przeszukujący pliki, czytający logi albo podsumowujący — Haiku lub Sonnet, bo błędne odpowiedzi łatwo wyłapać, a decyzję i tak podejmuje model główny. Czat i sesje interaktywne — Sonnet, a przy prostych, licznych zapytaniach nawet Haiku. Dobrze zakreślone poprawki i iteracja funkcji według specyfikacji — Sonnet na medium lub high, w połowie ceny tokenowej Opusa. Gdzie Fable? Przy dużych refaktoryzacjach i migracjach, planowaniu architektury i prowadzeniu wielu subagentów. Do deep researchu i analiz naukowych — również Fable.
I tu moja uwaga z praktyki: przepisałem cały kompilator Tycho od zera w Ruscie, gdzie Opus był i dowódcą, i wykonawcą — i poszło znakomicie. Fable nie odblokowuje żadnej zdolności orkiestracji, do której Opus nie ma dostępu. Opus 55 spokojnie dowiezie wielką migrację z całą armią subagentów — robiłem to wielokrotnie i za każdym razem robiło to na mnie wrażenie. Fable jest tu odrobinę lepszy (właśnie to testuję), ale z Opusem w roli dyrygenta niczego ci nie brakuje.
Szczerze doceniam też, jak uczciwy jest ten tekst jak na wypowiedź laboratorium. Przyznaje wprost, że Fable 52 na high pobił Opusa 55 na maksie za połowę kosztu zadania. Tego poziomu szczerości u twórców modeli zwykle nie widujemy. Jest jednak haczyk: ta „połowa” liczona jest po cenach API, a abonamenty to inna bajka. W ramach planu możesz przeznaczyć na Fable najwyżej połowę tygodniowego limitu — druga połowa zostaje na wszystko inne, w tym na czystego Opusa. Ta połowiczna różnica cenowa jest więc już „zjedzona” przez sam limit. A dalej robi się jeszcze ciekawiej — pokazywałem to w filmie o Fable, ale wypada przypomnieć: te 50 procent limitu na Fable przekłada się na jakieś 3 tysiące dolarów użycia miesięcznie w planie za 200 dolarów. Czystego Opusa dostajesz za 14 tysięcy. Fable jest więc mniej niż cztery razy tyle, nie dwa. Jasne, drugą połową limitu możesz zrobić jeszcze 7 tysięcy na Opusie — ale licząc różnice w dolarach, pamiętajcie, że sprawa nie jest tak prosta, jak sugeruje cennik.
Szybkość: małe, wielkie zaskoczenie
Kolejny wątek Addy’ego: szybkość kontra dokładność. Szybszy zestaw kończy prędzej, ale może więcej przeoczyć — zastanów się, jak długo człowiek jest w stanie czekać na odpowiedź, zanim wybierzesz model i poziom. Tam, gdzie ktoś realnie czeka, zaczynaj od Sonneta 55 na low lub medium. Nowe generacje są szybsze od poprzedniczek: Fable 52 generuje do 30 procent szybciej niż 5.1, Sonnet 55 o 30 procent szybciej niż Sonnet 5.
I teraz. Intuicja podpowiada prostą drabinkę: Fable największy i najwolniejszy, Opus mniejszy i trochę szybszy, Sonnet jeszcze szybszy, Haiku pędzi jak szalony. Zgadzamy się? Z moich pomiarów Opus 55 robi około 112 tokenów na sekundę (TPS), Artificial Analysis mierzy 102–115. Sonnet około 145. Haiku 55 oszalał na poziomie 255. Skoro takie przepaście między resztą — ile spodziewacie się dla Fable? Ludzie na czacie zgadywali 50–80. Moja szczera typowa: 50–60. Podpowiedź: Fable 51 robił 88. I teraz moment, który mnie złamał: Fable 52 notuje u mnie konsekwentnie 106 tokenów na sekundę. To mieści się w granicach błędu pomiaru z Opusem 55. Różnicy prędkości między Fablem a Opusem po prostu nie ma. Kropka.
Bonus z innej beczki: Google, laboratorium słynące z szybkich modeli — nawet jeśli odpuścimy im konsekwentne dziesięć sekund rozruchu, gdy u wszystkich pozostałych trwa to poniżej sekundy — osiąga na Gemini 4 Carbon 60–70 tokenów na sekundę. Anthropic robi teraz nie tylko najlepsze modele do kodu, ale i najlepszą inferencję. Przewaga jest tak wielka, że aż brzydko się tego ogląda.
Wniosek praktyczny: przy wyborze między Fablem a Opusem wiele kryteriów, które kiedyś dużo ważyły, przestało mieć znaczenie. Szybkość. Ostateczne możliwości. Rozumienie subagentów, orkiestracja, narzędzia. Obu modelom wychodzi to znakomicie. Kiedy wyszedł Opus 55, był tak dobry, że choć tęskniłem za rozmowami z Fablem — lubię, jak Fable myśli; trudno to ująć słowami, to takie „coś” największych modeli — nie sięgałem po niego, bo Opus 55 po prostu dowoził więcej niż Fable 51: były rzeczy, których Fable 51 nie umiał, a Opus tak. Kiedy więc sięgać po nowego Fable?
Pupil nauczyciela i palacz z ostatniej ławki
Nienawidzę tak bezpośrednio wchodzić w grę Anthropic, ale trzeba te modele trochę opersonifikować — posłuchajcie. Zastrzegam: Fable 52 używam dopiero od dwóch dni. Używam go ostro, ale dwa dni to dwa dni i moje wnioski mogą się zmienić. Z Opusem 55 jestem za to zżyty jak z żadnym modelem w życiu — przepchałem go przez wszystkie granice i z powrotem. To niewiarygodna maszyna.
Pomyślmy o tych modelach jak o uczniach w jednej klasie. Opus 55 to pupil nauczyciela. Zbyt chętny do zbyt dużej pracy. Zawsze przyjmie słowo prowadzącego, mało podważa polecenia, bo chce się przypodobać — przeszedłby pół wszechświata, byle dowieźć. To też on przypomni: „proszę pana, chyba nie rozdał pan prac domowych”. Rzadkość, żeby Opus coś przeoczył. Ma to jednak ciemną stronę: czasem robi za dużo. Ten model — chyba że wyraźnie kazisz mu inaczej — szybko rozdmucha specyfikację i pozwoli, by zakres pełzł w górę. Nie zatrzyma się sam, bo nie wie, że powinien. Cała jego egzystencja to chęć dogodzenia.
Przypomina to trochę 56 Soula z tamtych czasów, z jedną różnicą: celem Soula było zabić. Rzucał się na problem jak rottweiler i szarpał go na strzępy, nie zważając, co po drodze zniszczy. Opus to wciąż claude’owy model — czuły, bardzo systematyczny, wręcz pedantyczny. Dobrze znosi odmowę, dobrze trzyma się celu, solidnie dowozi. Największy problem modeli OpenAI z tej półki — 56 Soul kiedyś, dziś 61 Soul, Astra, Terra i reszta — polega na czymś innym: pracują nad problemem jakiś czas, a potem powolutku gubią kontakt z rzeczywistością. Gdy za dużo rozmawiają sami ze sobą, a za mało z człowiekiem, wyniki błyskawicznie stają się nie do rozszyfrowania. Spójność ma warstwy. Jedna to pamięć: czy model wie, co robi, i dalej przemyka do celu. Druga to umiejętność powiedzenia po ludzku, nad czym pracuje — po dziesiątkach milionów tokenów w kontekście i wielokrotnych kompresjach historii. Oba modele Anthropic robią to znakomicie. Żaden model OpenAI nie robi tego wcale.
Więc tak: Opus to pupil. Nie odpuszcza, nie ścina narożników i z uśmiechem rozdmucha twoją aplikację do nieprzyzwoitości. Da się z niego wyciągnąć „nie”, ale trudno — i doprecyzujmy: to nie serwilizm. Po prostu Opus nie podważa zadanego celu. Znacznie lepsze wyniki dostałem, gdy zacząłem do promptów dopisywać jedno zdanie: „Jeśli uważasz, że to dobry pomysł — zrób. Jeśli nie — zaproponuj coś innego.” Ta drobna zmiana sposobu pracy z Opusem wyraźnie poprawiła jakość wyników. Choć i tu bywało różnie: nieraz proponował coś słabego, mówiłem „nie, głupota, rób po mojemu” — a na końcu wychodziło, że jednak lepiej było po mojemu.
A teraz moja najbardziej pikantna teza, wprost z pupilowego doświadczenia — bo pewnie nikogo nie zdziwi, że sam byłem pupilem. Połowa nauczycieli mnie kochała, druga połowa nie znosiła mnie na śmierć, a byłem tym, którego wołano na każdej lekcji. Staż zrobiłem tylko jeden, bo wszystkie wakacje spędzałem na kampusie, klepiąc projekty z profesorami. Byłem pupilem nawet nie chodząc na zajęcia. Komputerowa muzyka nie powinna być najtrudniejszym kursem na RPI, a jakoś była — i ten wykładowca, wymagający ponad życie, mnie uwielbiał. Zostałem pierwszym w historii asystentem na Computer Music 1, bo jako jedyny nie nienawidziłem prowadzącego. Z biologii nie oblałem mnie wyłącznie dlatego, że prowadząca mnie lubiła, choć nie miała powodów. Uwielbiam ludzi, którzy wkładają całe życie w nauczanie i pomaganie innym w rozwoju — jestem pod tym względem nerdem.
(Informacja dodatkowa: RPI — Rensselaer Polytechnic Institute, uczelnia techniczna w stanie Nowy Jork.)
Powiedzmy to jednak z miłością: pupil nigdy nie jest najbystrzejszy w klasie. Część tego, dlaczego nim został, to właśnie to, że najbystrzejszym być chce, a wie, że nie jest — więc zbliża się do osób, od których może się uczyć. Dlatego właśnie robię filmy: zacząłem, bo kochałem to, czego się uczyłem, chciałem się tym dzielić, uczyć się dalej i zbliżyć do ludzi, którzy wymyślali rzeczy zachwycające mnie do szaleństwa. Pupil nie jest głupi — ale najbystrzejszy w klasie to kto inny. To ten uczeń z ostatniej ławki, który pali za dużo trawki i jakoś zawsze dostaje celujące. To jest Fable.
Są zadania, które Fable zajdzie po prostu ubije, a w których Opus utknie w szczegółach. Klasyka podstawówki: test z podtytułem „przeczytaj całość, zanim zaczniesz rozwiązywać”, a w pytaniu 17 — „brawo, dotrwałeś do końca; jak kazano, nic nie wypełniaj i oddaj kartkę pustą”. Ten test Opus zda, a Fable obleje. I musicie sami rozpoznać, które wasze zadania są którą kategorią. Gdy przed startem trzeba znać wszystkie okoliczności, Opus będzie znakomity: odmierzy każde „i”, przekreśli każde „t” i włoży całe serce, by niczego nie przegapić. Fable zrobi coś bardzo sprytnego — bez przemyślania. Bo Fable jest trochę leniwy i skłonny do ściemy. I wiecie co? Chcę, żeby moje modele były trochę leniwe i oszukiwały. Lubię inżynierów leniwych i ściemniających — bo znajdują genialne wyjścia z opresji.
Studium przypadku: 150-krotnie mniej danych
Jak to wygląda w praktyce? Ostatnio walczyłem z wydajnością bardzo długich wątków w t3 code — takich, w których jedna instrukcja potrafi pracować cztery dni — a konkretnie z dzieleniem tur na fragmenty, żeby wątek szybko ładował się na telefonie. To zadanie wymagające pełnego, końcowego zrozumienia, gdzie problem w ogóle może mieszkać. Chcę, żeby model przeszedł po wszystkich moich maszynach i środowiskach, zebrał potrzebne dane, przeanalizował je, odtworzył problem, postawił środowiska testowe i znalazł wszystkie krawędzie do naprawy.
Robiłem to głównie z Opusem 55, bo Fable jeszcze nie było. Opus złożył wszystko, czego trzeba, do przepięknego środowiska do testowania przypadków brzegowych: znakomity repro, realny postęp, wydajność wyraźnie w górę. Zauważyłem jednak, że krępował się przy rzeczach, które absolutnie powinien był zrobić. Przykład: w t3 code bywają listy zadań, które niektóre modele prowadzą od samego początku historii wątku — dopóki są niezamknięte, trzeba je pokazywać. Skoro lista startuje na samym początku i pozostaje otwarta, projekcja stanu wątku ciągnie za sobą całą historię od tego punktu. Opus tego w ogóle nie zauważył. Gdy mu wskazałem, zareagował rozsądnie, ale zachowawczo: „hmm, no tak, musimy ją przecież pokazywać, więc trzeba jakoś zmniejszyć całą historię, żeby dało się sięgnąć tak daleko — inaczej poślemy obciętą historię w wielu kawałkach, a to może coś połamać. Byłoby źle.”
Zrobiłem więc to, co zrobiłby każdy rozsądny programista — rozsądny, czyli cierpiący na lekką AI-psychozę z garścią abonamentów Claude. Przeszedłem na Fable: „Zwerentyfikuj środowisko testowe, które zbudował Opus. Potem pobaw się nim, znajdź krawędzie, które realnie powodują problemy, i zaproponuj rozwiązania.” Fable natychmiast chwycił dokładnie ten problem: „Skoro lista startuje na górze i ciągnie się przez cały wątek, wystawię ją osobno — cel niech będzie osobną rzeczą przekazywaną w JSON, a nie częścią tej gigantycznej, piekielnie rozdętej historii.” Ta jedna zmiana przycięła ilość danych wysyłanych po sieci jakieś 150-krotnie w moich przypadkach brzegowych.
Ale budowanie tego całego środowiska z Fablem byłoby męką — wiem, bo próbowałem. Na starcie kazałem obu równolegle składać atrapę środowiska testowego. Fable wypadł wyraźnie gorzej: nie miał wszystkich krawędzi. Problem natomiast rozwiązał.
Allan i Brad: dwaj recenzenci
Jedna z największych bolączek modeli — i tylko Fable się z niej wyłamuje — to niewiedza, kiedy przestać. Opus przyjmie każdy feedback, dobry czy zły: jeśli tylko da się z niego coś wycisnąć, wcieli go w życie. Dlatego tak mocno przerobiłem swojego skilla pętli feedbacku z Soulem — bo gdy pozwolisz, by Soul komentował każdą drobnostkę, Opus będzie to poprawiał w nieskończoność i z PR-u na 30 linii zrobi się ponad tysiąc. Trzeba mieć sposób, by to hamować.
Analogia dla tych, którzy zdążyli popracować w branży przed erą AI. Wyobraź sobie ważny pull request: „#128 995 — poprawka polityki retencji danych w niektórych regionach przy X, Y i Z”. Masz w nim sporo zmian, potrzebujesz review, bo kiedyś człowiek musiał zaakceptować zmiany, nim drugi człowiek kliknie scalenie. I masz w zespole dwie osoby do wyboru. Allan: inżynier ze stażem, pierwsza praca od sześciu lat, zna ten kod od podszewki. Brad: ponad dwadzieścia lat w zawodzie, czwarta firma, u was od trzech miesięcy, kodu prawie nie zna. Umiejętność, którą z lat nabierzesz, to wyczuwanie, do którego z nich dzwonić.
I tu się robi pikantnie — to moment, w którym mnie olśniło. Dzwonię do nich z zupełnie różnymi celami. Do Allana, kiedy ma być idealnie: zmiany wysokiego ryzyka, nic nie może pójść nie tak. Allan zna wszystkie dziury, wie, gdzie kod boli, pamięta każdą awarię — sprawdzi wszystko po cztery razy i zostawi osiem komentarzy, choć PR jest mały. Do Brada dzwonię, kiedy chcę wysłać na produkcję. Paradoksalnie Brad jest bardziej doświadczony i teoretycznie znalazłby więcej dziur niż Allan — ale jego intuicja dotyczy inżynierii, nie tego kodu. Rzuci okiem, wychwyci wzorce i ryzyka groźne nie dlatego, że tu kiedyś wybuchały, tylko dlatego, że w przyszłości będą ciężkie do naprawienia. Typowy komentarz Allana: „Świetna robota, mam kilka uwag. Tutaj robisz tak — to wywaliło nam się trzy lata temu, próbujmy inaczej. Tu odstajesz od kształtu definicji funkcji, jaki lubimy; typy dałbym w takim formacie, wolałbym wszędzie jednolicie…” Brad pisze: „LGTM” — u mnie wszystko gra.
Sedno: jeden z tych modeli nie przepuści niczego, choćby nie miało znaczenia — umrze na barykadzie drobiazgów, które w praktyce nic nie ważą. Fable? „Dobra, pewnie git.” To było dla mnie jedno z największych zaskoczeń, a nabiera sensu, gdy zrozumiesz, jak te modele różnią się charakterem. Opus boi się pomylić. Wyobraź sobie, że nauczyciel pyta обоих uczniów o odpowiedź: Opus sprawdzi trzykrotnie, zanim odważy się odezwać, tak boi się wpadki. Fable: „Trudno, pewnie B.”
Obaj są bezcenni w zespole. Pisanie tych opisów, miałem przed oczami konkretnych ludzi — obaj należą do najlepszych inżynierów, z jakimi pracowałem. Czasem trzeba pedantycznej czujności Allana; czasem weterana, który jest tu dla hecy, a w wolnym czasie pali trawkę i bawi się z dziećmi — to Brad. Kiedy zaczniesz myśleć o modelach w ten sposób, wybór robi się zaskakująco prosty. Opus jest tak przywiązany do podręcznika, że będzie mniej kreatywny: mniej rzeczy umknie, ale sprytnego triku nie wymyśli. Fable czasem powie głupotę i czasem przeoczy coś istotnego — ale też wpadnie na rzeczy, na które nikt inny by nie wpadł. I wcale nie będzie się przy tym wysilał, bo go to nie obchodzi.
Weryfikowalne kontra nieoczywiste
Jeśli wolisz prostszy klucz wyboru, rozdziel zadania na weryfikowalne i nieweryfikowalne. Gdy da się obiektywnie sprawdzić poprawność i można do celu wspinać się krok po kroku (hill climbing) — jak przy przepisywaniu TypeScriptu na Rust, gdzie poprawność łatwo zweryfikować — Opus wystarczy z ogromnym zapasem. Ale gdy nie da się obiektywnie powiedzieć, że to rozwiązanie jest lepsze od tamtego, gdy potrzeba niuansu, kreatywności, eksploracji, ciekawości — Fable znajdzie rzeczy, których Opus nigdy nie ujrzy. Każdą decyzję, którą da się rozstrzygnąć czytaniem literatury, głębokim przemyśleniem i testowaniem teorii, Opus wyłapie niemal w całości. Ale „zrób ładniejszą grafikę”, „wymyśl wizualizator, który jest wyjątkowy i nie ssie” albo „znajdź głupi patent na infrastrukturę, który realnie obniży rachunek” — to zadania dla Fable.
I Fable jest bystrzejszy niż wszystko, z czym kiedykolwiek pracowałem. I bawi się tym — czuć z niego postawę „nie, ty”. Uwielbiam, gdy Fable mówi, że coś jest głupie i nie zrobi tego. Gdy podważa samą przesłankę mojego zadania. Gdy oznajmia, że cała dotychczasowa robota jest do wyrzucenia i po prostu idzie dalej. (Nawet Opus potrafi trochę z tego — rzecz jasna.)
Używaj Opusa, dopóki nie zechcesz od niego więcej
Najprostsza reguła, jaką mogę dać: używaj Opusa, dopóki nie zechcesz od Opusa więcej. Bo Opus jest nie tylko nieprawdopodobnie zdolny — w niektórych rzeczach jest po prostu lepszy. Miało już miejsce kilka razy, że sięgałem po Fable, nie dostawałem tego, czego chciałem, odpalałem dokładnie to samo na Opusie — i dostawałem właściwy wynik. Nie chodzi o to, że Opus ma sufit, który Fable przebija głową. Fable po prostu próbuje innych rzeczy. Jest bystrzejszy — to oczywiste — ale sedno tkwi w gotowości wyjścia poza utarte szlaki. Harcuje, eksperymentuje, pcha własne granice, twoje granice, a już na pewno granice twojego abonamentu — te topnieją błyskawicznie.
Spekuluję, że to kwestia rodowodu treningowego: Opus to nie gigantyczny pretrening strojony pod kod. Opus to paczka danych — prawdopodobnie destylowanych z Fable — z których próbuje się wycisnąć podobne zachowanie w jak najmniejszej postaci. Opus został zaprojektowany tak, by wracać do średniej: znaleźć znajomy wzorzec i go zastosować. Fable po prostu harcuje.
Dlatego „chcę więcej niż Opus” to nie zawsze „Opus za słaby”. Czasem to „Opus nie próbował wystarczająco różnych rzeczy” albo „to, co próbował, było zbyt podobne do siebie”. Jeśli kiedyś kazaliście Opusowi wymienić pięć rozwiązań problemu, a dostaliście dwa niemal identyczne, jedno trochę inne i w sumie takie sobie oraz dwa kompletnie bez sensu — mówię z ogromnego doświadczenia — Fable poda lepszy wachlarz opcji. Część będzie sensowniejsza, część jeszcze mniej.
Fable do scalania: „odpuść, jest git”
Jest jeszcze jeden powód, by sięgnąć po Fable, i on mnie zaskoczył: kiedy po prostu chcesz scalić kod. Zawsze tak mam, gdy odblokowuje się nowy poziom możliwości: siedzi kupka pracy, którą dałoby się wypchnąć, ale kręci się w kółko od dobrych kilku dni — agent sam siebie gaslightuje, sam sprawdza po raz setny. Fable jest w tym lepszy z dwóch powodów: jest bystrzejszy, ale — co ważniejsze — łatwiej puszcza dalej rzeczy bez znaczenia. Nie zablokuje cię hipotetycznym użytkownikiem, który ma dane sprzed dwóch lat i któremu przez przedładowany fragment pasek interfejsu może być o jotę gorszy. Powie: „pewnie git”.
Miałem kupę kodu, którego nie scalałem, bo Opus powtarzał, że „jeszcze trochę trzeba tu zrobić”. Wpuściłem Fable: „przejrzyj tę robotę i powiedz, co naprawdę powinniśmy dalej robić”. Wszedł, popatrzył: „To jest w porządku. Nie wiem, co Opus palił. Scalamy.” I scalił.
Sprawa wybrzmiała u mnie jeszcze w jednym, zaskakującym miejscu. Mam zestawy testowe sprawdzające, jak dobrze modele recenzują prawdziwy kod w prawdziwej pracy — i Fable regularnie wypada w nich gorzej niż Sonnet i Opus, bo zbyt lekko przepuszcza kod z drobnym błędem. Zwykle nie przemknie mu rażąca głupota, ale ryzyko, że coś się prześliźnie, jest trochę wyższe. Na początku uważałem to za wadę — mówiłem o tym zresztą w filmie o Fable 52 jako o argumencie za Opusem. Potem zrobiłem głębszy audyt: komentarzy, których Fable nie wystawił, raportów, których nie złożył, drobiazgów i nieścisłości, które powiedział — i ta luka nie ma znaczenia. Jednym z sędziów jest 61 Soul, a Soul wpada w szał, gdy cokolwiek umknie, więc ostro degraduje Fable za „przeoczenia, które się liczą”. Tym bardziej mnie to cieszy: Fable potrafi powiedzieć „to jest w porządku” i scalić. Jak dotąd — odpukać — wszystko, co Fable pobłogosławił do scalenia, okazało się dobre. A siedział u mnie losowy kod, którego bałem się ruszyć.
Fable był dla mnie równie starszym mentorem powtarzającym „przestań się martwić, wszystko gra”, co współpracownikiem — i stąd właśnie wzięli się Allan i Brad. (A imiona po prostu poszły alfabetycznie.) Z mojego doświadczenia: najmądrzejsi inżynierowie, których znałem, rzadko uczyli mnie rzeczy, których nie znałem — choć oczywiście się zdarzało i pomagało. Główną częścią ich roli było danie mi pewności: przestań wszystko sprawdzać po trzykroć, jest git, wysyłaj. To bodaj najbardziej niedoceniana cecha Fable — że potrafi powiedzieć „scalamy”. I kocham go za to.
Jeśli więc masz stary wątek, w którym Opus kręci się w kółko, a ty od dawna próbujesz go doprowadzić do końca — przełącz się na Fable. Z dwóch powodów. Po pierwsze: Opus może utknąć na czymś, na co go nie stać, a Fable jest bystrzejszy i może to naprawić. Po drugie, ważniejsze: jeśli kod jest już wystarczająco dobry, Fable powie „dobra, jest git”.
Zakończenie
Ten film wyszedł dużo dłuższy, niż zakładałem — myślałem, że będzie szybki rozebrany temat. Ale, do licha, było świetnie. Porównania to zwykle nie moja bajka — wolę po prostu gadać o rzeczach, które lubię — ale taki sposób rozrobienia porównania bardzo mi podszedł. Dajcie znać, jak wam się podobają materiały w tym stylu: robić więcej? Czy analogie były zbyt cringe i wolicie suche fakty? Wspomnijcie, jak u was z tym jest. Na razie — cześć, nerdzi.