Wąskie gardło review: AI pisze więcej kodu, a my zatwierdzamy ten gorszy

Historia, którą wszyscy opowiadają o kodowaniu z AI, jest historią o generowaniu: agent pisze kod szybciej, więc dostarczasz szybciej. To w połowie prawda, a brakująca połowa jest tam, gdzie kryją się wszystkie kłopoty. Kod musi zostać zrecenzowany, zanim trafi na produkcję — a review robią ludzie, w ludzkim tempie, z ludzką uwagą. Generowanie staniało 2–5x. Review nie. Więc wąskie gardło nie zniknęło; przesunęło się w dół strumienia i pogorszyło. A najbardziej niewygodnym odkryciem 2026 roku jest to, że dokładnie w momencie, gdy review liczy się najbardziej, po cichu zawodzi — bo zatwierdzamy kod napisany przez AI chętniej, mimo że jest gorszy.

Wąskie gardło przesunęło się w dół strumienia

Zacznij od wolumenu, bo skala jest naprawdę nowa. GitHub raportuje, że Copilot code review przetworzyło ponad 60 milionów review, rosnąc 10x w niespełna rok, oraz że ponad jedno na pięć code review na GitHubie obejmuje teraz agenta. Pull requesty tworzone przez agenta to już nie ciekawostka; to znacząca część wszystkiego, co przepływa przez review.

Gdy generowanie przyspiesza, a review nie, kolejka się zatyka — a dane mówią, że tak właśnie się dzieje, mocno. Badanie inżynierskie Faros AI z 2026 roku, raportowane na próbie około 22 000 deweloperów, wykazało, że wraz ze wzrostem adopcji AI czas review PR-ów wzrósł o 91%, a rozmiar PR-ów urósł o 154%, nawet gdy ukończenia zadań i wolumen merge’ów rosły — bez odpowiadającej poprawy metryk dostarczania. (To raportowane liczby Faros, a nie takie, które moglibyśmy potwierdzić wobec pierwotnego zbioru danych, ale kierunek jest jednoznaczny i spójny w całej branży.) Więcej kodu, większe PR-y, dłuższe review, płaskie wyniki. Przyspieszenie jest realne; po prostu piętrzy się o tę jedną część pipeline’u, która działa w ludzkim tempie.

To jest problem mechaniczny: system zbudowany pod wyjście w ludzkim tempie jest zalewany wyjściem w tempie maszynowym. Code review zawsze było ukrytym regulatorem tego, jak szybko zespół może bezpiecznie się poruszać; teraz generowanie wymknęło się temu regulatorowi, a kolejka jest miejscem, w którym koszt się ujawnia. Ale pod kolejką leży drugi problem, gorszy, bo jest niewidoczny — nie ujawnia się jako opóźnienie, które możesz zmierzyć, lecz jako wyciek jakości, którego nie możesz.

Część, która powinna cię niepokoić: lubimy gorszy kod

Recenzowane badanie z 2026 roku — More Code, Less Reuse (arXiv 2601.21276), zaprezentowane na konferencji MSR mining-software-repositories — wyszło poza wskaźniki zdawalności, by przyjrzeć się temu, co pull requesty AI faktycznie robią z bazą kodu i jak reagują na nie recenzenci. Obiektywne odkrycie jest tym, czego można się obawiać: „LLM Agents frequently disregard code reuse opportunities, resulting in higher levels of redundancy compared to human developers.” Agenci doczepiają nowy kod, zamiast użyć ponownie tego, co istnieje, więc każda zmiana niesie więcej duplikacji i więcej długoterminowego ciężaru utrzymania niż równoważna zmiana ludzka.

Oto zwrot akcji, który czyni to niebezpiecznym. Analiza sentymentu w badaniu wykazała, że „reviewers tend to express more neutral or positive emotions towards AI-generated contributions than human ones.” Przeczytaj te dwa odkrycia razem: kod AI jest obiektywnie bardziej redundantny i obciążony długiem, a jednocześnie recenzenci czują się lepiej, zatwierdzając go. Autorzy precyzyjnie nazywają mechanizm — „the surface-level plausibility of AI code masks redundancy, leading to the silent accumulation of technical debt in real-world development environments.”

To brama review zawodząca w najgorszy możliwy sposób: nie przez bycie powolną, lecz przez bycie oszukaną. Slop nie zostaje złapany, bo nie wygląda jak slop.

Dlaczego wiarygodność bije poprawność przy bramie

Warto być precyzyjnym co do tego, dlaczego staranny recenzent zatwierdza gorszy kod z czystszym sumieniem, bo ta porażka jest strukturalna, a nie kwestią leniwych inżynierów. Kod generowany przez AI jest płynny. Jest dobrze sformatowany, idiomatycznie nazwany, pewnie skomentowany i czysty składniowo. Każdy powierzchowny sygnał, który ludzki recenzent nauczył się odczytywać jako „ten autor wiedział, co robi”, jest obecny — i żaden z tych sygnałów nie śledzi rzeczy, które faktycznie się tu liczą: czy zmiana użyła ponownie tego, co powinna, czy dodała czwarty sposób na zrobienie czegoś, co baza kodu robi już na trzy sposoby, czy po cichu poszerzyła powierzchnię utrzymania.

Więc czujność recenzenta spada dokładnie wtedy, gdy powinna rosnąć. Niechlujnie wyglądający, ludzki PR zaprasza do pytań; dopracowany PR AI zaprasza do kciuka w górę.

