Jak robić dobre code review? Także gdy kod pisze AI

Code review to jeden z ważniejszych etapów wytwarzania oprogramowania, a zauważyłem, że temat jest traktowany trochę po macoszemu. Jak robić dobre code review? Postaram się na to pytanie odpowiedzieć jak najlepiej, a przynajmniej dać wskazówki. Wpis powstał w 2021 roku; w październiku 2026 dopisałem do niego osobną sekcję o tym, jak sprawdzać kod napisany przez AI.

Czym jest code review?

Przede wszystkim jest to dyskusja. Dyskusja pomiędzy autorem a innymi programistami. Nikt nie powinien bać się tutaj wyrazić swojej opinii czy zadać pytania. Efektem końcowym code review powinien być kod, który nie jest podatny na błędy. Zaś osoby biorące udział w tym procesie powinny wyjść bogatsze w wiedzę. Czasami code review to sztuka podejmowania trudnych kompromisów, a czasem marnowanie czasu na „filozofowanie”.

To, jak sprawnie tworzone jest oprogramowanie, zależy od wielu czynników. Między innymi jest to zgranie zespołu (czy nie ma konfliktów) czy to, jak dobrze „wyceniane” są zadania. Zgrany zespół pozwala na swobodną wymianę opinii. Łatwiej wtedy jest powiedzieć, że kod jest do dupy. Nikt nie będzie miał o to pretensji, a może to zmobilizować do napisania lepszego, czytelniejszego kodu.

Większość pewnie zgodzi się ze stwierdzeniem, że kod można podzielić na trzy kategorie:

1. Działa, ale jest ciężki w utrzymaniu. Oznacza to, że każda większa zmiana w kodzie może wpływać negatywnie na istniejącą funkcjonalność.
2. Działa i dobrze się go czyta. Jest to idealna sytuacja, którą chciałaby mieć każda firma. Wymaga to jednak dużej dyscypliny w zespołach czy programistach.
3. Kombinacja dwóch powyższych punktów. Prawdopodobnie najczęstsza sytuacja w kodzie. Zdarzają się miejsca w kodzie, które można umieścić w pierwszym, jak i w drugim punkcie.

Także na etapie code review ustalane jest, w której z powyższych kategorii będzie znajdował się kod. U nas w zespole merge jest robiony, gdy kod jest zaakceptowany przez wszystkich.

Jak zatem robić dobre code review?

Na pewno nie ma tutaj złotego środka, który rozwiąże wszystkie problemy. Sprawę ułatwią firmowe standardy (guidelines) instruujące, jak pisać kod. W przypadku frontendu część rzeczy można zrobić takimi narzędziami jak prettier czy różnego rodzaju linterami. Na nasze nieszczęście tego typu dodatki odpowiadają za wizualną część kodu. Nie zastąpią ludzkiego pierwiastka. Do tego, czym dziś uzupełnia się ten „ludzki pierwiastek”, wrócę w sekcji o AI poniżej.

Co można zrobić oddając kod do code review?

1. Zastanów się czy kod dobrze się czyta, czy można coś napisać lepiej czy krócej. Czy w dobrym miejscu znajduje się plik i czy ma to jakieś uzasadnienie? A może coś da się wydzielić lub zrobić używalne?
2. Nie wrzucaj wszystkiego jako jeden, wielki commit. W miarę możliwości dziel kod na mniejsze porcje. Dużo łatwiej analizuje się mniejszą ilość zmian. Poza tym można prześledzić proces zmian.
3. Dodaj do swojego kodu komentarze opisujące dane rozwiązanie. Dzięki temu osoba po drugiej stronie będzie mogła zrozumieć twoje intencje i powód (kontekst) zmian. Może się okazać, że zaproponowane rozwiązanie jest optymalne w tym konkretnym przypadku.
4. W przypadku wprowadzania zmian w kodzie nie commituj ich jako cr fixes! To nic nie mówi. Opisuj faktyczne zmiany w kodzie. Idealnie sprawdzą się tutaj conventional commits (pro tip: w przypadku wprowadzania zmian po review będziesz chciał poprzedzić swój commit message przez refactor:).
5. Przeczytaj własny diff, zanim poprosisz o review, także wtedy, gdy kod napisał za ciebie agent AI. Wysyłasz go pod swoim nazwiskiem, więc to ty musisz wiedzieć, co w nim jest.

