Jak sprawdzają kod najwięksi: proces zespołu Claude Code

W monorepo Anthropic w maju scalano średnio około 2500 zmian dziennie, we wrześniu ponad 30 000. W osobnym repozytorium Claude Code od czerwca do września liczba scalonych pull requestów wzrosła ponad dwukrotnie, a odsetek tych, które trzeba było wycofać, spadł o ponad 40%. Obie liczby podano względnie, bez wartości wyjściowych, i pochodzą od firmy, która sprzedaje narzędzie do przeglądów.

Miarą jest czas ludzi, bezpiecznikiem odsetek wycofań

Zespół uważa, że pytanie „czy ktoś przeczytał ten kod?” słabo zastępuje właściwe: co może pójść źle w tej zmianie i która kontrola, automatyczna albo ludzka, powinna to wyłapać. Cel: większość pull requestów w repozytoriach Claude Code (CLI, aplikacje desktopowa, webowa i mobilne) ma być scalana z udziałem najwyżej jednej osoby, choćby samego autora, bez wzrostu liczby wycofań i incydentów.

Czas ludzi mierzy się liczbą ludzkich zatwierdzeń na PR (mediana i 95. percentyl), liczbą ludzkich komentarzy i tym, jak długo PR czeka na człowieka. Odsetek wycofań i incydentów działa jak bezpiecznik: jeśli rośnie, czas zaoszczędzony na przeglądach przeniósł się po prostu na naprawy.

Sześć warstw kontroli i szybkie wycofanie

Każda warstwa łapie część błędów i przepuszcza inne. Przez wszystkie przechodzi niewiele, a na te nieliczne czeka szybkie wycofanie.

• Weryfikacja przed PR. Agent dostaje coś, co da się uruchomić: testy, build albo zrzut ekranu do porównania z projektem graficznym, i ma pokazać wynik, zamiast ogłosić, że skończył. Potem diff czyta subagent z czystym kontekstem. Boris Cherny, twórca Claude Code, szacuje, że taka pętla sprawdzania daje dwa do trzech razy lepszy wynik końcowy.
• Przegląd AI przy każdym PR. Kilka agentów szuka błędów równolegle, osobna grupa głosuje nad każdym znaleziskiem i publikowane są tylko te, co do których zgodzi się dość głosujących, bez uwag o samym stylu. Każdy komentarz dostaje etykietę Important, Nit albo Pre-existing, a ta ostatnia chroni autora przed winą za błąd, którego PR nie wprowadził. Na każdy trzeba odpowiedzieć poprawką albo zamknięciem wątku z uzasadnieniem.
• Przegląd bezpieczeństwa, który blokuje. Dopóki otwarte jest jakiekolwiek znalezisko z przeglądu błędów albo bezpieczeństwa, PR nie da się scalić.
• Kontrole w CI: lint, sprawdzanie typów, testy na wszystkich platformach i build. Szablon PR pyta, jak zmianę sprawdzono i jak ją wycofać. Claude może te pola wypełnić, ale podpisuje się pod nimi osoba, która zleciła zmianę.
• Zatwierdzenie według ryzyka. Dokumentacja, teksty, funkcje tylko do użytku wewnętrznego i zmiany, które tylko coś dodają i są ukryte za flagą, nie potrzebują człowieka, gdy automatyczny przegląd i kontrole bezpieczeństwa są zielone. Zwykłe zmiany produktu i wrażliwe obszary, takie jak cache, autoaktualizacja czy prompty systemowe, wymagają jednej osoby, a najbardziej ryzykowny kod dwóch.
• Kolejka scalania, flagi i stopniowe wydanie. Kolejka ponownie uruchamia wszystkie kontrole na main z dołączoną zmianą, więc dwa PR‑y, które osobno przechodzą, nie zepsują razem gałęzi głównej. Nowe funkcje dostają zwykle najpierw pracownicy Anthropic, a publiczne wydania trafiają do kanału latest, za którym z opóźnieniem idzie stable.

Pod spodem jest szybkie wycofanie: flagę wyłącza się bez wdrożenia, a przy omawianiu incydentu pada pytanie, która warstwa powinna była go złapać.

