Code review z AI, gdy coraz więcej kodu piszą agenci kodujący

Dwa znaczenia code review z AI

Pod pojęciem przeglądu kodu AI kryją się dwa zadania. W pierwszym model przegląda pull request i publikuje uwagi, tak jak robią to CodeRabbit, Qodo, GitHub Copilot code review czy Bugbot. W drugim ludzie przeglądają kod napisany przez agenta kodującego, czyli zajmują się przeglądem kodu generowanego przez AI. Zespoły, które wdrażają agentów kodujących, potrzebują obu.

Presję tworzy skala. Inżynier, który rano przekaże agentom trzy zadania, w południe może mieć trzy pull requesty do przejrzenia, a recenzent bywa pierwszą osobą, która czyta je uważnie. Automatyczny przegląd może przejąć dużą część sprawdzania linijka po linijce, ale nie zdecyduje, czy zmiana w ogóle powinna powstać, i nie odpowie za nią po merge'u. W konfiguracjach, które budujemy, recenzent AI robi pierwszy przegląd, a decyzję podejmuje konkretna osoba.

W czym automatyczny przegląd kodu jest dobry, a co mu umyka

Obecni recenzenci AI czytają diff razem z otaczającym kodem, a niektórzy najpierw analizują całe repozytorium. Dobrze radzą sobie z problemami widocznymi w kodzie: nieobsłużonymi błędami i przypadkami null, błędami off-by-one, niezwolnionymi zasobami, niebezpieczną obsługą danych wejściowych, sekretami w kodzie, testami, które niczego nie sprawdzają, i naruszeniami twoich spisanych reguł. Czterdziestemu pull requestowi danego dnia poświęcają tyle samo uwagi co pierwszemu.

Umyka im głównie wiedza, której nie ma w repozytorium. Te kwestie nadal wymagają osoby, która zna zadanie i systemy wokół kodu.

• Intencja: czy zmiana robi to, czego wymagało zadanie
• Architektura: czy zmiana pasuje do tego modułu, czy powiela coś, co kod już robi
• Poprawność produktowa: zachowanie spójne w kodzie, ale błędne z punktu widzenia użytkowników, cen, uprawnień lub regulacji
• Wpływ na inne serwisy: kontrakty API, formaty komunikatów, wspólna konfiguracja i migracje na danych produkcyjnych
• Kwestie operacyjne: kolejność wdrożenia, feature flagi, monitoring i wycofanie zmiany

Pokrycie ma też luki. Według dokumentacji GitHuba Copilot code review pomija pliki zarządzania zależnościami, takie jak package.json i Gemfile.lock, a także pliki logów i SVG, więc nowa zależność wymaga innej kontroli. Sprawdź też listę wyłączeń swojego narzędzia.

Zmiany pisane przez agentów powtarzają też wzorce, które twoje reguły powinny nazywać. Typowe są testy poprawiane tak długo, aż przejdą, szeroka obsługa wyjątków, zduplikowane funkcje pomocnicze i zmiany wykraczające poza zadanie.

Konfiguracja recenzenta AI

Większość tych narzędzi łączy się z twoim hostingiem Git jako aplikacja albo działa w CI. Właściwa praca polega na ustaleniu, co recenzent sprawdza i co się dzieje, gdy coś znajdzie.

1. 1

   Ustal zakres

   Zacznij od jednego lub dwóch repozytoriów, do których regularnie trafiają pull requesty od agentów, i wyłącz z przeglądu kod generowany, lockfile i dołączone biblioteki zewnętrzne. W większości narzędzi wybierasz, kiedy uruchamia się review, na przykład przy otwarciu, przy każdym pushu albo na żądanie, a review przy każdym pushu zwykle kosztuje najwięcej.

2. 2

   Napisz krótkie reguły review

   Daj recenzentowi reguły, które stosowałby doświadczony inżynier w tym repozytorium, zaczynając od tego, co jest tutaj poważne, a co można pominąć. Formatowanie, linting i błędy typów zostaw CI. Długie pliki reguł rozmywają te najważniejsze, więc dodawaj regułę dopiero wtedy, gdy uzasadnia ją rzeczywiście przeoczony błąd.

