Code review w erze agentów: kto sprawdza kod AI

Kiedy agent pisze kod, pierwsze pytanie nie brzmi „czy to działa”, tylko „kto to sprawdzi”. Stara intuicja — autor pisze, recenzent czyta — przestaje pasować, bo „autorem” jest model, który nie ponosi konsekwencji i nie pamięta wczorajszej decyzji. Code review nie znika. Zmienia się jego struktura. Najlepsze zespoły, które obserwuję, ustawiają dwa review: najpierw agent-recenzent, potem człowiek. Każdy z nich łapie inną klasę błędów, i to jest cała pointa.

Model dwóch review

Pierwsza warstwa to agent-recenzent: osobny przebieg modelu, który czyta diff, zanim zrobi to człowiek. Druga warstwa to człowiek, który czyta to, co zostało po agencie. Kolejność nie jest przypadkowa. Agent jest tani i niezmęczony, więc puszczasz go pierwszego — ma odsiać szum, zanim zacznie kosztować czas seniora. Człowiek wchodzi na koniec, bo jego uwaga jest najdroższym zasobem w całym procesie i nie wolno jej marnować na rzeczy, które maszyna wyłapie sama.

To nie jest „dwa razy to samo”. Gdyby agent i człowiek łapali te same błędy, druga warstwa byłaby marnotrawstwem. Sens pojawia się dokładnie dlatego, że ich pola widzenia się nie pokrywają. Agent widzi wzorce w kodzie. Człowiek widzi sens w problemie.

Dlaczego każde review łapie inne błędy

Agent-recenzent jest świetny w rzeczach mechanicznych i powtarzalnych: niespójny styl, brakujące typy, nieobsłużona gałąź błędu, naiwna ścieżka kodu, której nikt nie przetestuje, zduplikacja, której autor nie zauważył, bo widział tylko swój plik. Model przeczyta tysiąc linii bez znudzenia i wskaże dwadzieścia miejsc, gdzie brakuje obsługi null. Robi to konsekwentnie o 9 rano i o 23, w pierwszym PR-ze dnia i w trzydziestym.

Człowiek łapie coś, czego model strukturalnie nie widzi: błędną interpretację domeny. Agent dostał zadanie „policz rabat” i policzył rabat — tylko że w tej firmie rabat liczy się od ceny netto, a nie brutto, i nigdzie w kodzie tego nie ma, bo to wiedza, która żyje w głowach trzech osób. Model nie wie, że pisze poprawną odpowiedź na złe pytanie. To wyłapuje człowiek, który zna kontekst.

Druga rzecz zarezerwowana dla człowieka: „rozwiązanie połowy problemu”. Agent potrafi zamknąć ticket kodem, który obsługuje happy path i wygląda kompletnie, a milczy o tym, że migracja danych, edge case z pustą listą i wsteczna kompatybilność API zostały pominięte. Kod się kompiluje, testy przechodzą, PR wygląda na gotowy. Tylko że problem jest rozwiązany w 50%, a pozostałe 50% to właśnie to, co wybuchnie w produkcji. Model nie ma poczucia „czy to naprawdę domyka temat”. Człowiek ma.

Agent-recenzent komentuje, nigdy nie zatwierdza sam

To jest reguła, której nie wolno złamać: agent-recenzent może komentować, ale nie może zatwierdzić PR-a samodzielnie. Różnica między pomocnikiem a decydentem jest tu absolutna. W momencie, w którym agent zaczyna mergować własne uwagi bez ludzkiej decyzji, zamykasz pętlę, w której maszyna ocenia maszynę — a obie mają te same ślepe plamy.

Powód jest praktyczny, nie filozoficzny. Agent-recenzent działa na tym samym rozkładzie treningowym co agent-autor. Te same założenia, które autor przyjął po cichu, recenzent uzna za oczywiste i przepuści. Błąd domenowy, którego nie widzi autor, jest niewidoczny także dla recenzenta z tej samej rodziny modeli. Dlatego ludzka akceptacja nie jest formalnością — jest jedynym punktem w pętli, w którym wchodzi kontekst spoza danych treningowych.

W praktyce: agent-recenzent zostawia komentarze w PR-ze, oznacza miejsca ryzykowne, sugeruje poprawki. Status „approved” nadaje człowiek, świadomie, biorąc na siebie odpowiedzialność za to, co wchodzi na main. Agent nigdy nie jest ostatnim podpisem.

Co dzieje się, gdy agent dowozi 5x więcej PR-ów

Tu zaczyna się prawdziwy problem skali. Agent nie pisze pięć razy lepiej — pisze pięć razy więcej. Jeden inżynier z dobrze ustawionym agentem otwiera tyle PR-ów, co wcześniej mały zespół. Wąskim gardłem przestaje być pisanie kodu. Staje się nim review.

Zespoły, które tego nie przewidziały, wpadają w jeden z dwóch trybów. Albo review staje się gumową pieczątką — ludzie klikają „approve”, bo kolejka ma czterdzieści pozycji i nikt nie przeczyta tego uczciwie. Albo review staje się wąskim gardłem, które kasuje całe przyspieszenie z agentów — piszesz 5x szybciej, ale i tak dowozisz w starym tempie, bo PR-y czekają w kolejce trzy dni.

