Jak Claude poprawia własny kod

O czym jest ten film

Theo omawia wpis inżynierów Anthropic o tym, jak zespół Claude Code recenzuje kod w czasach agentów — i komentuje go na bieżąco, porównując z procesem własnej trzyosobowej ekipy, która dostaje do 800 pull requestów dziennie.
W monorepo Anthropic liczba zmian trafiających na główną gałąź wzrosła z 2,5 tys. dziennie w maju do ponad 30 tys. we wrześniu — ręczne przeglądanie linia po linii stało się fizycznie niewykonalne, a sam zespół Claude Code przestał używać Gita i GitHuba, bo go spowalniają.
Kluczowa zmiana filozofii: pytanie „czy człowiek czytał ten kod?” to bardzo niedokładna miara. Liczy się „co może się zepsuć i który sprawdzian — automatyczny czy ludzki — wyłapie problem”.
Recenzja przestała być bramką na końcu drogi, a działa jak sprawdzanie pisowni podczas pisania: większość zmian jest już sprawdzona i poprawiona przez Claude, nim człowiek cokolwiek zobaczy (zdaniem Theo — powinna być wszystkie).
Każda zmiana przechodzi przez warstwy: weryfikacja u autora (testy, build, drugi agent na świeżo), CI, recenzja AI (kilka agentów szuka błędów, a inna grupa głosuje, czy znalezisko jest prawdziwe), osobny przegląd bezpieczeństwa i klasyfikacja ryzyka decydująca o liczbie ludzi potrzebnych do zatwierdzenia.
Wskaźniki cofnięć i incydentów pełnią rolę czujnika: jeśli rosną po odchudzeniu review, to ludzkiego czasu się nie oszczędziło — tylko przeniosło go na naprawianie szkód.
Recenzje muszą się kiedyś skończyć: pętla „agent poprawia — agent krytykuje” potrafi kręcić się w nieskończoność (ponad 50 rund u Anthropic; u Theo cztery dni i 80 tys. linii kodu). Ratują limity rund, ponowny przegląd samego diffu i ocena 1–10 zamiast liczenia uwag.
Ludzie zostają tam, gdzie trzeba ocenić, a nie sprawdzić: czy w ogóle coś budować, przegląd kodu ryzykownego (billing, autoaktualizacja, CI), architektura, czytanie dowodów (wyniki testów, nagrania, screenshoty) i odpowiedzialność za wynik.
Skoro maszyny czytają kod, wiedzę o nim buduje się inaczej: prosi się Claude o objaśnienie konkretnego fragmentu lub wizualizację, pracuje w otwartych kanałach, a połowę PR-ów po prostu zamyka, gdy kierunek okazuje się zły.
Theo koryguje jedną poradę z artykułu: zanim sięgnie się po pliki z instrukcjami (CLAUDE.md, review.md), trzeba naprawić sam kod i wzmocnić analizę statyczną. Całość domyka gotowa lista wdrożeniowa „przed / w trakcie / po” PR.

10 najważniejszych takeaways — z kontekstem zastosowania

1.Recenzja kodu to proces ciągły, nie bramka na końcu

Na czym polega: W Anthropic review działa przez cały czas pracy — jak sprawdzanie pisowni w edytorze. Większość zmian jest sprawdzona i poprawiona przez Claude, nim jakikolwiek człowiek zobaczy pull request.

Jak stosować: Wprowadź żelazną zasadę: żaden PR nie trafia do człowieka, dopóki agent go nie przejrzy i nie poprawi. U Theo pull request przechodzi osiem i więcej rund agentowego review w ciągu godziny–dwóch, zanim w ogóle poprosi o niego człowieka.

Na co uważać: Wystawianie PR-ów, których agent jeszcze nie sprawdzał, marnuje czas całego zespołu — Theo mówi to wprost i podkreśla, że taka praktyka powinna być piętnowana.

2.Mierz ludzki czas, a cofnięcia i incydenty trzymaj jako czujnik

Na czym polega: Zespół Claude Code optymalizuje „minimum ludzkiego review, które nie podnosi liczby cofnięć ani incydentów”. Mierzą zatwierdzenia na PR, komentarze ludzi i czas oczekiwania PR-a na osobę.

Jak stosować: Wdroż te trzy metryki plus odsetek rewertów i incydentów. Każde uproszczenie procesu oceniaj dopiero po ich zmianie — to jedyny uczciwy test, czy faktycznie coś zyskałeś.

Na co uważać: Mniej pracy ludzi przy jednoczesnym wzroście incydentów oznacza, że koszt nie zniknął, tylko przeniósł się z recenzji na gaszenie pożarów. Warto też pamiętać o „czasie pomiędzy”: oczekiwanie na recenzenta bywa większym wąskim gardłem niż samo sprawdzanie.

3.Daj agentowi sposób na sprawdzenie własnej pracy

Na czym polega: Boris, pierwotny twórca Claude Code, nazywa weryfikację najważniejszym czynnikiem dobrych wyników — jej brak to główny powód, dla którego zespoły narzekają na agentów. Według jego szacunków weryfikacja poprawia efekt końcowy dwu–trzykrotnie.

Jak stosować: Dawaj agentowi rzeczy do uruchomienia: testy, build, zrzuty ekranu do porównania z projektem, a przy interfejsach — środowisko, w którym odpali aplikację i nagra wideo działającej zmiany. Żądaj pokazania wyniku, nie deklaracji „gotowe”. U Theo każdy wątek dostaje własne „biurko” (jak Spaces w macOS), w którym może postawić serwer deweloperski i nagrać działającą funkcję.

Na co uważać: Weryfikacja wygląda inaczej w każdej domenie — od prostego testu po dedykowaną maszynę wirtualną — i bywa trudna do zbudowania. Trzeba jednak znaleźć sposób, bo kod, którego nie da się sprawdzić, to kod, w którym fatalnie pracuje i agent, i człowiek.

4.Naprawiaj problemy jak najbliżej źródła: kod → analiza statyczna → dopiero instrukcje

Na czym polega: Gdy agent powtarza błędy, pierwszym odruchem nie powinno być dopisywanie reguł do plików z wytycznymi, tylko naprawa samej architektury, a potem lintery i typy.

Jak stosować: Trzymaj się kolejności: najpierw kod, w którym łatwo nie pomylić się „na ślepo”; potem statyczna analiza dająca agentowi sprzężenie zwrotne; dopiero gdy to zawodzi — CLAUDE.md, review.md i skille. Wytyczne zmieniaj tylko wtedy, gdy przestają być prawdziwe, a nie przy każdej irytacji.

Na co uważać: Pliki instrukcji rozrastają się łatwo i stają się prowizorką. Theo porównuje to do labiryntu: lepiej zlikwidować dziury w podłodze niż wtłaczać w ciemność coraz dłuższą instrukcję obsługi.

5.Nikt nie powinien ręcznie sortować komentarzy botów

Na czym polega: Agenty i boty recenzujące nie powinny zasypywać ludzi uwagami, z którymi ci musi się zmierzyć ręcznie. Ocena, czy komentarz jest zasadny, to zadanie innego agenta.

Jak stosować: Kilka agentów szuka błędów równolegle, osobna grupa głosuje nad każdym znaleziskiem, a publikowane są tylko te potwierdzone. Uwagi dotyczące stylu i porządku lądują w koszu. Przefiltruj to wszystko, zanim człowiek cokolwiek zobaczy.

Na co uważać: Przyciski „skopiuj prompt z poprawką” to — jak mówi Theo — poziom 2024 roku. Szum drożej kosztuje przy agencie-autorze: człowiek zignoruje czepialstwo w sekundę, agent je „naprawi”, dorzucając commit, rundę review i zbędny kod.

6.Wymuszaj konwergencję: recenzja musi się skończyć

Na czym polega: Agent-autor i agent-recenzent potrafią zajmować się sobą w nieskończoność. U Anthropic jeden PR przeszedł ponad 50 rund overnight; u Theo porzucony wątek „iterował do zgody całej rady” cztery dni i urosnął do 80 tys. linii.