3. 3

   Zdecyduj, które uwagi blokują

   Część recenzentów domyślnie tylko doradza i to rozsądny punkt wyjścia. Jeśli jakiś rodzaj uwagi ma zatrzymać merge, na przykład brak sprawdzenia autoryzacji, egzekwuj to przez wymagany check, który sam kontrolujesz. Samo oznaczenie statusu recenzenta jako wymaganego nie wystarczy, bo GitHub traktuje wynik neutralny jak zaliczony, a check review w Claude Code i domyślne uwagi Bugbota zwracają właśnie wynik neutralny.

4. 4

   Ogranicz szum i fałszywe alarmy

   Ustal limit drobnych uwag na jedno review i wyłącz nowe drobiazgi przy ponownym review, żeby jednolinijkowa poprawka nie otwierała kolejnej rundy. Przez pierwszy miesiąc co tydzień bierz próbkę uwag i oznaczaj każdą jako przydatną, błędną albo szum, potem poprawiaj reguły i zachowaj oznaczenia jako punkt odniesienia. Reguły, których narzędzia uczą się z odpowiedzi twojego zespołu, potrzebują właściciela, który je przycina.

# Review rules: payments-service

## Treat as blocking
- Endpoint added or changed without an authorisation check
- Query not scoped to the caller's tenant
- Migration that cannot be rolled back
- Test changed to match new behaviour without a stated reason

## Do not report
- Formatting, lint and type errors (CI enforces them)
- Generated code under src/gen/ and lockfiles
- More than five minor findings per review

Copilot code review czyta instrukcje z brancha head pull requesta, więc zmiana od agenta może edytować reguły własnego review, natomiast Bugbot czyta swój plik konfiguracyjny z brancha bazowego. Obejmij pliki z regułami review wpisami w CODEOWNERS i traktuj zmiany w nich jak zmiany w CI.

Review wewnątrz workflow agentów

Najtańsza jest uwaga zgłoszona, zanim pull request powstanie. Workflow agenta może mieć krok review, w którym drugi agent ze świeżym kontekstem albo inny model sprawdza diff względem zadania, bez założeń, które wnosi agent piszący kod. Lokalne polecenie /code-review w Claude Code działa na przykład jako subagent w tle z własnym oknem kontekstu.

Plugin pstack do Cursora zawiera skill interrogate, który wysyła ten sam diff i te same kryteria oceny do osobnego recenzenta tylko do odczytu dla każdego skonfigurowanego modelu i porządkuje uwagi bez zmieniania kodu, a za najsilniejszy sygnał uznaje zgodność modeli. Jego playbook shipping merge'uje pull request tylko na podstawie werdyktu agenta, który nie pisał tego kodu, i wprost stwierdza, że zielone CI i zatwierdzające review bota nie są werdyktem.

Runmill, projekt open source naszego założyciela, stosuje tę samą zasadę w pipeline. Dokładnie ten commit, który jest kandydatem, musi przejść wymagane checki i review w świeżym kontekście, zanim na GitHubie zostanie otwarty pull request, a o pushach, pull requestach i merge'ach decyduje deterministyczny kod, nigdy agent. Runmill jest w fazie developer preview, a automatyczny merge jest eksperymentalny.

Nic z tego nie zastępuje review przez człowieka na końcu. Skille, playbooki i prompty do review instruują agenta, ale niczego nie egzekwują. Robią to ochrona branchy, wymagane checki i uprawnienia agenta.

Przewodnik po workflow pstack w CursorzeWdrożenie pluginu pstack do CursoraKod źródłowy Runmill na GitHubie

Standardy akceptacji pull requestów od agentów

Recenzenci pracują szybciej, gdy wiedzą, co musi zawierać pull request od agenta. Spisz ten standard, odsyłaj pull requesty, które go nie spełniają, zanim ktokolwiek przeczyta kod, i umieść ten sam standard w instrukcjach dla swoich agentów.

• Jedno zadanie na pull request, na tyle małe, żeby przejrzeć je za jednym podejściem, ze zmianami mechanicznymi oddzielonymi od zmian zachowania
• Link do issue, specyfikacji lub promptu, na podstawie którego pracował agent
• Testy nowego zachowania i uzasadnienie każdego zmienionego lub usuniętego testu
• Opis tego, co się zmieniło, co pominięto, czego agent nie był pewien i jak to zweryfikowano
• Żadnych niezwiązanych plików ani nowych zależności, jeśli zadanie ich nie wymagało
• Agent i model, które wytworzyły zmianę

