O czym jest ten film
- Autor zlecił dwóm wersjom agenta — Fable 5 i Fable 5.1 — zbudowanie dokładnie tej samej aplikacji; prompty różniły się wyłącznie linijką z tożsamością modelu i folderem roboczym.
- Prompt ustawiał agenta w roli orkiestratora: strategia, planowanie i odbiór pracy po jego stronie, wykonanie delegowane workerom na modelach Opus i Sonnet.
- Budowanym produktem jest OpsFlow — lokalna aplikacja do rysowania i symulowania planów reagowania na awarie produkcji.
- Obie wersje działają, ale różnią się wyglądem i zachowaniem, m.in. zasadami łączenia węzłów oraz obsługą odrzucenia zatwierdzenia.
- Aplikacje nie są wymienne: przyjmują różne schematy importu przepływów z plików JSON.
- Ślepa ocena w Codexie (bez etykiet, same numery portów): 9,1 dla Fable 5.1 wobec 8,4 dla Fable 5.
- Koszt i czas: Fable 5.1 — ok. 1200 USD i 36 godzin; Fable 5 — ok. 500 USD i pół doby.
- Rozkład pracy: 5.1 zrobił 57% zadań na drogim Opusie, Fable 5 aż 80% na tańszym Sonnecie.
- Część telemetrii budzi wątpliwości autora (rzekomo 256 tokenów wejściowych).
- Werdykt: przy zbliżonym rezultacie wygrywa Fable 5, tańszy o 700 dolarów — choć na co dzień autor i tak woli pracować z 5.1.
Redakcyjne tłumaczenie
Jeden prompt, dwie aplikacje, siedemset dolarów różnicy
Kazałem Fable 5.1 i Fable 5 zbudować dokładnie tę samą aplikację — i różnica okazała się spora. Aplikacje nie tylko wyglądają i obsługują się inaczej: jedna kosztowała mnie 1200 dolarów, druga 500. Jedna powstawała półtorej doby, druga zaledwie pół. Dziś rozbieram ten eksperyment na czynniki pierwsze — i bez owijania w bawełnę przechodzimy do rzeczy.
Punkt wyjścia: identyczny prompt, różnica w jednej linijce
Zacznę od prompta, który dostały oba agenty. Był obszerny, więc od razu proszę: nie czepiajcie się mojego stylu pisania promptów. Obie wersje otrzymały dokładnie ten sam tekst. Jedyna różnica polegała na tym, że w pierwszym przypadku zaczynał się on od słów „Jesteś Fable 5.1 i pracujesz w tym folderze”, a w drugim — „Jesteś Fable 5 i pracujesz w tym folderze”. Reszta była identyczna słowo w słowo. A mimo to oba modele zinterpretowały zlecenie zupełnie inaczej — i zaraz pokażę, jak bardzo.
Agent jako szef projektu, nie jako wykonawca
Kluczowa decyzja eksperymentu: nie kazałem żadnemu modelowi samemu pisać całej aplikacji. Chciałem, żeby całe wykonanie delegowały. Sedno instrukcji brzmiało (w tłumaczeniu):
„Odpowiadasz za strategię, planowanie, delegowanie zadań, ich kolejność, standardy jakości i końcowy odbiór. Osobiście nie prowadzisz researchu inżynierskiego, debugowania, testów ani produkcji warstwy wizualnej. Oszczędzaj swój kontekst, delegując wykonanie przez dynamiczne workflow. Zadania z zakresu architektury, kierunku produktowego i projektowego, trudnego rozwiązywania problemów oraz niezależnych recenzji powierzaj przede wszystkim workerom na modelu Opus. Implementację, research, testy, debugowanie i iteracje powierzaj przede wszystkim workerom na modelu Sonnet. Przydzielaj workerom jasną odpowiedzialność, zapobiegaj konfliktowym edycjom, a gdy wyniki są słabe — podmieniaj pracowników albo zmieniaj im kierunek. Porażka workera to nadal twoja odpowiedzialność.”
(Informacja dodatkowa: „worker” to tu proces wykonawczy, który główny agent uruchamia na innym modelu — Opus pełni rolę droższego i mocniejszego wykonawcy, Sonnet tańszego. Sam agent rozdaje zadania, nadzoruje je i odbiera rezultaty.)
Całego prompta czytać nie będę — powyżej jego sedno. Dorzuciłem do niego listę wymagań produktowych, definicję ukończenia („definition of done”, czyli warunki odbioru) oraz polecenie: „Nie zatrzymuj się na implementacji, która jedynie wygląda wiarygodnie. Kontynuuj kierowanie pracami, dopóki nie zdobędziesz obiektywnych dowodów, że kompletny produkt działa i jest gotowy do pokazania”.
Co miało powstać: OpsFlow, pracownia symulacji awarii
Produkt, który budowały oba agenty, to OpsFlow — lokalna, działająca bez chmury pracownia do projektowania i symulowania przepływów reagowania na incydenty. To nie platforma automatyzacji w stylu n8n (Informacja dodatkowa: n8n to popularne narzędzie do łączenia aplikacji w automatyczne przepływy) — chodzi o to, żeby plan zobaczyć i swego rodzaju przećwiczyć. Narzędzie dla osoby, która odpowiada za to, co dzieje się, gdy pada produkcja. Mówiąc potocznie: rysujesz plan awaryjny jako schemat blokowy, a potem oglądasz na ekranie, jak rozegrałby się w praktyce.
Skoro formalności mamy z głowy, czas na to, co powstało. Na razie nie zdradzam, który model zbudował którą wersję — obejrzyjcie obie i spróbujcie wyrobić sobie własne zdanie, karty odsłonię później.
Pierwsza aplikacja: pionowe bloki i raport, którego nie powiększysz
Pierwszy interfejs. Pierwsze pytanie, jakie sobie zadaję, brzmi: czy to nie przytłacza? Widzę go pierwszy raz. Po lewej stronie jest paleta bloków: wyzwalacz, warunek, akcja, zatwierdzenie, rozwiązanie. Przeciągam je na płótno i próbuję łączyć — i okej, działa. Da się podpiąć wyzwalacz do kolejnego elementu, płótno reaguje, panele się zamykają. To również schemat z węzłów, tylko rozłożony pionowo, a nie poziomo. Połączenia można usuwać — sprawdzam i wychodzi.
Uruchamiam przebieg (przycisk „Run”) i już na żywo widać, jak kolejne elementy się przetwarzają — całkiem fajny widok. Na końcu czeka podsumowanie ukończonego przebiegu: w tej gałęzi trzy kroki pominięto, siedem wykonano, a rozwiązanie brzmiało „zneutralizowano przez wycofanie zmian”. Jest tylko jedno ale: tego raportu nie da się powiększyć. Brakuje możliwości złapania krawędzi i rozciągnięcia okna na pełny ekran, więc czyta się go męcząco. Z przybliżaniem jest podobnie — żeby powiększyć fragment, trzeba wejść w podgląd i dopiero z niego nawigować. Poza tym wszystko działa jak należy.
Druga aplikacja: czystsza estetyka, ale własne dziwactwa
Druga wersja wygląda tak. Jej interfejs podoba mi się odrobinę bardziej, bo w pierwszej mamy ten typ kart z zaokrąglonymi kolorowymi plackami, który aż się prosi o komentarz: „to robiła sztuczna inteligencja”. Nie twierdzę, że tamta wersja to graficzny chłam, ale ten styl po prostu tak na mnie działa. Tu jest czyściej.
Przeciągam blok na płótno — spodobał mi się drobny automatyczny zoom przy upuszczeniu. Blok „rozwiązanie” nie przyjmuje połączeń, więc dodaję warunek. Próbuję podpiąć wyzwalacz pod drugi element — nie wyjdzie: „Odmowa połączenia. Wykryto skok błędów API. Ten wyzwalacz ma już aktywne połączenie”. W tej wersji wyzwalacz łączy się więc tylko z jednym węzłem — ciekawa decyzja projektowa, warto ją zapamiętać. Połączenia można przepinać, a gałąź „fałsz” buduje się bez problemu — działa, jak trzeba.
Dalej: da się przybliżać fragmenty, przesuwać płótno, rozszerzać panel wyników, zamykać zakładki, a nawet przełączyć jasny motyw (przepraszam, jeśli kogoś oślepiłem). Uruchamiam przebieg — znowu widać przetwarzanie, a jeden z węzłów czeka na zatwierdzenie: „Wycofanie zmian na produkcji wymaga akceptacji z tego adresu e-mail”. Zatwierdzam i przebieg rusza wybraną ścieżką. Odpalam ponownie i tym razem odrzucam — przebieg po prostu staje. Niestety wskaźnik nadal prowadzi po gałęzi „prawda”. Chwila szukania i mam rozwiązanie: wchodzę w szczegóły węzła, w danych wejściowych (payload) wybieram „niewielka degradacja” i uruchamiam jeszcze raz — teraz ruch schodzi gałęzią „fałsz”.
Przy okazji: w obu aplikacjach kliknięcie węzła otwiera z boku panel konfiguracji — etykieta, typ akcji, cel i pozostałe parametry.
Odsłonięcie kart i problem ze zgodnością schematów
Czas zdradzić, która jest która: ta pierwsza to Fable 5, ta druga — Fable 5.1. Za chwilę przejdziemy do kosztów i werdyktu. Najbardziej zaskoczyło mnie jednak co innego: obie wersje przyjmują różne schematy importu. Gdy usuwam zawartość i wgrywam przepływ z pliku JSON, format działający w jednej aplikacji w drugiej zostawia puste płótno. Nie wiem, czemu każda zbudowała to po swojemu — po prostu nie są zamienne.
Wgrywam więc większy, wielogałęziowy przepływ do wersji 5.1 i uruchamiam, żeby zobaczyć, jak poradzi sobie z czymś poważniejszym. Muszę przyznać, że wizualnie robi to dobre wrażenie — podoba mi się zarówno wygląd, jak i sposób, w jaki aplikacja prowadzi przez kolejne kroki. W połowie znowu czekała na moją decyzję, więc zatwierdziłem. Wszystko zadziałało zgodnie z oczekiwaniami. Teraz ten sam plik do wersji Fable 5.
I tu istotna obserwacja z warsztatu estetyki: w widoku oddalonym lepiej wygląda Fable 5, bo tekst w węzłach nie rośnie razem ze zoomem — rozmiar napisów pozostaje stały, czy przybliżam, czy oddalam. W wersji 5.1 tekst skaluje się razem z płótnem i moim zdaniem wygląda to tanio. Rozumiem, że to kwestia gustu i część z was się ze mną nie zgodzi. Ogólnie jednak interfejs 5.1 podoba mi się trochę bardziej — poza tym właśnie zoomem, którego kompletnie nie znoszę.
Test na ślepo: Codex ocenia obie wersje
Przechodzimy do wyników. Kazałem Codexowi otworzyć obie aplikacje — bez zdradzania, która jest która. Dlatego na wykresie widnieją wyłącznie numery portów: 4382 i 5321. Komunikat brzmiał: „Dwa agenty dostały ten sam prompt i zbudowały poniższe aplikacje. Przetestuj je porządnie i powiedz, co w każdej jest lepsze”.
Wynik ważony: 9,1 dla Fable 5.1 i 8,4 dla Fable 5. Po kategoriach: projekt wizualny i hierarchia informacji — 5.1; łatwość pierwszego uruchomienia — 5.1; tworzenie przepływów — 5.1; jakość przebiegu próbnego — 5.1; walidacja i bezpieczeństwo, czyli kategoria szczególnie ważna — bardzo wyrównana, ale znowu 5.1. Ostateczna przewaga: 0,7 punktu.
Ciekawsze od samych liczb jest zestawienie mocnych stron obu edycji. Po stronie Fable 5: głębsze narzędzia autorskie, czytelny znacznik czasu automatycznego zapisu, przydatne gotowe scenariusze testów negatywnych (na przykład brakująca waga incydentu) i znakomity podgląd na żywo względem bieżącego payloadu — z tą oceną w pełni się zgadzam. Po stronie 5.1: mocniejsza hierarchia informacji i czytelniejsze płótno (moim zdaniem też prawda, z wyjątkiem widoku oddalonego), solidne podsumowania przebiegów i możliwość pobrania logów, wyraźne stany węzłów — sukces, porażka, pominięcie, oczekiwanie — a wreszcie to, że odrzucenie zgody kończy przebieg błędem, zamiast fałszywie zgłaszać, że incydent zneutralizowano.
Koszty, czas i rozkład modeli
A teraz koszty — moim zdaniem najciekawsza część. Wersja 5.1 kosztowała nieco ponad dwukrotnie więcej niż Fable 5 i pracowała około trzy razy dłużej. Szczerze mówiąc, tego się nie spodziewałem. Spójrzcie jeszcze na rozkład modeli, bo to dopiero niespodzianka. 5.1 wykonał około 57% pracy na Opusie i około 40% na Sonnecie, a sama orkiestracja, czyli wkład samego Fable 5.1, to zaledwie około 3% tokenów. Po drugiej stronie Fable 5 rozliczył na Sonnecie około 80% zadań, na Opusie 12%, a sam wykonał 7%. Może właśnie dlatego ta aplikacja wyszła tak dużo tańsza i szybsza — choć w paru miejscach odrobinę słabsza.
Nie wierzę jednak, żeby droższa wersja była warta tę różnicę. Gdybym do aplikacji od Fable 5 dołożył te same dodatkowe pieniądze, żeby dopiąć ją do poziomu 5.1, sądzę, że wyszłaby lepiej. Trzeba się przecież na czymś oprzeć w takich porównaniach, a moim punktem odniesienia jest pytanie: co by było, gdyby oba modele wydały dokładnie tyle samo? Gdyby przepływ 5.1 kosztował tylko 519 dolarów, efekt raczej nie byłby tak dobry. Stąd ta argumentacja.
Zerknijmy jeszcze na tokeny. Liczba tokenów wejściowych przy Fable 5 — 256 — wygląda mi na nierealną; nie wiem, czy w ogóle da się zbudować taką aplikację na takim wejściu, więc podejrzewam błąd w telemetrii. Tokeny wyjściowe układają się już w sensowny obraz, pewnie dlatego, że większość pracy toczyła się w dynamicznych przepływach i podprzepływach. Tak czy inaczej: 5.1 pracował wyraźnie dłużej i kosztował nieco ponad dwukrotnie więcej — o jakieś 700 dolarów.
Widać to również w oknach kontekstu obu sesji. Fable 5.1 działał na porcie 5321 i przez 36 godzin zużył 404 tysiące tokenów — nieco pod 40% okna. Fable 5 na porcie 4382 zużył 260 tysięcy, czyli 26%. Pokazuję te dane w aplikacji desktopowej, żeby było widać, jak wyglądają w praktyce.
Werdykt: wygrywa Fable 5 — przynajmniej w tym zadaniu
Te liczby prowadzą mnie do wniosku, że to wyzwanie wygrał Fable 5. Nie twierdzę, że Fable 5 to lepszy model — z 5.1 miałem sporo udanych projektów. Szczerze: w codziennej pracy, przy typowych zadaniach, 5.1 wypada u mnie sprawniej i mam wrażenie, że lepiej rozumie, co chcę osiągnąć. Ogólnie teraz bardziej lubię 5.1. Ale w tym konkretnym scenariuszu Fable 5 wygrywa zdecydowanie. Pod względem kosztu, czasu, wydajności i finalnego efektu aplikacje są ostatecznie dość podobne — a czy zapłacilibyście za którąś z nich dodatkowe 700 dolarów? Ja nie.
To wszystko, co mam dla was dzisiaj. Mam nadzieję, że było warto. Jeśli chcecie zobaczyć, jak używam Fable 5.1 do projektowania stron — w szczególności mojej witryny Automation Society, która moim zdaniem wyszła po prostu pięknie, oraz strony osobistej i wielu innych stylów z porządnymi animacjami i efektami przewijania — zajrzyjcie do filmu, który polecam obok. Do zobaczenia.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Ten sam prompt dla dwóch modeli to najtańszy benchmark
Na czym polega: Autor porównał Fable 5 i 5.1 na identycznym zleceniu, zmieniając w prompcie wyłącznie nazwę modelu i folder roboczy. Dzięki temu różnice w wyniku, koszcie i czasie można przypisać modelowi, a nie promptowi.
Jak stosować: Przed większym projektem uruchom krótki, identyczny test na obu kandydatach — w osobnych folderach — i zapisuj koszt, czas oraz jakość. Testuj na własnym typie zadania, nie na wymyślonym przykładzie.
Na co uważać: Ten sam prompt dwa modele rozumieją po swojemu — tu jedna wersja zrobiła pionowy układ węzłów, a druga własny format importu. Porównuj zachowania, nie tylko wynik końcowy.
2.Delegowanie chroni kontekst głównego agenta
Na czym polega: Prompt zabraniał agentowi samodzielnego kodowania, testowania i projektowania wizualnego — miał planować, delegować i odbierać pracę. Efekt: po 36 godzinach 5.1 zużył ledwie około 40% okna kontekstu.
Jak stosować: W promptach projektowych wpisuj wprost podział ról: orkiestrator decyduje i odpowiada, tańsze modele wykonują. Mocniejszy model do architektury i recenzji, tańszy do implementacji i testów.
Na co uważać: Delegacja bez prawa do podmiany słabych pracowników kończy się słabym rezultatem — dodaj zapis „porażka workera to twoja odpowiedzialność”.
3.Warunki odbioru z dowodami, nie „wygląda działająco”
Na czym polega: Do zlecenia dołączono listę wymagań, definicję ukończenia i zakaz zatrzymywania się na implementacji, która tylko wygląda wiarygodnie — agent miał pracować do uzyskania obiektywnych dowodów działania.
Jak stosować: Każde zlecenie dla agenta zamykaj mierzalnymi kryteriami odbioru (funkcje, scenariusze, gotowość do pokazu) oraz poleceniem kontynuowania do ich spełnienia.
Na co uważać: Bez takiego zapisu dostaniesz ładny pokaz zamiast produktu, który się broni.
4.Podwójny koszt to nie podwójna jakość
Na czym polega: Droższa wersja kosztowała 1200 dolarów i trwała trzy razy dłużej, a w ślepej ocenie wygrała tylko 9,1 do 8,4. Autor woli wydać różnicę 700 dolarów na dopieszczenie tańszej aplikacji.
Jak stosować: Przy wyborze modelu licz koszt na punkt jakości i rozważ wariant „tańszy model plus dodatkowa iteracja”. Ustal punkt odniesienia: co by było przy tym samym budżecie po obu stronach.
Na co uważać: Jeden przebieg to anegdota — relacja ceny do jakości potrafi się odwrócić przy innym typie zadania.
5.Sprawdzaj, który model faktycznie wykonał pracę
Na czym polega: Różnica cen wzięła się głównie z rozkładu zadań: 5.1 odrobił 57% pracy na drogim Opusie, a Fable 5 aż 80% na tańszym Sonnecie; sama orkiestracja to 3–7% tokenów.
Jak stosować: Po każdym dużym zadaniu otwórz telemetrię i sprawdź podział między modelami. Jeśli drogi model robi robotę, którą udźwignie tańszy, popraw instrukcje delegowania.
Na co uważać: Telemetria bywa zawodna — autor nie wierzy w raportowane 256 tokenów wejściowych. Nie podejmuj decyzji na podstawie jednej podejrzanej liczby.
6.Oceniaj na ślepo i narzędziem z zewnątrz
Na czym polega: Oceny dokonał Codex, który dostał obie aplikacje bez nazw — tylko numery portów — i przetestował je w kategoriach z wynikiem ważonym.
Jak stosować: Porównując wersje, usuwaj etykiety i oddawaj artefakty do oceny innemu narzędziu lub innej osobie. Podziel ocenę na kategorie (łatwość startu, hierarchia informacji, walidacja, bezpieczeństwo) i policz wynik z wagami.
Na co uważać: Ocena estetyki to w dużej mierze gust — oddzielaj twarde kryteria (czy działa, czy przebieg kończy się poprawnie) od wrażeń wizualnych.
7.Dwie wersje modelu to dwa różne produkty
Na czym polega: Aplikacje zbudowane przez 5 i 5.1 przyjmowały niezgodne formaty importu z JSON — plik z jednej nie wczytywał się do drugiej. Każda wersja podjęła własne decyzje architektoniczne.
Jak stosować: Przełączając projekt między wersjami modelu, najpierw sprawdź zgodność kontraktów: formaty importu i eksportu, struktury danych, reguły interfejsu. Traktuj artefakty z różnych wersji jako niekompatybilne, dopóki nie udowodnisz inaczej.
Na co uważać: Drobiazgi w rodzaju „wyzwalacz łączy się tylko z jednym węzłem” potrafią zepsuć realne użycie — testuj ścieżki krytyczne, nie tylko scenariusz pokazowy.
8.Odmowa zgody musi mieć jednoznaczny skutek
Na czym polega: W ocenie Codexa zaletą 5.1 było to, że odrzucenie zatwierdzenia kończyło przebieg błędem, zamiast fałszywie raportować „zneutralizowano”. W narzędziu do ćwiczenia awarii takie fałszywe podsumowanie to prosta droga do katastrofy.
Jak stosować: W narzędziach operacyjnych testuj ścieżki negatywne: odrzucenie, przekroczenie czasu, brakujące dane. Wymagaj, by każdy stan końcowy był wyraźnie oznaczony.
Na co uważać: Automatyczne podsumowania potrafią upiększać wynik — każdorazowo weryfikuj je twardymi danymi z logów.
9.Skalowanie tekstu przy zoomie psuje czytelność dużych schematów
Na czym polega: Autor wolał wersję, w której przy oddalaniu napisy nie rosną — stała wielkość etykiet robi lepsze wrażenie niż tekst powiększający się razem z płótnem, który „wygląda tanio”.
Jak stosować: Projektując (lub zlecając agentowi) edytory schematów, wpisz w wymaganiach zachowanie przy zoomie — np. stały rozmiar etykiet z widocznością zależną od poziomu przybliżenia.
Na co uważać: To kwestia gustu, ale realnie wpływa na odbiór profesjonalizmu — zweryfikuj ją z przyszłymi użytkownikami.
10.Model na co dzień to nie to samo co model do konkretnego zadania
Na czym polega: Autor preferuje 5.1 w codziennej pracy (lepiej rozumie intencje), ale w budżetowym pojedynku wygrał Fable 5 — tańszy i szybszy przy zbliżonym rezultacie.
Jak stosować: Prowadź krótką listę własnych zadań próbnych (np. „aplikacja za 500 dolarów”, „refaktoryzacja modułu”) i dobieraj model do zadania na podstawie danych, a nie numeru wersji.
Na co uważać: Werdykt z jednego eksperymentu nie przenosi się na wszystkie typy zadań — koszt, czas i jakość licz zawsze osobno.