Jak stosować: Limit rund (po trzech recenzent prosi o przemyślenie podejścia), ponowny przegląd tylko zmienionych fragmentów, kategoryzacja błędów (napraw całą klasę, nie jedną linijkę), zakaz powtarzania tych samych uwag. Efekt u Anthropic: średnia liczba rund spadła z 2,08 do 1,32, a odsetek PR-ów wymagających pięciu i więcej rund z 9% do 1,5%.

Na co uważać: U Theo analiza „gita blame” pokazała, że 60% powtarzanych uwag dotyczyło kodu obecnego od pierwszego przejścia — recenzent rzadko znajdował coś nowego. Domyślne odpalanie wielu rund „bo zawsze coś znajdzie” sami sobie szkodzicie.

7.Oceniaj skalą 1–10 z progiem, a nie liczbą komentarzy

Na czym polega: PR z osiemnastoma drobiazgami może być „dziewiątką”, a PR z jedną uwagą „szóstką” — i to ten drugi jest pilniejszy. Liczba komentarzy to zła miara jakości.

Jak stosować: Niech recenzujące agenty zostawiają ocenę od 1 do 10, a ty ustal próg akceptacji. To naturalnie łączy się z dopisywaniem do szablonu PR skali wpływu i ryzyka (u Theo rozważa 1–10: jak bardzo zmiana dotyka użytkowników i ile może namieszać).

Na co uważać: To nie jest jedyna słuszna droga — znajomi z Cursora sugerują, że agent powinien po prostu podejmować decyzje zero-jedynkowe („czy tę uwagę można zignorować?”), tak jak płatny inżynier. Eksperymentuj, aż znajdziesz wariant, który działa u ciebie.

8.Klasyfikuj ryzyko zmiany, nie wybieraj autorów

Na czym polega: System ma określać, jak ryzykowna jest zmiana (u Anthropic: zero, jeden lub dwóch ludzi do zatwierdzenia), a nie wskazywać, kto ma ją obejrzeć.

Jak stosować: Bot opisuje poziom ryzyka, ludzie sami decydują, kto spojrzy. Ścieżki wrażliwe — autoryzacja, płatności, workflow CI, procesy wydawnicze — przypisz konkretnym właścicielom kodu i chroń gałąź główną. Lżejsze ścieżki tylko dla zaufanych autorów; reszta potrzebuje drugiej osoby.

Na co uważać: Zatwierdzenie bota nigdy nie wypełnia „ludzkiego slotu”, a zatwierdzenia dotyczą konkretnych commitów — nowy commit bez gwarancji restartuje proces. Dbaj też o odrębne oznaczenia działań botów, żeby „zatwierdzenie od Theona” było odróżnialne od „zatwierdzenia od bota Theona”.

9.Buduj system pod szybkie cofanie, nie pod powolność

Na czym polega: Jakiś błąd zawsze się prześlizgnie, więc ostatnia warstwa to szybkość wykrywania i cofania: flagi funkcji, użytek wewnętrzny przed publicznym, stopniowe wypuszczanie, jednokrokowy rollback, telemetria i dyżury.

Jak stosować: Trzymaj zmiany małe (łatwe do przejrzenia, debugowania i cofnięcia). Skala potencjalnych szkód wyznacza poprzeczkę: droższy kod dostaje więcej ludzi i sprawdzeń. Po incydencie pytaj, która warstwa powinna go wyłapać.

Na co uważać: „Zwolnij, to będzie mniej błędów” to pułapka — obniża liczbę pomyłek głównie dlatego, że robisz mniej wszystkiego. Zespół Claude Code świadomie wybrał przyspieszanie wykrywania i naprawiania zamiast zwalniania; Theo podpisuje się pod tym obiema rękami.

10.Zamieniaj incydenty w testy, a wiedzę buduj eksplainerami

Na czym polega: Dwie praktyki domykające system: PR-y, które kiedyś spowodowały incydent, trafiają do zestawu testów uruchamianego codziennie przeciwko recenzentowi; a wspólne rozumienie kodu buduje się, prosząc Claude o objaśnienie konkretnego wycinka lub wizualizację, a nie czytając trywialne diffy.

Jak stosować: Zbieraj problematyczne PR-y razem z rewertami, każ ekspertom potwierdzić każdy błąd i puść recenzenta na tym zbiorze każdego dnia — przy każdej zmianie promptu, narzędzi lub modelu mierz wynik od nowa. Do nauki kodu: wklej PR do Claude i zapytaj, co się zmienia, dlaczego i gdzie ryzyko; pozwól zbudować artefakt, który uczy w sposób odpowiadający danej osobie.

Na co uważać: Czego nie zmierzysz, tego nie naprawisz — ale pilnuj też szumu: sortuj komentarze po reakcjach ludzi i testuj recenzenta na PR-ach, o których wiesz, że są czyste. A gdy pojawi się wątpliwość co do kierunku, zgłaszaj ją wcześnie w otwartym wątku — połowa PR-ów Theo kończy zamknięta i to zdrowe.

Redakcyjne tłumaczenie

Nowy problem: potok zmian, którego nie da się już przeglądać ręcznie

O tym, jak wydajnie budować z agentami, mówiłem ostatnio dużo. Zdecydowanie za mało powiedzieliśmy natomiast o komunikacji wokół tego: jak pracować temu zespołowo, jak recenzować kod, co scalać, a co odrzucać, jak zarządzać całą tę machiną — zwłaszcza teraz, gdy tempo dostarczania zapewniają modele pokroju Opusa 5.5. Możecie się domyślić, że zespoły Anthropic, choćby ten odpowiedzialny za Claude Code, doświadczają tego w skali trudnej do ogarnięcia: przestali używać Gita i GitHuba, bo te ich po prostu spowalniają. Jak więc przejrzeć wszystkie napływające prośby o zmiany? Jak udźwignąć taki potok pull requestów?

Sami mierzymy się z tym w T3 Code — zdarza nam się 800 PR-ów dziennie, a przechodzenie przez to trzyosobowym zespołem graniczy z niemożliwego. To po prostu inny świat i review kodu musi wyglądać zupełnie inaczej niż dotychczas. Właśnie o tym dziś rozmawiamy: jak dawać radę z obciążeniem, skoro Opus sprawił, że wystawienie pull requesta kosztuje tyle, co wysłanie prompta. Jak decydować? Jak zarządzać? Mam przeczucie, że będzie ciekawie. Tego wpisu jeszcze nie czytałem — chciałem przerabiać go razem z wami, bo temat nie jest łatwy, a jego rozwiązanie to ważny element ogarnięcia nowej ery inżynierii. Na końcu obiecałem też kilka smaczków o tym, jak udało nam się tak rozpędzić T3 Code. Julie gotuje jak nigdy. Ale zanim wejdziemy w temat — krótki przerywnik sponsorski.

Przerywnik sponsorski: przeglądarka jako usługa

Agenty zrobiły się ostatnio potężniejsze — i nie tylko dlatego, że modele mądrzeją. Większość zysku pochodzi z lepszych narzędzi oraz z tego, że modele uczą się ich sprawniej używać. Spora część codziennych zadań dzieje się w przeglądarce: około 85% API w sieci nie da się po prostu wywołać przez curl — żeby coś załatwić, trzeba wejść na stronę. Możesz to zbudować sam albo skorzystać z dzisiejszego sponsora, Browserbase. W najprostszym ujęciu zamieniają całą sieć w programowalne API: wyszukiwanie, pobieranie treści w formacie HTML, JSON czy markdown, a także klikanie, nawigowanie, wypełnianie formularzy czy przechodzenie CAPTCHA — bo to jest właśnie „przeglądarka jako usługa”. Jeśli nie masz pomysłu, poproś własnego agenta: „spójrz, co robię codziennie, i sprawdź, ile z tego da się zautomatyzować”. Założę się, że wynik was zaskoczy. Szczegóły: solidity.link/browserbase.

Skala, w której GitHub przestaje nadążać

Zaczynamy od oczywistego pytania: jak robi się review przy takiej objętości kodu, jaką generują agenty? Cytat z zespołu Claude Code: „Kiedyś mieliśmy szeroki i głęboki przegląd kodu. Zaczęliśmy optymalizować minimalny czas ludzkiego review, który nie podnosi liczby cofnięć ani incydentów”. Brzmi sensownie — choć to zdanie jest fatalnie sformatowane.