Poziom ryzyka wynika ze zmiany, nie z autora

Klasyfikator czyta zmianę i przypisuje jej poziom, a drugi sprawdza, czy ta konkretna zmiana nie potrzebuje kolejnej osoby, nawet jeśli poziom tego nie wymaga. Ścieżki oznaczone przez właścicieli jako wrażliwe i każdy plik workflow CI zawsze wymagają człowieka. Z łagodniejszych zasad zatwierdzania korzystają tylko autorzy z listy zaufanych, głównie zespół, do którego należy repozytorium.

Do własnej firmy najłatwiej przenieść trzy reguły. Zatwierdzenie przez agenta nigdy nie liczy się jako zatwierdzenie człowieka. Przy PR napisanym przez agenta osoba, która kierowała agentem, jest jednym z wymaganych recenzentów, tak jakby pisała kod sama. Zatwierdzenie obejmuje jeden konkretny commit: gdy pojawi się commit, za który system nie ręczy, na przykład push agenta albo ręcznie rozwiązany konflikt, PR trzeba zatwierdzić ponownie.

Ludziom zostaje to, czego automat nie oceni: decyzja, czy w ogóle coś budować, przegląd kodu rozliczeń, autoaktualizacji i CI oraz architektury, którą inni będą kopiować, a także ocena dowodów, takich jak wyniki testów i zrzuty ekranu. Reguła zespołu brzmi: jeśli nie umiesz powiedzieć, czego kontrole nie wyłapią, poproś o prawdziwy przegląd zamiast szybkiej akceptacji.

Recenzent, który nie umie przestać

Najwięcej uczy błąd, który zespół popełnił sam. Agent piszący kod i agent recenzent mogą bez końca dokładać sobie pracy: jeden PR w projekcie CLI przeszedł w nocy ponad 50 rund przeglądu i poprawek, zanim autor go zatrzymał. Gdy zespół sprawdził przez git blame, czego dotyczyły powtarzane uwagi, w około 59% był to kod obecny od pierwszego przejścia recenzenta. Recenzent rzadko znajdował nowe błędy, za to w każdej rundzie kilka kolejnych starych.

Człowiek zbywa drobną uwagę w kilka sekund. Agent ją poprawia, a to oznacza kolejny commit i kolejną rundę. Zespół zmienił więc zasady ponownego przeglądu: po trzech rundach recenzent prosi autora o przemyślenie podejścia, po pierwszych przejściach czyta już tylko nowy diff, zgłasza całą klasę błędu, żeby autor poprawił wszystkie wystąpienia naraz, i nie powtarza znalezisk, które już zgłosił.

Postępy recenzenta mierzy zbiór testowy z PR‑ów, które wywołały incydenty; każdy błąd i jego miejsce potwierdzili inżynierowie znający ten kod. Recenzent przechodzi go codziennie, a każdą zmianę recenzenta ocenia się na całości. Szum mierzy się tym, co ludzie robią z komentarzami: czy poprawiają kod, czy uznają uwagę za błędną lub nieistotną. Na PR‑ach, o których wiadomo, że są czyste, zespół liczy zgłoszenia, które skłoniłyby kogoś do szkodliwej zmiany.

Co przenieść do zespołu pięciu osób

Mała firma nie potrzebuje klasyfikatorów ryzyka ani kolejki scalania. Wystarczą trzy rzeczy. Pierwsza to szablon PR z polami, które poleca Anthropic: jak sprawdzono, jakie ryzyko, jak wycofać. GitHub wczyta go z pliku .github/pull_request_template.md:

## Jak to sprawdzono
<!-- Uruchomione polecenia i ich wynik. Zrzut ekranu przy zmianie w interfejsie. -->

## Ryzyko
<!-- Niskie, średnie albo wysokie. Czego dotyka zmiana: płatności, dane klientów, CI? -->

## Jak wycofać
<!-- Revert commita, wyłączenie flagi albo kroki ręczne. -->

## Kto odpowiada
<!-- Jeśli kod napisał agent: osoba, która nim kierowała. -->

