LLM-y zrewolucjonizowały pracę programistów w praktycznie każdym obszarze. Nie inaczej jest w przypadku code review. Powstały liczne narzędzia usprawniające czy automatyzujące ten proces, jednak zmienił się również sam sposób jego przeprowadzania.

Code review stało się trudniejsze i znacznie bardziej czasochłonne niż kiedykolwiek wcześniej. W tym artykule przedstawię Ci moje przemyślenia o tym, co AI zmieniło w procesie code review oraz co można zrobić, by proces ten przebiegał nieco efektywniej.

Pisanie kodu to nie bottleneck – code review to bottleneck

Łatwość tworzenia kodu, klikania Tab Tab Tab, pisania next czy innych form poganiania LLM-ów do pracy sprawia, że kod powstaje w ilościach hurtowych. Tworzenie kodu coraz mniej przypomina rzemiosło, a coraz bardziej linię produkcyjną. Drastyczny wzrost tempa produkcji AI slopu kodu jest widoczny, potwierdza sam GitHub.

Yup, platform activity is surging. There were 1 billion commits in 2025. Now, it’s 275 million per week, on pace for 14 billion this year if growth remains linear (spoiler: it won’t.)

GitHub Actions has grown from 500M minutes/week in 2023 to 1B minutes/week in 2025, and now… https://t.co/iGsM2j1efO

— Kyle Daigle (@kdaigle) April 3, 2026

Przed spopularyzowaniem LLM-ów dni, gdy przekraczałem 1500 linii napisanego kodu, należały raczej do rzadkości. Obecnie Claude Code potrafi takie zmiany napisać, gdy mam przerwę na obiad. Problemem nie jest samo tempo powstawania kodu, lecz to, że ktoś musi go sprawdzić. Pisanie kodu przestało być głównym ograniczeniem. Coraz częściej bottleneckiem jest code review.

W kontekście rozmiaru pull requestów dość powszechną obserwacją jest, że czas review i liczba pozostawionych komentarzy maleją wprost proporcjonalnie do rozmiaru pull requesta.

Review kodu jest trudne. Dobre review kodu jest jeszcze trudniejsze. Dobre review tysięcy linii kodu jest bardzo trudne lub wręcz niewykonalne. Z wielką mocą idzie wielka odpowiedzialność. Wrzucenie „ośmiotysięcznika” do review niemal na pewno skończy się tym, że dostaniemy approve niemal w ciemno lub ktoś go nie sprawdzi. Nawet jeśli ktoś podejdzie do zadania ambitnie, to utrzymanie stałego poziomu koncentracji przy tak dużych zmianach jest trudne i bardzo męczące. Ostatecznie takie review nie będzie jakościowe.

Obecnie, bardziej niż kiedykolwiek, istotne jest odpowiednie planowanie i dzielenie pracy na etapy. Jedno z podejść do dzielenia dużych zmian na etapy opisałem w jednym z artykułów na blogu. LLM może nam pomóc w planowaniu i dzieleniu pracy, ale potrzebujemy go odpowiednio pokierować.

Jednak duże PR-y to tylko część problemu. Drugą jest po prostu rosnąca ilość kodu do sprawdzenia, którego jest więcej niż kiedykolwiek. Niezależnie od tego, czy dostaniemy 1 PR z 3000 LOC, czy 10 PR-ów z 300 LOC, prawdopodobnie po sprawdzeniu tylu linii kodu będziemy wypompowani.

Niestety, na ten problem nie ma prostego, uniwersalnego remedium. Można podjąć działania, które nieco zredukują ten problem:

• Triaż pull requestów – nie każdy PR wymaga review. Serio! Proces triażu można zautomatyzować, wykorzystując AI. Każdy PR może otrzymać ocenę opartą na krytyczności zmian, np. high, medium, low. Wszystko, co otrzymuje ocenę low, dostaje automatycznie approve. Mogą to być mniej istotne zmiany w kodzie aplikacji, jak na przykład proste refaktoryzacje, zmiany w testach czy dokumentacji. Innymi słowy, jeśli zmiana nie rokuje potencjalnego wysypania produkcji lub popsucia czegoś klientom, to może być akceptowana automatycznie. Na takie zmiany często szkoda czasu zarówno autora czekającego na review, jak i sprawdzającego. Oczywiście review człowieka w takiej sytuacji nadal może być robione, jeżeli uznamy to za zasadne.
• Przymknięcie oka na nitpicki takie jak mikrooptymalizacje, literówki, drobne(!) odstępstwa od konwencji projektowych. Kilka lat temu aż mnie trzęsło, gdy znajdowałem takie rzeczy na masterze… ale już nie trzęsie. Można się tego oduczyć. Świat się od tego nie zawali. Takie rzeczy można poprawiać zgodnie z Boy Scout Rule albo po prostu zostawić. Często samo napisanie komentarza w review zajmie dłużej niż dodanie poprawek. W review skupmy się na designie rozwiązania, błędach, niezgodnościach z wymaganiami czy domeną, aspektach architektonicznych, bezpieczeństwie czy długu technicznym. Jednym z głównych celów review jest łapanie istotnych problemów, zanim wybuchną. Kolejne cele to nauka od innych osób w zespole, dzielenie się wiedzą, propagowanie standardów czy dobrych praktyk. Skupianie się na pierdołach nie spełnia żadnego z tych celów.
• Wykorzystaj AI do review. Możesz to zrobić zarówno wtedy, gdy sprawdzasz swój kod, jak i cudzy. Automatyczne review nie zwalnia jednak z samodzielnego myślenia. Krytycznie analizujmy to, co wskazuje LLM, i nie zakładajmy, że jeśli czegoś nie znalazł, to tego nie ma.
• Automatyzuj, co się da – istnieje mnóstwo rzeczy, które nie powinny nawet docierać do etapu review. Poprawki językowe można wyeliminować, np. wykorzystując Grammarly czy dowolny LLM. Styl kodu można poprawić linterami. Do sprawdzania pokrycia kodu testami również istnieją narzędzia. Jeśli w projekcie istnieje jakaś zasada, to upewnij się, że jest jakiś automat ją sprawdzający. Może to być zarówno instrukcja dla LLM-a robiącego code review, jak i deterministyczne narzędzia.
• Skup się na jakości testów. Jeśli nie ufasz testom i przy każdej zmianie musisz uruchomić aplikację, to sygnał, że być może coś jest do poprawy w testach. To jednak nie jest zero-jedynkowa rekomendacja. W moim obecnym projekcie aplikacja działa w sposób niedeterministyczny i jest częścią większego ekosystemu. Jej sensowne automatyczne przetestowanie czasami jest niemożliwe. Wiele aspektów da się przetestować automatycznie, jednak do pełnego potwierdzenia poprawności działania często potrzeba ludzkiej weryfikacji. Pracowałem jednak w projektach, gdzie praktycznie nie miałem potrzeby uruchamiać aplikacji i bazowałem niemal całkowicie na testach. Jeśli jednak potrzebujesz przeklikać zmianę po każdym zmienionym if-ie, to traktowałbym to jako potencjalną lampkę ostrzegawczą.
• Review innych PR-ów powinno mieć co najmniej taki priorytet jak nasze zadania. Zdecydowana większość projektów to praca zespołowa. O sukcesie projektu decyduje to, ile jesteśmy w stanie dowieźć jako zespół. Kiszenie PR-ów nie tylko blokuje pracę innych, ale również generuje konflikty w kodzie, których rozwiązywanie niekiedy bywa frustrujące.

Więcej dobrych praktyk, jak robić lepsze review opisałem w innym artykule na blogu, gdy AI nie było jeszcze tak powszechnie wykorzystywane jak obecnie. Wiele z nich pozostaje aktualnych.

A może by tak nie wymagać review wcale?

Istnieją firmy i zespoły, w których review jest całkowicie opcjonalne. Wychodzi się wtedy z założenia, że pracujemy z dojrzałymi inżynierami, którzy wiedzą, co robią i biorą za to pełną odpowiedzialność. Takie podejście jest w mojej ocenie do obrony. Wiedząc, że pracujemy z profesjonalistami, obowiązek robienia review niektórych zmian to strata czasu. Review powinno być wtedy zarezerwowane dla bardziej problematycznych przypadków i wynikać z inicjatywy autora zmian.

Takie podejście ma sens, o ile faktycznie pracujemy w świadomym i odpowiedzialnym zespole. Jeśli pomimo wdrożenia AI do procesu tworzenia kodu zespół nadal pracuje w sposób dojrzały i odpowiedzialny, to nie ma różnicy, czy kod pisze człowiek, czy LLM. Nadal ufamy, że osoba, która commituje zmiany, robi to w sposób odpowiedzialny.

Istotne znaczenie ma również samo środowisko pracy. Korzystanie z feature flag, możliwość szybkiego rollbacku, dobrze zaprojektowany system metryk i alertów również pozwalają na mniej restrykcyjne sprawdzanie każdej zmiany.

Takie podejście oczywiście nie wszędzie jest możliwe. W wielu firmach są polityki bezpieczeństwa, które nie pozwalają na takie podejście.