Wcześniej Anthropic mówiło, że Claude pisze około 90% kodu samego Claude Code. Dziś musi być tego więcej. Nie sądzę, żeby ktokolwiek w moim zespole ręcznie edytował choć linijkę kodu w T3 Code — poza prozą w plikach markdown — od co najmniej trzech miesięcy. Claude to u nas ponad 90%, reszta to Codex. Szczerze: dziwi mnie, że u nich nie jest to więcej. Rok temu liczby i tak robiły wrażenie — 85% kodu pisanego przez model to było coś szalonego. Rok później 90% wydaje mi się za mało.

Od czerwca do września liczba scalonych PR-ów w repozytorium Claude Code więcej niż się podwoiła, a odsetek tych, które trzeba było cofnąć, spadł o ponad 40%. Wygląda mi to na efekt poprawy modeli w równym stopniu co procesu — u nas proces dał duże zyski, ale upuszczony Opus 5.5 dał jeszcze większe. Osobiście powiedziałbym, że nasz odsetek cofnięć spadł znacznie mocniej niż o 40%. Miałśmy też drugą wyraźną zjazdówkę… znaczy zjeżdżalnię w dół, gdy zakazałem wszystkim modelom Gemini lądowania kodu.

Ważne: nie zlikwidowali recenzji. Przenieśli większość czytania kodu na maszyny, zoptymalizowali proces pod ludzki czas i uwagę, a mocno zainwestowali w szybkie i łatwe odwracanie błędów. Pytam tylko: to będzie siatka bezpieczeństwa czy barierki? Proszę, niech to będzie siatka bezpieczeństwa. (Informacja dodatkowa: „safety net” to mechanizm, który łapie cię po błędzie — np. szybki rollback; „guardrails”, barierki, blokują działania z góry. Theo jednoznacznie staje po stronie pierwszego podejścia.) Mam dobre przeczucie.

Zacznijmy od przemyślenia samego celu review. Gdy kod piszą agenty, liczba zmian rośnie błyskawicznie. W monorepo Anthropic codziennie lądujące zmiany wzrosły z 2,5 tys. w maju do ponad 30 tys. we wrześniu. Claude Code żyje w osobnym repozytorium, poza monorepo — i też czuje ogromny napór. Przy takim tempie ręczne, linia po linii przeglądanie kodu jest niewiarygodnie trudne, jeśli w ogóle możliwe. Ciekawostka: to, że Claude Code siedzi w osobnym repo, oznacza, że rozważali jego open-sourcing — taka jest logika tego podziału.

Dwa zadania code review — i to niedoceniane

Recenzja kodu ma dwie główne funkcje: znajdować i naprawiać problemy przed wydaniem oraz — moim zdaniem ważniejsze — budować wspólną kontekstową wiedzę i rozumienie bazy kodu w zespole. To najbardziej niedoceniany aspekt review i wciąż nie mam pomysłu, jak go utrzymać przy rosnącym tempie. Jak zapewnić, żeby mój zespół rozumiał szalone zmiany, które robię w protokole wymiany danych? Jak sprawić, żeby integrację sterowania komputerem, nad którą pracuje Julius, rozumieli wszyscy współtwórcy? Jak ogarnąć Orchestratora V2, zanim go scalimy? Mieliśmy ludzi, którzy tak mocno pchali gałąź Orchestratora V2 przed jego wylądowaniem, że rozumieli przebudowę naszej warstwy orkiestracji lepiej ode mnie — zanim jeszcze trafiła do maina. To będzie trudny do utrzymania balans i ciekawie zobaczyć, dokąd pójdzie. Sam artykuł skupia się na pierwszej funkcji; do drugiej wraca pod koniec. Okej, mogę poczekać.

„Czy człowiek czytał ten kod?” — niewłaściwa miara

Autorzy mają osobiste przekonanie, że „czy człowiek czytał ten kod” to bardzo niedokładna miara tego, co naprawdę powinniśmy pytać: „co może pójść nie tak w tej zmianie i który sprawdzian — automatyczny czy ludzki — jest właściwy, żeby to wyłapać”. To ważny szczegół. Mam wrażenie, że dyskusja o review strasznie się zdegradowała, bo oparła się na założeniu, że agenty popełniają błędy dużo agresywniej niż ludzie — i bez człowieka pilnującego, czy AI nie zrobiło czegoś głupiego, wyprodukujesz samą mielonkę.

Powiem brutalnie szczerze: praktycznie każdą regresję, jaką wydaliśmy w T3 Chat albo T3 Code, zarazem taką, którą recenzowałem, jak i nie — nie wyłapałbym w code review. I obiecuję: wy też byście nie wyłapali. Błędy, które dziś przechodzą, nie są typu „popatrzysz długo na kod i wydedukujesz, co się zepsuje”. Potrzebujesz wielu innych sposobów analizy i weryfikacji. Dorzucę kontrowersyjną tezę: większość agentów recenzuje dziś kod lepiej niż większość ludzi. A jeśli u ciebie jest odwrotnie, to nie dlatego, że agent jest słaby — tylko dlatego, że twoja baza kodu jest beznadziejna. Ale to temat na inny raz.

Recenzja jak sprawdzanie pisowni

Samo zadanie tego pytania zmieniło też moment, w którym odbywa się review. Kiedyś recenzja była bramką na końcu drogi: piszesz kod, wystawiasz PR i czekasz na kolegów. Dzibie… dziś review biegnie nieustannie, jak sprawdzanie pisowni podczas pisania. Większość zmian jest recenzowana i poprawiana przez Claude co najmniej raz, nim człowiek zostanie poproszony o spojrzenie. „Większość” to za mało — powinny być wszystkie. Mówię to od dawna: jeśli wystawiasz PR-y, których twój agent jeszcze nie przejrzał, marnujesz czas zespołu, i to mnie wścieka. Podobno Claude pisze u nich już jeszcze większy procent kodu, ale muszą najpierw doprowadzić do porządku atrybucję — sprawdzić, co naprawdę powstało z modelu — zanim coś takiego ogłoszą. Powodzenia. To zabawne.

Mam świetny przykład od jednego z widzów na to, że „zły kod trafia do review” się wydarza: w LLVM przez dziesięć lat siedział błąd łamiący bezpiecznego Rusta. (Informacja dodatkowa: LLVM to podstawa toolchainu kompilatorów; błąd przez ok. dekadę potrafił podważać gwarancje pamięciowe „bezpiecznego” Rusta.) Jedno z najlepiej recenzowanych źródeł, pisane przez jednych z najbystrzejszych inżynierów świata, utrzymyło agresywny błąd — bo nawet najlepsi ludzie nie wyłapują wszystkiego. I ludzie, i agenty są „stratni”: część informacji zawsze przepada. Różnica polega na tym, że najinteligentniejsza SI nie wypali się, jeśli każesz jej sprawdzać w kółko to samo. Ludzie dość bystrzy, żeby takie rzeczy łapać, są zbyt zajęci, żeby sobie zawracać tym głowę.

Czas, uwaga i energia ludzi

Wchodzimy w moje ulubione wątki. Jedyny naprawdę deficytowy zasób — poza procesorami graficznymi — to ludzki czas i uwaga. Chcemy je zachować dla problemów, które potrafi rozwiązać tylko człowiek, a resztę zrzucić na automatyczne sprawdzenia. Przy obecnym tempie zmian pracy dla ludzi wciąż jest mnóstwo, a nasz zespół niemal codziennie mierzy się z czymś nowym. W pełni się zgadzam — z jednym dodatkiem: energia człowieka to nie to samo co czas i uwaga. Niektóre zadania pochłaniają dużo energii, a mało czasu. Minimalizowanie kosztu energetycznego — żeby ludzie nie robili rzeczy bolesnych, powolnych i przykrych, tylko angażujących i ważne — to cenne rozróżnienie. Wrócę do tego.

