Code review kodu napisanego przez AI: na co patrzeć w diffie agenta

Agent AI skończył zadanie, testy świecą się na zielono, kod wygląda porządnie. Kliknięcie „zatwierdź” kusi, bo wszystko jest spójne i dobrze sformatowane. I właśnie to jest problem: kod z AI jest zwykle czytelny, więc nie ma w nim sygnałów, które u człowieka zwykle zdradzają niepewność. W artykule o tym, czym jest code review, opisuję sam proces przeglądu i rolę AI jako pomocnika recenzenta. Tu odwracam sytuację: ty recenzujesz to, co napisał agent. Jeśli chcesz zrozumieć, jak agenci działają od środka, łącznie z zatwierdzaniem ich pracy przez człowieka i oceną jakości wyników, w ścieżce AI Engineer budujesz takiego agenta samodzielnie w Pythonie.

Czym review kodu od AI różni się od zwykłego przeglądu?

Zasady przeglądu zostają te same: czytasz zmiany, pytasz o intencję, sprawdzasz testy i komentujesz konkretnie. Zmienia się to, gdzie szukasz błędów i jak bardzo ufasz sygnałom pozornie dobrym:

W praktyce znaczy to jedno: mniej ufasz formie, więcej sprawdzasz zachowanie.

Dlaczego pull requesty od agentów są odrzucane?

Pierwsze badania opisują, jak wygląda to w praktyce w projektach open source na GitHubie. Trzy prace oparte na zbiorze pull requestów agentów AI (AIDev):

Dwa wnioski przydatne recenzentowi: mały i skupiony diff ma większą szansę na przyjęcie, a odrzucany PR często dostaje decyzję bez żadnego komentarza. To drugie jest złym nawykiem, bo autor (a często i agent) nie ma jak się nauczyć, co poprawić.

Zastrzeżenie: to projekty open source, a nie typowa praca w firmie, a przy wielu odrzuceniach nikt nie napisał, dlaczego, więc podane powody są niepełne. Traktuj to jako wskazówkę, nie prawo.

Od czego zacząć review diffa agenta?

Zanim przeczytasz pierwszą linijkę kodu, odpowiedz na dwa pytania:

1. Czy to jest to, o co poproszono? Porównaj diff z opisem zadania (zgłoszeniem, specyfikacją, kryteriami akceptacji). Jeśli zadanie było zapisane w specyfikacji dla agenta, masz gotową listę do odhaczenia.
2. Jak duży jest diff? Sprawdź git diff --stat. Gdy agent dotknął dwudziestu plików przy zadaniu na jedną funkcję, to sygnał, że część zmian jest poza zakresem albo że zadanie było za duże.

git diff --stat main
git diff main -- . ':!package-lock.json'

Jeśli diff jest za duży, żeby go realnie przeczytać, nie zatwierdzaj go na wiarę (rubber stamp). Wróć do agenta i poproś o podział na mniejsze kroki. Mała zmiana, którą naprawdę rozumiesz, jest lepsza niż duża, którą tylko przejrzałeś. Więcej o pracy małymi krokami piszę w artykule o narzędziach AI dla programistów.

Jak wygląda PR od agenta z zielonymi testami i trzema błędami?

Zobaczysz to na małym przykładzie. Zadanie dla agenta brzmiało: „Dodaj kody rabatowe w procentach do koszyka. Nieznany kod ma zgłaszać błąd.” Poniżej kod po jego pracy (diff pokazuję w całości, uruchomiłem go lokalnie na Pythonie 3.13 i pytest 9.2.0):

# cart.py
DISCOUNTS = {"SAVE10": 10, "SAVE20": 0.2}


def total(prices):
    return round(sum(prices), 2)


def vat(amount):
    return int(amount * 0.23 * 100) / 100


def apply_discount(amount, code):
    try:
        percent = DISCOUNTS[code]
        return round(amount * (1 - percent / 100), 2)
    except Exception:
        return amount

# test_cart.py
from cart import DISCOUNTS, apply_discount, total, vat


def test_total():
    assert total([10.0, 5.5]) == 15.5


def test_vat():
    assert vat(100) == 23.0


def test_apply_discount():
    for code, percent in DISCOUNTS.items():
        assert apply_discount(100, code) == round(100 * (1 - percent / 100), 2)


