Agenci zastępują recenzenta, a nie samą recenzję

W czerwcu 2026 roku Martin Monperrus, badacz inżynierii oprogramowania znany z automatycznej naprawy programów, opublikował artykuł zatytułowany The End of Code Review: Coding Agents Supersede Human Inspection. Teza brzmi, że agenci kodujący przekroczyli próg możliwości, za którym sytuacja, w której człowiek bada różnicę kodu przed scaleniem, nie stanowi już koniecznej bramki jakości, a powszechny układ, w którym agenci piszą kod, a ludzie pozostają obowiązkowymi recenzentami, to ślepa uliczka.¹

Artykuł ma rację w większym stopniu, niż przyznają to jego krytycy, a myli się w jednym konkretnym i istotnym punkcie. Agenci zastąpili recenzenta: człowiek, który czyta różnicę kodu wiersz po wierszu w poszukiwaniu usterek, wykonuje pracę, którą zespół agentów robi teraz lepiej i przy każdym commicie. Artykuł utożsamia jednak tę rolę z samą recenzją. Gdy faktycznie uruchamia się opisany w nim potok agentów, ludzka praca nie znika. Przenosi się ona od inspekcji kodu do odpowiedzialności za intencję, którą kod miał spełnić. Uruchamiam ten potok. Recenzent umiera. Recenzja przesuwa się w górę stosu.

Chcę potraktować ten artykuł poważnie, ponieważ większość odpowiedzi na niego tego nie zrobi. Odruchowa replika brzmi „przecież agenci halucynują”, a Monperrus już to przyznaje. Uczciwe podejście zaczyna się od uznania tego, w czym ma on rację.

W skrócie

• Monperrus twierdzi, że agenci kodujący zakończyli potrzebę ludzkiej recenzji kodu, ponieważ każdy cel recenzji (wykrywanie usterek, styl, bezpieczeństwo, transfer wiedzy) jest realizowany lepiej i taniej przez agentów, a ludzka zdolność do recenzowania nie nadąża za przepustowością napędzaną przez agentów.¹
• Ma rację, że obowiązkowy checkbox z ludzką akceptacją odchodzi w przeszłość, oraz że agenci wykonują systematyczną inspekcję lepiej niż zmęczony człowiek przebiegający wzrokiem po dużej różnicy kodu.
• Nie jest w tej kwestii naiwny: artykuł przyznaje istnienie halucynacji, prompt injection, skorelowanych martwych pól w obszarze bezpieczeństwa i zastrzega rolę człowieka dla zmian wysokiego ryzyka, nowatorskich, regulowanych oraz wymagających oceny etycznej.¹
• Luka polega na tym, że traktuje on resztkową rolę człowieka jako niewielki zbiór sytuacji eskalacji. W produkcji jest ona nośnym centrum: agent optymalizuje pod kątem otrzymanej specyfikacji, a napisanie i wzięcie odpowiedzialności za tę specyfikację to nieredukowalnie ludzki akt.
• Rola recenzenta jest automatyzowana. Recenzja, rozumiana jako osąd, czy oprogramowanie jest poprawne ze względu na swój cel, przenosi się tam, gdzie agent nie może podążyć.

W czym artykuł ma rację

Monperrus opiera się na zestawieniu Bacchelli i Birda dotyczącym tego, dlaczego zespoły recenzują kod: wykrywanie usterek, egzekwowanie stylu i standardów, transfer wiedzy oraz świadomość zespołowa, z bezpieczeństwem jako piątym wymiarem.¹² Jego ruch polega na tym, by wziąć każdy z tych celów i wykazać, że agent realizuje go lepiej. Agenci sprawdzają każdy commit bez zmęczenia i bez opóźnień strefowych. Wyliczają klasy podatności bardziej systematycznie niż człowiek wykonujący doraźny przegląd. Generują podsumowania architektoniczne i zaktualizowaną dokumentację w momencie scalenia. Artykuł przytacza krzywą możliwości SWE-bench, aby uzasadnić tezę o przekroczeniu progu, od najlepszego modelu rozwiązującego poniżej 2 procent rzeczywistych zgłoszeń z GitHuba w momencie startu benchmarku w 2023 roku, do najlepszych agentów przekraczających 70 procent pod koniec 2025 roku.¹³