Staraj się nie dociągać kodu z innych branchy. Wprowadza to duży szum informacyjny. Merge kodu powinien być ostatnią czynnością, jaką robisz.

Co zrobić gdy jesteś proszony o code review?

1. W miarę możliwości zrób to szybko

Code review to tylko część całego procesu wytwarzania oprogramowania. Taki kod musi być jeszcze przetestowany przez QA. Im dłużej zwlekasz z wykonaniem tego zadania, tym bardziej blokujesz proces. Oczywiście jeżeli ilość kodu jest większa, wiadomo, że nie da się tego sprawdzić i „klepnąć” w pięć minut.

2. Czy kod dobrze wygląda?

Czy do funkcji czy też komponentu nie jest przekazywanych za dużo argumentów? Czy dany kawałek kodu robi to, co trzeba? Czy znajduje się w odpowiednim miejscu? A może jakiś warunek jest zbyt skomplikowany i należałoby coś uprościć? A może nazwy zmiennych lub funkcji nie są najlepiej dobrane? Wszystko to (i pewnie kilka innych rzeczy) wpływa na jakość i utrzymanie kodu.

3. Uruchom kod lokalnie

Bardzo dobrym nawykiem jest sprawdzenie, czy członek zespołu poprawnie zaimplementował funkcjonalność lub poprawił błąd. Czy wszystko działa jak należy, czy podstawowe przypadki są pokryte. U nas w firmie jest tak, że przed oddaniem kodu do testów inna osoba z zespołu (nie QA) musi sprawdzić, czy wszystko jest poprawnie zaimplementowane. Dzięki temu zmniejszamy szansę na pojawienie się błędu w późniejszym etapie.

4. Testy!

Dobrze sprawdzić, czy kod został pokryty testami (są od tego nawet automaty). Wiem, że z testami jest różnie i zależy to od wielu czynników. Warto zwrócić na to uwagę. Pokrycie kodu testami, nawet tego ciężkiego w utrzymaniu, pozwoli w części ograniczyć późniejsze problemy. Jeżeli są testy, to warto zwrócić uwagę, co w nich się znajduje i czy ma to sens. Czy snapshoty komponentów reactowych (czy też stylów css) są wystarczające?

5. Stwórz dedykowane spotkanie, by omówić kod lub problemy

W moim aktualnym zespole nad wyraz dobrze sprawdzają się meetingi na temat kodu. Każdy z nas pokazuje, co zrobił i dlaczego. Następnie każdy zadaje pytania, które przekształcają się w ciekawe dyskusje. Wcześniej pisaliśmy sobie dużo komentarzy, ale nie sprawdzały się one dobrze przy bardziej złożonych problemach. Takie spotkanie to dobry moment na live coding (czy też pair coding), w którym rozwiązujemy razem dany problem.

6. Bądź uprzejmy…

O tym chyba nie trzeba wspominać. Czasami spotykam się z sytuacjami, w których niektórzy lubią dodać uszczypliwe komentarze w kodzie dla zasady lub mają z kimś (np. w zespole) chłodniejsze relacje. Pamiętaj też, że jeżeli zobaczysz jakieś ciekawe rozwiązanie, nie bój się pochwalić.

Code review, gdy kod pisze AI

Wszystko powyżej zakładało, że kod napisał człowiek, który potrafi ten kod obronić. Dziś coraz częściej pierwszą wersję pisze agent, a PR-ów jest po prostu więcej. Pytanie „czytać kod od AI czy nie?” jest moim zdaniem źle postawione. Ciekawiej jest zapytać: kiedy go czytać i jak lepiej zrozumieć to, co powstaje.

Dobry punkt odniesienia opisał zespół Claude Code w artykule o tym, jak robią code review w Anthropic (jednym z autorów jest Addy Osmani). Według nich Claude pisze około 90% kodu Claude Code, a mimo to review nie zniknęło. Większość czytania przeniesiono na maszyny, a czas człowieka zarezerwowano tam, gdzie jest najbardziej potrzebny.

Zmienia się pytanie