Ustal, co recenzent może zakładać: że CI zbudowało i przetestowało dokładnie ten commit, który przegląda, oraz że uwagi AI zostały poprawione albo odrzucone z uzasadnieniem. Nie powinien zakładać, że podsumowanie agenta jest prawdziwe, że testy pokrywają zmianę ani że recenzent AI sprawdził intencję i wpływ na inne serwisy.

Przewodnik po spec-driven development

Konkretna osoba odpowiada za każdy merge

Komentarz modelu w review to wskazówka. Zatwierdzenie to decyzja, za którą ktoś odpowiada, a przy kodzie od agentów taka osoba musi istnieć. Domyślnie review Copilota nie liczą się do wymaganych zatwierdzeń, a Code Review w Claude Code ani nie zatwierdza, ani nie blokuje. OpenAI w dokumentacji Codex zaznacza, że reguły review nie zastępują testów, ochrony branchy ani wymaganych zatwierdzeń.

Niektóre narzędzia potrafią już zatwierdzać. Copilot approvals, obecnie w public preview, po włączeniu w ustawieniach repozytorium, organizacji i enterprise pozwalają Copilotowi wystawić zatwierdzające review, które spełnia regułę wymaganych zatwierdzeń. Opcjonalny workflow request changes w CodeRabbit zatwierdza pull request, gdy spełnione są jego własne warunki. Zdecyduj wprost, czy jakiekolwiek automatyczne zatwierdzenie może liczyć się do twoich reguł merge'a, a jeśli tak, dopuść je tylko na ścieżkach niskiego ryzyka.

Traktuj inżyniera, który zlecił zadanie, jak autora zmiany i niech zatwierdza ją ktoś inny. GitHub wbudował to we własnego agenta: osoba, która poprosiła Copilot cloud agent o utworzenie pull requesta, nie może go zatwierdzić. Przy innych agentach sprawdź, czy osoba, która uruchomiła agenta, może zatwierdzić wynik jego pracy, a jeśli tak, zamknij tę lukę regułą zespołu albo wymaganym checkiem.

Ustawienia ochrony branchy, które to egzekwują

• Wymagaj pull requesta z co najmniej jednym zatwierdzającym review przed merge'em
• Wymagaj review od code ownerów i wpisz w CODEOWNERS osoby lub zespoły odpowiedzialne za konfigurację agentów i reguły review
• Unieważniaj nieaktualne zatwierdzenia, gdy nowe commity zmieniają diff
• Wymagaj zatwierdzenia ostatniego pusha przez kogoś innego niż osoba, która go wypchnęła
• Wymagaj zaliczenia checków buildu i testów przed merge'em

Przewodnik po bezpieczeństwie agentów kodujących

Pomiar obciążenia review bez oceniania ludzi

Jeśli agenci dokładają pull requesty szybciej, niż rośnie przepustowość review, wydłuża się kolejka albo review staje się płytsze. Które z tych dwóch zjawisk zachodzi, pokażą tylko dane. Mierz system review według zespołu, repozytorium, typu zadania i narzędzia, w porównaniu z punktem odniesienia sprzed wprowadzenia agentów albo nowego recenzenta.

• Czas do pierwszego review przez człowieka od oznaczenia pull requesta jako gotowego
• Czas review przez człowieka na zmianę, w odniesieniu do rozmiaru diffu
• Liczba komentarzy i rund review na zmianę
• Odsetek uwag AI, na które zareagowano, czyli oznaczony kod zmieniono albo wątek zamknięto poprawką
• Poprawki i reverty zmergowanych zmian w uzgodnionym oknie czasowym
• Błędy, które prześlizgnęły się dalej, przypisane do zmergowanych zmian, z podziałem na pracę agentów i ludzi

Odsetek uwag, na które zareagowano, to najbardziej bezpośrednia miara szumu. Licz go z historii pull requestów, bo reakcje pod komentarzami review zależą od tego, czy ktoś pamięta, żeby je kliknąć. Oznaczaj pull requesty od agentów konsekwentnie, żeby każdą metrykę dało się rozbić według tego, kto lub co napisał zmianę.

Nie wykorzystuj tych liczb do oceny pracy pojedynczych osób. Gdy metryka zaczyna oceniać inżynierów, zachowanie się do niej dopasowuje: zmiany są dzielone, żeby wyglądały na szybkie, a zatwierdzenia przychodzą przed lekturą. Raportuj według zespołu, typu zadania i narzędzia.