Nie mam zastrzeżeń do tej części, ponieważ codziennie obserwuję, jak to działa. Moja autonomiczna pętla budowania uruchamia bramkę z trzema recenzentami: osobni agenci sprawdzają poprawność, konwencje i bezpieczeństwo przed scaleniem kodu, a druga pętla wysyła implementację do niezależnego modelu w celu przeprowadzenia kontradyktoryjnego przeglądu. Ci agenci wychwytują prawdziwe usterki i wychwytują je przy każdej zmianie, a nie tylko przy zmianach, na które człowiek miał czas. Dwa wpisy poprzedzające ten na tej stronie przeszły każdorazowo przez ewaluatora będącego agentem, który ocenił je względem rubryki i wskazał konkretne problemy faktograficzne, które musiałem następnie naprawić. Twierdzenie z artykułu, że agenci wytwarzają wykonalny, ustrukturyzowany wynik recenzji porównywalny z wynikiem wyszkolonego recenzenta, nie jest dla mnie spekulacją. To moja codzienność.

Argument o przepustowości również jest słuszny i to właśnie tę część ludzie nie doceniają. Programista wspomagany przez agenta wytwarza więcej pull requestów dziennie, niż ludzka zdolność recenzowania jest w stanie wchłonąć. Gdy autor jest szybki, a recenzentem jest człowiek, kolejka recenzji staje się wiążącym ograniczeniem, a recenzja degeneruje się do formalności wykonywanej pod presją czasu.¹ Monperrus ma rację, że naiwny układ, w którym agenci piszą, a człowiek przybija pieczątkę, nie daje żadnej realnej gwarancji. Człowiek, który akceptuje, bo kod wygląda poprawnie, a testy przechodzą, nie recenzuje. On podpisuje.

Opisywany przez niego potok to ten, który uruchamiam

Tym, co artykuł proponuje w miejsce ludzkiej recenzji, nie jest „zaufaj jednemu modelowi”. Jest to potok weryfikacji z agentem w pętli: wiele niezależnych agentów, najlepiej różnych modeli, wytwarzających skalibrowaną, ustrukturyzowaną akceptację (pokrycie testami, skany bezpieczeństwa, ślady rozumowania w postaci JSON lub SARIF, standardowego formatu wymiany wyników analizy statycznej), a nie nieformalne wątki komentarzy, przy czym agenci są instruowani, by wstrzymywać się przy braku pewności, a ludzie są zarezerwowani dla trudnych przypadków.¹

To, pod innymi nazwami, architektura, którą buduję i o której piszę od roku. Argumentowałem, że pull requesty agentów potrzebują mniejszych powierzchni recenzji, że zautomatyzowana recenzja potrzebuje sprzeciwu, a nie jednego pewnego siebie sędziego, oraz że pakiety recenzji zawierające ustrukturyzowane dowody zastępują nieformalny komentarz do różnicy kodu. Nie spieram się więc z samym potokiem. Pomogłem zbudować argumentację na jego rzecz. Spieram się o to, co pozostaje człowiekowi, gdy potok już istnieje, ponieważ żyję w tej odpowiedzi, a nie jest to odpowiedź, którą daje artykuł.

Gdzie argument się załamuje: recenzja nigdy nie była wyłącznie inspekcją

Monperrus zastrzega rolę człowieka dla zmian wysokiego ryzyka, nowatorskiej architektury, regulowanych ścieżek kodu oraz osądu etycznego i ujmuje to jako eskalację: wyjątki kierowane do osoby, gdy agenci je oznaczą.¹ To ujęcie sprawia, że rola człowieka brzmi jak rzadkie przerwanie w skądinąd zautomatyzowanej linii.

Uruchamianie tej linii uczy czegoś przeciwnego. Agent nie generuje własnego celu. Optymalizuje pod kątem otrzymanej specyfikacji, a przy każdej zmianie, która ma znaczenie, ktoś musi zdecydować, co oznacza poprawność, zanim agenci będą mogli cokolwiek względem tego sprawdzić. Sam artykuł przyznaje istnienie tej granicy w sekcji dyskusji: agenci optymalizują pod kątem technicznych metryk jakości i nie są niezawodnie wyposażeni, by zauważyć, że zmiana w telemetrii narusza rozsądne oczekiwania użytkownika co do prywatności albo że poprawka w rankingu wzmacnia uprzedzenie.¹ Przedstawia się to jako ograniczenie na obrzeżach. Nie jest ono na obrzeżach. Pytanie „czy ta zmiana jest poprawna względem tego, czego faktycznie chcemy” znajduje się w centrum każdego nietrywialnego scalenia i jest dokładnie tym pytaniem, którego agent skalibrowany do specyfikacji nie może zadać o tę specyfikację.

