Czy nadal powinieneś przeglądać kod swojego agenta AI?

Dyskusja zaczyna się w ten sam sposób w każdej drużynie. Jedna strona mówi, że agenci teraz dostarczają czystszy kod niż połowa pull requestów, które wcześniej zatwierdzaliśmy, więc dlaczego wciąż czytamy każdą linię? Druga strona mówi, że to my jesteśmy tymi, którzy to zatwierdzili.

Obie strony mają rację. To właśnie dlatego ta dyskusja nigdy się nie kończy. Nie kończy się, ponieważ pytanie jest błędne, a gdy tylko naprawisz pytanie, odpowiedź staje się niemal nudna.

Argument za wysyłaniem bez czytania każdej linii

Zacznij od najsilniejszej wersji optymistycznego argumentu, ponieważ jest ona silniejsza, niż przyznają to większość recenzentów.

W przypadku zadania o wyraźnej specyfikacji i zestawie testów, nowoczesny agent kodujący produkuje bardziej spójny kod niż przeciętny człowiek pracujący pod presją czasu. Nie nudzi się na ścieżce błędu. Pisze sprawdzenie null w piątek o 18:00. Przestrzega konwencji projektowych, które mu podano, za każdym razem, bez małych cichych buntów, na które pozwala sobie zmęczony programista.

Ludzki przegląd był już zepsuty przed przybyciem agentów. Każdy, kto pracował w prawdziwej drużynie, zna odruch LGTM: uwaga recenzenta opada po kilku setkach linii, a zatwierdzenia, które następują, są społeczne, a nie techniczne. Nie straciliśmy złotej ery rygorystycznego przeglądu. Straciliśmy rytuał, który był już w większości teatrem.

Potem jest jeszcze kwestia objętości. Jeden programista uruchamiający pięć agentów równolegle generuje więcej różnic na godzinę, niż jakikolwiek człowiek może dokładnie przeczytać. Jeśli twoją zasadą jest "czytaj wszystko", to cicho przywróciłeś się jako wąskie gardło, które właśnie zautomatyzowałeś. Człowiek przeglądający różnicę 900 linii produkuje podpis bez zdobywania wiedzy, a to gorsze niż brak przeglądu w ogóle, ponieważ wytwarza pewność tam, gdzie jej nie ma.

Argument za utrzymywaniem człowieka na różnicy

Teraz druga strona, która również jest silniejsza, niż przyznają to entuzjaści.

Odpowiedzialność się nie przenosi. Model nie jest wzywany o 3 nad ranem. Nie bierze udziału w przeglądzie incydentów, nie rozmawia z klientem, którego dane wyciekły, i nie ponosi konsekwencji zmiany w następnym kwartale. Kto łączy, ten ponosi odpowiedzialność za wynik, a przegląd to sposób, w jaki ta odpowiedzialność jest wykonywana, a nie tylko deklarowana.

Recenzenci agenci zawodzą w tym samym kierunku, co autorzy agentów. To jest argument, który faktycznie rozstrzyga propozycję "pozwól, aby inny agent to przeglądał". Dwaj agenci z tej samej rodziny modeli, mający ten sam kontekst, dzielą priorytety, dzielą dane treningowe i dzielą ślepe punkty. Ich błędy są skorelowane. Drugi agent chętnie wychwyci brakujący test lub nieobsłużony błąd, a także chętnie zatwierdzi subtelne nieporozumienie dotyczące twojej dziedziny, które spowodowało błąd w pierwszej kolejności, ponieważ sam popełnił to samo nieporozumienie. Dwaj recenzenci, którzy są w błędzie w tym samym kierunku, nie sumują się do przeglądu.

Pomiar nie jest również korzystny. Dane z branży pokazują, że recenzenci wymieniają znacząco więcej rund na zmiany generowane przez AI niż na te napisane przez ludzi: kod przychodzi szybciej i dłużej staje się godny zaufania. Badanie z stycznia 2026 roku poszło dalej i wykazało, że zmiany generowane przez agentów niosą więcej redundancji i więcej skumulowanego długu technicznego na zmianę niż te napisane przez ludzi, podczas gdy recenzenci zgłaszają, że czują się lepiej zatwierdzając je. Ta różnica, między tym, jak dobry wydaje się kod, a tym, jak dobry jest, to całe ryzyko w jednym zdaniu.

Debata jest źle sformułowana

Oto przekształcenie, które kończy spotkanie.