Zamiast „czy człowiek przeczytał ten kod?” zespół pyta: co może pójść nie tak w tej zmianie i który check, automatyczny czy ludzki, jest tu właściwe? Review przestaje być samą kontrolą na końcu, a staje się procesem. To zgadza się z tym, co opisałem wyżej: dyskusja i zrozumienie są ważniejsze niż samo „klepnięcie” PR-a.

Review w warstwach

Każda warstwa łapie co innego i przepuszcza to, co złapie dopiero następna. W opisie Anthropica wygląda to mniej więcej tak:

1. Weryfikacja przed PR-em. Agent uruchamia testy, build i lintera, a drugi agent w świeżym kontekście przegląda diff. Agent ma pokazać wynik, a nie tylko zapewnić, że skończył.
2. Automatyczne review na każdym PR-ze. Wiele agentów szuka błędów równolegle, osobna grupa potwierdza znaleziska, a do autora trafiają tylko te sprawdzone i posortowane wg priorytetu.
3. Blokujące checki. Linter, typy, testy, build, a także przegląd bezpieczeństwa, który może zatrzymać merge.
4. Człowiek, zależnie od ryzyka. Dokumentacja czy zmiana za flagą mogą przejść bez zatwierdzenia, zwykła zmiana produktowa wymaga jednej osoby, a najbardziej ryzykowny kod dwóch. Poziom ustala się po zmianie, a nie po tym, kto ją napisał.
5. Merge queue, flagi i stopniowe wdrożenie. Nowe zachowania trafiają najpierw do wąskiej grupy, a flagę można wyłączyć bez nowego deployu.

Całość zamyka szybkie wycofanie zmian i przegląd po każdym incydencie: która warstwa powinna była to wyłapać? Wniosek jest prosty. Jeśli mniej czytasz kod, musisz bardziej zadbać o to, żeby błędy dało się szybko wykryć i cofnąć.

Uwaga na nieskończone rundy

Jest tu pułapka, o której przy review między ludźmi się nie myśli. Agent-autor i agent-reviewer mogą w nieskończoność generować kolejne rundy poprawek. Człowiek odrzuca drobny komentarz w kilka sekund, agent zrobi z niego kolejny commit i leci kolejna runda. Według artykułu jeden PR przeszedł ponad pięćdziesiąt rund w ciągu jednej nocy, zanim autor go zatrzymał.

Co pomaga:

• twardy limit rund (po trzech autor ma przemyśleć podejście, zamiast poprawiać),
• ponowne review tylko nowego diffu,
• grupowanie błędów tej samej klasy i nieskładanie tych samych uwag po raz kolejny.

Szum kosztuje więcej, niż mogłoby się wydawać, więc lepiej, żeby reviewer zgłaszał mniej uwag, ale prawdziwych.

Co zostaje nam – ludziom

Nawet gdy maszyny czytają większość kodu, człowiek nadal jest potrzebny w trzech miejscach:

• Decyzja, czy to w ogóle budować. Kierunek, smak i zakres. Agent chętnie zaimplementuje coś, co nie powinno powstać; zadanie „czy w ogóle powinniśmy to robić?” zostaje po stronie ludzi. Skoro kod powstaje szybko, zamknięcie PR-a to nie strata, tylko tańsza korekta kierunku.
• Ryzykowny kod. Płatności, automatyczne aktualizacje, workflow CI, wszystko, gdzie błąd może być bolesny lub kosztowny.
• Odpowiedzialność. W artykule padło zdanie, które warto zapamiętać: „A person is accountable for every change that ships, whoever typed it.”, czyli za każdą wdrożoną zmianę odpowiada człowiek, niezależnie od tego, kto ją stworzył.

Jak zrozumieć to, co zbudował agent

Review miało zawsze drugie zadanie: rozprzestrzeniać wiedzę o kodzie. Jeśli maszyny analizują większość, to pojawia się pytanie, jak ktoś w zespole ma się tego kodu nauczyć. Jednolinijkowa zmiana tekstu uczy prawie niczego, za to wyjaśnienie modułu, który zaraz będziesz zmieniać, uczy bardzo dużo.

