Jak zespół Claude Code przeprowadza przegląd kodu: siedem kroków i żadnych wyłączników awaryjnych

15 października 2026 r. zespół Claude Code opublikował własną relację o tym, jak przegląda kod — czternastominutowy artykuł inżynierski podpisany przez Addy'ego Osmaniego, Morgan Westlee Lunt i Qing Wang. Zdanie, które wyjaśnia, dlaczego ktokolwiek tego szuka, pojawia się wcześnie: Claude pisze około 90 procent własnego kodu Claude Code. Tekst nie jest obroną tej liczby, lecz opisem maszynerii, która musiała powstać u jej podstaw, zanim można było z tym pracować, a fragmenty warte uważnej lektury to te, których wciąż brakuje.

Większość podsumowań zatrzymuje się na dwóch nagłówkowych liczbach: liczba scalonych pull requestów do bazy kodu Claude Code więcej niż podwoiła się między czerwcem a wrześniem 2026 r., a odsetek tych, które trzeba było wycofać, spadł o ponad 40 procent. Obie pochodzą od samego zespołu i obie mogą wynikać z kilku różnych rozwiązań, w tym tego, które ludzie zakładają — że przegląd został po cichu usunięty. W poście napisano, że tak nie było. Przenieśli większość czytania na maszyny, zoptymalizowali pod kątem ludzkiego czasu i uwagi oraz zainwestowali w to, by błędy można było szybko i łatwo cofać. Cała reszta to szczegóły, jak to zrobiono.

Dlaczego przegląd w ogóle stał się wąskim gardłem

Presja nie wynikała z decyzji politycznej. Wynikała z wolumenu. W monorepo Anthropic, jak podaje wpis, liczba zmian wchodzących dziennie wzrosła z około 2500 w maju do ponad 30 000 we wrześniu 2026 r. Claude Code znajduje się we własnym repozytorium, oddzielnym od tego monorepo, ale podlega tej samej presji w mniejszej skali.

W takim tempie, przyznaje wpis, ręczny przegląd linia po linii jest niezwykle trudny, jeśli nie niemożliwy. Nikt tam nie twierdzi, że człowiek czytający każdy diff jest niepotrzebny. Twierdzą, że czytanie każdego diffa nie jest już skalowalne i że pytanie „czy człowiek przeczytał kod” zawsze było niedokładnym wskaźnikiem zastępczym dla pytania, które naprawdę się liczy: co może pójść nie tak w tej zmianie i która kontrola — automatyczna czy ludzka — jest właściwa, by to wychwycić.

Gdy ująć to w ten sposób, brama się przesuwa. Przegląd przestaje być drzwiami na końcu drogi i staje się ciągły, bliższy sprawdzaniu pisowni podczas pisania. Większość zmian została przeczytana i poprawiona przez Claude’a, zanim spojrzy na nie człowiek.

Na co optymalizowali i co uchodzi za porażkę

Deklarowanym celem jest to, że większość pull requestów w repozytoriach Claude Code — które w poście opisano jako CLI, aplikacje desktopowe i webowe oraz aplikacje mobilne — jest scalana z udziałem co najwyżej jednej osoby, którą może być autor, bez wzrostu liczby wycofań lub incydentów. To trzeci warunek czyni go prawdziwym celem, a nie ćwiczeniem z obniżania kosztów.

Mierzą czas człowieka po obu stronach bilansu: czas, który ludzie poświęcają na przegląd, oraz czas, który poświęcają na naprawianie tego, co psuje zły kod. Skrócenie pierwszego nie pomaga, jeśli koszt pojawia się ponownie w drugim, i zespół mówi to wprost. Śledzone wskaźniki to więc zatwierdzenia przez człowieka na pull request, raportowane jako mediana i 95. percentyl, komentarze od ludzi oraz to, jak długo pull request czeka na osobę. Wskaźniki wycofań i incydentów leżą pod tym wszystkim jako zabezpieczenie: jeśli rosną, nie zaoszczędzono czasu człowieka, tylko go przeniesiono.

Metryki kosztów przeglądu łatwo oszukać w oderwaniu od kontekstu; recenzent, który zatwierdza wszystko, generuje piękne wykresy czasu zatwierdzania. To właśnie zabezpieczenie nie pozwala wykresowi kłamać.

Siedem kroków, a nie jedna brama

Wpis przedstawia ścieżkę typowej zmiany w postaci siedmiu ponumerowanych kroków. Każda warstwa wychwytuje część problemów, a inne pomija, przy czym tańsze kontrole są uruchamiane przed droższymi.