Nie przeglądasz kodu, ponieważ nie ufasz autorowi. Przeglądasz go, ponieważ to ty podpisujesz. To są całkowicie różne czynności, a cała dyskusja wynika z ich pomieszania.

Gdy już to zobaczysz, "czy agent jest lepszy od człowieka" przestaje być decydującym pytaniem. Decydującym pytaniem jest: jeśli ta zmiana jest błędna, jak kosztowne jest to, aby się o tym dowiedzieć, i jak kosztowne jest to, aby cofnąć? Literówka w nagłówku marketingowym zostaje odkryta w kilka sekund i cofa się w kilka sekund. Sprawdzenie uprawnień odwrócone w middleware autoryzacyjnym zostaje odkryte przez klienta lub przez regulatora, i nigdy nie jest naprawdę cofnięte, ponieważ do tego czasu dane zostały już odczytane.

Więc odpowiedź nie brzmi "przeglądaj wszystko" ani "ufaj agentowi". To jest:

Przestajesz przeglądać linie. Zaczynasz przeglądać ryzyko.

Konkretnie, przegląd przesuwa się z środka pracy na jej dwa końce. Przedtem: przeczytaj plan, ponieważ błędny plan wykonany perfekcyjnie jest najdroższym trybem awarii, a plan ma piętnaście linii zamiast dziewięciuset. Potem: przeczytaj różnicę proporcjonalnie do promienia eksplozji. W międzyczasie linie należą do maszyny.

Jak wygląda "agent zepsuł"

Najbardziej użyteczną rzeczą, którą możesz przynieść do swojego zespołu, nie jest opinia, ale lista obiektywnych sygnałów. Nie "kod wydaje się zły", ale sygnały, które możesz sprawdzić w różnicy w mniej niż minutę. Oto te, które zasłużyły na swoje miejsce.

1. Testy zmieniły się w tym samym commicie, co kod, który pokrywają. Zielony został skonstruowany, a nie zaobserwowany. To jest najwyższy sygnał w tej liście i to jest to, co należy sprawdzić jako pierwsze.
2. Asercja została osłabiona lub test został wyłączony. skip, only, asercja rozszerzona, aby zaakceptować to, co nowy kod zwraca, try/catch, które pochłania błąd, który test miał ujawnić.
3. Różnica jest większa niż zadanie. Pliki, o które nikt nie prosił, zostały dotknięte. Rozrost zakresu w agencie to nie entuzjazm, to znak, że agent zreinterpretował cel gdzieś po drodze.
4. Wynalezione powierzchnie. Metoda API, opcja konfiguracyjna lub ścieżka, która nie istnieje. Kompiluje się w głowie agenta i nigdzie indziej.
5. Środowisko zostało naprawione zamiast kodu. Twardo zakodowana absolutna ścieżka, wartość specyficzna dla maszyny, osobisty token, nazwa użytkownika. Objaw zniknął na maszynie agenta i przeniósł się na maszyny innych.
6. Zależność pojawiła się bez pytania. Nowy łańcuch dostaw, nowa licencja, nowa powierzchnia konserwacyjna, zdecydowana przez coś, co tego nie utrzyma.
7. Duplikacja zamiast ponownego użycia. Zaimplementował pomocnika, który już istniał dwadzieścia linii dalej. To jest mechanizm stojący za zmierzonym długiem: każda zmiana wydaje się lokalnie rozsądna, a baza kodu cicho zyskuje trzeci sposób na zrobienie tego samego.
8. Podsumowanie nie pasuje do różnicy. "Naprawione i przetestowane", gdy żaden test nie został uruchomiony. Narracja jest generowana z tą samą pewnością, niezależnie od tego, czy praca się odbyła, więc traktuj to jako twierdzenie do weryfikacji, nigdy jako raport.
9. Instrukcje przestały być przestrzegane. Małe konwencje cicho porzucone to sposób, w jaki sesja degraduje, zanim zacznie całkowicie halucynować. Jeśli używasz kanarka w swoim pliku kontekstowym, to dokładnie to, co ma na celu wychwycenie.
10. Wrażliwe obszary zostały dotknięte mimochodem. Odczyt .env, nowe wywołanie sieciowe wychodzące, nowa linia logu zawierająca dane użytkownika, migracja zintegrowana z commitem funkcji.