Ludzki czas obejmuje obie strony kosztu recenzji: czas na sprawdzanie i czas na naprawianie tego, co zepsuł zły kod. Jest i trzeci wymiar: czas pomiędzy. Ktoś wystawia PR — czekamy. Inny człowiek recenzuje — czekamy. Autor czyta uwagi, poprawia, wypycha — czekamy na kolejną recenzję. To mnóstwo czasu, z którego więcej schodzi na oczekiwanie między komunikatami niż na samą robotę — i to jedno z największych wąskich gardeł blokujących wydawanie. Nawet jeśli skrócisz samo review, ale dalej traci się czas na poprawianie kodu, oszczędność jest iluzoryczna.

Stąd cel: większość PR-ów w repozytoriach Claude Code — CLI, aplikacji desktopowych, webowych i mobilnych — powinna się scalać z maksymalnie jednym człowiekiem w pętli (którym może być sam autor), bez wzrostu cofnięć ani incydentów. Żeby mierzyć ludzki czas, śledzą zatwierdzenia na PR, komentarze ludzi i czas oczekiwania PR-a na osobę. Wskaźniki cofnięć i incydentów pełnią rolę czujnika: jeśli rosną, to znaczy, że nie zaoszczędziliśmy ludzkiego czasu — tylko go przenieśliśmy.

Życie zmiany: kolejne warstwy ochrony

Zobaczmy, jak wygląda życie pojedynczej zmiany. Typowa poprawka — z laptopa inżyniera albo z sesji w chmurze odpalonej ze Slacka — przechodzi przez kilka warstw review. Najpierw, tuż po napisaniu, praca jest weryfikowana: Claude odpala testy, buduje, lintuje, może drugi agent obejrzeć diff na świeżym kontekście.

Dorzucę swoje: gdzie się da, weryfikacja powinna wykraczać poza szybkie przejście test-build-lint. Jeśli zmiana jest wystarczająco złożona, niemal zawsze warto ją realnie odpalić i przetestować — zwłaszcza w UI, czy to w symulowanej przeglądarce, czy przez sterowanie komputerem w środowisku, gdzie agent otworzy aplikację i sam ją przejdzie. Uwielbiam w T3 OS to, że każdy wątek może odpalić własne okno — odpowiednik biur ze Spaces w macOS. Dzięki temu wątek bez trudu stawia serwer deweloperski T3 Code w Electronie, nagrywa wideo działającej zmiany i wysyła mi je albo wkleja do PR-a. Dodałem też w trybie deweloperskim atrapy modeli ze scementowanymi zdarzeniami, które puszczamy przez rury — dzięki temu agent przeprowadza pełny test end-to-end bez spalania tokenów (poza renderowaniem samej weryfikacji). To wszystko mocno podniosło naszą pewność i częstotliwość, z jaką mogę lądować przerażające zmiany — bo agenty testują i walidują kod dokładnie tak, jak zrobiłby to użytkownik. Gdy agent mówi mi, że kod jest gotowy do spojrzenia, zweryfikował go już w większość sposobów, w jakich zrobiłbym to ja. Ale to mój proces, nie ich. Wróćmy do Anthropic.

Każdy pull request przechodzi obowiązkowe CI: linters, typy, testy na wszystkich platformach, budowanie i pakowanie. Czerwone blokuje scalenie — zgodnie z oczekiwaniem. Potem krok Claude Code review: sam Claude Code wchodzi i przechodzi przez zmianę tak, jak zrobiłby to człowiek grający z aplikacją. Odpala równolegle kilka agentów polujących na błędy, a weryfikatory głosują nad każdym znaleziskiem; to, co przeżyje, jest szeregowane według wagi. Dalej osobne przejście security review — wyszukiwanie rzeczy potencjalnie niebezpiecznych. Na końcu zatwierdzenie oparte na ryzyku: klasyfikator ocenia, jak ryzykowna jest zmiana i ile ingerencji ludzkiej wymaga — zero osób, jedna czy dwie.

Ciekawe — sam myślę o czymś podobnym w T3 Code: żeby szablon PR-a dostawał na końcu notkę ze skalą 1–10: jak doniosła jest ta zmiana, ilu użytkowników dotyka, jakie jest ryzyko. Ułatwi to trawienie napływających PR-ów. Potem kolejka scalania — my jeszcze jej nie mamy, choć pewnie powinniśmy. Main łamaliśmy już dość razy: nie w sensie zepsutego builda, tylko losowych potknięć CI. Wolałbym unikać kolejki jak najdłużej.

Po scaleniu zmiana chowa się najpierw za wewnętrzną flagą, potem następuje stopniowe wypuszczanie, obserwacja wydania i — w razie potrzeby — naprawa w przód albo rollback, gdy psucia jest za dużo na łatwą naprawę. Wszystko to się spina. Podoba mi się ten obraz warstw: dobra zmiana ma przez nie przejść, a blokady mają zatrzymywać te, które schodzą na złą ścieżkę. Zła zmiana może się przemycić przez weryfikację, ale wywali ją CI; przejdzie przez CI — zatrzyma ją recenzja AI; przejdzie i przez nią — zatrzyma security review. Każda warstwa zwiększa szansę, że zły kod nie dotrze do końca.

Jest jednak i druga strona medalu: warstwy nie tylko odcinają złe rzeczy — czasem dokładają zbędne. Nie umiem zliczyć, ile razy widziałem PR-a, który powinien mieć 50 linii, a spuchł do 800–2000, bo agent w środku obsłużył każdą uwagę z każdej warstwy po drodze. Efekt był po prostu zły. I najważniejsze, na samym dole diagramu: jeśli coś złego jednak przejdzie, musisz umieć to szybko cofnąć. To jest kluczowe. Awarie powinny dotykać jak najmniej ludzi i kosztować jak najmniej odwrócenia. Tak było zawsze, ale dziś jest to ważniejsze niż kiedykolwiek. Systemy każdego z nas muszą być zbudowane tak, żeby rollback był realny.

Najpierw weryfikacja, potem wszystko inne

Krok pierwszy: praca jest weryfikowana, nim ktokolwiek inny na nią spojrzy. Większość recenzji odbywa się, zanim PR w ogóle istnieje. Dajemy Claude’owi coś, co może uruchomić — test, build, zrzut ekranu do porównania z projektem — i prosimy o pokazanie wyniku zamiast zapewniania, że „gotowe”. Potem podagent ogląda diff na świeżym kontekście. Oba nawyki pochodzą z ich przewodnika dobrych praktyk. Przed otwarciem PR-a wielu z nich odpala dodatkowo wewnętrzne skille: jeden poluje na błędy, drugi upraszcza diff, trzeci sprawdza zachowanie od końca do końca. Zmiany w UI są dodatkowo konfrontowane z wytycznymi projektowymi.

To zgrane z tym, co mówiłem wcześniej. Boris — pierwotny twórca Claude Code — wyposażył Claude’a w sposoby weryfikacji własnej pracy i twierdzi, że to najważniejsza rzecz dla dobrych wyników. Bezwzględnie się zgadzam. Sporo osób, które marzną z agentami, marzną dlatego, że nie dały agentowi żadnej możliwości sprawdzenia, czy to, co zrobił, działa. Z czasem — mówiąc uczciwie — ci sami ludzie wpadliby w identyczne kłopoty ze świeżo zatrudnionym inżynierem: jeśli tworzysz kod, którego nie da się sprawdzić, stworzyłeś bazę kodu, w której fatalnie się pracuje. Boris szacuje, że weryfikacja czyni efekt końcowy dwa–trzy razy lepszym. Pisze tak: weryfikacja w każdej dziedzinie wygląda inaczej — od pojedynczej komendy w bashu, przez zestaw testów, po aplikację w przeglądarce czy symulatorze telefonu. Bywa też znacznie bardziej złożona — ja musiałem zbudować szaloną maszynę wirtualną do testowania T3OS. Testy nie są łatwe. Budowanie systemów weryfikacji nie jest łatwe. Ale musisz znaleźć sposób — zawsze jakiś istnieje.

Gdzie naprawiać powtarzające się błępy

