Artykuł · AI-DLC i wytwarzanie oprogramowania

Code review, gdy kod pisze agent: zasady dla zespołu

W code review kodu od agenta recenzent AI robi pierwszy przebieg, zatwierdza człowiek spoza zadania, a głębokość sprawdzania zależy od ryzyka zmiany. Wąskim gardłem staje się przegląd.

Dla: Liderzy zespołów, architekci, staff i senior engineers, bezpieczeństwo aplikacji · Stan na 02.11.2026 · Autor: Karol Krawczyk

Ile pull requestów zaczyna agent AI?

GitHub podał w raporcie Octoverse z 28 października 2026, że we wrześniu ponad 40% pull requestów zaczęło się od agenta, wobec 17% w marcu. We wrześniu dało to 110 mln pull requestów. Agent-started oznacza pull request, którego pierwszy szkic pochodzi od wykrywalnego agenta, a GitHub nazywa tę liczbę dolną granicą. Mowa więc o udziale w pull requestach, nie w liniach kodu, i o całym GitHubie, nie o typowej firmie. Zespół powinien policzyć własny udział, zanim zmieni proces.

Te same dane mówią o obciążeniu recenzenta. Zmiany zaczęte przez agenta dotykają wielu plików w około 87% przypadków, pozostałe w 79%. We wrześniu 90% z nich scalono w ciągu dwóch tygodni, wobec około 86% pull requestów bez wykrytego agenta. Wysoki odsetek scaleń nie dowodzi jakości, bo mierzy decyzję o scaleniu, a nie to, co stało się później. LinearB w raporcie benchmarkowym na 2026 rok, udostępnionym w grudniu 2025, z 8,1 mln pull requestów pokazuje niemal odwrotny obraz: w ciągu 30 dni scalono 32,7% zmian AI wobec 84,4% ręcznych. Według PDF raportu pull requesty od agentów czekają na pierwszego recenzenta 5,3 razy dłużej niż zmiany bez AI (percentyl 75: 1055 wobec 201 minut), a przegląd trwa 382 minuty wobec 252. Strona opisująca raport podaje inne liczby: 4,6 razy i przegląd 2 razy szybszy. Raport nie wyjaśnia, jak rozpoznawano zmiany AI, więc tych liczb nie da się zestawić z GitHubem.

Kto przegląda pull requesty od agentów AI?

Szczegółowe dane o przeglądzie pull requestów od agentów AI pochodzą z Polski. Badacze z Uniwersytetu Mikołaja Kopernika w Toruniu przeanalizowali w pracy z maja 2026, przyjętej na EASE 2026, zbiór AIDev. W repozytoriach z co najmniej 100 gwiazdkami 61,38% z 33 596 pull requestów od AI nie miało zapisanego przeglądu, a 84% nie miało go wcale albo miało tylko przegląd AI. Kiedy jednak porównano zmiany od AI i od ludzi w tych samych repozytoriach, braków zapisanego przeglądu było mniej przy AI: 28,92% wobec 34,52%. Różnica dotyczy rodzaju przeglądu: wyłącznie ludzki dostało 8,08% przeglądanych zmian od AI i 25,21% zmian od ludzi. Ponad jedna czwarta komentarzy ludzi pod zmianami AI to wskazówki dla agenta, nie ocena kodu. Autorzy zastrzegają, że milczące zatwierdzenie liczą jako brak przeglądu, a badanie nie ocenia jakości ani skuteczności przeglądów.

Zielone testy też nie zastępują czytania. W notatce METR z 10 marca 2026 czterej opiekunowie scikit-learn, Sphinx i pytest dostali 296 zmian od AI, które przeszły automatyczny test SWE-bench. Wskaźnik ich decyzji o scaleniu był o około 24 punkty procentowe niższy od wyniku testów. Powody sięgały od jakości kodu po nierozwiązane zadanie. Próba jest mała, agent miał tylko jedno podejście bez uwag zwrotnych, a recenzenci pracowali bez CI, więc wynik opisuje lukę między testem a osądem opiekuna przy jednym podejściu.

Recenzent AI w code review: możliwości i koszt

Copilot code review czyta kod z kontekstem repozytorium i proponuje poprawki. Szacunki GitHuba to około 0,25 dolara za przegląd na poziomie Lite, 1,50 dolara na Balanced i 10 dolarów na Max, bez minut GitHub Actions. Claude Code Review uruchamia kilku agentów równolegle, weryfikuje znaleziska i skupia się na błędach groźnych dla produkcji. Nie buduje ani nie uruchamia kodu, nie zatwierdza i nie blokuje zmian. Anthropic podał 9 marca 2026, że średni koszt to 15 do 25 dolarów, a wewnętrznie odsetek pull requestów z merytorycznymi uwagami wzrósł z 16% do 54%, przy czym inżynierowie uznali za błędne mniej niż 1% znalezisk. To dane dostawcy o własnym zespole, bez zewnętrznej weryfikacji.