Zauważ, co nie znajduje się na liście: styl, nazewnictwo, formatowanie, "zrobiłbym to inaczej". To zawsze były najsłabsze elementy ludzkiego przeglądu i teraz są naprawdę stratą dla człowieka. Usuń je ze swojego przeglądu, a odzyskasz uwagę, której potrzebujesz na dziesięć powyższych punktów.

Ile przeglądu zasługuje zmiana?

Decyduje promień eksplozji, a nie rozmiar różnicy. Tabela, którą twój zespół może przyjąć tego popołudnia:

Rozmiar różnicy mówi ci, jak długo trwa przegląd. Promień eksplozji mówi ci, czy jest opcjonalny.

Wiersze nie dotyczą poziomów zaufania. Chodzi o koszt bycia w błędzie, co jest cechą kodu, a nie tego, kto go napisał. To sprawia, że tabela jest użyteczna: nikt nie musi zgadzać się co do tego, jak dobrzy są agenci, aby zgodzić się na tabelę. Jeśli twój zespół utknął w filozoficznym pytaniu, pomiń je i negocjuj wiersze. Będziesz zaskoczony, jak szybko to się zbiega.

Jeśli twój produkt obsługuje dane osobowe w Europie, jeden dodatkowy wiersz jest pisany dla ciebie przez prawo, a nie przez gust: co funkcja zbudowana przez AI musi przestrzegać zgodnie z RODO nie jest decyzją do podjęcia, a "agent to napisał" nigdy nie było obroną.

Co się zmienia, gdy pięć agentów działa jednocześnie

Wszystko powyżej zakłada, że możesz zobaczyć zmianę. Przy równoległych agentach to założenie łamie się jako pierwsze, i łamie się w specyficzny sposób: różnica przestaje mieć jednego autora. Trzy agenty dotknęły roboczego drzewa od twojego ostatniego commita, a pytanie "kto zmienił ten plik i w ramach jakiego zadania" nie ma już oczywistej odpowiedzi. Przegląd bez przypisania nie jest przeglądem, to archeologia.

To jest problem narzędziowy, i to jest powód, dla którego AgentsRoom umieszcza przegląd tam, gdzie są agenci, a nie na końcu pull requestu:

• Review Mode pokazuje każdą zmianę, jaką wprowadziły twoje agenty, jako czytelną różnicę, zanim cokolwiek zostanie zatwierdzone. To jest krok "przeczytaj różnicę proporcjonalnie do promienia eksplozji", zrobiony na tyle tanio, że ludzie faktycznie to robią.
• Przegląd na poziomie agenta filtruje tę różnicę według agenta i pozwala na zatwierdzenie pracy każdego agenta osobno. Pięć równoległych agentów staje się pięcioma jednostkami do przeglądu zamiast jednego nieczytelnego roboczego drzewa, a zła zmiana pozostaje przypisana do zadania, które ją wyprodukowało.
• Wiadomość commit jest generowana z prawdziwej różnicy za pomocą przycisku błysku w polu commit, więc historia opisuje, co się zmieniło, a nie to, co agent powiedział, że robił. Ta różnica ma znaczenie o 3 nad ranem, sześć miesięcy później.

Nic z tego nie zastępuje osądu. Usuwa wymówki do jego niewykonywania.

Spraw, aby maszyna posiadała linie

Jeśli chcesz przestać czytać linie, coś innego musi je czytać. W praktyce cztery rzeczy noszą ten ciężar:

Testy, których agent nie napisał w tym samym oddechu, co kod. Napisane najpierw, lub napisane przez innego agenta, lub przynajmniej przeglądane jako ich własna zmiana. W momencie, gdy kod i jego testy pochodzą z tej samej generacji, przestają być niezależnym dowodem.

Recenzent z innym modelem. To jest praktyczna odpowiedź na problem skorelowanej awarii. Jeśli drugi agent przegląda, uruchom go na innym dostawcy lub rodzinie modeli niż autor. Nie wyeliminujesz błędów całkowicie, ale recenzent z rodziny Codex na kodzie napisanym przez Claude'a wychwytuje mierzalnie inną klasę problemów niż recenzent z tej samej rodziny modeli, dokładnie dlatego, że nie dzieli priorytetów autora.

Bramki, które się nie męczą. Typy, lint, skanowanie sekretów, minimalne pokrycie, CI, które odrzuca migrację związaną z funkcją. Każda zasada, którą możesz wyrazić jako bramkę, jest zasadą, którą nigdy więcej nie musisz zauważać.