• Weryfikacja przed utworzeniem pull requesta. Claude uruchamia testy, kompilację i linter, a drugi agent przegląda diff w świeżym kontekście. Wielu inżynierów korzysta także z wewnętrznych umiejętności: jedna szuka błędów, jedna upraszcza diff, jedna sprawdza działanie od początku do końca. Boris Cherny, twórca Claude Code, nazwał danie Claude'owi sposobu na weryfikowanie własnej pracy prawdopodobnie najważniejszą rzeczą dla dobrych wyników i szacuje, że poprawia to końcowy wynik dwa do trzech razy.

• Przegląd AI przy każdym pull requeście. Przegląd Claude'a analizuje diff w kontekście całego repozytorium oraz zadeklarowanego celu pull requesta. Kilku agentów równolegle szuka błędów, a następnie osobna grupa głosuje nad każdym znaleziskiem i jest ono publikowane tylko wtedy, gdy wystarczająca liczba głosów uzna je za rzeczywiste. Znaleziska dotyczące stylu, diagnostyki lub porządków są odrzucane. To, co przetrwa, pojawia się jako komentarze w treści oznaczone jako Important, Nit lub Pre-existing. Gdy uruchomiono podgląd badawczy, odsetek wewnętrznych pull requestów otrzymujących merytoryczne komentarze w przeglądzie wzrósł z 16 do 54 procent. Administratorzy ustawiają każde repozytorium na tryb Quick, Standard lub Deep.

• Przegląd bezpieczeństwa. Osobny automatyczny przebieg. Pull request nie może zostać scalony, dopóki ustalenie z któregokolwiek przeglądu pozostaje otwarte; naprawiasz je lub zamykasz wątek z krótkim uzasadnieniem. Ten sam mechanizm kontrolny jest publicznie dostępny jako open-source'owa akcja GitHub do przeglądu bezpieczeństwa lub polecenie /security-review.

• Automatyczne kontrole, które blokują. Lint, sprawdzanie typów, testy na każdej platformie i kompilacja.

• Zatwierdzanie przez człowieka, proporcjonalne do ryzyka. Klasyfikator odczytuje zmianę i ustala poziom zamiast autora, który ustalałby go sam. Ten krok ma własną sekcję poniżej, ponieważ to w nim tkwi większość interesujących decyzji projektowych.

• Kolejka scalania, flagi i stopniowe wdrażanie. Kolejka ponownie uruchamia każdą kontrolę względem gałęzi main z uwzględnieniem zmiany, dzięki czemu dwa pull requesty, z których każdy przechodzi osobno, nie mogą połączyć się w zepsutą gałąź main. Nowe zachowanie jest najpierw udostępniane pracownikom Anthropic za flagą, a następnie trafia do kanału latest, przy czym kanał stabilny podąża z opóźnieniem.

• Szybkie wykrywanie i wycofywanie zmian. Flagi można wyłączyć bez wdrożenia, obowiązuje cotygodniowy dyżur on-call, a przeglądy incydentów odpowiadają na pytanie, która warstwa powinna była wychwycić problem. Niektóre błędy i tak się przedostaną, dlatego ostatnia warstwa polega na szybkim ich zauważeniu, a nie na zapobieganiu im.

To zmiana ustala poziom, a nie autor.

Poprawka dokumentacji i zmiana w mechanizmie automatycznych aktualizacji nie niosą ze sobą tego samego ryzyka, więc nie są poddawane takiej samej weryfikacji. Tabela w poście ma trzy poziomy, a każdy z nich odpowiada na jedno pytanie: ile osób, jeśli w ogóle, musi zatwierdzić tę zmianę, zanim zostanie scalona.

Niski obejmuje dokumentację, teksty, funkcje wyłącznie do użytku wewnętrznego i zmiany rozszerzające za flagą; gdy automatyczny przegląd i kontrola bezpieczeństwa zakończą się powodzeniem, nie jest wymagana żadna osoba. Średni obejmuje zwykłe zmiany produktowe oraz wrażliwe obszary, takie jak buforowanie, mechanizm automatycznych aktualizacji i prompty systemowe, i wymaga jednej osoby. Wysoki obejmuje kod o najwyższym ryzyku i niewielki zestaw ścieżek, które zawsze wymagają dwóch osób.

