O czym jest ten film
- Anthropic wypuściło model Sonnet 5, który według benchmarków osiąga wyniki zbliżone do Opus 4.8 w zadaniach agentowego kodowania, a przy tym jest tańszy.
- Autor postanawia sprawdzić te deklaracje na praktycznym zadaniu, zamiast wierzyć samym benchmarkom.
- Zadanie z twistem: zamiast kolejnego klona gry, model ma najpierw zbudować własny silnik gry i własny zestaw narzędzi, a dopiero potem samą grę.
- Kluczowa idea: agent buduje narzędzia „wokół własnych ograniczeń” (np. brak możliwości oglądania gry w czasie rzeczywistym), żeby móc niezawodnie tworzyć i debugować grę.
- Przykładowe narzędzia to podgląd zasobów („character studio”), odtwarzanie animacji klatka po klatce oraz spowalnianie animacji, tak by model mógł je analizować.
- Oba modele dostały identyczny prompt (Age of Empires w przeglądarce) i te same poprawki korygujące, uruchomione w trybie Ultra Code z użyciem workflows.
- Sonnet 5 zbudował działającą grę z jednostkami, zbieraniem surowców, mgłą wojny, przeciwnikami oraz kompletnym zestawem narzędzi deweloperskich.
- Opus 4.8 dostarczył — zdaniem autora — wyraźnie lepszy efekt: ładniejsze menu i zasoby, płynniejszą walkę, minimapę i działające AI przeciwnika.
- Idea „agent buduje własne narzędzia” dotyczy nie tylko gier — sprawdza się też przy oprogramowaniu firmowym (frameworki testowe, narzędzia weryfikacyjne).
- Autor nie potrafi dokładnie porównać kosztów w interfejsie, ale szacuje, że oba przebiegi kosztowały i trwały podobnie; subiektywnie wygrywa Opus 4.8.
Redakcyjne tłumaczenie
Wstęp: nowy Sonnet 5 i pytanie o jego jakość
Anthropic właśnie wypuściło Sonnet 5. Według ich własnych benchmarków ten model osiąga w agentowych zadaniach programistycznych wyniki podobne do Opus 4.8 — a przy tym jest tańszy. Nie zamierzam jednak wierzyć Anthropic na słowo. Zobaczmy, jak ten model radzi sobie w realnym zadaniu agentowego kodowania.
Wracam więc do Claude Code, wybieram Sonnet 5 i uruchamiam go w trybie Ultra Code, żeby dać mu najlepsze możliwe warunki.
(Informacja dodatkowa: „agentowe kodowanie” to tryb, w którym model nie tylko generuje kod, lecz samodzielnie planuje, uruchamia narzędzia, testuje i poprawia efekty. „Ultra Code” to tryb pracy dający agentowi więcej zasobów i swobody działania.)
Twist: niech agent zbuduje własny silnik i własne narzędzia
Wiem, jak część widzów reaguje na youtuberów budujących gry za pomocą tych modeli. Dlatego owszem — poproszę o zbudowanie gry, ale z pewnym twistem. Zamiast kazać modelowi klepać kolejnego klona Minecrafta, poproszę go, żeby zbudował własny silnik gry oraz wszystkie narzędzia, których sam potrzebuje, aby tę grę stworzyć.
Pokażę, o co mi chodzi, na innym projekcie. Gdy buduje się gry w przeglądarce, często pojawiają się problemy: obiekty wyglądają nie tak, jak powinny, ich rozmieszczenie jest błędne, drzwi nie pasują do futryn, a fizyka i animacje po prostu nie działają. Ta gra wygląda tak dobrze wyłącznie dlatego, że poprosiłem agenta, aby zbudował własny zestaw narzędzi — i to jest naprawdę zdumiewające.
Agent stworzył podgląd zasobów, coś w rodzaju „studia postaci”, które pozwala oglądać obiekty z różnych kątów i naprawiać je w bardzo kontrolowanym środowisku. Potrafi też odtwarzać animacje w tempie, które sam jest w stanie przeanalizować.
Dlaczego to działa: narzędzia budowane wokół własnych ograniczeń
Trzeba pamiętać, że ta gra działa w przeglądarce, a agent nie ma jak grać w nią w czasie rzeczywistym. Musiałby wykonywać 30 albo 60 zrzutów ekranu na sekundę, żeby zobaczyć, co się dzieje — a to nierealne.
Normalnie taki agent pracuje tak: otwiera przeglądarkę, klika przycisk, robi zrzut ekranu, a następnie model musi wizualnie przeanalizować ten obraz, żeby zrozumieć, co się dzieje. Zanim jednak zrobi drugi zrzut, mijają czasem dwie–trzy minuty i świat gry wygląda już zupełnie inaczej.
Kiedy jednak każemy agentowi zbudować własne narzędzia, może on spowolnić animację do tempa, które jest w stanie przeanalizować. Innymi słowy, agent buduje narzędzia wokół własnych ograniczeń. Efektem końcowym jest bardzo przydatny zestaw narzędzi, którego agent może używać do pracy ze swoim środowiskiem.
To nie dotyczy wyłącznie gier. Jeśli budujesz oprogramowanie firmowe, naprawdę warto prosić agenta, żeby najpierw stworzył frameworki testowe i narzędzia, dzięki którym może niezawodnie zaimplementować to oprogramowanie.
Prompt: najpierw silnik i narzędzia, potem gra
Wybieram więc Sonnet 5, przełączam na Ultra Code i wpisuję prompt mniej więcej taki:
„Zbuduj klon Age of Empires działający w przeglądarce. Nie buduj jednak na ślepo. Najpierw stwórz silnik gry oraz narzędzia do tworzenia i testowania gry. Mają one pozwalać na tworzenie zasobów, animacji i tak dalej. Te narzędzia nie są dla użytkownika — są dla ciebie, żebyś mógł wizualnie budować grę z uwzględnieniem własnych ograniczeń, takich jak ograniczona liczba klatek przy pracy w przeglądarce. Gdy już stworzysz te narzędzia, zbuduj całą grę wraz z poziomami AI, wyzwaniami i resztą. Nie buduj etapami. Użyj workflows, żeby zbudować wszystko bez pytania mnie o zdanie. O wszystkim decydujesz sam. Ma to wyglądać dopracowane co do piksela, a pętla rozgrywki ma być przyjemna”.
(Informacja dodatkowa: „workflows” w Claude Code to mechanizm pozwalający agentowi realizować wieloetapowe zadania samodzielnie, w sposób deterministyczny, bez pytania użytkownika o kolejne kroki.)
Wysyłam prompt.
Wynik Sonnet 5
Całość zajęła około dwóch godzin. Agent uruchomił workflow, zaczął budować grę i testował ją w przeglądarce. Ponieważ stworzył własny zestaw narzędzi, był też w stanie wygenerować niewielki arkusz animacji/postaci, którego mógł używać dla wszystkich zasobów w grze. Poprosiłem go jeszcze o kilka poprawek, bo zauważyłem parę błędów, ale starałem się utrzymać wszystko możliwie prosto.
Dla porównania uruchomiłem dokładnie ten sam prompt na Opus 4.8 — identyczny, z tymi samymi promptami korygującymi, żeby oba modele startowały z tej samej bazy. Najpierw obejrzyjmy, co dał Sonnet 5, a potem porównamy z Opus 4.8.
To jest nasza gra w stylu Age of Empires od Sonneta. Mamy postacie, można je zaznaczać i przemieszczać po mapie. Po kliknięciu prawym przyciskiem na obiektach jednostki faktycznie zabierają się do zbierania surowców. Gdy poruszamy się po mapie, mgła się rozwiewa i widać różne zasoby, na przykład wodę — nie jestem pewien, czy to ma być piasek, czy coś innego. Po kliknięciu w budynek mamy kilka opcji, na przykład szkolenie kolejnych wieśniaków. Właśnie natknęliśmy się na bazę przeciwnika i chyba nasz wieśniak zginął. Nieźle — mamy działającą grę.
Chcę też pokazać zestaw narzędzi, który zbudował agent. Przejdźmy do podglądu zasobów — to jest naprawdę świetne. Jeśli kiedykolwiek próbowałeś budować gry za pomocą agentów i postacie wyglądały nie tak, a animacje były dziwne — ręce ruszały się poza osią — to jest znakomity sposób, by agent sam debugował takie problemy. Dla wieśniaków możemy zmieniać animacje, na przykład cykl chodzenia. Możemy nawet spowolnić prędkość, dając agentowi więcej czasu na analizę. Mamy też narzędzie do podglądu animacji, które pozwala analizować animację klatka po klatce. Jest również edytor mapy oraz „engine harness”, czyli sposób na podgląd minimapy i sprawdzenie, że wszystko działa. Nieźle, Sonnet.
Uważam, że Sonnet wykonał świetną robotę. Co ważniejsze, potrafił zbudować zestaw narzędzi i osiągnąć naprawdę dobre wyniki.
Wynik Opus 4.8
Teraz zobaczmy, co zrobił Opus 4.8. Już samo menu to ogromna poprawa i całość wygląda dużo lepiej, niż można się spodziewać. Zasoby prezentują się bardzo dobrze. Można kliknąć dowolną z postaci, a one faktycznie reagują na siebie nawzajem — co jest świetne — choć momentami przenikają się przez siebie. Można przybliżać i oddalać widok. Przemieśćmy jedną z jednostek na dół mapy; w rogu widać niewielką minimapę i wszystko po prostu działa. I proszę — jesteśmy właśnie atakowani. AI również działa. Jednostki faktycznie walczą i zadają obrażenia. Moim zdaniem to zdecydowanie lepsza wersja gry.
Przyjrzyjmy się też narzędziom zbudowanym przez agenta. Mamy „asset studio”, w którym widać różne tekstury, oraz „animation lab”, który również wygląda świetnie i pozwala przełączać się między postaciami. Mam nadzieję, że widać już, jak przydatne jest zlecanie agentom budowy własnych narzędzi — daje to po prostu dużo lepszy efekt końcowy.
Podsumowanie i wnioski o kosztach
Co o tym sądzicie? Czy Sonnet 5 rzeczywiście jest na poziomie Opus 4.8? Niestety nie mogę pokazać, ile dokładnie kosztowały mnie te sesje — w widoku kontekstu nie ma sensownego rozbicia kosztów. Zgaduję jednak, że były mniej więcej takie same i zajęły podobną ilość czasu. Osobiście uważam, że Opus 4.8 dostarczył zdecydowanie lepszy wynik, ale dajcie znać w komentarzach, co myślicie.
(Informacja dodatkowa: na końcu autor zaprasza do swojej płatnej społeczności edukacyjnej „Agentic Labs” z kursami o agentowym kodowaniu — to część promocyjna, niezwiązana z merytoryką testu.)
10 najważniejszych takeaways — z kontekstem zastosowania
1.Nie ufaj samym benchmarkom — testuj model na własnym zadaniu
Na czym polega: Anthropic deklaruje, że Sonnet 5 dorównuje Opus 4.8 w agentowym kodowaniu i jest tańszy, ale autor weryfikuje to praktycznym, powtarzalnym testem.
Jak stosować: Zanim wybierzesz model do stałej pracy, przepuść przez oba ten sam, reprezentatywny dla ciebie prompt i porównaj wyniki na tej samej bazie.
Na co uważać: Pojedynczy test to nie statystyka — jeden przebieg może być losowo lepszy lub gorszy. Jeśli decyzja jest kosztowna, powtórz test kilka razy.
2.Każ agentowi najpierw zbudować silnik i narzędzia, dopiero potem produkt
Na czym polega: Twist tego eksperymentu polega na tym, że model najpierw tworzy własny silnik i narzędzia deweloperskie, a grę buduje dopiero za ich pomocą.
Jak stosować: Przy większych projektach dodaj do promptu jawne polecenie „najpierw zbuduj narzędzia i infrastrukturę, potem funkcjonalność” — poprawia to jakość i powtarzalność.
Na co uważać: To wydłuża czas i koszt (tu ~2 godziny). Dla drobnych zadań będzie to nieopłacalny narzut.
3.Narzędzia mają obchodzić ograniczenia samego agenta
Na czym polega: Agent nie widzi gry w czasie rzeczywistym, więc zbudował podgląd klatka po klatce i spowalnianie animacji — narzędzia dopasowane do własnych ograniczeń percepcji.
Jak stosować: Zastanów się, czego agent „nie widzi” (stan aplikacji, logi, render) i poproś go o narzędzie, które udostępni mu tę informację w formie, którą potrafi przeanalizować.
Na co uważać: Agent nie zawsze sam rozpozna swoje ograniczenia — czasem trzeba je nazwać wprost w promptcie, jak zrobił autor („ograniczona liczba klatek w przeglądarce”).
4.Zasada „własnych narzędzi” dotyczy też oprogramowania firmowego
Na czym polega: Autor podkreśla, że to samo podejście warto stosować przy budowie oprogramowania biznesowego — frameworki testowe i narzędzia weryfikacyjne.
Jak stosować: Przy projektach produkcyjnych proś agenta o testy, harnessy i skrypty diagnostyczne zanim zacznie implementować logikę, aby mógł sam weryfikować swoją pracę.
Na co uważać: Narzędzia testowe też mogą być błędne — zieloną kontrolkę traktuj jako sygnał, a nie dowód; przejrzyj przynajmniej próbkę wygenerowanych testów.
5.Porównuj modele na identycznym promptcie i tej samej bazie
Na czym polega: Oba modele dostały dokładnie ten sam prompt oraz te same prompty korygujące, żeby porównanie było uczciwe.
Jak stosować: Przy A/B modeli trzymaj stałe: prompt, tryb pracy, poprawki i punkt startowy. Zmieniaj tylko jedną zmienną — model.
Na co uważać: Nawet przy identycznych warunkach modele są niedeterministyczne. Różnice mogą wynikać z losowości, nie tylko z „lepszego” modelu.
6.Subiektywnie: Opus 4.8 dał lepszy efekt, mimo parytetu w benchmarkach
Na czym polega: Autor uznał wersję Opus 4.8 za wyraźnie lepszą (menu, zasoby, walka, AI), choć benchmarki sugerują równorzędność.
Jak stosować: Traktuj benchmarki jako punkt wyjścia, ale przy zadaniach wymagających „smaku” i jakości wizualnej licz się z tym, że mocniejszy model może dawać lepszy odbiór.
Na co uważać: To ocena subiektywna i jednorazowa. Dla twojego typu zadań różnica może być odwrotna lub pomijalna — sprawdź u siebie.
7.Tańszy model bywa „wystarczająco dobry” — licz opłacalność
Na czym polega: Sonnet 5 dostarczył w pełni działającą grę z kompletnym zestawem narzędzi, choć mniej dopracowaną niż Opus.
Jak stosować: Do zadań, gdzie liczy się działanie, a nie maksymalna jakość, rozważ tańszy model — może dać porównywalny efekt niższym kosztem.
Na co uważać: „Działa” nie znaczy „dopracowane”. Jeśli finalna jakość jest kluczowa, oszczędność na modelu może się nie opłacić.
8.Interfejsy narzędzi nie pokazują pełnych kosztów sesji — mierz je inaczej
Na czym polega: Autor nie mógł pokazać rzeczywistych kosztów, bo widok kontekstu nie daje sensownego rozbicia.
Jak stosować: Jeśli koszt jest istotny, śledź go poza narzędziem — przez rozliczenia API, dedykowane liczniki tokenów lub logi — zamiast polegać na UI.
Na co uważać: Szacunki „na oko” (autor zakłada podobny koszt obu przebiegów) potrafią mocno mijać się z rzeczywistością, zwłaszcza między modelami o różnych cenach.
9.Buduj w jednym przebiegu przez workflows, ale zostaw miejsce na poprawki
Na czym polega: Prompt zabraniał budowania etapami i kazał użyć workflows do wykonania całości bez pytań, jednak autor i tak dołożył ręczne poprawki błędów.
Jak stosować: Do rozległych zadań używaj trybu autonomicznego (workflows), ale zaplanuj krótką rundę poprawek po zakończeniu — pojedynczy przebieg rzadko jest bezbłędny.
Na co uważać: „Nie pytaj mnie o zdanie” oznacza, że agent podejmie wszystkie decyzje sam — także te, z którymi się nie zgodzisz. Przejrzyj efekt, zanim go zaakceptujesz.
10.Wizualne narzędzia debugujące ratują jakość generowanych gier/animacji
Na czym polega: Podgląd zasobów, „animation lab” i odtwarzanie klatka po klatce pozwoliły agentowi samodzielnie wychwycić błędy postaci i animacji (ręce poza osią itp.).
Jak stosować: Gdy generujesz treści wizualne z pomocą agenta, poproś o dedykowane narzędzie do ich oglądania i weryfikacji — to realnie podnosi jakość efektu.
Na co uważać: Samo istnienie narzędzia nie gwarantuje, że agent poprawnie zinterpretuje to, co widzi. Warto samemu rzucić okiem na kluczowe zasoby przed publikacją.