def test_unknown_code():
    assert apply_discount(100, "NOPE") == 100

Wynik uruchomienia: 4 passed. CI jest zielone. Czy można zatwierdzić? Nie. W tym diffie są trzy błędy, a żaden nie wyświetla się jako czerwony test.

Jak wyłapać testy, które nic nie sprawdzają?

Spójrz na test_apply_discount. Oczekiwana wartość jest liczona tym samym wzorem i z tych samych danych co implementacja:

assert apply_discount(100, code) == round(100 * (1 - percent / 100), 2)

Taki test przejdzie zawsze, nawet gdy dane są złe. A są: kod SAVE20 ma w słowniku 0.2 zamiast 20, więc zamiast rabatu 20% klient dostaje rabat 0,2%:

>>> apply_discount(100, "SAVE20")
99.8

Test powinien znać oczekiwany wynik z zewnątrz, z wymagań, nie z implementacji. Zasada: jeśli test da się przeczytać jako przepisanie kodu, nie testuje niczego. O pisaniu testów, które opisują zachowanie, piszę w artykule o TDD i BDD w pytest.

Szybka metoda dla recenzenta: zepsuj kod i zobacz, czy test to zauważy. Zmień 0.2 na 20 i na odwrót. Jeśli żaden test nie zmienia koloru, test nic nie chroni.

Dlaczego except Exception w kodzie od agenta to czerwona flaga?

Zadanie mówiło, że nieznany kod ma zgłaszać błąd. Agent zrobił odwrotnie: złapał każdy wyjątek i po cichu zwrócił niezmienioną kwotę:

    except Exception:
        return amount

Użytkownik wpisze save10 z literówką, nic się nie stanie, nikt nie dostanie komunikatu, a rabat po prostu nie zadziała. I jeszcze jedno: agent dopisał test test_unknown_code, który utrwala to błędne zachowanie (assert apply_discount(100, "NOPE") == 100). Test zielony, wymaganie złamane.

Zwracaj uwagę na każdy except bez konkretnego typu wyjątku i na wartości „domyślne” zwracane po błędzie. To klasyczny sposób na „kod, który działa, dopóki nikt nie spojrzy”.

Jak rozpoznać zmiany poza zakresem?

W tym samym diffie jest zmiana, o którą nikt nie prosił:

-    return round(amount * 0.23, 2)
+    return int(amount * 0.23 * 100) / 100

Agent „przy okazji” zmienił zaokrąglanie VAT na obcinanie. Istniejący test vat(100) == 23.0 dalej przechodzi, ale dla innych kwot wynik jest inny:

>>> vat(10.99)
2.52   # przed zmianą było 2.53

W sklepie internetowym to różnice w fakturach. To jest rozrost zakresu (scope creep), a wykrywasz go tylko wtedy, gdy czytasz cały diff, nie tylko nowe funkcje. Pytanie kontrolne: „po co ta linijka jest w tym PR?”. Jeśli nie umiesz odpowiedzieć, poproś o wycofanie albo osobny PR.

Jak sprawdzić, czy naprawa naprawdę działa?

Napisz testy jako recenzent, z wartościami wziętymi z wymagań, nie z kodu:

import pytest

from cart import apply_discount, vat


def test_apply_discount_values():
    assert apply_discount(100, "SAVE10") == 90.0
    assert apply_discount(100, "SAVE20") == 80.0


def test_unknown_code_raises():
    with pytest.raises(ValueError):
        apply_discount(100, "NOPE")


def test_vat_rounds_half_up():
    assert vat(10.99) == 2.53

Na kodzie agenta wszystkie trzy testy padają (3 failed): wynik 99,8 zamiast 80, brak wyjątku i VAT 2,52 zamiast 2,53. Po poprawkach przechodzą:

DISCOUNTS = {"SAVE10": 10, "SAVE20": 20}


def vat(amount):
    return round(amount * 0.23, 2)


def apply_discount(amount, code):
    if code not in DISCOUNTS:
        raise ValueError(f"Nieznany kod rabatowy: {code}")
    return round(amount * (1 - DISCOUNTS[code] / 100), 2)

Zauważ, że wszystkie trzy błędy znalazły trzy proste testy z wartościami z głowy, a nie lektura implementacji.

Co jeszcze sprawdzić po zakresie i testach?