Jeśli jednak jedynym argumentem, by ograniczyć lub przestać robić review, jest fakt, że zmian jest za dużo, to moim zdaniem jest to herezja. Jeśli przed wdrożeniem LLM-ów wymagaliśmy review jako formy kontroli wdrażanych zmian, to dlaczego mielibyśmy naiwnie zakładać, że wdrożenie LLM-ów nagle zwiększy jakość kodu? LLM-y bazują na tym, jak je promptujemy, oraz na istniejącym kodzie. Jeśli wcześniej review było konieczne, to teraz moim zdaniem potrzeba go tym bardziej. Co więcej, zaprzestanie review może szybko i drastycznie obniżyć jakość kodu w projekcie. LLM, widząc wadliwe rozwiązania, będzie je powielał przy implementacji kolejnych zmian.

Zbyt wiele kodu to, moim zdaniem, nie jest argument za zaprzestaniem code review. Nie przekonuje mnie również review robione wyłącznie przez LLM-y. One będą w stanie złapać oczywiste błędy, nieścisłości czy niezgodności z wymaganiami. Brakuje im jednak projektowego czy firmowego know-how, które może ostatecznie wpłynąć na kształt rozwiązania. Oczywiście, można zwiększać jakość odpowiedzi generowanych przez LLM-y przez tworzenie dokumentacji – PRD, ADR, RFC, analiz postmortem i całej masy innej dokumentacji. Należy jednak sobie szczerze odpowiedzieć na pytanie, czy rzetelnie i konsekwentnie od początku projektu taka dokumentacja jest tworzona.

Podsumowanie

W projektach i zespołach, gdzie przed włączeniem AI w proces tworzenia kodu review było konieczne, obecnie review jest jeszcze ważniejsze. LLM jest narzędziem wspierającym inżynierów, ale nie myśli za nich. Wykorzystanie LLM-ów przez odpowiedzialny i doświadczony zespół nie sprawi również, że zacznie on dostarczać gorsze rozwiązania.

Jeśli review jest konieczne, to drastycznie rosnąca ilość kodu do sprawdzenia faktycznie jest problemem i obecnie nie widzę jednego rozwiązania, które rozwiąże ten problem. Widzę natomiast wiele usprawnień, które razem potrafią znacząco ograniczyć jego skalę.

Wspomaganie się LLM-ami w review to świetna pomoc, jednak absolutnie nie zastępuje to review wykonanego przez człowieka. W takiej sytuacji uważam, że zamiast szukać kolejnych narzędzi czy usprawnień, lepiej włożyć wysiłek w zwiększenie kompetencji, wiedzy i dojrzałości zespołu, by docelowo móc ograniczyć review tylko do obszarów, w których faktycznie go potrzebujemy.

Źródła i materiały dodatkowe

• Thomas Paul Mann – No code reviews by default
• Code review z wykorzystaniem asystentów AI
• Jak zrobić DOBRE code review?
• Addy Osmani – AI writes code faster. Your job is still to prove it works.
• Simon Willison – Your job is to deliver code you have proven to work
• RDEL #109: How do AI-assisted code fixes impact code review time?
• Ankit Jain – How to Kill the Code Review
• Every layer of review makes you 10x slower
• Adam Polak – Don’t fear AI code reviews
• Tomasz Ducin na LinkedIn o code review
• Greg Sabo na LinkedIn o code review bottleneck
• Anton Zaides – The price of mandatory code reviews
• Sean Goedecke – Mistakes I see engineers making in their code reviews
• Projekt 100% zrobiony z pomocą AI pokazał, co naprawdę blokuje delivery – Taby vs Spacje #128

Zaobserwuj mnie w mediach społecznościowych!

LinkedIn jest głównym medium, poza blogiem, gdzie publikuję swoje przemyślenia. Zachęcam też do zaobserwowania devszczepaniak.pl na Facebooku, gdzie oprócz informacji o nowych artykułach publikuję linki do ciekawych treści.

Udostępnij wpis

Szukasz taniego i dobrego VPS? Skorzystaj z Mikrusa i przy zakupie odbierz dodatkowy miesiąc usługi za darmo!

📖 Koniecznie sprawdź ofertę księgarni Helion oferującej tysiące książek dla programistów w dobrych cenach! Kupując z tego linku, pomagasz w rozwoju bloga.

📈 Szukasz księgowości dla swojej JDG? Skorzystaj z mojego polecenia i odbierz pierwszy miesiąc za 1zł netto!

Chcesz docenić moją pracę? Postaw mi kawę!