Odczułem to konkretnie przy dwóch wpisach, które opublikowałem przed tym. Recenzent będący agentem ocenił je i wychwycił w każdym faktograficzne nadużycie: niezweryfikowane twierdzenie instytucjonalne w jednym, błędnie przypisaną statystykę w drugim. Wychwycenie było zasługą agenta. Naprawa już nie. Decyzja, jak skorygować nadużycie zgodnie z prawdą, które źródło faktycznie popierało twierdzenie, jak brzmiała uczciwa wersja zdania, wymagała osądu intencji, który rubryka mogła oznaczyć, ale nie rozwiązać. Agent wykrył, że coś jest nie tak. Człowiek zdecydował, jak wygląda to, co właściwe. Ten podział pracy to właśnie owo przeniesienie i dokonał się on przy rutynowej treści, a nie w regulowanym przypadku granicznym.

Człowiek nie opuszcza więc pętli. Człowiek przesuwa się z jej końca na jej początek. Recenzja była kiedyś ostatnim punktem kontrolnym, osobą badającą gotowy kod. W potoku agentów inspekcja jest zautomatyzowana, a nieredukowalna ludzka praca przenosi się na sam początek: do określenia intencji na tyle precyzyjnie, by agenci mieli coś prawdziwego, względem czego mogliby weryfikować, oraz do wzięcia odpowiedzialności za konsekwencje, gdy dostarczony wynik spełnia specyfikację, lecz mija się z celem. Odpowiedzialności nie można delegować systemowi, który optymalizuje pod kątem metryk, ponieważ odpowiedzialność to gotowość do bycia w błędzie świadomie i poniesienia za to konsekwencji.

Uczciwa wersja tezy

Gdy zedrzeć z tytułu prowokację, broniąca się teza jest węższa niż „koniec recenzji kodu”. Broniąca się teza to koniec człowieka jako inspektora różnicy kodu i obowiązkowego checkboxa akceptacji. Ta rola rzeczywiście odeszła, a udawanie inaczej, by chronić wygodny rytuał, jest własną formą nieuczciwości. Zespoły, które utrzymują człowieka w fotelu inspektora dla pozoru, akceptując kod agenta, którego nie potrafią naprawdę zbadać, już utraciły gwarancję, którą wydaje im się, że posiadają.

Lecz „recenzja kodu” zawsze była słowem zastępczym. Nazywała punkt kontrolny, a oznaczała osąd: czy ta zmiana robi to, czego potrzebujemy, bezpiecznie, w sposób, za którym możemy się opowiedzieć. Zautomatyzuj punkt kontrolny, a osąd nie wyparuje. Przenosi się do określania intencji na wejściu i odpowiedzialności na wyjściu, a w zespole poruszającym się z prędkością agentów staje się ważniejszy, a nie mniej ważny, ponieważ agenci wiernie i błyskawicznie zbudują wszystko, co mówi specyfikacja, łącznie z tym, co błędne. Im szybszy autor, tym bardziej wąskim gardłem staje się wiedza, o co prosić. Monperrus ma rację, że recenzent jest zastępowany. Myli się, że recenzja się kończy. Przenosi się ona do jedynego fotela, którego agent nie może zająć.

Kluczowe wnioski

Dla liderów inżynierii: - Przestańcie obsadzać ludzką recenzję jako inspekcję różnicy kodu. Agenci robią to lepiej i nieprzerwanie; checkbox z ludzką akceptacją na kodzie agenta to teatr gwarancji. - Przekierujcie tę ludzką zdolność na określanie intencji i odpowiedzialność, czyli te części recenzji, które rozstrzygają, czy poprawne-względem-specyfikacji jest poprawne-w-rzeczywistości.