Gdy zakres i testy się zgadzają, zostają błędy, które mają własne artykuły:

• Nieistniejące biblioteki i metody, nowe zależności: sprawdź każdy nowy import i wpis w requirements.txt albo package.json. Jak to robić, opisuję w artykule o halucynacjach AI w kodzie.
• Luki bezpieczeństwa: dane od użytkownika, sekrety, brak autoryzacji. Przeglądaj je według listy z artykułu o bezpieczeństwie kodu generowanego przez AI.
• Zgodność z konwencjami projektu: jeśli agent ignoruje zasady, które znasz, być może nie dostał ich w pliku z instrukcjami.
• Duplikaty: czy ta funkcja już gdzieś istnieje? Zdarza się, że agent pisze coś od nowa zamiast użyć istniejącego kodu.

Jak napisać komentarz do PR od agenta?

Badania pokazują, że część odrzuconych pull requestów nie dostaje żadnego komentarza. Napisz komentarz, który da się wykonać:

• Wskaż plik, linię i problem, nie ogólne „kod jest zły”.
• Podaj oczekiwane zachowanie albo przykład, który je pokazuje (np. test, który pada).
• Rozdziel blokujące uwagi od sugestii.
• Jeśli prosisz agenta o poprawkę, daj mu ograniczenie: „zmień tylko apply_discount, nie dotykaj vat”.

Dobry komentarz do przykładu wyżej: „test_apply_discount liczy oczekiwaną wartość tym samym wzorem co kod i nie złapie błędnych danych. Dodaj test z wartościami wprost: SAVE20 na 100 zł ma dać 80,00.”

Jak recenzować pull request od kolegi, który użył AI?

To inna sytuacja niż własny agent: autor mógł wkleić kod, którego sam nie rozumie. Wrażenie „AI slop” bierze się zwykle z tego, że autor nie przeczytał własnego diffa. Nie rozwiązuje się tego wykrywaniem, czy kod pochodzi z AI, tylko jasnym oczekiwaniem co do autora:

• Autor odpowiada za PR tak samo, niezależnie od tego, kto napisał kod.
• Autor mówi w opisie, co sprawdził sam.
• Zespół ma limit rozmiaru PR i go pilnuje.

Jak pracować z pull requestami w zespole, opisuję w artykule o git, branchach i pull requestach.

Jaki szablon opisu PR pomaga recenzentowi?

Proponuję szablon opisu pull requestu dla autora, który korzystał z AI. Nie jest to dana od nas ani wynik badań, tylko praktyczna propozycja do dopasowania:

## Co zmieniłem i dlaczego
(jedno–dwa zdania: cel zadania, nie przepisanie diffa)

## Co zlecono agentowi, a co zrobiłem sam
- Zlecono: ...
- Napisane ręcznie / zmienione przeze mnie: ...

## Co sprawdziłem
- [ ] Przeczytałem cały diff
- [ ] Uruchomiłem testy i sprawdziłem ręcznie: ...
- [ ] Nowe zależności zweryfikowane: ...
- [ ] Zmiany poza zakresem zadania: brak / lista

## Czego nie jestem pewien
(miejsca, w których potrzebuję drugiej pary oczu)

Ostatnia sekcja jest najważniejsza: autor, który przyzna, czego nie rozumie, zwalnia recenzenta z odgadywania, gdzie szukać problemów.

Podsumowanie: jak robić code review kodu napisanego przez AI

• Zacznij od zakresu i rozmiaru diffa: czy to jest to, o co poproszono i czy da się to realnie przeczytać.
• Zielone testy to nie dowód. Sprawdź, czy testy mają oczekiwane wartości z wymagań, a nie z implementacji.
• Szukaj połkniętych wyjątków i „domyślnych” wartości po błędzie.
• Czytaj cały diff, bo zmiany poza zakresem ukrywają się w plikach, których nie prosiłeś ruszać.
• Pisz konkretne komentarze; odrzucony PR bez komentarza niczego nie uczy.
• Wymagaj od autora opisu, co sprawdził, a czego nie jest pewien.

Jeśli dopiero uczysz się, jak recenzować kod, zacznij od artykułu o code review. Gdy chcesz zrozumieć, jak zadać agentowi zadanie tak, żeby diff był mały i zgodny z zakresem, zajrzyj do artykułu o spec-driven development.