Shippuję tak codziennie (produkty i feature'y dla prawdziwych użytkowników, nie „linijki kodu”): sesje trwające tygodniami, 5 subskrypcji, $30k miesięcznie na tokeny, agenci piszący kod, którego nie czytam. Kiedy Anthropic opisał, jak zespół Claude Code robi code review (artykuł (si apre in una nuova scheda)), a Theo przeczytał to na wideo (tutaj (si apre in una nuova scheda)), rozpoznałem swój własny proces. Tam, gdzie się nie zgadzają, prawie zawsze jestem po stronie Theo.
Ich liczby mówią to, co widzę u siebie. W Claude Code liczba zmergowanych PR wzrosła między czerwcem a wrześniem ponad dwukrotnie, a odsetek revertów spadł o ponad 40%. Theo dostaje do 800 PR dziennie na T3 Code przy zespole trzech osób. Większa prędkość i mniej błędów jednocześnie. Oto jak utrzymuję to u siebie.
Czytanie diffu nigdy nie było safety net
Nie czytam każdej linijki i pracuję przez to lepiej. Błędy, które dziś przechodzą, żyją między kawałkami systemu, w czasie i w danych, a wpatrywanie się w kod rzadko je znajduje. Theo mówi, że prawie każda regresja, którą shippował, przeszłaby też przez jego review, i moje doświadczenie jest takie samo. Zadaję pytanie, które Anthropic dobrze formułuje: co może pójść nie tak z tą zmianą i który check, automatyczny czy ludzki, powinien to złapać?
Review zawsze robi u mnie model z innej rodziny. Tej jesieni, w projekcie badawczym o uruchamianiu agentów kodujących w sandboxach, zleciłem dwa niezależne review mojego kodu: oba znalazły prawdziwe problemy, a każdy fix wszedł z testem, który przed nim nie przechodził, a po nim przechodził. Theo nazywa swoją wersję Council: trzy modele z trzech rodzin, na subskrypcjach. Uważa produkt review od Anthropic za zbyt drogi przy tym tempie i zgadzam się z nim. Dziś reviewerzy, którym nic nie umyka, to GPT-6.1 Sol i Astra. Bugi, które przechodzą przez review Opusa i Astry, to bugi, których nigdy bym nie znalazł, wpatrując się w kod intensywnie i z pasją. Ty też nie. Moja praca to decyzja, które findingi mają znaczenie.
Każda zmiana przychodzi zweryfikowana
Anthropic pisze, że większość zmian przechodzi review Claude'a, zanim zobaczy je człowiek. Theo mówi, że wszystkie, i ja też: PR, którego twój agent nie zweryfikował, marnuje czas tego, kto go czyta. U mnie Claude dosłownie testuje feature tak, jak zrobiłby to użytkownik: żadnych sMoKe TeStS „trust me bro”. Boris Cherny, twórca Claude Code, szacuje, że danie agentowi sposobu na samosprawdzenie poprawia wynik dwu- lub trzykrotnie. Theo pozwala nawet każdemu wątkowi otworzyć własny pulpit, uruchomić aplikację i dołączyć do PR wideo działającej zmiany.
Najwięcej o weryfikacji nauczył mnie zielony zestaw testów. W tym samym projekcie testy, które potrzebowały kontenerów, po cichu same się skipowały, gdy silnik kontenerów był wyłączony. Run mówił, że jest zielono, a znaczyło to tylko, że zielone były testy, które się wykonały. Weryfikacja musi mówić, co się uruchomiło, co skipnięto i co zostało do zrobienia. W Company Brain Yempik to reguła każdego release'u (historia jest tutaj).
Review czyta mój agent. Ja czytam werdykt.
Tu jestem z Theo do końca. Komentarze z review są dla agenta, który napisał PR: to on decyduje, który feedback jest dobry, fixuje i dopiero wtedy mnie woła. Ręczne kopiowanie sugestii reviewera do promptu to robota z 2024 roku. Warstwy checków dokładają jednak też kod: Theo widział PR na 50 linii, które urosły do 2000, bo agent posłuchał każdego komentarza. Dlatego finding trzeba zweryfikować, zanim ktokolwiek na jego podstawie zadziała.
Ludzka uwaga idzie za ryzykiem
Tier ustala zmiana, nigdy autor. Docs i copy za flagą przechodzą bez człowieka, gdy checki są zielone, ryzykowny kod wymaga jednej lub dwóch osób, workflowy CI zawsze przechodzą przez człowieka. Anthropic stosuje stałe tiery: zero, jedna albo dwie osoby. Theo chce je dynamiczne, z botem, który opisuje ryzyko i nigdy nie wybiera, kogo otagować, i wolę jego wersję. Jednej reguły nie negocjuję: zatwierdzenie bota nigdy nie zastępuje mojego. To finding, a podpis jest mój. Autorem zmiany jest ten, kto ją zlecił w prompcie.
Najbardziej przydatne review tej jesieni nie dotyczyło błędów. Agent otworzył PR na tej stronie z nowymi stronami usług: build zielony, fakty sprawdzone, wszystko na swoim miejscu. Zamknąłem go tego samego dnia, bo kierunek był zły: za bezpiecznie, za dużo tekstu przy zbyt małej wartości. Żaden check by tego nie złapał. Decyzja, czy coś w ogóle ma istnieć, to część review, która zostaje ludzka.
Pętla review potrzebuje stopu
Przy mojej skali to najważniejsza reguła. Przy sesjach trwających tygodniami pętla, której nikt nie zatrzyma, wysysa ci cały weekly limit. W Anthropic jeden PR przeszedł w ciągu nocy ponad 50 roundów review i fixów, a około 59% tego, co reviewer wciąż zgłaszał, było kodem obecnym od pierwszego roundu. Theo zapomniał o pętli w zwiniętej karcie i po czterech dniach PR miał około 80 000 linii. Noise kosztuje więcej, gdy autorem jest agent: człowiek zignoruje nit w kilka sekund, agent go fixuje, z kolejnym commitem i kolejnym roundem.
Fix jest prosty. Cap na trzy roundy, potem reviewer prosi o przemyślenie podejścia. Po pierwszych roundach review tylko nowego diffu. Zgłaszaj klasę błędu zamiast pojedynczej linii i nigdy nie powtarzaj findingu. Dzięki tym regułom Anthropic zbił średnią liczbę review potrzebnych do przejścia z 2,08 do 1,32. Mój próg to wynik pewności zamiast liczby komentarzy: PR z jednym komentarzem i oceną 6 na 10 idzie przed PR z dwudziestoma nitami i oceną 9 na 10. Tę lekcję zapłaciłem już wcześniej retry'ami (tutaj).
Zwolnienie niczego nie naprawia. Tani rollback tak.
Zwolnienie obniża odsetek błędów głównie dlatego, że robisz mniej wszystkiego. Jeśli twoim sposobem, żeby nic nie psuć, jest zwolnienie, po prostu zrobiłeś mniej. Zespół, który robi brrrr, musi nauczyć się sprawiać, żeby błędy były tańsze i łatwiejsze do zrevertowania. Wolę szybciej zauważać i fixować: flagi wyłączane bez deployu, najpierw użycie wewnętrzne, stopniowy release, rollback w jednym kroku. Kto wprowadza zmianę, ten ją fixuje, jeśli się zepsuje, bo ma najwięcej kontekstu.
W Intarget tego lata zmieniliśmy sposób, w jaki platforma agentowa zapisuje rozmowy, podczas gdy ludzie używali jej codziennie. Stary storage dalej dostawał każdy zapis równolegle, jako droga powrotu za zero kosztów. Odczyty przeszły za flagę. Starą kopię usunęliśmy dopiero po powtarzanych porównaniach z zerową liczbą różnic. W każdej chwili rollback był jednym switchem. Przed każdą ryzykowną zmianą zadaję sobie dwa pytania: jak ją zrevertuję i jak szybko zauważę, że muszę to zrobić.
Reviewer ma własny eval set
Reviewer to model plus harness jak każdy inny agent, więc traktuję go tak samo. Incydenty i reverty stają się jego eval setem, a zmiana promptu, narzędzi albo modelu zostaje tylko wtedy, gdy wynik rośnie. Anthropic mierzy też noise, uruchamiając reviewera na PR, o których wie, że są czyste. Reguła, którą stosuję wszędzie, działa i tutaj: wynik zmierzony na cudzej pracy nic nie mówi o twojej.
Najmocniejszy zarzut: to działa w Anthropic, a nie w małym zespole
Działa u Theo, który ma trzy osoby i żadnej merge queue, i działa u mnie. Do tego tygodnia ta strona nie miała nawet szablonu PR: bramką były zielone build, lint i typecheck na mojej maszynie, a potem build platformy. Warstwy kosztują niewiele: szablon, reviewer AI na jednym repo, cap na roundy, flaga. Tym, co się nie skaluje, jest traktowanie ludzkiego czytania jako gwarancji. Od tego eseju każdy PR na stronie zaczyna się od szablonu, który pyta o Testing, Risk i How to revert.
Od poniedziałku
- Daj agentowi sposób na weryfikację jego pracy i proś o output, nigdy o „gotowe”.
- Dodaj do szablonu PR sekcje Testing, Risk i How to revert.
- Postaw na jednym repo reviewera AI z innej rodziny modeli, przez kilka tygodni dostrajaj to, co zgłasza, potem rozszerz.
- Komentarze z review niech czyta agent, który napisał PR. Ty czytasz werdykt.
- Tier ustalaj na podstawie zmiany, nigdy autora. Zatwierdzenie bota nigdy nie liczy się jak zatwierdzenie człowieka.
- Daj cap na roundy review, a po pierwszych sprawdzaj tylko nowy diff.
- Spraw, żeby każdą ryzykowną zmianę dało się zrevertować jednym switchem.
- Zamień incydenty i reverty w eval set dla swojego reviewera.
// sesje trwające tygodniami, $30k miesięcznie na tokeny. przy tej skali albo masz stop, albo za niego płacisz.