Klasyfikator to tylko połowa projektu. Drugi klasyfikator sprawdza, czy ta konkretna zmiana wymaga drugiej osoby, nawet gdy jej poziom mówi, że nie. Niektóre ścieżki zawsze wymagają osoby niezależnie od poziomu: wszystko, co właściciele oznaczyli jako wrażliwe, oraz każdy plik przepływu pracy CI. Tylko autorzy z listy zaufanych repozytorium, głównie zespół właścicielski, korzystają z lżejszych ścieżek; wszyscy inni potrzebują drugiej osoby. Zatwierdzenie przez agenta nigdy nie liczy się jak zatwierdzenie przez osobę, więc automatyczny przegląd może zatwierdzić zmianę niskiego ryzyka, ale nie może obsadzić miejsca wymagającego człowieka. Kto zainicjował zmianę, ten za nią odpowiada. A zatwierdzenie obejmuje jeden konkretny commit, więc nowy commit, w tym push agenta lub ręcznie rozwiązany merge, ponownie wymaga zatwierdzenia.

Dwa szczegóły warto zapożyczyć, nawet jeśli nigdy nie zbudujesz klasyfikatora. Poziom wynika ze zmiany, a nie z autora, a zaufanie to osobna, węższa brama nałożona na to. Zatwierdzenie jest przypisane do commita, a nie do pull requesta, co zamyka najczęstszą lukę w systemach przeglądu: zielony ptaszek zdobyty wcześnie na gałęzi wydany na kod, którego nikt nie obejrzał.

Recenzent jest szkolony na podstawie własnych incydentów

To jest ta część, którą większość opracowań pomija, a która wyjaśnia, dlaczego ten układ wciąż działa, zamiast się rozjeżdżać.

Zespół zebrał przeszłe pull requesty, które spowodowały incydenty, wraz z ich fix-forwardami i wycofaniami, i poprosił inżynierów znających ten kod o potwierdzenie każdego błędu oraz miejsca, w którym się znajdował. Ten zbiór jest teraz evalem. Recenzent jest uruchamiany na nim codziennie. Gdy zmieniają się jego prompty, narzędzia lub model, zmiana musi przetrwać cały zbiór: zatrzymać ją, jeśli wynik wzrośnie, odrzucić, jeśli nie. Ich awarie stały się zestawem testów dla mechanizmu, który miał wychwytywać ich awarie.

To inne podejście niż strojenie lintera, który jest oceniany względem stałego zestawu reguł. Ten recenzent jest oceniany pod kątem konkretnych sposobów, w jakie ta baza kodu już się psuła, więc eval rośnie za każdym razem, gdy coś idzie nie tak. Żaden wynik dla niego nie pojawia się w niczym, co Anthropic opublikowało i co przeczytaliśmy, a wpis nie twierdzi, że recenzent jest gotowy.

Warstwa, której jeszcze nie zbudowano

Oto wyznanie, które czyni ten wpis wiarygodnym. Wszystko powyższe opisuje system, który wychwytuje i odwraca błędy, a nie taki, który zauważa zmianę własnego wskaźnika błędów. Zespół nie ma jeszcze bezpieczników, które automatycznie zaostrzają zatwierdzanie, gdy zmieniają się liczby wycofań lub incydentów, a inżynierowie chcą ich, zanim więcej kodu przejdzie na scalanie bez udziału człowieka.

Zamiast tego istnieje ludzka uwaga. Flagi są wyłączane bez wdrożenia, cotygodniowy dyżur on-call czuwa, a przeglądy incydentów pytają, która warstwa powinna była wychwycić problem. Wypowiedź jednego z kolegów to najużyteczniejsze zdanie dla każdego, kto planuje podobne wdrożenie: zwolnienie tempa rzeczywiście obniża wskaźnik błędów, ale głównie dlatego, że robisz mniej wszystkiego. Zespół wolałby szybciej zauważać i naprawiać problemy, niż wolniej je tworzyć.

Przeczytaj ponownie te siedem kroków, mając to na uwadze. Sześć z nich decyduje, czy zmiana zostanie przeprowadzona. Siódmy to zestaw nawyków pozwalających zauważyć ją później. Nie ma pętli sprzężenia zwrotnego połączonej od wyniku z powrotem z bramką, i ludzie, którzy zbudowali ten system, mówią to wprost.

Drugie zadanie recenzji, które ten wpis w większości pomija

W poście wyraźnie zaznaczono, że przegląd kodu pełni dwie funkcje: wykrywa i naprawia problemy, zanim trafią do wydania, oraz buduje wspólny kontekst w zespole. Skupia się na tej pierwszej, a następnie wraca do drugiej z niezwykle szczerą odpowiedzią: nie istnieje na to żaden formalny proces, nikt nie ma w głowie kompletnego modelu Claude Code i uważają, że nikt tego nie potrzebuje. Chcesz zrozumieć część bazy kodu? Poproś Claude'a o wyjaśnienie dokładnie tego fragmentu.