Najważniejsze narzędzia AI do code review

Poniższe opisy opierają się na dokumentacji dostawców według stanu na październik 2026 i nie tworzą rankingu. Przed decyzją sprawdź aktualną dokumentację.

Samodzielne produkty do review

CodeRabbit przegląda pull requesty, a konfiguruje się go plikiem .coderabbit.yaml albo w interfejsie webowym. Domyślnie traktuje popularne pliki instrukcji dla agentów, takie jak AGENTS.md i CLAUDE.md, jako kryteria review, a opcjonalny workflow request changes może żądać zmian i zatwierdzać pull requesty, gdy spełnione są jego warunki.

Qodo prowadzi w pull requestach review z udziałem wielu agentów, w którym agent sędzia łączy uwagi, usuwa duplikaty i odfiltrowuje te o niskiej pewności. Standardy review buduje na podstawie twojego kodu, historii pull requestów i wymagań, a jego Rule Miner zamienia powtarzające się wzorce z wcześniejszych pull requestów w egzekwowane reguły.

Review w platformach agentów kodujących

GitHub Copilot code review przegląda pull requesty na GitHubie na żądanie albo automatycznie i może analizować kontekst całego repozytorium. Czyta instrukcje dla repozytorium, pliki instrukcji dla konkretnych ścieżek i AGENTS.md, a funkcja zatwierdzania jest w public preview.

Bugbot to recenzent pull requestów od Cursora dla GitHuba, GitLaba, Bitbucketa i Azure DevOps. Jego reguły trzyma się w plikach .cursor/BUGBOT.md, a ogólne reguły projektu w Cursorze go nie dotyczą. Opcjonalny Autofix uruchamia agenta Cursora w chmurze, który naprawia znalezione błędy.

Claude Code oferuje zarządzane Code Review dla GitHuba, w fazie research preview dla subskrypcji Team i Enterprise. Kilku agentów analizuje diff równolegle, krok weryfikacji odsiewa fałszywe alarmy, a plik REVIEW.md steruje tym, co jest zgłaszane. Zespoły mogą też uruchamiać Claude we własnych pipeline'ach w GitHub Actions lub GitLab CI/CD.

Codex code review od OpenAI publikuje standardowe review na GitHubie, gdy ktoś skomentuje pull request poleceniem @codex review, albo automatycznie po włączeniu tej opcji. Na GitHubie zgłasza tylko problemy o priorytecie P0 i P1 i stosuje reguły review z plików AGENTS.md do plików, których dotyczą.

Przy wyborze porównaj, dokąd i na jakich warunkach trafia kod, jakie pliki instrukcji czyta narzędzie i jak jego zatwierdzenia i checki pasują do twoich reguł merge'a. Potem przetestuj kandydatów na własnych zmergowanych zmianach.

Jak pomaga Cloudsail

Oceniamy konfiguracje review na twoich własnych zmergowanych zmianach. Przepuszczamy wcześniejsze pull requesty, także te, które później wymagały poprawki lub reverta, przez rozważanych recenzentów i konfiguracje, a potem porównujemy ich uwagi z tym, co faktycznie poszło nie tak. Widzisz, które błędy wyłapałaby każda konfiguracja oraz ile szumu i kosztów dodaje w przeliczeniu na przejrzaną zmianę.

Reguły review piszemy razem z twoimi inżynierami, wraz z instrukcjami dla repozytoriów, wpisami w CODEOWNERS i ochroną branchy, od których zależą, a każdy z tych elementów ma właściciela. Wdrażamy też pomiar obciążenia review na poziomie zespołu i narzędzia.

Szkolenia dla recenzentów prowadzimy jako sesje zespołowe na twoich repozytoriach, zdalnie albo na miejscu w Niemczech i w Polsce, po angielsku, niemiecku lub polsku. Skupiamy się na czytaniu pull requestów od agentów: sprawdzaniu intencji względem zadania, rozpoznawaniu powtarzających się wzorców i decydowaniu, kiedy odesłać zmianę. Nie prowadzimy kursów otwartych ani nie wydajemy certyfikatów.

Ewaluacje na twoich repozytoriachHarness engineeringWdrożenie GitHub Copilot