Pętla, która zamyka się na sobie. Agent, który buduje, uruchamia swoją własną pracę zgodnie z planem i iteruje przed przekazaniem czegokolwiek, usuwa całą kategorię "nawet nie uruchomiono" z twojego przeglądu. To jest pętla samokorygującego agenta, i to jest różnica między agentem, który produkuje różnicę, a tym, który produkuje wynik. To nie odpowiada na pytanie, czy człowiek powinien podpisać. To po prostu oznacza, że człowiek podpisuje coś, co już działa.

Więc, czy nadal przeglądasz?

Tak, i mniej niż robisz to dzisiaj.

Przestań czytać linie, aby czuć się odpowiedzialnym. Przeczytaj plan wcześniej, ponieważ to tam popełniane są najdroższe błędy. Przeczytaj różnicę później proporcjonalnie do tego, co może zepsuć, używając drabiny zamiast swojego nastroju. Zachowaj człowieka, osobiście, na autoryzacji, płatnościach, uprawnieniach, danych osobowych i wszystkim, co jest nieodwracalne, ponieważ model nie może ponosić odpowiedzialności, a drugi agent dzieli ślepe punkty pierwszego. Wszystko inne oddaj testom, typom, bramkom i recenzentowi, który nie dzieli modelu autora.

Zespoły, które to źle rozumieją, zawodzą w jednym z dwóch kierunków, a oba są do uniknięcia. Jeden przegląda wszystko, staje się wąskim gardłem i cicho zaczyna zatwierdzać bez czytania, co jest najgorszym z obu światów. Drugi nie przegląda nic, szybko wysyła przez dwa miesiące, a potem spędza kwartał na spłacaniu długu, którego nigdy nie widział.

Dyskusja na twoim standupie nie dotyczy naprawdę tego, czy agenci są dobrzy. Chodzi o to, kto jest gotów podpisać. Odpowiedz na to, a polityka przeglądu pisze się sama.

Często zadawane pytania

Czy nadal powinieneś przeglądać kod generowany przez AI?

Tak, ale nie linia po linii we wszystkim. Przeglądaj plan przed rozpoczęciem agenta, a następnie przeglądaj różnicę proporcjonalnie do tego, co zmiana może zepsuć. Teksty i CSS przeglądają się przelotem. Autoryzacja, płatności, uprawnienia, dane osobowe i migracje są przeglądane linia po linii przez człowieka, za każdym razem.

Czy agent AI może przeglądać kod innego agenta AI?

Pomaga, ale nie jest to substytut dla człowieka w ryzykownym kodzie. Dwaj agenci z tej samej rodziny modeli, mający ten sam kontekst, mają tendencję do zawodzenia w tym samym kierunku. Ich błędy są skorelowane, więc drugi agent wychwytuje literówki i brakujące testy, ale dzieli ślepe punkty, które spowodowały błąd. Jeśli używasz recenzenta agenta, uruchom go na innym modelu niż autor.

Jak dowiedzieć się, czy agent AI popełnił błąd?

Szukaj obiektywnych sygnałów w różnicy, zamiast czytać pod kątem stylu. Najsilniejszy: testy zmieniły się w tym samym commicie, co kod, który pokrywają, co oznacza, że zielony został skonstruowany, a nie zaobserwowany. Inne to rozrost zakresu, wyłączona lub osłabiona asercja, wynalezione API, twardo zakodowana lokalna ścieżka i podsumowanie, które nie pasuje do różnicy.

Czy agenci AI zastąpią ludzkich recenzentów kodu?

Już zastąpili większość czytania linii. Nie mogą zastąpić podpisu. Odpowiedzialność nie przenosi się na model, więc człowiek nadal ponosi decyzję o połączeniu czegokolwiek, co jest trudne do odwrócenia.

Czy musisz przeglądać kod AI linia po linii?

Tylko tam, gdzie promień eksplozji to uzasadnia. Przegląd linia po linii nie skaluje się po kilku agentach działających równolegle, a człowiek przeglądający różnicę 900 linii o 18:00 produkuje podpis bez zdobywania wiedzy. Spędź tę uwagę na zmianach, które są kosztowne do cofnięcia.

Co nigdy nie powinno być scalane bez przeglądu przez człowieka?

Cokolwiek dotykającego autoryzacji, płatności, uprawnień, danych osobowych, migracji baz danych, ścieżek usunięcia i infrastruktury. Te mają jedną cechę: koszt bycia w błędzie nie jest proporcjonalny do rozmiaru różnicy.