Dwa pliki instrukcji przenoszą kontekst, który wcześniej znajdował się w głowach recenzentów. CLAUDE.md mówi modelowi Claude, czym jest projekt, jaki jest stos technologiczny, konwencje, cele i niecele — celowo zwięźle. REVIEW.md jest tworzony przez właścicieli kodu i opisuje, jak wygląda błąd w ich części kodu, które ścieżki pomijać, oraz prosi o wskazanie pliku i wiersza zamiast zgadywania.

Odpowiedzialność ma własną regułę: jeśli coś wdrażasz, to za to odpowiadasz. Po scaleniu małej lub średniej zmiany, jeśli coś pójdzie nie tak, normą jest, że to naprawiasz. Działa to, bo zmiany są małe, bo flagi i wycofania cofają większość błędów w ciągu minut, a zasięg oddziaływania wyznacza poprzeczkę dla liczby kontroli, którym podlega zmiana. To norma nałożona na regułę zatwierdzania, a nie jej zastąpienie.

Gdzie router pasuje, a gdzie nie

Powyższy pipeline to pipeline wywołań modeli: agent przeglądający czyta diff względem całego repozytorium, kilku agentów polujących na błędy działa równolegle, grupa głosuje nad każdym znaleziskiem, odbywa się przebieg kontroli bezpieczeństwa, a recenzent jest codziennie ponownie uruchamiany względem rosnącego zbioru ewaluacyjnego. To problem routingu, zanim staje się problemem przeglądu, ponieważ zły dzień jednego dostawcy nie powinien zatrzymywać kolejki scalania.

OrcaRouter to jeden punkt końcowy zgodny z OpenAI dla ponad 200 modeli na jednym kluczu, z automatycznym przełączaniem awaryjnym między dostawcami i zerową marżą, co oznacza przekazanie ceny katalogowej dostawcy bez zmian. Zespoły uruchamiające własną wersję tego potoku zyskują jedną relację rozliczeniową i jedno miejsce, w którym można zmienić model, gdy zmieni się jakość w ocenie recenzenta — a właśnie to ma wykrywać codzienna ewaluacja.

Granica ma znaczenie. Hostujemy modele. Nie hostujemy Claude Code, nie uruchamiamy Code Review for Claude Code i nie mamy dostępu do potoku, którego dotyczy ten artykuł. Code Review for Claude Code to produkt Anthropic, ogólnie dostępny w planach Team i Enterprise, a jego lżejsza wersja jest dostępna lokalnie jako /code-review. Jeśli chodzi ci o ten potok, to właśnie tam się znajduje; w wersji należącej do twojego zespołu router to decyzja infrastrukturalna, a nie decyzja dotycząca przeglądu.

Co mniejszy zespół może faktycznie skopiować

Zapisz zasady przeglądu tam, gdzie recenzent może je przeczytać: krótki CLAUDE.md dla projektu oraz REVIEW.md dla każdego obszaru, który wskazuje, jak wygląda niepowodzenie, i wymaga podania pliku i wiersza zamiast zgadywania. Ujmij poziomy ryzyka na piśmie, uczyń je właściwością zmiany, a nie autora, zacznij surowo i luzuj tylko na podstawie dowodów. Ogranicz zakres tego, co może zatwierdzić automatyczny przegląd, i nigdy nie pozwól, by zatwierdzenie przez agenta liczyło się jako zatwierdzenie przez człowieka. Powiąż zatwierdzenia z commitami. Uruchamiaj kolejkę scalania. Zamieniaj incydenty i wycofania zmian w przypadki testowe i ponownie oceniaj recenzenta za każdym razem, gdy go zmienisz, ponieważ niemierzony recenzent to linter z lepszym marketingiem.

Więc patrz na zabezpieczenie, a nie na czas zatwierdzania. Sposób, w jaki zespół sam to ujmuje, daje test dla każdej zmiany w przeglądzie, którą rozważasz: czy wskaźniki wycofań i incydentów się utrzymały, czy czas po prostu przeniósł się od recenzenta do osoby, która później sprząta? Na to pytanie można odpowiedzieć, korzystając z danych, które większość zespołów już ma, a pozwala ono odróżnić proces, który przyspieszył, od takiego, który tylko wygląda na szybszy przez kwartał.