Dlatego zespół Claude Code nie ma formalnego procesu, tylko nawyk: kto chce zrozumieć fragment kodu, prosi Claude’a o napisanie wyjaśnienia dokładnie tego fragmentu. Zajmuje to chwilę i odzwierciedla kod taki, jaki jest dzisiaj, a nie jaki był w dokumentacji sprzed pół roku. Część osób idzie krok dalej i prosi o mały graficzny artefakt, który pokazuje ten fragment kodu i uczy go w sposób, w jaki dana osoba lubi się uczyć. Niektóre zespoły idą jeszcze dalej i robią krótkie filmiki, których jedynym zadaniem jest wyjaśnienie danego zagadnienia.

W firmie, z którą współpracuję, AI tworzy kod. My zarządzamy całym procesem tworzenia. Od zbierania informacji i planowania po testowanie tego, co stworzył taki agent. Code review mamy częściowo automatyczne i też przeglądamy kod osobiście. Największym problemem code review robionego przez AI jest brak kontekstu. W efekcie część komentarzy jest bez sensu.

Największy nacisk kładziemy na osobiste code review w początkowej fazie projektu (czyste repo). Tutaj trzeba krótko trzymać agenta od pisania kodu. Pomimo wielu zasad często lubi komplikować proste rzeczy. Trzeba to poprawiać, kalibrować.

Co ze zrozumieniem kodu? Jeśli czegoś nie rozumiem, to proszę agenta o wyjaśnienie mi działania całego kodu, który stworzył. Z danymi, payloadami jakie idą itp. Ostatnio dla zespołu stworzyłem interaktywną prezentację pokazującą przepływ informacji w jednym projekcie. Czyli co dokładnie się dzieje na backendzie gdy user wprowadzi dane do systemu. Zrobiło to na wszystkich duże wrażenie.

Jak sprawdzać kod od AI w praktyce

1. Zacznij od opisu, nie od diffu. Co zmiana ma robić i po co? Jeśli autor (albo agent) nie umie tego napisać w trzech zdaniach, to znak, że zmiana jest za duża.
2. Trzymaj zmiany małe. Agent bez problemu wygeneruje tysiąc linii, ale żaden człowiek rzetelnie ich nie sprawdzi. Zasada o dzieleniu na mniejsze porcje działa tu jeszcze mocniej niż wcześniej.
3. Daj reviewerowi kontekst. Plik z konwencjami projektu i celami (u Anthropica to CLAUDE.md) oraz uwagi właścicieli konkretnych części kodu o tym, co jest w nich ważne (REVIEW.md). To ten sam kontekst, który autor przekazuje komentarzami, tyle że spisany raz.
4. Nie wierz w „skończone”, wymagaj dowodu. Uruchom testy, zbuduj projekt, odpal kod lokalnie, tak jak przy review kodu od człowieka.
5. Sprawdź, czy testy testują cokolwiek. Testy napisane przez ten sam agent, który napisał kod, potrafią potwierdzać błędne założenia. Zajrzyj, co faktycznie sprawdzają.
6. Czytaj dokładniej tam, gdzie ryzyko jest największe: uwierzytelnianie, płatności, migracje danych, uprawnienia.
7. Każdy incydent zamień w lekcję. Jeśli błąd przeszedł przez review, zapytaj, która warstwa powinna go złapać, i dopisz test albo regułę.

Warto też pamiętać o skali problemu. Raport CodeRabbit, który opisywałem w osobnym wpisie, pokazał średnio 10,83 problemu na PR przy kodzie od AI wobec 6,45 przy kodzie od ludzi. A w badaniu opisanym we wpisie o vibe codingu programiści uczący się nowego narzędzia z AI mieli gorsze wyniki w teście zrozumienia, zwłaszcza w debugowaniu. Wniosek jest ten sam: im więcej kodu powstaje bez nas, tym ważniejsze jest, żebyśmy go rozumieli.

Bonus – ciekawe publikacje na temat code review

Gdyby ktoś chciał jeszcze więcej poczytać o tym procesie, to poniżej znajduje się garść linków, które mogą was zainteresować.

• Jak zespół Claude Code robi code review – review kodu pisanego przez AI, warstwy weryfikacji i zrozumienie kodu (2026)
• 10 tips to guide you toward effective peer code review – m.in. o prędkości czytania kodu
• How to Make Good Code Reviews Better
• Code Review Best Practices
• Code Review – Best Practices, Guidelines & Process Insights
• Why code reviews matter (and actually save time!)