Druga to trzy ustawienia ochrony gałęzi głównej na GitHubie, bliskie regułom Anthropic. Dismiss stale pull request approvals when new commits are pushed unieważnia zatwierdzenie, gdy zmieni się diff. Require review from Code Owners razem z plikiem CODEOWNERS wymaga akceptacji właściciela kodu przy zmianach w uwierzytelnianiu, rozliczeniach, instalatorach oraz workflow CI i wydań. Require conversation resolution before merging blokuje scalenie PR z nierozwiązanym wątkiem, także wątkiem recenzenta AI. W repozytoriach prywatnych ochrona gałęzi wymaga planu GitHub Pro, Team albo Enterprise.

Trzecia, dla firm na planie Claude Team lub Enterprise, które włączą Code Review, to plik REVIEW.md w głównym katalogu repozytorium. Usługa czyta go z gałęzi bazowej albo domyślnej, nigdy ze zmian w samym PR, a wykluczenia ścieżek, limit drobiazgów i obniżanie ważności działają tylko wtedy, gdy plik leży na chronionej gałęzi. Lokalne polecenie /code-review czyta CLAUDE.md, ale nie REVIEW.md, więc reguły dla obu narzędzi trzymaj w CLAUDE.md.

# Instrukcje przeglądu

## Co tu znaczy Important
Important zarezerwuj dla błędów, które zmienią kwotę na fakturze albo
w zamówieniu, pokażą dane jednego klienta innemu, zapiszą dane osobowe
w logach albo zablokują wycofanie wdrożenia. Styl i nazewnictwo to
najwyżej Nit.

## Limit drobiazgów
Zgłoś najwyżej pięć uwag Nit w jednym przeglądzie.

## Nie zgłaszaj
- Tego, co sprawdza już CI: lint, formatowanie, błędy typów
- Plików generowanych w `src/gen/` i plików `*.lock`

## Zawsze sprawdź
- Każde zapytanie do bazy jest zawężone do bieżącego klienta
- Kwoty są liczbami całkowitymi w groszach, nigdy liczbami zmiennoprzecinkowymi
- Twierdzenie o działaniu kodu wskazuje plik:linię, a nie domysł z nazwy

## Podsumowanie
Zacznij od liczby znalezisk. Jeśli nie ma czego poprawiać, napisz to wprost.

Stałej ceny nie ma, koszt rośnie z wielkością zmiany i poziomem przeglądu. Przy premierze w marcu Anthropic podawał, że przegląd kosztuje średnio 15 do 25 dolarów i trwa około 20 minut, co przy 80 PR miesięcznie i jednym przeglądzie na PR daje 1200 do 2000 dolarów. Repozytorium dodane w panelu administracyjnym startuje jednak z przeglądem po każdym pushu, co mnoży koszt przez liczbę pushy, więc na pilotaż przestaw je na jeden przegląd po otwarciu PR i ustaw miesięczny limit wydatków. Lżejszą i według Anthropic tańszą opcją jest Claude Code GitHub Action z własnym kluczem API, a polecenie /code-review działa w sesji Claude Code na każdym planie. Usługa nie jest dostępna dla organizacji z włączonym Zero Data Retention.

Pierwszy krok: lista wycofań

Zanim zapłacisz za jakiekolwiek narzędzie, załóż arkusz. Każdy PR, który trzeba było wycofać albo który wywołał incydent, zapisuj z linkiem do poprawki i jednym zdaniem o tym, gdzie był błąd. Anthropic zrobił z takiej listy zbiór, na którym codziennie sprawdza recenzenta. U Ciebie po kwartale będzie to pierwszy uczciwy test dowolnego recenzenta AI: uruchamiasz go na tych PR‑ach i liczysz znalezione błędy, a na kilku czystych liczysz fałszywe alarmy.

Jeśli kod pisze dla Ciebie software house, zapytaj, kto odpowiada za zmianę napisaną przez agenta, czy zatwierdzenie bota liczy się jako akceptacja i ile minut zajmuje wycofanie złego wdrożenia.