Jeśli zauważysz, że automatyczni recenzenci bez przerwy flagują to samo, czas naprawić problem u źródła: w skillu, regule lintera albo aktualizacji plików z instrukcjami — np. CLAUDE.md, który mówi Claude’owi, czym jest projekt i jakich konwencji się trzymać, czy review.md pisanym przez właścicieli kodu, który mówi recenzentowi, co się liczy w ich części repozytorium. Osobno sprawdzają, czy recenzent faktycznie się tego trzyma. Dobre wersje są krótkie: mówią, jak w tym repo wygląda porażka. W dokumentacji: „kłamie”. W konfiguracji: „kieruje ruch w złe miejsce”. Można limitować drobne czepialstwa, wymieniać ścieżki do pomijania i tak dalej. Znajdź dobre miejsce na te informacje.

Tylko że — powiem wprost — to nie jest właściwy punkt startowy. Zacytuję tu Lauren, bo jej wskazówki są moim zdaniem lepsze. Gdy musisz poprawić agenta, szukaj miejsca najbliższego „górze”, które wywołało błąd. Szczyt hierarchii to sama baza kodu: jeśli agent się w niej myli, sprawdź, czy da się kod tak poprawić, żeby błąd był mniej prawdopodobny — i to nie przez obsypywanie wszystkiego komentarzami, tylko przez lepszą, łatwiejszą architekturę. Drugi stopień to analiza statyczna: lintery, sprawdzacze, reguły, typy — wszystko, co daje agentowi (a często i człowiekowi) sygnał, że coś jest źle zaimplementowane. To da agentowi informację zwrotną, której potrzebował, skoro nie wywnioskował poprawności z samego kodu. Dopiero gdy obie te warstwy zawodzą i próbowałeś już wszystko, sięgasz po prompty: CLAUDE.md, review.md, agent.md, budowanie skillów. Po tym, jak reszta zawiodła. Zawsze jednak staraj się z całych sił, żeby kod i sprawdzenia statyczne same prowadziły ludzi i agentów do sukcesu.

Najprostsza rama wyobrażeniowa: przedstaw sobie naprawdę bystrą osobę, która właśnie dołączyła do zespołu, ale nie wie, gdzie co jest. Pracowała w tysiącach baz kodu, ale nigdy w twojej. Twoim zadaniem jest zrobić jej jak najłatwiej, żeby mogła wejść na ślepo i działać, minimalizując szansę głupich wpadek. I ta osoba ma jeszcze jedną cechę: kompletnie nie przeszkadza jej nuda — potrafi odsiadywać żmudną robotę cały dzień, codziennie, bez powodu. Jeśli już wcześniej porządkowałeś repozytoria pod wygodę kolegów z zespołu, ta transformacja przyjdzie ci z łatwością.

Recenzja AI na każdym pull requeście

Kolejna sekcja: każdy PR dostaje recenzję Claude’a, nim spojrzy człowiek. Model czyta diff względem całego repo i deklarowanego celu PR-a i pyta: „czy ta zmiana rozwiązuje problem i pasuje do systemu, czy coś innego psuje?”. Przy poprawkach błędów szuka przyczyny źródłowej. Wersja publiczna, Code Review dla Claude Code, jest ogólnie dostępna w planach Team i Enterprise, a polecenie /code review odpala lokalnie lżejszą odmianę. Po starcie podglądu badawczego odsetek wewnętrznych PR-ów z merytorycznymi uwagami recenzji wzrósł z 16% do 54%. Większość PR-ów powyżej tysiąca linii dostaje znaleziska, większość małych wraca czysta. Administratorzy ustawiają każde repo na tryb szybki, standardowy lub głęboki — głęboki opłaca się tam, gdzie jeden przeoczony błąd kosztuje więcej niż dodatkowy czas review.

Nie będę wam sprzedawał tego produktu, bo ich recenzja jest według mnie o niebo za droga w większości realnych zastosowań — zwłaszcza gdy shipujecie tak szybko, jak sami tu zalecają. Jest mnóstwo tańszych narzędzi albo takich, które da się subsydiować lokalnie. Uwielbiam mój skill „Council”: kod recenzują trzy różne modele z trzech różnych rodzin. Dziala w ramach moich subskrypcji, daje wyniki równie dobre albo lepsze niż te procesy, a do tego biega na prawdziwym komputerze — może odpalić kod i go sprawdzić. Nie mówię, że ich produkt jest zły; jest po prostu drogi jak na to, co oferuje, a lepsze prompty w innych agentach dadzą ci to samo. I wielomodelowość to aspekt, o którym oni nigdy nie powiedzą, a który moim zdaniem jest naprawdę mocny.

Koniec z ręcznym segregowaniem komentarzy botów

Jeszcze jedna rzecz — dziwię się, że tak mało ludzi to wyłapało, a jest naprawdę ważna. Nie o to chodzi, żeby agenty i boty recenzujące zostawiały sterty komentarzy, które potem ręcznie przeglądamy i wybieramy, które zaadresować. To jest praca dla twojego agenta. I zwracam się teraz wprost do moich sponsorów, bo wiem, że oglądacie, a kilku z was robi produkty do AI code review: wynoście te podpowiedzi promptów z review. To jest świeżynka z 2024 roku. Mamy 2026. Ja nie będę kopiował z recenzji do mojego agenta. Mój agent pilnuje PR-a. Mój agent ocenia, czy wasz feedback jest dobry. Wszyscy to robią — nawet Bugbot, o którym byś pomyślał, że Cursor zrozumiał lekcję. Nie. Wszyscy domyślnie zostawiają jednoklikowy prompt z poprawką do przeklejenia. To i autokompletowe „napraw wszystko” — wyrzućcie. Chcę, żeby moje agenty decydowały, czy wasza uwaga jest zasadna, i żaden człowiek nie powinien patrzeć, dopóki to się nie skończy. Nie powinienem widzieć komentarzy, które moje agenty zostawiają na PR-ach. Proszę: sprawcie, żeby znaleziska były weryfikowane przez inne agenty, zanim zmusicie ludzi do ich recenzowania.

Głosowanie agentów nad każdym znaleziskiem

Kilka agentów może jednocześnie szukać błędów, a osobna grupa głosuje nad każdym znaleziskiem — publikowane jest ono tylko wtedy, gdy zgadza się wystarczająco dużo „głosów”, że problem jest realny. Uwagi dotyczące wyłącznie stylu, diagnostyki czy porządku są odrzucane. Te filtry przetestowali najpierw metodą A/B na własnych PR-ach, zanim je zostawili. To, co przeżyje, pojawia się jako komentarze w kodzie posegregowane według wagi, każde otagowane jako „ważne”, „drobiazg” albo „istniało wcześniej” — dzięki temu błąd, którego PR nie wprowadził, nie wygląda na winę autora. Każde znalezisko, które przeszło przez filtr, musi zostać rozliczone: naprawiasz albo zamykasz wątek z powodem. Często poprawkę w nocy podnosi agent, więc autor wraca do PR-a, który przeszedł już kolejną rundę. Czy Anthropic działa u nas wolniej? Mój PR przechodzi osiem i więcej takich rund w godzinę czy dwóch, a dopiero potem mnie wołają, że gotowe.

Bezpieczeństwo potrafi zablokować scalenie

Bezpieczeństwo dostaje własną, automatyczną recenzję. PR nie może się scalić, dopóki otwarte jest jakiekolwiek znalezisko — z bug review albo security review. Albo naprawiasz, albo zamykasz wątek krótkim uzasadnieniem: tak właśnie czyści się fałszywe trafy. Jeśli później commit naprawia problem, znalezisko znika samo. To samo można ustawić open-sourcowym GitHub Action do security review albo poleceniem /security review — konfigurację opisują w swoim przewodniku. Świetnie. Mamy więc automatyczne sprawdzenia blokujące — klasyczne CI: linting, testy, wiecie, o co chodzi.

Ile ludzi? Decyduje ryzyko, nie autor

Warstwy ludzkich zatwierdzeń wyglądają tak: niskie ryzyko — człowiek zbędny, scalasz, jak jest zielono. Średnie, czyli zwykła zmiana — jedna osoba powinna spojrzeć. Wysokie, poważne — co najmniej dwie.