Liczba znalezisk rośnie z wielkością zmiany: według danych Anthropic z marca 2026 w pull requestach powyżej 1000 linii narzędzie znajdowało coś w 84% przypadków, średnio 7,5 problemu, a w tych poniżej 50 linii w 31%, średnio 0,5 problemu. GitHub podał w Octoverse z 28 października 2026, że użycie przeglądu wspomaganego przez AI wzrosło rok do roku o ponad 90%.

Obie dokumentacje mówią to samo o ograniczeniach. GitHub nie gwarantuje wykrycia wszystkich problemów, Anthropic przypomina, że brak znalezisk nie oznacza bezpiecznego kodu. Recenzent AI daje więc pierwszy przebieg, a odpowiedzialność za scalenie zostaje przy zespole. Trzeba też liczyć koszt: tryb After every push u Anthropic mnoży cenę przez liczbę pushów.

Ustawienia code review łatwe do przeoczenia w GitHubie i Claude Code

Trzy domyślne zachowania GitHuba warto znać przed włączeniem agenta. Osoba, która zleciła Copilotowi pull request, nie może go zatwierdzić, a gdy pull requesta nie da się przypisać osobie i repozytorium wymaga zatwierdzeń, potrzebne jest jedno dodatkowe. Workflow nie startują po pushach agenta, dopóki ktoś z prawem zapisu ich nie dopuści, a dokumentacja radzi zwrócić uwagę na zmiany w .github/workflows. Istnieje przy tym opcja, w której zatwierdzenie Copilota spełnia regułę wymaganych recenzji. Włączenie jej zdejmuje człowieka z tego punktu, dlatego w kodzie produkcyjnym zostaw ją wyłączoną.

Mniej oczywista jest gałąź, z której recenzent czyta instrukcje. Copilot bierze je z gałęzi head, czyli ze zmienianej gałęzi, natomiast Claude Code Review bierze REVIEW.md z gałęzi bazowej i nigdy ze zmian w pull requeście. W pierwszym przypadku pull request może więc zmienić reguły, według których sam będzie oceniany. To wniosek z dokumentacji, nie wynik testu. Pliki instrukcji powinny mieć właściciela w CODEOWNERS, a ich zmiany przegląd człowieka.

Jak ustawić code review według ryzyka zmiany?

Code review według ryzyka dzieli zmiany na trzy poziomy, których progi trzeba dopasować do własnego systemu. Ten podział to propozycja tego tekstu, oparta na ustawieniach narzędzi i tekście DORA z 10 marca 2026 o "verification tax": czas zaoszczędzony przy pisaniu przechodzi na sprawdzanie, a recenzenci dostają większe zmiany. DORA radzi dawać autorowi uwagi AI jeszcze w trakcie pisania, pracować małymi porcjami i przemyśleć, czy przegląd asynchroniczny nadal ma sens.

Zmienia się też to, na co człowiek patrzy. Styl i proste błędy może wyłapać automat, dlatego recenzent powinien zacząć od pytania, czy zmiana rozwiązuje właściwy problem. Potem sprawdza, czy agent nie osłabił testów, by przeszły, czy nie dodał zależności, czy nie obszedł istniejącej konwencji i czy opis pull requesta zgadza się z diffem. To propozycja tego tekstu, nie wynik badania, choć odpowiada powodom odrzuceń z notatki METR, gdzie obok jakości kodu pojawiały się psucie innego kodu i nierozwiązane zadanie. Trzy poziomy przeglądu:

Niskie ryzyko, np. testy, dokumentacja, zmiany bez wpływu na zachowanie: CI, recenzent AI i szybkie potwierdzenie człowieka.
Zwykła zmiana funkcjonalna: osoba zlecająca sama czyta wynik przed prośbą o przegląd, a drugi człowiek sprawdza zgodność z celem i testy.
Wysokie ryzyko, np. uwierzytelnianie, płatności, dane osobowe, migracje, workflow i pliki instrukcji: właściciel kodu, przegląd bezpieczeństwa, zmiana podzielona na małe części.

Co zrobić w firmie

Policz, jaki odsetek pull requestów w firmie zaczyna agent i ile czeka na pierwszy przegląd człowieka
Zapisz zasadę, że osoba zlecająca agentowi czyta wynik i odpowiada za niego przed prośbą o przegląd
Wprowadź limit wielkości zmiany od agenta i poziomy ryzyka w opisie pull requesta
Sprawdź, skąd narzędzia czytają instrukcje, i dodaj je do CODEOWNERS
Nie pozwalaj, by zatwierdzenie AI spełniało regułę wymaganych recenzji w kodzie produkcyjnym
Wprowadź recenzenta AI na próbnej grupie repozytoriów z limitem wydatków i sprawdź, które uwagi prowadzą do zmian

Powiązane materiały

Źródła

Chcesz przełożyć to na swój zespół?

Szkolimy zespoły z pracy z Copilotem, Claude Code i Codexem na ich własnych zadaniach.

Umów rozmowę Oferta dla firm

Więcej: AI-DLC i wytwarzanie oprogramowania

← Wszystkie artykuły