Wyobraź sobie konkretny przypadek. Agent zostaje poproszony o dodanie helpera do formatowania dat. Baza kodu ma już dwa, zagrzebane w module utils, do którego agent nigdy nie zajrzał. Agent pisze trzeci — czysty, dobrze nazwany, ze schludnym docstringiem i zdającym testem. Diff to przyjemność czytać. Recenzent, nie widząc nic złego w diffie, zatwierdza go w trzydzieści sekund. Nic nie było złe w diffie. Złość była w tym, czego diff nie wiedział: że ta funkcja nie powinna istnieć. Pomnóż to przez każdy PR, w zespole mergeującym o 98% więcej pull requestów niż wcześniej, a dostajesz cichą akumulację długu, którą opisuje badanie — nie przez jakąkolwiek pojedynczą złą decyzję, lecz przez tysiące lokalnie wiarygodnych, których żadne review na poziomie diffa nigdy nie miało szans złapać. To ta sama źródłowa porażka, o której pisaliśmy z dwóch innych perspektyw. To dlatego agenci stają się gorsi, im dłużej działają — redundancja kumuluje się tura po turze — i to konkretny dowód na to, dlaczego zła pętla dostarcza zły kod szybciej: przyspiesz generowanie, zostaw bramę weryfikacji ludzkiej intuicji, a nie tylko dostarczasz szybciej, lecz dostarczasz gorzej szybciej, przy czym wszyscy czują się przy tym dobrze.

Naprawianie bramy

Jeśli problem polega na tym, że wiarygodność oszukuje ludzki osąd, naprawą jest przestać polegać na ludzkim osądzie w rzeczach, w których jest słaby, i zarezerwować go dla rzeczy, w których jest dobry. Konkretnie, brama review musi stać się odporna na powierzchowny połysk:

Zautomatyzuj kontrole strukturalne. Wykrywanie duplikacji, metryki złożoności, analiza zależności i martwego kodu, realne delty test coverage — redundancja, która oszukuje ludzkiego recenzenta, jest dokładnie tym, co narzędzie łapie deterministycznie. To powinno działać zanim człowiek w ogóle zobaczy PR, żeby człowiek nie był pierwszą linią obrony przed slopem.
Wymuszaj małe, wąsko zakreślone PR-y. PR o 154% większy jest nie do zrecenzowania z tą samą głębią; im większy diff, tym bardziej wiarygodność zastępuje czujność. Zakreślanie pracy na drobno — ta sama dyscyplina, która chroni długo działający harness przed gniciem — utrzymuje każdą zmianę faktycznie recenzowalną.
Recenzuj wobec istniejącego kodu, nie tylko diffa. Porażki reuse są niewidoczne w odizolowanym diffie i oczywiste w kontekście. Zadaniem recenzenta przy PR-ach AI jest mniej „czy ten kod jest poprawny?”, a bardziej „czy ten kod powinien istnieć, czy duplikuje to, co mamy?”.
Każ generującemu agentowi udowodnić reuse. Przepchnij kontrolę w górę strumienia: wymagaj, by agent szukał i cytował istniejące implementacje, zanim napisze nowe, i by uzasadnił każdy nowy helper wobec tego, co już istnieje. Najtańszym slopem do złapania jest slop nigdy nienapisany — pętla generowania, której kazano najpierw używać ponownie, produkuje znacznie mniej do odrzucenia przy bramie.

Idea spajająca: brama weryfikacji nie może być vibe’em. Gdy generowanie jest w tempie maszynowym i maszynowo wiarygodne, brama musi być zainżynierowana z tą samą powagą co generowanie — zautomatyzowana, gdzie się da, zakreślona tak, by pozostać recenzowalną przez człowieka, gdzie się nie da, i jawnie sceptyczna wobec połysku.

Dlaczego sprzyja to Azji Południowo-Wschodniej

Oto część, która liczy się dla tego regionu, i jest to najostrzejsza wersja argumentu, który wciąż stawiamy. Zespoły, które wygrają erę agentową, nie będą tymi, które generują najwięcej kodu — generowanie jest teraz towarem, dostępnym dla każdego za tę samą cenę. Będą tymi z najlepszą dyscypliną weryfikacji: osądem, by nie ufać wiarygodnemu diffowi, rygorem, by bramkować na strukturze zamiast sentymentu, powściągliwością, by utrzymywać PR-y małe. Nic z tego nie wymaga GPU, frontierowego modelu ani kapitału. Wymaga kultury inżynierskiej — a kultura to coś, co skupiony zespół w Phnom Penh albo Da Nang może budować rozmyślnie, szybciej, niż rozlazła organizacja tonąca w auto-zatwierdzanych PR-ach AI potrafi to naprawić.

To dyscyplina inżynierii pętli w punkcie, w którym opłaca się najbardziej bezpośrednio. Mały zespół, który traktuje review jako realną, zainżynierowaną bramę — i odmawia pozwolenia, by wiarygodność zastępowała poprawność — produkuje czystszą, łatwiejszą w utrzymaniu bazę kodu niż lepiej finansowany konkurent dostarczający 2–5x wolumen zatwierdzonego slopu. W świecie, w którym każdy potrafi generować, trwałą przewagą jest wiedza o tym, czego nie mergeować. To najbardziej niedoceniana umiejętność w stosie agentowym i zarazem najtańsza do zbudowania.