Nie przepadam za tym przedstawieniem zero-jeden-dwa. Wolałbym, żebyśmy my i nasi agenty decydowali na bardziej dynamicznej skali — pobawię się tymi pomysłami, zobaczymy. Sedno tiera jest jednak inne: nie wybiera autora, wybiera poziom ryzyka. Dużo botów, które widziałem, próbuje wskazać, którego człowieka otagować: „ten musi to obejrzeć, ten musi to obejrzeć”. Idealnie, gdy zespół sobie ufa na tyle, żeby sam wiedział, kto może recenzować — a jeśli wchodząca osoba stwierdzi, że lepiej, żeby spojrzał ktoś inny, to niech tak zrobi. Ale to nie bot powinien otagowywać konkretnych ludzi. Bot ma opisywać wagę ryzyka, a ludzie załatwią resztę. Znajomi z Cursora mówią, że tiering ryzyka to przegrana sprawa — dalej go robią, ale jak dotąd nie ma z tym tak dobrze. Ich zdaniem są ścieżki, które zawsze wymagają człowieka: wszystko, co właściciele oznaczyli jako wrażliwe w plikach workflow CI. Zgadza się. Mam parę takich w T3 Code — wszystko, co dotyka obszarów przewijania, jest moje i nie wyląduje, dopóki nie spojrzę.

Na lekkie ścieżki dostają się wyłącznie autorzy z listy zaufanych w danym repo — w większości zespół, który je posiada. Wszyscy pozostali potrzebują drugiej osoby do zatwierdzenia. A zatwierdzenie agenta nigdy nie liczy się jako ludzkie: automatyczna recenzja może przepuścić zmianę niskiego ryzyka, ale nie zapełni slotu przeznaczonego dla człowieka. Jest jedna rzecz, która doprowadza mnie na GitHubie do szału: chcę, żeby moje boty były otagowane inaczej niż ja. W pewnym sensie już to zrobiłem — dodałem skille, które wstawiają wielki komunikat: „Jestem Opus 5.5 przez Claude Code i T3 Code, komentuję w imieniu Theona”. Ale chcę widzieć osobno, że zatwierdził bot Theona, i osobno, że zatwierdził Theo. Chcę dwóch osobnych checków zatwierdzenia.

Piszą też, że kto zlecił zmianę promptem, ten na niej siedzi. Nie możesz winić agenta, skoro ty go o coś poprosiłeś — to twoja własność, twój problem. I zatwierdzenia pokrywają konkretne commity: jeśli wylądują nowe, których system nie może ręczyć — push od agenta albo ręcznie rozwiązany merge — zatwierdzanie startuje od zera. Dalej mają kolejkę scalania z flagami i stopniowaniem wydań: najpierw zmiany idą na kanał latest, dopiero potem na stable.

Szybkie wykrywanie, szybkie cofanie

Niektóre pomyłki i tak się przemkną, więc ostatnia warstwa polega na szybkim ich łapaniu. Mają cotygodniową rotację dyżurów. Przegląd incydentu zaczyna się od pytania, która warstwa powinna była go wyłapać. Zauważenie złego scalenia wciąż zależy od autora i dyżurnego oraz od dashboardów rewertów i incydentów. Nie mają jeszcze bezpieczników, które automatycznie zaostrzałyby zatwierdzanie, gdy te liczby drgną — inżynierowie chcą ich, zanim więcej kodu przejdzie na scalanie bez udziału człowieka. Ma to sens: bezludowych mergerów u nich nie ma dużo. My właśnie zaczynamy trochę robić to przy wystarczająco prostych poprawkach błędów — tak Julius dochodzi do lądowania 400 PR-ów dziennie.

Jeden z kolegów powiedział kiedyś, że zwolnienie obniża liczbę błędów — ale głównie dlatego, że robisz wtedy mniej wszystkiego. Zespół postanowił, że woli przyspieszyć zauważanie i naprawianie problemów niż zwalniać, żeby ich unikać. I tu się zgadzam w całej rozciągłości: jeśli twoim rozwiązaniem problemu wydawania psujących zmian jest po prostu wolniejsze tempo, to nie rozwiązujesz problemu. Mocne.

Incydenty stają się ewaluacjami

Proces review ciągle się poprawia w pętli. Każdy incydent staje się evalą: zespół zbiera PR-y, które kiedyś spowodowały incydenty, razem z naprawami i rewertami, a inżynierowie znający kod potwierdzają każdy błąd i jego lokalizację. Recenzent odpala na tym zbiorze codziennie. Zrobiłbym to inaczej, ale kierunek mi się podoba: incydent, potwierdzenie przez eksperta, dopisanie do zestawu i codzienny przebieg sprawdzający, czy te błędy znów by się wydarzyły.

Szum mierzą, obserwując, co ludzie robią z komentarzami. Łatwo łapać więcej błędów, jeśli nie przeszkadza ci flagowanie mnóstwa nie-błędów — trzeba na to mieć hamulec. W pełni się zgadzam: szum na PR-ach to piekło. Każdy komentarz recenzenta sortują według reakcji: naprawiono / uznano za błędny / zachowanie zamierzone / nieistotne. Recenzenta puszczają też na PR-ach, o których wiedzą, że są czyste, i liczą, jak często zgłasza coś, co nakłoniłoby kogoś do szkodliwej zmiany. Priorytet, spisany czarno na białym: najpierw łapanie prawdziwych błędów, dopiero potem skracanie rund recenzji. Ma sens.

Szum kosztuje więcej, gdy autorem jest agent. Człowiek zbywa drobiazg w kilka sekund; agent go „naprawi” — czyli nowy commit, nowa runda review, więcej zbędnego kodu i tona innej mielónki.

Recenzje muszą się zbiegać do końca

Dlatego recenzje muszą zbiegać do końca. Agent-autor i agent-recenzent potrafią zajmować się sobą bez końca. Miałem coś, co miało być prostą zmianą: pracuję w T3 Code nad doświadczeniem w stylu Grokbota — jeden główny wątek sterujący wszystkimi pozostałymi. Prototyp działał, ale niezupełnie tak, jak chciałem, więc rzuciłem go do review w Council z poleceniem: „oto, czego chcę; iterujcie, aż cała rada odblokuje”. I o nim zapomniałem, bo zwinął się w karcie roboczej. Zauważyłem go dopiero wczoraj. Szło cztery dni. PR urosnął do jakichś 80 tysięcy linii kodu i musiałem wejść z górną pięścią: „nie, po prostu kręcicie się w kółko”. Zdałem sobie sprawę, że muszę dodać do skilli bezpieczniki przerywające — bo dalej nie robił żadnego postępu. Tak, review muszą mieć koniec.

W ich przypadku: jeden PR do CLI przeszedł ponad 50 rund recenzji i poprawek przez noc, zanim autor go zatrzymał. Nie zdawałem sobie sprawy, że właśnie opisuję własny przypadek, zanim nie przeczytałem tego zdania. Komiczne. A kiedy puścili gita blame na to, co recenzent bez przerwy flagował, okazało się, że około 60% uwag dotyczyło kodu obecnego od pierwszego przejścia. Recenzent rzadko znajdował nowe błędy — łapał kilka takich, których dawne rundy nie wyłapały. Sami zrobili sobie gorzej: przyzwyczaili się do odpalania kilku rund z domyślnu, bo każde przejście coś nowego znajdowało. Przy ryzykownych zmianach może to mieć sens, ale nie przy każdym PR. Zespół śledzi teraz liczbę rund do przepuszczenia obok czułości wykrywania i ponownego przeglądu samego diffu.

Udało mi się to naprawić w dość błahy sposób. Zamiast zbierać wszystkie drobiazgi i iść dalej, aż agent powie „już dobrze”, przeszedłem na punktację: agenty recenzujące zostawiają ocenę od 1 do 10, a ja sam ustalam próg. Bo PR może mieć osiemnaście komentarzy i wciąż być na dziewiątkę — wszystkie uwagi to głupie drobiazgi. A może mieć jeden komentarz i być na szóstkę — i ten z jednym komentarzem jest pilniejszy do naprawy niż ten z dwudziestoma. Ustalenie poprzeczki nie po liczbie uwag, lecz po tym, jaką pewność budujesz w systemie — to jest droga, która działa.