Dla twórców narzędzi dla programistów: - Zbudujcie zespołowy potok recenzji opisany w artykule: wiele modeli, skalibrowane wstrzymywanie się, ustrukturyzowana akceptacja. Sprzeciw między recenzentami jest sygnałem. - Zaprojektujcie początek potoku, nie tylko bramkę. Najcenniejsza powierzchnia jest tam, gdzie człowiek zamienia intencję w specyfikację, względem której agenci mogą weryfikować.

Dla inżynierów: - Wasza umiejętność recenzowania nie staje się bezwartościowa; zmienia adres. Wartość przesuwa się od wypatrywania błędu w różnicy kodu do definiowania, co kod miał robić, i wzięcia odpowiedzialności za wynik.

Najczęściej zadawane pytania

Czy ten artykuł oznacza, że ludzka recenzja kodu się skończyła?

Człowiek jako inspektor różnicy kodu wiersz po wierszu i obowiązkowy akceptujący odchodzi w przeszłość, co jest najmocniejszym punktem artykułu: agenci wykonują systematyczną inspekcję lepiej i przy każdym commicie. Tym, co się nie kończy, jest osąd, którego recenzja kodu była substytutem, mianowicie czy zmiana jest poprawna ze względu na swój rzeczywisty cel. Ten osąd przenosi się do określania intencji i wzięcia odpowiedzialności za konsekwencje, a nie znika.

Co właściwie twierdzi Monperrus?

Że agenci kodujący realizują obecnie każdy deklarowany cel recenzji kodu (wykrywanie usterek, styl, transfer wiedzy, bezpieczeństwo) niższym kosztem i przy wyższej przepustowości, oraz że utrzymywanie ludzi jako obowiązkowych recenzentów kodu napisanego przez agentów to ślepa uliczka, bo nie daje żadnej realnej gwarancji i nie nadąża za skalą. Proponuje zespół agentów wytwarzający ustrukturyzowaną akceptację, z ludźmi zarezerwowanymi dla przypadków wysokiego ryzyka i etycznych. To artykuł stanowiskowy, a nie badanie empiryczne.¹

Gdzie argument jest najsłabszy?

W traktowaniu resztkowej roli człowieka jako rzadkiej eskalacji. W praktyce rola człowieka jest nośna przy każdej nietrywialnej zmianie, ponieważ agent optymalizuje pod kątem specyfikacji, której nie może ani stworzyć, ani zakwestionować. Zdefiniowanie specyfikacji i odpowiedzenie za jej skutek to praca centralna, a nie przypadek graniczny.

Czy zespoły powinny utrzymywać krok ludzkiej akceptacji przy pull requestach agentów?

Nie jako teatr inspekcji. Jeśli człowiek nie potrafi naprawdę zbadać zmiany, akceptacja jest podpisem, a nie recenzją. Lepiej zainwestować ludzki wysiłek wcześniej, w precyzyjne określanie intencji, oraz później, w wzięcie odpowiedzialności za dostarczony wynik, pozwalając zespołowi agentów wykonywać inspekcję.

Źródła

• Martin Monperrus, „The End of Code Review: Coding Agents Supersede Human Inspection”, arXiv, 11 czerwca 2026: arxiv.org/abs/2606.13175. Artykuł stanowiskowy syntetyzujący istniejące dowody na temat możliwości; wylicza cele recenzji kodu według Bacchelli i Birda, przywołuje krzywą możliwości SWE-bench i omawia ograniczenia, w tym halucynacje, prompt injection oraz odpowiedzialność etyczną.
• Alberto Bacchelli i Christian Bird, „Expectations, Outcomes, and Challenges of Modern Code Review”, ICSE 2013, empiryczne źródło taksonomii celów recenzji, na której opiera się artykuł: Microsoft Research
• Carlos E. Jimenez et al., „SWE-bench: Can Language Models Resolve Real-World GitHub Issues?”, ICLR 2024, benchmark stojący za krzywą możliwości (najlepszy model rozwiązał 1,96% w momencie startu): arxiv.org/abs/2310.06770
• Powiązane teksty na temat recenzji przez agentów z doświadczenia produkcyjnego: mniejsze powierzchnie recenzji, recenzja potrzebuje sprzeciwu, pakiety recenzji oraz autonomiczna pętla budowania, której bramka z trzema recenzentami jest potokiem opisanym w tym wpisie.