Agentowe code review: co agent AI łapie, a co zostaje przy recenzencie

Agentowe code review to praktyka, w której agent AI (na przykład w Claude Code) wykonuje pierwszą warstwę przeglądu pull requesta, zanim spojrzy na niego człowiek. Nie zastępuje recenzenta. Przejmuje powtarzalną część: styl, oczywiste błędy, brakujące testy i odstępstwa od konwencji repozytorium. Decyzje architektoniczne, poprawność w kontekście domeny i kod krytyczny dla bezpieczeństwa zostają przy ludziach. To umiejętność, którą zespół wbudowuje w swój sposób pracy, a nie gotowe narzędzie, które „samo zrobi review”.

Co agent AI realnie łapie w pull requeście

Najwięcej wartości daje tam, gdzie reguła jest jasna, a ręczne sprawdzenie nużące. W praktyce agent dobrze radzi sobie z:

• literówkami i niespójnym nazewnictwem zmiennych oraz funkcji,
• martwym kodem i nieużywanymi importami,
• brakującą albo płytką obsługą błędów i przypadków brzegowych,
• brakującymi lub powierzchownymi testami do nowej logiki,
• naruszeniami konwencji przyjętych w repozytorium, jeśli agent ma dostęp do jego kontekstu,
• oczywistymi podatnościami, jak sekret wpisany w kod albo brak walidacji danych wejściowych.

To jest właśnie ta część przeglądu, na którą senior developer nie powinien tracić uwagi. Jest jedno zastrzeżenie: agent potrafi zgłosić błędną uwagę z pełnym przekonaniem, więc jego wynik traktujemy jak wejście do przeglądu, a nie jak werdykt.

Co zostaje po stronie recenzenta

Wszystko, co wymaga decyzji, a nie sprawdzenia reguły. Człowiek zostaje przy architekturze i granicach modułów, projekcie API, poprawności w kontekście procesu biznesowego, kompromisach między wydajnością a czytelnością oraz przy logice krytycznej dla pieniędzy i bezpieczeństwa. Recenzent odpowiada też za pytanie, którego agent nie zada: czy ta zmiana w ogóle powinna powstać w tym kształcie. Merge zatwierdza człowiek i to człowiek bierze za niego odpowiedzialność.

Czym to się różni od lintera i analizy statycznej

Linter i analiza statyczna sprawdzają reguły deterministyczne: formatowanie, nieużyte zmienne, znane wzorce błędów. Są szybkie, powtarzalne i niczego nie zmyślają, ale nie rozumieją kontekstu. Agent AI wchodzi warstwę wyżej. Potrafi zauważyć, że test sprawdza tylko ścieżkę optymistyczną i pomija przypadek brzegowy, że nazwa funkcji obiecuje co innego niż jej treść albo że zmiana łamie konwencję widoczną dopiero w kilku plikach. Ceną tej elastyczności jest zawodność: tam, gdzie linter albo się odzywa, albo nie, agent czasem myli się z przekonaniem. Dlatego rozsądny zespół zostawia lintery i analizę statyczną jako twardą bramkę, a agenta traktuje jako dodatkową parę oczu przed człowiekiem, a nie zamiast tych narzędzi.

Jak to wygląda w praktyce pull requesta

W typowym układzie agent uruchamia się przy otwarciu pull requesta i zostawia uwagi jako komentarze: część oznaczonych do poprawki, część tylko do rozważenia. Autor zmiany triage'uje je najpierw, poprawia oczywiste rzeczy i odrzuca fałszywe alarmy, zanim zawoła recenzenta. Człowiek dostaje pull request już uporządkowany i skupia uwagę na tym, czego agent nie rozstrzyga. Kluczowa zasada jest jedna: uwaga agenta nie blokuje merge sama z siebie. Bramką zostają testy, lintery i zatwierdzenie człowieka, a agent tylko skraca drogę do tego zatwierdzenia. Taki układ daje też efekt uboczny, który zwykle bardziej się opłaca niż samo przyspieszenie review: juniorzy dostają szybką, spokojną informację zwrotną o powtarzalnych błędach, zanim trafią z nimi do seniora.

Gdzie są granice agentowego review