Oni zaczęli od limitu rund — ja też to zrobiłem w Solo, w Council jeszcze nie i muszę nadrabiać. Po trzech rundach recenzent prosi autora o krok wstecz i przemyślenie podejścia. Potem ponowny przegląd wyłącznie diffu po pierwszych przejściach, warstwa oznaczająca klasę błędku, żeby autor naprawił wszystkie wystąpienia, a nie jedną linijkę, i zakaz powtarzania już zgłoszonych znalezisk. Dobre zmiany. Agenty recenzujące biegają też nocą po istniejącym kodzie i pomagają wyłapywać stare błędy, zanim wystrzelą gdzie indziej. Po zmianach konwergencyjnych: o 13% wzrósł odsetek PR-ów przechodzących po jednej rundzie recenzji i poprawy; PR-y wymagające pięciu i więcej rund spadły z 9% do 1,5%; średnia liczba recenzji do przepuszczenia z 2,08 na 1,32. Dobre zmiany.

Jeszcze jeden głos, zanim przejdziemy do ludzi — od Jake’a od naszych przyjaciół z Graphite (czyli, żartobliwie licząc, Cursora, SpaceX i Grokbota). Uważa, że punktacja to nie jest rozwiązanie: agentom trzeba ufać na tyle, żeby podejmowały decyzje zero-jedynkowe z odpowiednim kontekstem — dokładnie jak inżynierom, którym za to płacisz: „czy tę uwagę mogę zignorować, czy nie?”. Jego celem jest prostota. W dużej mierze się zgadzam, choć będę to testował na różne sposoby — gdy rozwiązanie przestaje mi się podobać, bawię się nim, aż znajdę lepsze, i trzymam się go, aż znów mnie zirytuje. Pozdrowienia dla wszystkich znajomych z laboratoriów, którzy podpowiadają mi podczas nagrywania — to niesamowicie pomaga.

Gdzie zostają ludzie

No dobrze — gdzie w tym wszystkim zostają ludzie? Po pierwsze: decydują, czy daną rzecz w ogóle warto budować. Kierunek, gust, zakres. Jeden zespół, który uznał swoje wąskie gardła recenzji za rozwiązane, i tak zostawił ludzkie review dla zmian napływających spoza zespołu — żeby ktoś pytał: „czy my w ogóle powinniśmy to robić?”. Dalej: recenzowanie ryzykownego kodu — płatności, autoaktualizator, workflow CI. Recenzowanie architektury, bo ona ustawia wzorce, które inni potem kopjują. Czytanie dowodów: wyniki testów, uruchomione komendy i to, co faktycznie zwróciły, zrzuty ekranu, znaleziska recenzji. Jeśli nie potrafisz powiedzieć, czego sprawdzenia nie obejmą, poproś o prawdziwą recenzję, a nie o szybkie kliknięcie aprobaty. I wreszcie: odpowiedzialność za wynik. Kto wystawił PR, ten go posiada — nie ma znaczenia, skąd sam kod pochodził.

Skoro maszyny czytają kod, jak ludzie mają go poznać?

Bo — nie ukrywajmy — kocham review właśnie za to: nie tylko za łapanie błędów, ale za pewność, że wszyscy wiedzą, co dzieje się w bazie kodu. Do dziś, gdy proszę kolegę o recenzję, robię to zwykle z tego powodu: chcę, żeby to zrozumiał. Jeśli nie zrozumie, wszystko naprawiać będę ja; jeśli zrozumie — nie jestem sam z tym na przyszłość.

Drugie zadanie review zawsze polegało na rozprowadzaniu rozumienia kodu. Czytanie cudzego diffu to sposób, w jaki uczysz się, co się zmieniło i jak elementy do siebie pasują. Jeśli czytanie robią głównie maszyny — skąd ktokolwiek ma znać kod? Nie mają na to formalnego procesu. Nikt w zespole nie trzyma w głowie kompletnego modelu Claude Code. Wiem, że część z was pomyśli: „to szaleństwo, ktoś musi wiedzieć, jak to wszystko działa”. Jeśli tak myślisz, mam nadzieję, że bezrobocie dobrze cię traktuje — bo w żadnej większej bazie kodu nie istnieje jedna osoba znająca wszystko. Miałem z tym dyskusje, tam i z powrotem. Jest mnóstwo bardzo ważnych repozytoriów doskonale rozumianych przez jednego–dwóch opiekunów — i są bardzo małe. Tylko że to już nie są etaty: jeśli baza jest na tyle mała, że ogarnia ją jeden człowiek, to znaczy, że nie ma wystarczającej przepustowości zmian. Nie chodzi o ruch — mała baza potrafi obsłużyć miliardy zapytań dziennie — ale nie zmienia się na tyle, żeby opłacało stawiać wokół niej żelazny proces pozwalający lądować zmiany codziennie. Jeśli robisz jedną zmianę tygodniowo i pięć z sześciu dni spędzasz na upewnianiu się, że jest dobra — w porządku, to ma sens. To po prostu zupełnie inny rodzaj pracy niż ten, o którym tu mówimy. Większość etatów to praca w bazach, których żaden człowiek nie jest w stanie zrozumieć w całości. Żaden agent też, dodajmy. Ale nikt nie musi rozumieć całości.

Gdy ktoś chce zrozumieć fragment bazy, prosi Claude’a o eksplainer dokładnie tego wycinka. Zajmuje to minuty i odzwierciedla kod w jego aktualnym stanie. Według mnie ludzie strasznie niedoceniają, jak mocne to jest. Gdy recenzuję ciężkie zmiany, często wklejam PR do T3 Code z Claude’em i proszę o rozbicie: co się zmienia, dlaczego i gdzie jest ryzyko. Część zespołu idzie dalej: każe Claude’owi zbudować artefakt wizualizujący dany fragment kodu, który uczy ich, jak działa, w formie odpowiadającej temu, jak dana osoba lubi się uczyć. Rewelacja, szczerze polecam. Jeśli celem jest dobre wydawanie ludzkiej uwagi, to bije na głowę czytanie trywialnego diffu linijka po linijce. Jednolinijkowe zmiany w tekście niczego nie uczą; eksplainer modułu, który zaraz będziesz zmieniać — uczy bardzo dużo.

Pomaga też kultura domyślnego działania na otwartych kanałach Slacka: widzisz, co budują inni, w trakcie budowania. Uwielbiam to i bardzo chcę, żebyśmy w T3 Code z figured out, jak pracować zespołowo i widzieć, kto co i kiedy robi. Jest sporo powodów, dla których to trudne — ale chciałbym to rozgryźć.

Kto scala, ten odpowiada — ale bez szukania winnych

„Wylądowałeś — twoje”. Jeśli lądujesz małą albo średnią zmianę i coś pójdzie nie tak, normą zespołową jest, że to ty to naprawisz. Kilka rzeczy chroni ten układ przed degeneracją: zmiany są małe, więc łatwe do przejrzenia, debugowania i cofnięcia. Wszystko jest odwracalne. Poprzeczkę wyznacza zasięg szkód — droższy kod dostaje więcej ludzi i sprawdzeń. Regresje wychodzą szybko dzięki telemetrii i własnemu użytkowi. I nie jest to szukanie winy: własność nie znaczy, że zawiniłeś, tylko że rozumiesz sprawę najlepiej — więc jesteś gotowy wejść i naprawić to, przy czym masz najwięcej kontekstu. Własność jest też dzielona: większość zespołu pracuje w otwartych kanałach, gdzie każdy widzi, co budują pozostali, może podchwycić wątek albo pazurkiem wskazać lukę. Feedback napływa również od osób, które kodu nie posiadają. Ta otwartość to duży element tego, dlaczego jakość utrzymuje się wysoko bez zastawiania bramki na każdej linijce.