Wyjście nie polega na tym, żeby czytać szybciej. Polega na tym, żeby czytać mniej, ale mądrzej. Agent-recenzent powinien przejąć cały dół piramidy: styl, typy, oczywiste braki. Człowiek dostaje PR już przefiltrowany, z oznaczonymi miejscami ryzyka, i czyta tylko to, co wymaga ludzkiego osądu. Drugi mechanizm to różnicowanie: PR zmieniający tekst w stopce nie potrzebuje tego samego review co zmiana w kodzie rozliczeń. Trzeci: małe PR-y. Agent, który dowozi 5x więcej, powinien dowozić też 5x mniejsze kawałki — review dziesięciu małych diffów jest uczciwsze niż review jednego ogromnego.

Zmęczenie recenzją i jak z nim walczyć

Zmęczenie recenzją to nie lenistwo — to fizjologia uwagi. Po dwudziestym PR-ze tego samego dnia człowiek nie czyta, tylko skanuje. Mózg przechodzi w tryb rozpoznawania wzorców: „wygląda jak poprzednie, pewnie OK”. To jest dokładnie ten moment, w którym przechodzi błąd domenowy, bo on z definicji wygląda poprawnie.

Z agentami problem się nasila, bo kod od agenta jest jednolicie schludny. Nie ma literówek, nie ma dziwnych wcięć, nie ma niczego, co zatrzymałoby wzrok. Wszystko wygląda dobrze, więc recenzent przestaje się zatrzymywać. Paradoksalnie, kosmetyczna doskonałość kodu z modelu usypia czujność szybciej niż surowy kod juniora, który zmusza do myślenia.

Co działa w praktyce. Ogranicz liczbę review na osobę dziennie — po pewnym progu jakość spada poniżej zera, czyli wpuszczasz więcej błędów niż wyłapujesz. Rotuj recenzentów, żeby nikt nie czytał trzydziestu PR-ów z rzędu. Wymagaj od autora (także agenta) opisu „co i dlaczego” w PR-ze, bo czytanie zaczyna się od intencji, nie od diffu. I oddziel review „trywialne” od „ryzykownych” — te drugie rób rano, ze świeżą głową, nie o 18 jako dwudziesty z kolei.

Praktyczna checklista PR-a w erze agentów

To jest lista, którą człowiek przechodzi świadomie, po tym jak agent-recenzent zostawił już swoje komentarze. Agent zajmuje się punktami mechanicznymi; ta lista jest o tym, czego model nie wyłapie:

1. Czy ten kod rozwiązuje właściwy problem, a nie problem obok?
2. Czy problem jest domknięty, czy to tylko happy path? Gdzie są edge case'y?
3. Czy założenia domenowe są poprawne dla tej firmy, nie dla podręcznika?
4. Co się stanie przy migracji danych i wstecznej kompatybilności?
5. Czy testy sprawdzają zachowanie, czy tylko że linia się wykonała?
6. Czy agent-recenzent oznaczył miejsca ryzyka i czy każde z nich rozwiązano?
7. Czy PR jest na tyle mały, że dało się go uczciwie przeczytać?
8. Czy biorę odpowiedzialność za ten merge — czy klikam „approve” ze zmęczenia?

Ostatni punkt jest najważniejszy. Jeśli odpowiedź brzmi „klikam ze zmęczenia”, to znaczy, że proces ma za dużo PR-ów na zbyt mało ludzkiej uwagi — i trzeba naprawić proces, nie przepychać PR.

Mit: skoro agent pisze, agent niech recenzuje

Kuszące i fałszywe. Tak, drugi agent wyłapie część rzeczy — i powinien, to cała rola pierwszej warstwy. Ale dwa modele z tej samej rodziny dzielą te same ślepe plamy. Interpretacja domeny, „rozwiązana połowa” i odpowiedzialność za produkcję pozostają ludzkie. Agent-recenzent skaluje review w dół piramidy, gdzie błędy są liczne i mechaniczne. Człowiek pilnuje wierzchołka, gdzie błędy są rzadkie, drogie i niewidoczne dla maszyny. Usuń człowieka, a usuniesz jedyny punkt w pętli, który widzi spoza danych treningowych.

TL;DR

Code review w erze agentów to dwa review: agent-recenzent pierwszy, człowiek drugi. Agent łapie styl, typy i mechaniczne braki; człowiek łapie błędną domenę i rozwiązaną połowę problemu. Agent komentuje, nigdy nie zatwierdza sam — bo dzieli ślepe plamy z autorem. Gdy agent dowozi 5x więcej PR-ów, wąskim gardłem staje się review: ratuj je filtrowaniem, różnicowaniem ryzyka i małymi PR-ami. Walcz ze zmęczeniem recenzją limitami i rotacją. Trzymaj się checklisty — a ostatnie pytanie zawsze brzmi: czy biorę odpowiedzialność za ten merge.