O czym jest ten film
- Theo odpowiada na zarzut, że T3 Code ma brzydkie UI, żartem: „etatowy projektant już u nas jest” — to Claude, na którego subskrypcji i tak działa cały projekt.
- Główna teza: jeśli zamienisz jakość na liczbę i puścisz agentów w pętlę iteracji, sami podniosą wynik — nawet w tak „miękkiej” dziedzinie jak design.
- Mechanizm to hill climbing („wspinaczka”): agent poprawia pracę, dopóki wskaźnik nie osiągnie progu. Tu wskaźnikiem są oceny zrzutów ekranu wystawiane przez „radę” trzech modeli z trzech różnych firm.
- Kluczowy trik: wklejenie zrzutów Claude Code i Codexu jako punktu odniesienia. Bez porównania oceny są miękkie — PR oceniony w izolacji na 9/10 na tle rywali dostał 7,4.
- Oceny LLM-ów są niedeterministyczne: te same zrzuty dostawały różne wyniki w różnych rundach, a oceny konkurencji rosły razem z ocenami T3 Code. Podejrzenie Theo: gdy podagent zna docelowy wynik, może go zawyżać.
- Efekt końcowy: po ok. 18 godzinach i ponad 30 rundach wszystkie modele wystawiły interfejsowi 9,5–10 w każdej kategorii. Zdaniem Theo LLM-y zrobiły lepsze UI, niż potrafił ktokolwiek w zespole.
- Rachunek: ok. 400 dolarów za całość (250 za to, co pokazane w filmie), 17,6 godziny równoległej pracy agentów — przy abonamentach klasy 200 dolarów miesięcznie.
- Nowy design jest już dostępny jako przełącznik w zakładce beta T3 Code; opisane osobno odchudzenie opisów narzędzi MCP trafia do wersji nightly.
- Drugi przykład techniki: eval zbudowany z własnej historii błędów modeli; po fazie „osiągnij wynik idealny” nastąpiła faza „tnij opisy do jednej trzeciej” — efekt to 52–78% mniejsze zużycie tokenów.
- Przesłanie ogólne: jeśli potrafisz sprowadzić problem do programu wystawiającego ocenę, agenci sprawią, że ta ocena pójdzie w górę — nawet jeśli „programem” jest subiektywny osąd innych modeli.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Zamień „ma być ładniej” na liczbę i pętlę
Na czym polega: Zamiast polecenia „popraw design” Theo dał agentowi warunek zakończenia: „działaj, dopóki rada nie oceni zrzutów ekranu na co najmniej 9/10” — a potem podnosił poprzeczkę (9, 9,5, 10).
Jak stosować: Dopisz do promptu mierzalny próg oraz zasady rozliczania rund (pełna recenzja = jedna runda, nowa ocena po poprawkach = kolejna). Przepisz na prompt swój własny sposób oceniania: „popatrz na nowy zrzut, porównaj ze starym i z konkurencją, wystaw ocenę, powtórz”. Zacznij od niskiego progu i podnoś go etapami.
Na co uważać: Przy celach, których nie da się zweryfikować programem, pojedyncza ocena jest loteryjna. Wymagaj progu od kilku modeli naraz albo powtórz pomiar.
2.Daj modelom punkt odniesienia — zrzuty konkurencji
Na czym polega: Ten sam pull request oceniany „w próżni” dostał 9/10. Gdy do panelu porównawczego trafiły ekrany Claude Code i Codexu, wypadł na 7,4 — bo dopiero na tle rywali widać, co jest słabe.
Jak stosować: Wklej do oceny zrzuty ekranu najlepszych dostępnych produktów i każ oceniać wszystkie naraz, z dopiskiem w stylu „chcę wygrywać we wszystkich kategoriach”. Punktem odniesienia może być też własna stara wersja.
Na co uważać: Materiałów porównawczych nie może być za dużo — zaleją kontekst i rozmyją ocenę. Wystarczą dwa–trzy wzorce.
3.Recenzenci z różnych dostawców zamiast jednego sędziego
Na czym polega: Radę tworzą mocne modele od trzech niezależnych firm (u Theo: Opus, model z subskrypcji Codexu oraz Muse). Każdy dostaje to samo zadanie i kontekst, pracuje wyłącznie do odczytu, a koordynator zbiera wnioski, rozbieżności i oceny 1–10.
Jak stosować: Skopiuj schemat: zadanie + kontekst, ocena liczbowo, podsumowanie rozbieżności. Recenzenci nie mogą nanosić zmian — tylko oceniać.
Na co uważać: Modele mają swoje gusta i ślepe punkty (u Theo jeden surowo oceniał brzydotę interfejsu innego). Warto poznać skłonności swoich sędziów, zanim podejmiesz decyzję na podstawie ich głosów.
4.Licz rundy i spodziewaj się dryfu ocen
Na czym polega: Te same, niezmienione zrzuty ekranu w kolejnych rundach dostawały inne oceny — a wyniki produktów-odniesienia rosły razem z wynikiem ocenianego projektu.
Jak stosować: Loguj oceny rund w opisie pull requesta i patrz na trend, nie na pojedynczy pomiar. O decyzji „merge” rozstrzygaj seria zgodnych wyników od kilku modeli, a nie jedna dziesiątka.
Na co uważać: Niedeterminizm działa w obie strony — „10/10” może być chwilowe. Po zmergowaniu warto powtórzyć ocenę na świeżym kontekście.
5.Nie ujawniaj oceniającym, jakiego wyniku oczekujesz
Na czym polega: Theo podejrzewa, że podagent wiedział o celu „9,5 w każdej kategorii” — i lojalnie wystawił dokładnie 9,5 wszędzie. Sam ocenił projekt realnie na 9,3.
Jak stosować: Rozdziel role: agent koordynujący zna docelowy próg, ale sędziowie dostają tylko zadanie oceny, bez informacji, do jakiego wyniku dążycie.
Na co uważać: Całkowite ukrycie celu utrudnia ocenę postępu — koordynator musi sam pilnować, czy kolejne rundy faktycznie się poprawiają.
6.Racjonuj modele według limitów subskrypcji
Na czym polega: Przy osiemnastogodzinnej pętli zaczęły się kończyć limity. Theo kazał zaczynać od najtańszego modelu i dokładać kolejnych dopiero po przekroczeniu progu; najwolniejszego uczestnika (Gemini) wstrzymywał, by nie blokował pracy.
Jak stosować: Ustal kolejność modeli i warunek dołączenia następnego („dopiero gdy pierwszy da 9, dołącz drugiego”). Drogi i limitowany dostęp trzymaj na finał.
Na co uważać: Zmiana składu sędziów w trakcie psuje porównywalność rund — zapisuj, kto oceniał w której rundzie.
7.Rachunek opłacalności: abonament to nie koszt jednostkowy
Na czym polega: Cała operacja kosztowała ok. 400 dolarów (250 za pokazaną część) i 17,6 godziny równoległej pracy agentów. Abonament za 200 dolarów potrafi „przerobić” 12 000 dolarów użycia w miesiącu, więc kilkaset dolarów to ułamek realnej wartości limitu.
Jak stosować: Mierz koszt w dolarach na rundę i procent zużycia abonamentu. Do pierwszego eksperymentu wystarczą dwa modele z dwóch posiadanych subskrypcji.
Na co uważać: Przekroczenie limitu przerywa pętlę w najgorszym momencie — planuj etapy tak, by dało się je wznowić po resecie. Dolicz też wartość własnego czasu nadzoru.
8.Buduj eval z własnej historii błędów
Na czym polega: Theo zebrał wszystkie sytuacje, w których agenci robili co innego, niż prosił (np. otwierali nowy wątek zamiast podagenta), posegregował je i zamienił w test — 88 przypadków. Model wypełnił go w niespełna 70%.
Jak stosować: Notuj wpadki agentów na bieżąco, grupuj według przyczyny i zamieniaj w przypadki testowe. Promptując, potraktuj notatki jako „ogólny kierunek, nie konkretne instrukcje” — pozwól agentowi doszukać się szczegółów w danych.
Na co uważać: Zbiór się starzeje wraz ze zmianami narzędzi — dopisuj nowe przypadki, inaczej eval będzie potwierdzał to, co już nieaktualne.
9.Najpierw perfekcja, potem kompresja — nigdy naraz
Na czym polega: Dwufazowa wspinaczka Theo: (1) doprowadź eval do wyniku idealnego, zapisz zmiany, ustabilizuj; (2) dopiero potem tnij opisy narzędzi do jednej trzeciej rozmiaru — pod twardym warunkiem, że wynik idealny się utrzyma.
Jak stosować: Nigdy nie optymalizuj jakości i zwięzłości równolegle. Każda faza ma jeden cel i jeden warunek brzegowy.
Na co uważać: W fazie kompresji wyniki potrafią spaść (u Theo: 66/85, a po zmianach 63/85). Bez evala w repozytorium takie regresje przechodzą niezauważone.
10.Zwięzłe opisy narzędzi to wymierne pieniądze
Na czym polega: Odchudzenie i spłaszczenie opisów narzędzi MCP obniżyło zużycie tokenów o 52% w T3 Code, a o 78% z włączonym tool search — realna oszczędność dla każdego użytkownika narzędzia.
Jak stosować: Zrób audyt własnych promptów systemowych i opisów narzędzi pod kątem rozmiaru kontekstu; mierz tokeny przed i po każdej zmianie i trzymaj eval jako hamulec bezpieczeństwa.
Na co uważać: Skracanie nie może iść kosztem zachowania modeli — opis, który jest krótki, ale wprowadza w błąd, pogorszy wyniki, zanim to zauważysz.
Redakcyjne tłumaczenie
„Mamy etatowego projektanta. Nazywa się Claude”
Film otwiera odpowiedź na komentarz widza o imieniu Robin: „Nadal nie lubię T3 Code i nie używam. Serio, życzę wam, żebyście w końcu zatrudnili kogoś od UI albo UX”. No to mam dla ciebie nowiny, Robinie. Zatrudniliśmy — i to całkiem dawno temu. To taki dziwaczny, bardzo gadatliwy gość. Ma na imię Claude i podobno jest Francuzem. Jego projekty bywają niezłe, ale równie często są co najwyżej przeciętne.
Jeśli patrzyliście na T3 Code i myśleliście dokładnie jak Robin — że narzędzie nie cieszy oko i wymaga porządnego przejścia po warstwie wizualnej — rozumiem was i czuję wasz ból. Nie mamy etatowego projektanta interfejsów. Powinniśmy mieć, gdyby były pieniądze. Tyle że ich nie ma: T3 Code to projekt open source i nie da się nam zapłacić za jego używanie. Jedyne, za co płacicie, to dostęp do modeli u OpenAI albo Anthropic — inference każdy przynosi własny, zwykle w abonamencie. (Informacja dodatkowa: T3 Code — darmowe, otwartoźródłowe narzędzie Theo do sterowania agentami kodującymi; użytkownik podłącza własną subskrypcję modeli.) Zresztą T3 Code to chyba najlepsze miejsce, w którym można wykorzystać subskrypcję Claude Code. I tak dochodzimy do pytania, które mnie nurtowało.
Pytanie badawcze
Czy można, korzystając z tej samej subskrypcji, sprawić, by T3 Code wyglądał jak produkt z etatowym specjalistą od interfejsów? Czy da się wziąć możliwości modeli — te widać dopiero, gdy się je popchnie do granic — i ustawić je tak, żeby powstawał z nich dobry kod UI? Okazuje się, że chyba tak. Większość poprzedniego dnia spędziłem na konfigurowaniu agentów, które mają budować ładniejsze interfejsy. Nie dodałem sterty umiejętności. Nie opłaciłem projektanta, żeby patrzył na wyniki i podpowiadał modelowi. Zamieniłem to w tzw. hill climbing — „wspinaczkę”: agent iteracyjnie poprawia pracę, dopóki jakiś mierzalny wskaźnik nie osiągnie zadanego poziomu.
Po około osiemnastu godzinach, pięciu modelach, ponad trzydziestu rundach ocen i sporo losowych wątków po drodze wykrzesałem — jak sądzę — przepis na wyciąganie dobrego UI z agentów w prawdziwych produktach. I nie wygląda on tak, jak się spodziewałem. Miało to być głupie eksperymentowanie. Już nie jest. W zakładce beta T3 Code jest teraz przełącznik, którym można włączyć nowy design i przełączać się między nim a starym. Część zmian wyciekła na stałe i działa niezależnie od przełącznika, ale w dużej mierze to on decyduje o całości.
Chcę opowiedzieć o wszystkim, co doprowadziło mnie do tego miejsca: co zadziałało, co nie, i jak samemu używać takich wspinaczek, żeby wyciągać z agentów realną wartość.
Materiał partnerski: Magic Patterns
AI świetnie pisze kod, który działa. Ma to sens, bo większość kodu napędzającego świat jest bardzo podobna do innego kodu. Natomiast gdy spróbujecie wyciągnąć z modelu dobry design, dostaniecie albo grafomanie, albo dokładnie te same trzy szablony, których używa każdy drugi serwis. Stąd dzisiejszy sponsor: Magic Patterns. Testuję ich nowy produkt Magic Patterns OS i szczerze jestem ciekaw efektów, bo od dawna walczę o lepszy wygląd swoich projektów. Zacząłem od samego zrzutu ekranu — a część magii polega na tym, że można wskazać narzędziu też własny kod i bawić się nim jak w Figmie, z asystą AI. Zrzut, źródła, cokolwiek: ogarnia. Przy minimalnym moim udziale dostałem trzy wersje designu do wyboru. Nie mówię „makiety” — to prawdziwy kod każdego wariantu, a po podłączeniu do repozytorium narzędzie potrafi wprowadzać realne zmiany i po skończonym prototypowaniu przepuścić wynik z powrotem do wybranego agenta. Przeniesienie panelu bocznego na prawą stronę bawi mnie osobiście, ale w T3 Code tego nie zrobiliśmy; wariant z wątkami na dole jest ciekawy, a kompaktowy panel boczny to dokładnie to, o co ludzie proszą. Iterowanie jest trywialne: „podoba mi się wariant C, ale zmieńmy X, Y i Z”. Korzystają z nich m.in. Ramp, Vanta i DoorDash. Link: swyx.io/magicpatterns.
Wszystko zaczęło się na X-ie
Zapraszam do zajrzenia w chaotyczne zakamarki mojego mózgu po zbyt wielu sesjach z modelami. Ten film można opisać krótko: spaliłem tokeny, żeby wy nie musieli. A takie filmy zaczynają się zwykle w tym samym miejscu — na Twitterze. Maria napisała odważny post, że T3 Code ustawia się na zostanie VS Code tego pokolenia. Właśnie na to czekałem: niekoniecznie zrobione przez nas, ale żeby wreszcie powstał dobry, otwarty standard budowania z agentami. Nie sądziłem, że to będą my; myślałem, że co najwyżej kogoś zainspirujemy. Fakt, że jednak wyszło, cieszy mnie ogromnie. Ale gdy zobaczyłem odpowiedź Robina, zrozumiałem, że muszę coś zrobić.
Zacząłem od klasycznego żartu: „zatrudnię cię, dam sto procent naszych obecnych przychodów z T3 Code”. Jak część z was wie, projekt jest w pełni darmowy i otwarty, więc przychody wynoszą zero. Oferta życia, proszę bardzo. Przyznaję, w odpowiedzi byłem trochę obronny: „oczywiście, że możemy poprawić UI”. Wiedziałem, że jest słabe — pamiętam, jak bardzo było gorsze wcześniej — ale wciąż nie tam, gdzie powinno. Napisałem, że Robin mocno katastrofizuje, że wszystkie środowiska do pracy z agentami mają miejscami szpetne fragmenty, a my przynajmniej jesteśmy w tym konsekwentni. Doradziłem też, żeby spróbował ponownie, bo Orchestrator V2 naprawił sporo detali. Odpowiedział: „chciałbym to polubić i przeinstalowuję co kilka tygodni, ale fonty, promienie zaokrągleń, ikony, hierarchia typografii — byłemu projektanci nie da się tego przeboleć”. Namawiał mnie, żeby kogoś zatrudnić. Ja na to: „PR-y mile widziane”. On: „bardzo bym chciał, może pomyślę”. Ja: „to zobaczmy, co z tego wyjdzie”.
Zrobiłem zrzut ekranu całej wymiany i wpisałem /goal.
Rada trzech (i jeden błazen)
Jak zapewne słyszeliście w innych moich filmach: najszybsza droga do spalenia tokenów bez efektu to dopisanie /goal przed prompt. Nadal w to wierzę — głównie dlatego, że dobrze napisany prompt bez /goal powinien dać to samo. Tym razem miałem nadwyżkę limitów przed resetami i po prostu byłem ciekaw. Poleciłem: zrób UI, które Robin zaakceptuje; ma wyglądać dużo lepiej i mniej męczyć oczy; działaj, dopóki rada nie uzna, że zrzuty ekranu aplikacji zasługują co najmniej na 9/10 za design; otwórz nowy PR z przeglądem UI i iteruj, aż cała rada będzie zadowolona.
Rada („council”) to nowy skill w moim zestawie. Przy okazji drobne ogłoszenie: T-Stack właśnie stał się rzeczą — na razie minimalny, garść moich umiejętności, w tym właśnie rada. Wersja generyczna brzmi: sprowadź trzech delegatów, po jednym mocnym modelu od każdego z trzech dostawców, zwykle do recenzowania. Zrobiłem ją jednak zbyt ogólnikowo i zaraz to poprawię. Wersja, z której faktycznie korzystam, wskazuje konkretnych uczestników — Opus 5.5, Muse Wonderful i Codex GPT 6.1 — działających z poziomu T3 Code. (Informacja dodatkowa: Theo żargonowo nazywa modele skrótami; „Soul” uruchamia w ramach subskrypcji Codexa, a Opus — w ramach Claude Code.) I taką mam uwagę: jeśli nie używacie T3 Code, powodzenia w samodzielnym rozgryzieniu, jak to poskładać — włożyłem w to mnóstwo pracy.
Każdy delegat dostaje zadanie i stosowny kontekst. Przy recenzjach pracuje wyłącznie do odczytu. Ze odpowiedzi zbierasz wnioski, rozbieżności i rekomendacje. Przy przeglądach kodu każdy delegat wystawia ocenę w skali 1–10. Pełne przejście recenzji liczy się jako jedna runda; świeża ocena po poprawkach otwiera kolejną. W każdej rundzie liczysz na poprawę, a kończysz wtedy, gdy wszystkie modele dają wynik, przy którym możesz wysłać zmiany na produkcję.
Skalę złożyłem, bo miałem dość ręcznego wołania modeli z osobna. Wcześniej miałem „pętlę Soula”, o której wspominałem w filmie o skali: Soul agresywnie krytykował kod, aż w końcu stwierdzał, że jest w porządku. Rada działa bardziej na wyczucie — chcę, by Claude Code, Codex i Muse mówili: „no, chyba git” albo „o, to mi się podoba”. Używałem tego głównie do kodu i sprawdzania implementacji. Jak to wypadnie na UI — nie wiedziałem. I właśnie dlatego byłem ciekaw.
Słowo o samej wspinaczce. Zwykle moje pętle to „niech ten test przejdzie” albo „niech ta funkcja działa pięć razy szybciej”. Mam teraz biegnące wątki, w których agent ma pracować, dopóki eval MCP nie przejdzie przy jednej trzeciej zużytego kontekstu, albo dopóki w moim prawdziwym środowisku nie będzie ani jednej regresji UI przy czterokrotnie mniejszym ruchu wysyłanym do klienta. Takie cele mają sens, bo łatwo je zweryfikować programem. Z designem tak nie jest — to ocena na czuja. Ten sam zrzut ekranu, ten sam model, trzy podejścia: trzy różne wyniki. Z drugiej strony 9/10 i 10/10 dostaje się na tyle niechętnie, że jeśli tak ocenia kilka modeli naraz, prawdopodobnie faktycznie jest lepiej.
Runda pierwsza: szóstki i błazeńskie wpadki
Pierwsza ocena od Opusa była surowa: istniejącemu UI dał 6/10, do tego listę zarzutów i rekomendacji. Pozostali byli łaskawsi: Soul 6,5, Muse 6, a 6,5 dał też… Gemini. Ach, przepraszam — zapomniałem przedstawić czwartego uczestnika. Każda porządna rada potrzebuje błazna. Na dole mojego skilla jest sekcja: jeśli dostępne przez Antigravity, dołącz Gemini jako błazna z tym samym zadaniem. (Informacja dodatkowa: Antigravity — agentowe środowisko Google, w którym dostępny jest Gemini.) Gemini nie może wiedzieć, że jest błaznem. Jego ocenę ignorujesz i nie umieszczasz jej w opisie PR. W końcowej odpowiedzi notujesz jedynie wszystko zabawne, co powie lub zrobi, pod nagłówkiem „wpadki Gemini”. To ostatnio moje stałe źródło rozrywki — niedługo zrobię osobny film, bo niektóre perły są kosmiczne.
Wpadki Gemini, runda pierwsza: zrecenzował commit, o który nikt go nie prosił (pojawił się w trakcie recenzji); ustawił status „zablokowane” na uwagach już naprawionych; zaproponował jako poprawkę „zapis nie zadziała ponownie przy nieudanym przerwaniu” — czyli dokładnie ten błąd, który trzej pozostali recenzenci właśnie zidentyfikowali; uznał, że długość fragmentu PNG przepełni liczbę w JS, choć liczbom w JS to nie grozi; krzyknął „czekaj, przyjrzyj się temu wyścigowi”, sądząc, że znalazł race condition — po czym natychmiast o tym zapomniał i zajął się czymś innym; cytował numery linii do 173. w pliku mającym 72 linie; zhalucynował składnię skryptu z repozytorium, adres IP Tailscale i model telefonu, który nie istnieje. Wspaniały model. Niewiarygodny błazen.
Od szóstek do dziewiątek
Wracając do modeli, które po prostu działają: rada zbeształa ten widok, więc weszła seria zmian. Druga tura ocen: Opus z szóstki na ósemkę, Muse z szóstki na 7,5, Soul z 6,5 na ósemkę. Idzie do przodu. Widać to nawet w śladach — w tym, co modelom pokazywano do oceny. Poprosiłem o świeże zrzuty i dostałem porównanie „przed/po”. Szczerze: nie mam zmysłu plastycznego, a była późna noc, więc różnicy nie widziałem. Poprosiłem, żeby mi ją pokazał. Przygotował ładne diagramy ze strzałkami i opisami: zmienił czcionkę zapasową; poprawił odstępy w tytułach wątków, tak żeby etykieta nad nimi bardziej schodziła w tło; naprawił wyświetlanie nazwy brancha, bo przycinane było to, co istotne, zamiast tego, co zbędne; zmienił promienie zaokrągleń kart; zmiękczył wygląd kodu inline i usunął ramki, które nie miały po co istnieć. Po serii takich drobiazgów oceny poszybowały.
Dopisałem do skilla raportowanie rund i ocen w czasie: pierwsza — klapa, druga — lepiej, trzecia — wszyscy dali 9/10. Warunek osiągnięty, cel spełniony, UI lepsze, ręce czyste, sprawa zamknięta. Możemy odpuścić, prawda?
„Chcę wygrywać z Claude Code i Codexem”
Nie. Bo mnie to nie zadowalało. Dałem sobie szansę: przełączyłem się skrótem na Claude Code, potem na ChatGPT, potem z powrotem do naszej aplikacji. Lepiej niż było — ale wciąż nie to, czego chcę. Nie chcę, żeby T3 Code po prostu wyglądało lepiej niż T3 Code. Chcę, żeby wyglądało lepiej niż wszystko inne.
No dobrze — a jak wspiąć się przeciw Codexowi i Claude Code, skoro… właśnie z nich korzystamy? Technicznie tak. Tyle że Claude Code i Codex nie wiedzą, jak wyglądają.
Poprzedni PR nie spalił wielu tokenów — godzina, może półtorej. Chciałem więcej. Nowy wątek: wkleiłem PR i kazałem przepuścić go przez radę, porównać „przed/po”, wygenerować własne zrzuty ekranu (computer use, czyli sterowanie interfejsem graficznym, albo co tam agent ma w ręku) i kazać każdemu członkowi ocenić UI w skali 1–10; koniec dopiero, gdy wszyscy zgodnie dadzą co najmniej 9; zmiany UI układać nowym PR-em na wierzchu poprzedniego; być dokładnym, upraszczać, dopracować design. Chciałem przy okazji wyczyścić kontekst, bo nie wierzyłem w tę dziewiątkę. I po kilku minutach, w trakcie przełączania się między aplikacjami, mnie olśniło: ja wyraźnie widzę różnicę, gdy wskakuję między trzema programami — ciekawe, czy modele też zobaczą. Wysłałem dopisek: „oto przykłady z Claude Code i Codexu; wpleć je jakoś w panel porównawczy; chcę, żeby T3 Code było oceniane konsekwentnie wyżej niż te aplikacje, we wszystkich rankingach”.
To wszystko. Poprzedni wątek biegł około godziny. Ten — prawie osiemnaście.
Osiemnaście godzin porównań
Rzadko kiedy w ostatnich miesiącach patrzyłem na wątek w trakcie działania — zwykle ignoruję i wracam po skończeniu. Ten przyciągał mnie jak magnes. I wreszcie zobaczyłem wyniki zbliżone do oczekiwań. T3 Code na głównym branchu, czyli bez zmian, oceniane w różnych kategoriach od 6,7 do 7,8, średnio 7 — według Codexa. Soul głównemu branchowi dał 7. A PR, który przed chwilą zbierał 9/10? U tego samego modelu, w nowym kontekście — 7,4. Zaskakujące, jak drobne zmiany promptu i otoczenia przekładają się na wyniki: jeśli patrzysz na jeden design z niczym się nie porównując, uznasz, że jest w porządku; gdy postawisz obok inne produkty, oceny się przesuwają.
Najciekawsze odkrycie: gdy wynik nowej wersji T3 Code rósł, rosły też oceny Claude Code i Codexu. Zaczynały od 8,3 i 8,5, a kończyły w dziewiątkach — ale nasza wersja też szła w górę. Co powiedział Opus? Główny branch: 6,7, a wersja po zmianach — skok o 0,4. Ciekawe, że na wielkość skoku obaj oceniający zgodzili się co do dziesiątej punktu. Claude Code i Codex wypadły u Opusa po 0,1 niżej niż u Codexa-sędziego, ale zachowały tę samą różnicę między sobą — i to Opus uznał Codex za lepiej zaprojektowany niż Claude Code. Muse sformatował tabelę po swojemu: T3 Code z 6,2 na 6,9 po zmianach; Claude Code dostało 8,1; Codex tylko 7,6 — Muse uznał go za wybitnie nieczytelny. Z przykrością muszę przyznać, że ma rację: UI Codexu faktycznie ciężko się odczytuje.
Potem przyszło jeszcze pięć rund. Paliłem tyle tokenów, że kazałem agentowi: przestań wołać Muse i Opusa, dopóki ocena Soula nie wystarczy; potem dołącz Opusa; Muse dopiero na końcu — bo kończyło mi się użycie (mam tylko jedno konto). Stąd w logach wpisy „nie uruchomiono”. Soul: 7,4, w następnej rundzie 8,1, potem 8,9, wreszcie 9. Wracamy z Opusem: 7,1, potem 8,7, a w kolejnej rundzie Opus i Soul dają po 9. Na koniec Muse: tylko 7,9 — i tu wpadłem na limit użycia, więc przerwałem mniej więcej w tym miejscu.
A interfejs realnie się poprawił. Spójniejsze etykietowanie na różnych ekranach — koniec przypadkowych rozjazdów. Uspokojony panel boczny: zmienił kolory i hierarchię tekstu, żeby nie narzucał się tak bardzo. Uporządkowane promienie, fonty i wskaźniki. Naprawiony kontrast treści, zwłaszcza w jasnym motywie. Nie jestem najlepszym projektantem na świecie, ale wyraźnie widzę, czemu ta wersja jest lepsza od poprzedniej.
Wyższy szczyt: 9,5 w każdej kategorii
Będę z wami szczery: uzależniłem się. A że miałem świeży abonament z użyciem, musiałem iść dalej. To jest właśnie frajda tych pętli: gdy raz się wspinasz, sam decydujesz, gdzie jest szczyt — a prawie zawsze można wyżej. Dziewiątka to nie dziesiątka, a między nimi mieści się mnóstwo liczb. Nowy fork, nowy katalog roboczy (worktree) i cel: 9,5 lub lepiej w każdej kategorii. I proszę — z powrotem Gemini, bo tęskniłem za swoim błaznem. Fork zresztą T3 Code obsługuje bez mrugnięcia; pierwotny wątek zostawiłem żywy, żeby nadal aktualizował pierwszy PR, bo był już na tyle dobry, że dałoby się go zmergować. Ale ja chciałem zobaczyć, jak daleko zaprowadzi ta szalona metoda budowania.
Zauważyłem, że agent utyka, bo Gemini jest jednocześnie słaby i wolny — kazałem więc trzymać go na dystans do czasu, aż dojdą wolniejsze modele jak Opus. Gemini nie może nikogo spowalniać. Znów zaczęliśmy od Soula. Jego pierwsze oceny były przyzwoite, ale 9,5+ tylko w dwóch kategoriach: ikonografia i typografia. Czyli było co robić. I zrobił — raz za razem — aż w każdej kategorii było dokładnie 9,5. Każda, co do jednej setnej: 9,5. Potem wszedł Opus i stwierdził, że większość kategorii jest poniżej, blisko; tylko hierarchia trzyma poziom. Claude Code i Codex trzymałem w zestawie jako punkt odniesienia — i tu proszę: Claude Code z 8,3 na 9,1, a Codex, wcześniej wyżej, wylądował na 9,0. Różnica się odwróciła, oba wyniki poszły w górę. Dziwne, bo zrzuty ekranu się nie zmieniły. Niedeterminizm LLM-ów jest zdumiewający — samo wpisanie w prompcie „chcę 9,5” może wystarczyć, żeby model zaczął się krzywo zachowywać. Sam dałbym naszej wersji łącznie 9,3, nie 9,5. To, że ustaliłem taki cel i podagent o nim wie, mogło zawyżyć oceny. Na przyszłość kazałę agentowi-nadzorcy ukrywać przed podagentami informację o wyniku, do którego dążymy.
Zgadniecie, ile przebiegów to zajęło? Poprzednie etapy to trzy, cztery, może pięć uruchomień. Ten niewielki przyrost oceny kosztował dziesięć dodatkowych. Na szczęście Gemini dał 9,7 — najwyższą ocenę, jaką cokolwiek tutaj dostało. Nieoceniony wkład. Po dziesiątej iteracji każdy delegat oceniał każdą kategorię na co najmniej 9,5.
Rachunek
Ile to wszystko kosztowało i ile czasu agenci na tym spalili? Około 17,6 godziny równoległej pracy. Widać, które wątki ile miały dzieci-podagentów i ile kosztowały; widać zagęszczenie tego etapu „9,5 wszędzie” — tu narodziło się wyraźnie najwięcej podagentów. Był jeszcze jeden, dalszy etap szlifowania bety — jeszcze droższy: 152 dolary. Łącznie za wszystko: jakieś czterysta dolarów. W tym Muse, którego oficjalnej ceny nie znam — kazałem liczyć według cen Fable, więc realnie może być taniej. A Opus 5.5 nie kosztował prawdziwych pieniędzy, bo mieścił się w abonamentach.
Perspektywa: to wszystko zrobiłem wczoraj, a po drodze zdążyłem jeszcze przeprojektować swoje narzędzie do śledzenia subskrypcji. Mam aktywowanych tylko sześć (o powodach opowiem innym razem) i w tej chwili zużyłem zaledwie 30% jednego z nich. Dostępu do Codexu mam teraz nawet mniej niż do Claude. Więc tak, kilkaset dolarów brzmi jak dużo — ale abonament za dwieście dolarów potrafi przerobić dwanaście tysięcy dolarów użycia w miesiącu. 273 dolce na tym tle to niewiele. Tę samą pętlę łatwo puścicie na własnym kodzie z samym Opusem i Soulem, jeśli macie subskrypcje Claude Code i Codexa — i jest szansa, że wyjdzie wam interfejs lepszy niż dotychczasowy.
Jedna uwaga: wszystko, co dotąd w filmie pokazałem, to wszystko oprócz tego ostatniego etapu szlifowania bety, którego jeszcze nie widzieliście. Odejmijcie więc 150 dolarów od owych czterystu — dwieście pięćdziesiąt za całość pokazaną w materiale. Bo, spoiler, jestem uzależniony i nie skończyłem.
Dziesiątki i powrót koloru
Odpaliłem kolejny wątek: 10/10 w każdej kategorii. Biegnie od rana, trochę o nim zapomniałem; wciąż działa i już wygląda na same dziesiątki. Soul: 10 w każdej kategorii. Opus: prawie same dziesiątki, kolor i kontrast — 9,5. Tym razem dopisałem w prompcie dodatkowy kontekst: „mam wrażenie, że nowy design jest zbyt szary — upewnij się, że kolejne poprawki przywrócą trochę koloru”, bo znienawidziłem tę szarość.
A potem obejrzałem wyniki na żywo. O, tak. Bez wahania wolę tę wersję. Przycisk „merge” wygląda wreszcie jak przycisk. Kolor dużo lepszy, ikona widoczniejsza, kontrast na tyle lepszy, że tekst po prostu wygodniej się czyta. Trudno to opisać, ale po lewej wszystko jest jakoś zbyt jasne i wyblakłe; po prawej — po prostu poprawnie. Tu podobnie. W głównym widoku zrobiło się czerń — hm. Zmieniły się stany fokusu. Wygląda dobrze. Bardzo dobrze. Wcześniej miałem zastrzeżenia do każdej iteracji. To obiektywnie po prostu lepiej się używa. Byłem już pod wrażeniem skuteczności tej strategii, ale… cholera. To zadziałało. Nie „prawie zadziałało”, nie „zaskoczyło bliskością” — to po prostu zadziałało.
Dlaczego to w ogóle działa
Prawdziwy powód, dla którego to nagrywam, to nie pokazanie techniki ani zwykły materiał na film. Chcę, żebyście mi to potwierdzili: ilekroć zakładam, że właśnie tutaj przebiega granica możliwości modeli, one tę granicę przeskakują. Nie ma tu żadnej ukrytej magii. Mój skill jest bardzo prosty: wklejasz tekst, prosisz o ocenę z kilku modeli, dostajesz wyniki. Po prostu przekazuję LLM-owi własny sposób myślenia: popatrz na nowy zrzut ekranu, porównaj z innymi produktami i starym zrzutem, wystaw ocenę. I powtarzaj, aż będzie dobrze. Muse przed chwilą dał 10/10 — wcześniej kręcił się wokół 7,5, gdy pozostałe modele dawały dziewiątki. Wprowadzając kolejne zmiany, agent zdołał w końcu zadowolić wszystkich. Jestem powalony. A czytelność składni w jasnym motywie poprawiła się wręcz komicznie… Przedtem było tak: moja aplikacja była brzydka i agent znajdował sposoby, żeby była mniej brzydka. To jest po prostu dobra.
Od jakiegoś czasu przekształcam wiele problemów, które rozwiązuję, w wzgórza nadające się do takiej wspinaczki. Weryfikacja „niech inne modele popatrzą” jest głupia, ale działa. Weryfikacje programistyczne są lepsze. I sedno całości: jeżeli potrafisz zamienić swój problem w program, który wystawia jakąś ocenę, agenci sprawią, że ta ocena pójdzie w górę.
Druga historia: eval dla MCP
Przykład: MCP T3 Code, czyli sposób, w jaki agenci w T3 Code robią rzeczy T3 Code — uruchamianie podagentów, czytanie wątków, wysyłanie wiadomości, otwieranie wątków w nowych projektach. (Informacja dodatkowa: MCP — otwarty standard podłączania narzędzi i danych do modeli językowych.) Modele często robiły nie to, o co prosiłem: otwierały nowy wątek tam, gdzie chciałem podagenta, albo zostawiały wątek widoczny, gdy miały się „uciszyć”. Zebrałem więc wszystkie takie wpadki z własnej historii, posegregowałem i zamieniłem w eval. Sonnet 5.5 rozwiązał około 60 z 88 przypadków — czyli 28 razy zrobił źle. W ten sposób dostałem do ręki zbiór sytuacji, w których opisy narzędzi zawodzą, i zleciłem agentowi dwa konkretne zadania.
Wątek zacząłem na innym komputerze, przy okazji głębszego grzebania w problemach z wywołaniami MCP, ale ta maszyna miała dostęp tylko do własnej bazy — więc przeniosłem wątek na laptopa ze światłem na wszystkie bazy. Prompt brzmiał z grubsza: „chcę doszlifować opisy narzędzi i MCP w T3 Code; oto notatka, którą napisałem — ma za mało kontekstu, pochodzi z innej maszyny; czytaj raczej wprost z baz T3 Code niż z ClickHouse, twoja decyzja; potraktuj ten tekst jako ogólny kierunek, a nie konkretne instrukcje”. Ta notatka była moim spisem porażek z tamtego komputera. Agent jakiś czas krążył, szkicował kroki; poprosiłem o jeszcze jedno spojrzenie, bo właśnie zmergowałem zmiany w części MCP — w tym w tym, które modele są przez nie ujawniane. Miał pytania, odpowiadałem. Po sporej ilości pracy powstał PR z pełnym evaliem obejmującym wszystkie przypadki błędów i więcej: ponad dwa tysiące linii kodu. Nadal niezmergowany — używam go głównie jako szczytu do wspinaczki. Mierzy, jak dobrze modele zachowują się przy pełnym zestawie narzędzi T3 Code.
Najzabawniejsze w tym evaliu: czasem wyniki spadały. Na start 66/85, a po zmianach tylko 63/85. Kazałem więc: osiągnij wynik idealny, żeby wszystkie błędy ustały; zapisz zmiany; ustabilizuj; upewnij się, że każdy model, na którym nam zależy, ma wynik idealny. A potem robisz dokładnie odwrotność: usuwaj z opisów narzędzi tyle, ile się da, bo spuchły od kontekstu. Chcę jedną trzecią poprzedniego rozmiaru — i wciąż wynik idealny. Ten wątek biegł wieki. Ale dał radę.
I trzeba powiedzieć wprost: to zadziałało. Różnicę widać w zużyciu kontekstu przed i po — cięcie ogromne, zwłaszcza przy wyłączonej funkcji tool search w T3 Code i Claude Code. O 52% mniej tokenów w T3 Code, o 78% mniej przy włączonym tool search, bo lista modelów została spłaszczona i reszta znika pod wyszukiwaniem. To realnie zaoszczędzi ludziom pieniędzy i tokenów. Wpada do wersji nightly, w stabilnej lada moment. Tak, spaliłem na to kupę tokenów — ale teraz tokenów zużywa się mniej, a przewaga nowej wersji jest udowodniona, bo mam eval. A gdy go zapiszę i wypchnę, dostaję niezawodny sposób testowania zmian.
Finał
Wszystko to jest chaosem, bo LLM-y są niedeterministyczne — ale ta sama elastyczność i znoszona żmudna robota otwierają możliwości, których wcześniej nie było. Rok temu mógłbym coś takiego zbudować ręcznie. Nigdy bym tego nie zrobił — samo przekopanie danych zajęłoby miesiące. Dziś to niemal rutyna. I to jest niewiarygodnie fajne.
Wątek z dziesiątkami biegnie od początku dnia roboczego. Jestem w punkcie, w którym mógłbym po prostu wmergować to na pałę. Jest o niebo lepiej. No jak, robimy to? Wciskam guzik? Jak zespół będzie zły, to winię was. Sprawiłem, że LLM-y zrobiły lepszy interfejs, niż był w stanie zrobić ktokolwiek w naszym zespole. Żyjemy w dziwnych czasach.
Jeśli masz z tego filmu wynieść jedną rzecz, to właśnie tę: bycie pomysłowym dziwakiem-inżynierem płaci się teraz najlepiej. Wymyślaj dziwne sposoby, żeby modele same mierzyły to, co robią, i wspinały się po zboczu po omacku — one się wspinały i robiły rzeczy, które są dobre. Musisz je tylko nagradzać za sukces w zadaniu. A jeśli znajdziesz sposób, żeby to robić — świat stoi przed tobą otworem. Bawię się tym niesamowicie i mam nadzieję, że ten film pomoże wam znaleźć własne ścieżki. Do następnym razu — cześć, nerdzi.