I jeszcze jedna wielka rzecz — cieszę się, że ją wpleli: zmiana kierunku. Agenty tanio pozwalają coś zacząć, więc część pracy nie powinna wylądować. Zgaduję, że w T3 Code merge’uje się około połowa moich PR-ów; druga połowa jest zamykana z różnych powodów. Zwykle ktoś na kanale zapyta „po co?”, wskaże wcześniejszą decyzję albo zaproponuje prostszą drogę — i autor zamyka albo przebudowuje PR-a. Skoro kod pisze się szybko, zamknięcie nie boli. Sztuka polega na tym, żeby inny kierunek podnosić wcześnie, w samym wątku — a nie blokującym komentarzem pod skończonym PR-em.

Checklista wdrożenia: przed, w trakcie i po

Boże, jak ja nie znoszę, że nie wiem, kto to napisał. Wiem, że duża część to Addy, ale formatowanie niektórych zdań jest potworne. „Większość elementów, by zrobić to z zespołem, istnieje dziś” — jedno z najgorszych zdań, jakie czytałem: bez pauzy, bez członienia, desperacko potrzebuje przecinka albo rozbicia na kilka zdań. Przepraszam, jestem przewrażliwiony na punkcie prozy; lubię pisać. Chore, że duże modele językowe zrobiły się świetne we wszystkim poza generowaniem tekstu. Nienawidzę pisania LLM-ów i wietrzę tu rzeczy, które mi się nie podobają — ale procesowo nadal jest czego się nauczyć.

Podoba mi się, że zaczynają od czasu sprzed PR-a — bo jest przed, w trakcie i po PR: tak właśnie należy to rozmyślać.

Przed PR-em: daj agentowi sprawdzenia do odpalenia i sposoby weryfikacji pracy; uruchomiaj skille code review i security review lokalnie — u mnie to część głównego skilla lądującego zmiany, a agent sam decyduje, co włączyć. Dodaj review.md i wrzucaj tam powtarzające się uwagi recenzentów. I najpierw napraw kod.

Na każdym PR-ie: wymagaj CI; do szablonu PR-a dodaj, jak testować, jakie jest ryzyko i jak cofnąć zmianę — ta część mi się podoba: szablon i skille wystawiające PR-y powinny zawierać test, ryzyko i sposób odwrócenia. Dodaj recenzenta AI — ich albo dowolnego z hojnych sponsorów tego kanału. Przez kilka tygodni dostrajaj review.md, potem poszerzaj zakres sprawdzania. Dorzuć automatyczny security review i wymagaj rozliczenia każdego wątku recenzji przed scaleniem. Kocham, jak wrzucają to niewinnie, jakby to było oczywiste — a nasz Claude blokuje pytania o bezpieczeństwo. Rozwiązania istnieją, ale po stronie Anthropic nie będą specjalnie darmowe, niestety.

Dopasuj wysiłek recenzji do ryzyka: szybkie przejście przy rutynie, głębokie tam, gdzie przeoczony błąd jest drogi — czyli te tryby quick/standard/deep. I limituj rundy recenzji, żeby nie lecieć w nieskończoność — ja spaliłem tony tokenów na przypadkowych wiecznych review.

Zatwierdzanie: zapisz poziomy ryzyka itd. Ryzyko ustalaj na podstawie zmiany, nie autora. Zachowaj lżejsze ścieżki dla autorów, którym ufasz. Używaj code owners i ochrony gałęzi — autoryzacja, płatności, CI i procesy wydawnicze oraz inne kluczowe dostają konkretne osoby. Nigdy nie pozwól, by aprobata bota zastąpiła ludzką. Tak.

Scalanie i potem: kolejka scalania, flagi funkcji, najpierw użytek wewnętrzny; wypuszczanie etapami i jednokrokowe rollbacki to ogromna sprawa. Zamieniaj incydenty i reverty w zestawy evalów. Za każdym razem, gdy zmienia się prompt, narzędzia albo model recenzenta, zmierz jego skuteczność od nowa — zobacz, czy faktycznie robi postęp. Czego nie mierzysz, tego nie naprawisz — bo AI jest dziś genialne w naprawianiu rzeczy, o ile dasz mu narzędzia, po których może się wspinać. Jeśli umiesz zrobić evalę z typów zmian, które nie powinny trafiać do twojego kodu, i zamienić ją w test do odpalenia, naprawa staje się banalna. Rozkręcam ten temat w filmie o „wspinaczce pod górę” i wiecznym uruchamianiu Claude’a — tam pokazuję szczegółowo, jak stawiać takie środowiska. Oni też radzą mierzyć ludzki czas oraz wskaźniki rewertów i incydentów.

Dokąd to zmierza — i z czym się nie zgadzam

Gdy zapowiadali produkt Code Review dla Claude Code, powiedzieli: zatwierdzanie PR-a to wciąż ludzka decyzja. Produkt publikuje znaleziska, nie aprobaty. Ich własne repozytoria idą dalej — właściciele decydują, które zmiany niskiego ryzyka scalają się wyłącznie na podstawie automatycznych sprawdzeń. I ta granica będzie się dalsz… dalej przesuwać. A gdy recenzja coś przeoczy, pytają, czego model nie miał przed oczami, i poprawkę lądują w CLAUDE.md, skillu albo nowym checku. Nie. To nie tak. Nie podoba mi się ta rada. Najpierw próbuj naprawić kod; jeśli nie da się go tak poprawić, żeby problem nie wynikał — dodaj sprawdzenie. Dopiero jeśli i to nie działa, ewentualnie skill albo CLAUDE.md.

Całe nasze wytyczne niedawno generalnie przerobiliśmy. Zerknijmy, jak często ten plik się zmienia — o, zmiana agent.md osiem godzin temu. Miesiąc zmian nadal mieści się na jednej stronie — znacznie mniej niż gdziekolwiek indziej w tej bazie. Widok czatu zmienia się na przykład 30–50 razy dziennie, a agent.md mniej więcej raz dziennie, dawniej raz na pięć. Nie kręcimy tego w kółko. Chwila — Julius przeniósł nas z TS Rust? Julius, wystarczyło mi powiedzieć, żebym leciał dalej, od razu bym odpalił agenta z powrotem. No dobrze: zeszliśmy z TS Rust, bo Julius chciał nowe funkcje Effecta. Ale samo to pokazuje sedno: zmieniliśmy wytyczne nie dlatego, że coś nas zirytowało, tylko dlatego, że repo się zmieniło i jedna z reguł przestała być prawdziwa. O to chodzi — a nie że widzimy agenta robiącego coś źle i dokładamy kolejne zdania ostrzegawcze.

Wyobraź sobie, że jesteś ślepy i brodzisz po ciemku przez labirynt, obijając się o ściany i potykając. Możemy dać ci lepszą instrukcję, zanim wejdziesz — albo zlikwidować dziury i tak urządzić labirynt, żeby twoje widzenie nie miało znaczenia. Ja nie chcę wciąż dokładać modelowi instrukcji przed drzwiami; chcę, żeby pokój, przez który chodzi, był jak najłatwiejszy do nawigowania. Coraz więcej plików review.md to żadne rozwiązanie.

Finał

Na końcu mają apel: powiedzcie nam, które sprawdzenia automatyzujecie, które wciąż wymagają ludzi i co według was rozumiemy źle. Tym bardziej cieszę się, że ten film wychodzi — wiem, że będą słuchać. Może naprawdę wypróbują część tych rzeczy, zwłaszcza że po drugiej stronie są Addy i Emma, dwójka starych znajomych. Emma jest absolutnie niesamowita — bardzo się cieszę, że jest teraz w Anthropic. Michaela i Amy znam słabiej, ale słyszałem same dobre rzeczy.

Świetny tekst. Naprawdę miło widzieć Anthropic w takiej szczerości. Taki blog rok temu u nich po prostu by nie istniał — nie dzielili się wtedy tym, jak pracują w środku, i to jest piękna zmiana. Mam nadzieję, że odebraliście z tego tyle samo co ja. Uwielbiam zaglądać za kulisy pracy z tymi narzędziami — a może i wy wynieśliście parę pomysłów na własny użytek. Dajcie znać w komentarzach, jak u was wygląda review. Do następnego razu — pa, nerdasy.