Agent ocenia wzorzec, nie intencję. Na typowym kodzie sprawdza się dobrze, na nowym albo nietypowym myli się częściej, a mimo to potrafi brzmieć równie pewnie. Bez ugruntowania w zasadach danego repozytorium narzuca konwencje z innych projektów, których u Was nie chcecie. I nie bierze odpowiedzialności za skutek. Dlatego działa jako pierwsza warstwa, która porządkuje pull request przed człowiekiem, a nie jako instancja, która go zamyka. Zdanie „nasze review jest w pełni automatyczne” jest sygnałem ostrzegawczym, nie zaletą.

Praktyczny przykład: agent potrafi zażądać testu do funkcji, która celowo nie ma logiki wartej testowania, albo zgłosić brak obsługi błędu tam, gdzie błąd jest obsługiwany warstwę wyżej. To nie są katastrofy, ale dobrze pokazują, dlaczego autor zmiany musi mieć prawo odrzucić uwagę bez tłumaczenia się przed maszyną, a recenzent nie może zdejmować z siebie odpowiedzialności zdaniem „przecież agent to sprawdził”.

Jak wprowadzić agentowe review jako praktykę zespołu

To jest umiejętność, a nie zakup. Agent musi pracować na Waszym repozytorium, z Waszymi konwencjami, w Waszym procesie pull requestów. Rozsądny start to ustalenie, co agent może komentować z automatu, a co tylko sygnalizować, ugruntowanie go w spisanych zasadach zespołu i pozostawienie merge człowiekowi. Właśnie tej pracy agentowej na własnym kodzie uczymy na Kursie AI-Native. Jeśli chcecie zacząć od samego narzędzia, pomaga szkolenie Claude Code dla zespołów, a szerszy kontekst pracy z agentami opisuje tekst o vibe codingu po polsku.

Kiedy nie warto tego wdrażać

Agentowe review nie ma sensu, jeśli nie macie spisanych konwencji: agent nie ma się wtedy czym kierować i produkuje szum. Odpuść też, gdy zespół potraktowałby jego uwagi jak wyrocznię zamiast jak wejście do przeglądu, bo to obniża jakość zamiast ją podnosić. Przy jednym małym repozytorium z lekkim ruchem pull requestów ręczny przegląd zwykle wystarcza. Najpierw uporządkuj zasady i dostawcę modelu z umową powierzenia danych, potem dokładaj agenta.

FAQ

Czy agent AI zastąpi senior developera w code review?

Nie. Przejmuje powtarzalną warstwę przeglądu i oddaje seniorowi czas na decyzje, których agent nie podejmuje: architekturę, projekt API i logikę krytyczną.

Czy agentowe review jest bezpieczne dla naszego kodu?

Zależy od dostawcy i ustawień. Bezpieczna odpowiedź dla firmy to plan biznesowy z umową powierzenia danych oraz jasne granice dostępu agenta do repozytorium.

Od czego zacząć?

Od jednej warstwy mechanicznej: styl, testy i typowe błędy. Dopiero po kilku tygodniach rozszerzaj zakres o kontrolę konwencji.

Czym to się różni od gotowego narzędzia SaaS do review?

Praktyka agentowa jest ugruntowana w Waszych zasadach i procesie, a nie w cudzej domyślnej konfiguracji. Uczy się jej zespół, a odpowiedzialność za merge zostaje po Waszej stronie.

Jak mierzyć, czy agentowe review pomaga?

Patrz, ile uwag agenta autorzy realnie przyjmują, a ile odrzucają jako fałszywe alarmy, i czy recenzenci zgłaszają mniej powtarzalnych błędów. Niski odsetek trafnych uwag to sygnał, żeby zawęzić zakres i lepiej ugruntować agenta w Waszych zasadach.

Jak zacząć

Zanim wprowadzisz agentowe review, odpowiedz na kilka pytań:

1. Czy macie spisane konwencje, którymi agent ma się kierować?
2. Które warstwy przeglądu są dziś najbardziej powtarzalne i nużące?
3. Kto zatwierdza merge i bierze za niego odpowiedzialność?
4. Na jakim planie i z jaką umową powierzenia danych pracuje model?

Jeśli chcecie nauczyć zespół pracy agentowej na własnym repozytorium, porozmawiajmy o Kursie AI-Native. Jeżeli wolisz najpierw uporządkować jeden proces poza kodem, umów bezpłatny skan procesów.

Sprawdź też: Szkolenie Claude Code dla zespołów | Vibe coding po polsku | Kursy i szkolenia z agentów AI w Polsce