AI Code Review 2.0 – kto sprawdzi kod, który piszą agenci AI?

Agent AI przygotował zmianę, napisał testy, uruchomił je i otworzył pull request. Wszystko na zielono. Drugi agent przeprowadził AI Code Review i nie znalazł istotnych problemów.

Możemy robić merge?

Niekoniecznie.

Testy mogły nie obejmować najważniejszego scenariusza. Reviewer mógł nie znać wymagań biznesowych. A oba agenty mogły przyjąć to samo błędne założenie.

Agenci potrafią już samodzielnie przygotowywać implementacje, refaktoryzować kod, tworzyć testy i poprawiać błędy, coraz częściej kilka zadań równolegle. Im więcej z tego korzystamy, tym wyraźniej widać, że szybkie tworzenie kodu nie oznacza, że równie szybko potrafimy sprawdzić jego poprawność.

Nie jest to już wyłącznie eksperymentalny model pracy. W badaniu AI-to-AI Code Reviews of GitHub Pull Requests, opublikowanym na ESEM 2026, autorzy przeanalizowali ponad 248 tys. pull requestów zidentyfikowanych jako przypadki, w których agent AI przygotowywał zmianę, a AI uczestniczyło również w jej review.

W około 45 tys. przypadków kod był sprawdzany przez produkt AI inny niż ten, który go przygotował. To pokazuje skalę zjawiska, ale otwiera też kolejne pytanie:

czy drugi agent rzeczywiście zapewnia niezależną kontrolę, czy czasem tylko potwierdza założenia pierwszego?

Skoro AI może pisać kod, może też go sprawdzać – i rzeczywiście, narzędzia takie jak Claude Code Review, GitHub Copilot Code Review czy OpenAI Codex analizują kod coraz lepiej. Tylko skąd wiemy, czy wnioski takiego reviewera są prawidłowe?

W artykule zestawiam wyniki badań, doświadczenia firm, które wdrożyły AI Code Review, i kilka scenariuszy z testowania. Pokazuję też, jak połączyć AI Review z testami automatycznymi, Quality Gates i monitorowaniem produkcji – bo moim zdaniem zmienia się nie tyle samo Code Review, ile cały proces weryfikacji oprogramowania.

Czego dowiesz się z tego artykułu?

• Dlaczego coraz szybsze generowanie kodu tworzy nowe problemy w procesie Code Review.
• Jak odróżnić wykrycie potencjalnego błędu od potwierdzenia, że faktycznie występuje.
• Co pokazują badania Microsoft Research, GitHuba i doświadczenia Anthropic.
• Jak wykorzystać agentów AI do analizy API, bezpieczeństwa, testów Playwright i ryzyka zmian.
• Dlaczego AI reviewer może generować błędne komentarze, a nawet prowadzić do niepotrzebnych poprawek.
• Jak połączyć Code Review z Quality Gates i zaprojektować proces dopasowany do ryzyka.
• Jak mierzyć skuteczność własnego rozwiązania bez skupiania się wyłącznie na liczbie komentarzy.

Czy proces weryfikacji nadąża za kodem generowanym przez AI?

W dyskusji o AI w developmentcie często skupiamy się na tym, jak szybko potrafimy wygenerować kolejną funkcjonalność. Znacznie rzadziej sprawdzamy, ile pracy potrzeba później, żeby mieć pewność, że działa ona zgodnie z oczekiwaniami.

W badaniu The State of Software Quality and Testing 2026 firma SmartBear zebrała odpowiedzi 1436 specjalistów i liderów technologicznych pracujących w organizacjach, które już wykorzystują AI w procesie wytwarzania oprogramowania. Badanie objęło duże organizacje, głównie ze Stanów Zjednoczonych, dlatego wyniki traktowałbym jako obraz wyzwań w tej grupie, a nie reprezentatywny pomiar całego rynku IT.

Wyniki pokazują kilka interesujących zależności:

• 65% respondentów deklaruje, że AI tworzy lub przyspiesza pracę nad co najmniej 41% kodu.
• 55% zgłasza problemy jakościowe wynikające z tego, że development wyprzedza możliwości zespołów testujących.
• 46% przyznaje, że ich organizacja wdrożyła kod generowany przez AI, który później zawiódł na produkcji.
• 47% miało trudności z wyjaśnieniem, jak AI przyczyniło się do błędu lub incydentu.

To deklaracje ankietowanych, a nie pomiar odsetka wadliwego kodu. Pokazują jednak problem, który wykracza poza wybór modelu lub narzędzia do code review.

Sprawdzamy kod częściej niż intencję

Ciekawy jest też sposób weryfikacji kodu. Tylko 46% respondentów deklaruje sprawdzanie zgodności specyfikacji z rzeczywistą intencją przed rozpoczęciem generowania kodu przez AI. Tymczasem 60% niezależnie testuje ponad 60% kodu AI przed wydaniem.

Kontrola koncentruje się więc częściej na późniejszych etapach procesu. A przecież nawet bardzo dobre testy i code review nie zagwarantują poprawności produktu, jeżeli punktem wyjścia było źle zrozumiane wymaganie.

Podobne napięcie opisuje DORA w analizie z marca 2026 roku, opartej na 1110 wypowiedziach inżynierów Google. Z ich doświadczeń wynika, że czas zaoszczędzony na generowaniu kodu bywa później przeznaczany na jego kontrolę i weryfikację. To badanie jakościowe, a nie pomiar czasu odzyskanego i utraconego w każdym projekcie. Pokazuje jednak ważne zjawisko – przyspieszenie jednej części SDLC może zwiększyć obciążenie w innej.

Dlatego samo przyspieszenie code review nie wystarczy. Potrzebujemy procesu, który sprawdza intencję przed implementacją, pozwala niezależnie weryfikować rezultaty i dostarcza informacji potrzebnych do oceny ryzyka przed wdrożeniem.

W tym kontekście podejście Anthropic do wieloetapowego i wieloagentowego code review jest szczególnie interesujące. Nie dlatego, że usuwa człowieka z procesu, ale dlatego, że próbuje zwiększyć przepustowość weryfikacji bez traktowania pojedynczej odpowiedzi modelu jako wystarczającego dowodu poprawności.

Więcej kodu, więcej zmian, więcej rzeczy do sprawdzenia

Wyobraźmy sobie zespół, w którym programiści coraz intensywniej korzystają z agentów AI. Większa funkcjonalność zajmowała wcześniej kilka dni. Teraz agent szybciej generuje implementację, testy i dokumentację, a programista zamiast pisać cały kod, kieruje pracą agenta, analizuje wyniki i zleca kolejne zadania.

Zmian przybywa, a Code Review nadal wymaga czasu. Ktoś musi zrozumieć intencję zmiany, sprawdzić jej wpływ na system, przeanalizować możliwe błędy i zdecydować, czy merge jest bezpieczny.

Tak powstaje nowe wąskie gardło: przyspieszamy development, ale niekoniecznie delivery.

Czy większa liczba PR-ów oznacza większą produktywność?

Podobny problem poruszałem w artykule Modele dojrzałości AI – postęp czy chaos?. Opisywałem tam organizację, która intensywnie korzysta z AI, ale jej procesy nie nadążają za narzędziami. Programiści pracują z agentami, testerzy generują scenariusze, liczba zmian rośnie. Standardy są jednak rozproszone, dokumentacja zostaje w tyle, a review robi się coraz płytsze.

Z zewnątrz wygląda to na postęp. Ale jeśli mierzymy tylko szybkość tworzenia zmian, możemy przeoczyć rosnącą liczbę regresji, reworku i problemów produkcyjnych.

Z AI Code Review jest podobnie. Możemy automatycznie analizować setki PR-ów i generować tysiące komentarzy. Tylko czy wykrywamy więcej istotnych błędów? Czy oszczędzamy czas ludzi? Czy zmniejszamy ryzyko?

Celem nie powinno być zautomatyzowanie jak największej liczby komentarzy, lecz zmniejszenie kosztu i ryzyka weryfikacji zmian.

W tę stronę idzie też publikacja OpenAI – A Practical Approach to Verifying Code at Scale. Autorzy zwracają uwagę na wartość pojedynczego komentarza: dobry reviewer powinien zgłaszać przede wszystkim problemy, których wykrycie daje więcej niż kosztuje ich analiza i ryzyko fałszywego alarmu. Każde zgłoszenie wymaga czyjejś uwagi. Nawet jeśli zajmuje się nim kolejny agent AI, to nadal koszt, opóźnienie i okazja do nowych błędów.

AI Code Review to nie to samo co weryfikacja poprawności

AI reviewer analizuje zmianę i zgłasza potencjalne problemy. Może korzystać z kontekstu repozytorium, dokumentacji, instrukcji projektowych i narzędzi do analizy kodu. Sam komentarz reviewera nie jest jednak dowodem, że defekt istnieje.

W praktyce warto rozdzielić trzy działania:

1. Wykrycie problemu (Detection) – identyfikujemy potencjalny defekt, niezgodność lub ryzyko.
2. Weryfikacja (Verification) – sprawdzamy, czy problem rzeczywiście występuje i jakie może mieć konsekwencje.
3. Decyzja (Decision) – na podstawie zebranych informacji określamy, czy zmianę można zaakceptować, czy wymaga dalszej pracy.

W klasycznym Code Review często wszystkie trzy wykonuje ta sama osoba. Przy AI możemy je częściowo rozdzielić: agent wyszukuje potencjalne problemy, inny mechanizm próbuje je potwierdzić, a Quality Gate na podstawie wyników ocenia, czy zmiana spełnia wymagania.

Nie znaczy to, że każdy etap musi wykonywać osobny agent. Często najlepszym mechanizmem weryfikacji będzie zwykły test automatyczny, analiza statyczna albo sprawdzenie kontraktu API.

Czy drugi agent rzeczywiście zapewnia niezależną weryfikację?

Warto odróżnić dwa pojęcia: niezależnego kontrolera i niezależne źródło informacji o poprawności.

Dwa agenty mogą działać w osobnych sesjach, korzystać z różnych modeli, a mimo to opierać się na tej samej, błędnie zinterpretowanej specyfikacji. Ich zgodne odpowiedzi zwiększają nasze zaufanie do wyniku, ale niekoniecznie jego wiarygodność. Inaczej wygląda sytuacja, gdy reviewer zgłasza potencjalny problem, a jego istnienie potwierdza test oparty na zaakceptowanym wymaganiu, reprodukcja defektu albo niezależnie zdefiniowany kontrakt API. Nie oznacza to, że kilkuagentowe review nie ma wartości. Może zwiększać wykrywalność problemów. Trzeba jednak wiedzieć, czy uzyskujemy kolejną opinię modelu, czy nowy dowód dotyczący zachowania systemu.

Ten wątek rozwijałem w artykule Testy automatyczne w erze AI – czym jest Verification Engineering?, gdzie pisałem o projektowaniu środowiska, które dostarcza agentowi wiarygodnych informacji o poprawności jego pracy. AI reviewer może być częścią takiego środowiska, ale nie powinien być jedynym źródłem prawdy.

Poniższe przykłady to ilustracje możliwych problemów, a nie opisy incydentów w konkretnych organizacjach.

Przykład 1. Zmiana w API – poprawny kod, zepsuty kontrakt

Rozwijamy aplikację e-commerce. Agent zmienia endpoint:

GET /api/orders/{id}

W ramach refaktoryzacji usuwa pole totalGross, bo podobna informacja jest już w nowej strukturze pricing.

Implementacja wygląda poprawnie. Testy jednostkowe przechodzą, TypeScript nie zgłasza błędów, AI reviewer nie znajduje istotnych problemów w logice.

Starsza wersja aplikacji mobilnej nadal jednak korzysta z totalGross i po wdrożeniu przestaje poprawnie wyświetlać podsumowanie zamówienia.

Co powinien sprawdzić reviewer?

Sam diff nie wystarczy. Potrzebujemy wiedzieć, jak wyglądał poprzedni kontrakt API, które aplikacje korzystają z endpointu, czy pole zostało oficjalnie wycofane i czy zmiana wymaga wersjonowania. AI reviewer może pomóc w analizie tych zależności, ale bez odpowiedniego kontekstu może w ogóle nie zauważyć ryzyka.

Lepszy proces mógłby wyglądać tak:

Wykrycie: agent identyfikuje zmianę publicznego kontraktu API.

Weryfikacja: uruchamiany jest test kontraktowy, który sprawdza zgodność implementacji z obowiązującymi wymaganiami i oczekiwaniami klientów API.

Decyzja: jeżeli zmiana narusza wymagany kontrakt, Quality Gate blokuje merge do czasu rozwiązania problemu lub zatwierdzenia zmiany kontraktu.

Tu przydają się narzędzia takie jak Pact, które weryfikują zgodność między konsumentem a dostawcą API.

Zgodność implementacji ze specyfikacją OpenAPI nie zawsze dowodzi kompatybilności z rzeczywistymi klientami – specyfikację też można błędnie zmienić. Dlatego trzeba odróżniać sprawdzenie zgodności ze schematem od sprawdzenia oczekiwań konsumentów.

To także przykład problemu test oracle, o którym pisałem w artykule o Verification Engineering. Jeśli nie wiemy, jakie zachowanie jest poprawne, nawet najbardziej rozbudowane AI Review nie zagwarantuje właściwej oceny.

W praktyce warto utrzymywać kontrakty wynikające z rzeczywistych oczekiwań konsumentów API i weryfikować je przed wdrożeniem kolejnej wersji dostawcy. Jeżeli starsza aplikacja mobilna wymaga pola totalGross, taka zależność powinna być widoczna w testach kontraktowych lub w innych jawnie utrzymywanych wymaganiach kompatybilności.

Agent może wtedy wskazać zmianę potencjalnie niezgodną wstecznie, a pipeline potwierdzić ją testem.

Jeśli jednak nie mamy ani aktualnego kontraktu konsumenta, ani wiedzy o używanych wersjach aplikacji, reviewer może jedynie zasygnalizować ryzyko. Nie powinien udawać, że zna wpływ zmiany na wszystkich klientów.

Przykład 2. Security Review – błąd, którego nie widać w pojedynczej funkcji

Mamy aplikację SaaS, w której wiele organizacji korzysta ze wspólnej infrastruktury. Każdy użytkownik ma przypisany identyfikator organizacji – tenantId.

Agent modyfikuje endpoint pobierający dokumenty i upraszcza zapytanie do bazy. Nowa implementacja poprawnie wyszukuje dokument po identyfikatorze, ale pomija ograniczenie do organizacji zalogowanego użytkownika.

Kod działa, testy przechodzą, funkcja zwraca dokument. Tyle że użytkownik jednej organizacji może teraz potencjalnie dostać się do dokumentu innej.

To już nie drobna uwaga do implementacji, tylko naruszenie izolacji danych – klasa problemów znana jako Broken Object Level Authorization (BOLA), opisana w OWASP API Security Top 10.

Jak powinien wyglądać proces weryfikacji?

Reviewer może sprawdzić, czy zmiana dotyka autoryzacji, zapytań do bazy i filtrowania danych. Jeśli dostrzeże ryzyko, powinien wskazać konkretny scenariusz, w którym problem wystąpi.

Następnie możemy przygotować test, który:

1. Tworzy dwie organizacje oraz przypisanych do nich użytkowników.
2. Tworzy dokument należący do pierwszej organizacji.
3. Próbuje uzyskać do niego dostęp z konta użytkownika drugiej organizacji.
4. Weryfikuje, że dostęp został prawidłowo zablokowany.

Test mówi, jak API zachowuje się w tym konkretnym scenariuszu. Jego przejście nie dowodzi jednak, że podatności nie ma – może istnieć inna ścieżka dostępu, inna konfiguracja uprawnień albo nieprzetestowany wariant zapytania.

Przy zmianach dotyczących bezpieczeństwa warto więc łączyć kilka mechanizmów: analizę kodu, testy autoryzacji, SAST, testy bezpieczeństwa i przegląd przez specjalistę.

Anthropic w artykule Automate security reviews with Claude Code pokazuje, jak używać AI do wcześniejszego wykrywania potencjalnych podatności. Nawet kilka agentów analizujących ten sam kod nie zastępuje jednak niezależnej weryfikacji. Trzy modele mogą dojść do identycznego, błędnego wniosku.

Kilka zgodnych opinii AI nie jest tym samym co niezależny dowód poprawności.

Przykład 3. Playwright – agent poprawił test, ale zepsuł weryfikację

Mamy test E2E w Playwright, który po złożeniu zamówienia sprawdza, czy wyświetla się komunikat potwierdzający. Test zaczyna sporadycznie padać z powodu problemów z synchronizacją, więc prosimy agenta AI o poprawienie jego stabilności.

Agent analizuje kod, zmienia sposób oczekiwania i uruchamia testy. Wszystkie przechodzą.

Problem w tym, że przy okazji usunął asercję sprawdzającą pojawienie się potwierdzenia. Test nadal wykonuje akcje użytkownika, ale przestał weryfikować jeden z najważniejszych rezultatów. W CI wszystko wygląda dobrze.

Przed poprawką test wyglądał tak:

await page.getByRole('button', {
    name: 'Place order',
}).click();

await expect(
    page.getByText('Order confirmed')
).toBeVisible();

Po stabilizacji wygląda tak:

await page.getByRole('button', {
    name: 'Place order',
}).click();

// Assertion removed.
// Test passes.

Czy AI Code Review powinno to wykryć?

Powinien, ale nie zawsze będzie w stanie. Jeśli analizuje tylko składnię i strukturę kodu, uzna refaktoryzację za poprawną. Żeby zauważyć problem, musi rozumieć intencję testu i oczekiwane zachowanie – wtedy może porównać asercje przed zmianą i po niej, zauważyć utratę zakresu weryfikacji albo usunięcie kontroli krytycznej dla scenariusza.

Możemy też użyć niezależnego mechanizmu: uruchomić test na kontrolowanej, zmodyfikowanej wersji aplikacji, w której komunikat potwierdzający się nie wyświetla. Jeśli test mimo to przechodzi, mamy mocny sygnał, że nie wykrywa już problemu, który miał sprawdzać.

To podejście nawiązuje do mutation testingu. Narzędzia takie jak StrykerJS badają, czy testy wykrywają celowo wprowadzone zmiany w zachowaniu kodu. Tutaj nie potrzebujemy jednak pełnego mutation testingu dla testów E2E – wystarczy prostszy, kontrolowany wariant negatywny.

Możemy zacząć od czegoś znacznie prostszego niż pełny mutation testing – porównywania krytycznych asercji przed zmianą i po niej. Jeżeli agent usuwa asercję albo zastępuje ją mniej wymagającym sprawdzeniem, reviewer powinien przynajmniej poprosić o uzasadnienie.

Przy bardziej ryzykownych zmianach warto pójść krok dalej – celowo zasymulować brak oczekiwanego rezultatu i sprawdzić, czy test nadal wykrywa problem. W takim podejściu nie pytamy wyłącznie, czy test przechodzi. Sprawdzamy również, czy test wciąż spełnia swoją funkcję weryfikacyjną.

Co to oznacza dla frameworków testowych?

W artykule Agent AI może napisać kod. Ale skąd wie, że zrobił to dobrze? opisywałem test automatyczny jako sensor, który mówi agentowi, jaki był rezultat jego działania. Dobry sensor jest szybki, deterministyczny, niezależny od sprawdzanej implementacji i dostarcza użytecznych informacji diagnostycznych.

Co jednak, jeśli agent sam zmienia sensor, którym potem ocenia własną pracę? Może poprawić wynik, nie poprawiając jakości.

Dotyczy to także Code Review. Reviewer nie powinien oceniać tylko tego, czy zmieniony test jest poprawnie napisany, ale też to, czy nie osłabiono jego zdolności do wykrywania defektów. W przypadku Playwrighta warto patrzeć między innymi na usunięte asercje, niepotrzebne retry, sztuczne opóźnienia, zależności między testami i zmiany w zarządzaniu danymi.

Nie wszystkie takie kontrole wymagają AI. W artykule o Verification Engineering pokazywałem przykład z page.waitForTimeout(): zamiast kolejny raz prosić agenta, żeby unikał sztucznych opóźnień, można włączyć odpowiednią regułę ESLint i mieć szybką, deterministyczną kontrolę.

Jeżeli problem da się wykryć prostą regułą, nie trzeba za każdym razem angażować do niego modelu językowego.

Przykład 4. Reviewer chce naprawiać coś, co nie jest błędem

Do tej pory agent przeoczał problem. Bywa też odwrotnie.

Funkcja oblicza rabat dla klienta. Zgodnie z wymaganiem biznesowym rabat jest zaokrąglany w dół do pełnych groszy. AI reviewer zgłasza, że zamiast zaokrąglania w dół należy użyć standardowego zaokrąglania matematycznego, i proponuje rozsądnie wyglądającą poprawkę.

Obecna implementacja jest jednak zgodna z zaakceptowaną regułą biznesową. Jeśli agent odpowiedzialny za kod przyjmie sugestię, wprowadzimy regresję.

Problem nadmiernego poprawiania kodu

W czerwcu 2026 roku opublikowano badanie Are LLMs reliable code reviewers? Systematic overcorrection in requirement conformance judgement. Autorzy sprawdzali, jak modele oceniają zgodność implementacji z wymaganiami, i zaobserwowali over-correction – uznawanie poprawnego kodu za niezgodny z wymaganiami. Bardziej rozbudowane prompty, wymagające wyjaśnienia problemu i zaproponowania poprawki, potrafiły zwiększać liczbę takich błędnych ocen.

Badacze zaproponowali mechanizm Fix-guided Verification Filter. Zamiast ufać ocenie modelu, traktujemy zaproponowaną poprawkę jako hipotezę do sprawdzenia: uruchamiamy testy dla oryginalnej implementacji i sugerowanej zmiany, porównujemy zachowanie i sprawdzamy, czy poprawka rzeczywiście coś rozwiązuje.

Taki mechanizm też zależy od jakości testów i wymagań, więc nie gwarantuje pełnej poprawności. Kierunek uważam jednak za wartościowy.

Reviewer może brzmieć przekonująco, a mimo to nie mieć racji.

Automatyczne akceptowanie wszystkich komentarzy AI może więc być równie problematyczne jak ich ignorowanie.

Przykład 5. Każdy test przechodzi osobno, ale system psuje się po merge

Dwa agenty niezależnie pracują nad różnymi fragmentami aplikacji. Pierwszy aktualizuje backend i zmienia obsługę jednego z pól odpowiedzi API. Drugi dostosowuje frontend do nowej funkcjonalności, opierając się na wcześniejszej wersji kontraktu.

Oba pull requesty przechodzą swoje testy i dostają pozytywną ocenę reviewerów. Po połączeniu zmian frontend i backend okazują się niekompatybilne.

Review każdego PR-a w izolacji tego nie wyłapie. Potrzebujemy weryfikacji zintegrowanego stanu systemu. Można tu użyć GitHub Merge Queue, która ponownie uruchamia wymagane kontrole na zmianach połączonych z aktualnym stanem gałęzi docelowej. Merge queue niczego jednak nie zagwarantuje, jeśli testy nie wykrywają błędu.

Wracamy tu do Piramidy testów 2.0. Piramida nie traci sensu w erze AI – kiedy zmian przybywa, szybkie testy jednostkowe, komponentowe i integracyjne oraz dobrze dobrane testy E2E znaczą jeszcze więcej. Nie chodzi o to, żeby bez końca dokładać testów, tylko o kontrole dopasowane do architektury systemu i rzeczywistych ryzyk.

Weryfikacja nie powinna też kończyć się na merge. Zmiana konfiguracji, feature flagi czy danych produkcyjnych może wywołać problem, którego nie ma na środowisku testowym. Dlatego potrzebujemy monitoringu, stopniowego wdrażania zmian i możliwości szybkiego rollbacku.

Co o AI Code Review mówią badania?

Zanim zbudujemy rozbudowany proces, warto sprawdzić, jak dobrze obecne rozwiązania radzą sobie z wykrywaniem błędów.

Microsoft Research: 71,9% wykrytych znanych błędów

W październiku 2026 roku opublikowano badanie (When) Should a Software Factory be Lights-off? Benchmarking Code Review Agents on Bug Detection. Badacze przygotowali CRBugBench: 1000 zadań review z 98 repozytoriów open source oraz 800 dodatkowych przypadków z wewnętrznych repozytoriów przemysłowych.

Najlepsza badana konfiguracja, Claude Opus 5 z Copilot CLI, wykryła 71,9% znanych błędów w pięciu najwyżej ocenionych komentarzach. Wynik dotyczy jednak konkretnego benchmarku i przypadków, w których badacze znali już defekt. Nie mówi nam, jaki odsetek wszystkich problemów agent wykryje w rzeczywistym projekcie.

Co istotne, skuteczność wyraźnie spadała w przypadku bardziej złożonych zmian, problemów wymagających analizy odległych zależności oraz wewnętrznych repozytoriów przemysłowych. To właśnie tam znajomość kontekstu projektu staje się szczególnie ważna. Dostęp do całego repozytorium nie oznacza, że model rozumie wszystkie zależności biznesowe.

OpenAI: reguły projektu mają znaczenie

Publikacja Custom Code Review Rules for Codex opisuje wewnętrzną ewaluację, w której precyzyjne reguły projektowe zwiększyły wykrywanie wymaganych naruszeń z 58,3% do 98%.

Nie znaczy to, że Codex wykrywa 98% wszystkich błędów. Wynik dotyczy konkretnego zestawu reguł i przygotowanych przypadków ewaluacyjnych. Pokazuje natomiast, ile zależy od dostarczonego kontekstu.

Zamiast ogólnej instrukcji:

Sprawdź bezpieczeństwo API.

Możemy zapisać konkretną zasadę:

Każdy endpoint pobierający dokument użytkownika musi egzekwować autoryzację i izolację danych między organizacjami. Jeśli wykryjesz możliwość dostępu do danych innego tenantId, wskaż konkretną ścieżkę oraz warunki wystąpienia problemu.

Podobnie we frameworku Playwright możemy określić, że reviewer ma szczególnie pilnować usuwania asercji, osłabiania izolacji testów i zastępowania mechanizmów synchronizacji sztucznymi opóźnieniami.

W Codex można korzystać z instrukcji repozytorium, a Claude Code Review pozwala definiować zasady w REVIEW.md. Sam plik z instrukcjami nie gwarantuje jednak poprawnego review. Reguły też bywają niekompletne lub nieaktualne, dlatego warto sprawdzać, czy reviewer faktycznie ich przestrzega.

Warto przy tym sprawdzać nie tylko to, czy reviewer wykrywa naruszenie reguły, ale również, czy nie zgłasza jej tam, gdzie zastosowano prawidłowe rozwiązanie alternatywne.

Dla przykładu brak filtra tenantId w samym zapytaniu do bazy nie musi oznaczać podatności, jeśli autoryzacja obiektowa jest prawidłowo egzekwowana w innej warstwie. Reviewer powinien rozpoznać cały mechanizm, zamiast automatycznie odrzucać każdą implementację odbiegającą od jednego wzorca.

Więcej kontekstu nie zawsze oznacza lepsze review

Dostęp do dokumentacji, repozytorium i decyzji architektonicznych jest ważny. Nie oznacza to jednak, że powinniśmy przekazywać agentowi wszystko naraz.

Badanie SWE-PRBench pokazało, że w testowanych konfiguracjach zwiększanie ilości kontekstu pogarszało skuteczność wykrywania problemów. Jedną z możliwych przyczyn jest rozproszenie uwagi modelu na informacje, które nie pomagają w ocenie konkretnej zmiany.

Inne badania, między innymi Microsoft Research, wskazują jednak na korzyści z aktywnej eksploracji repozytorium przez agenta.

W praktyce nie chodzi więc tylko o wielkość kontekstu, ale o jego dobór, aktualność i sposób wykorzystania. Reviewer powinien wiedzieć, gdzie znaleźć potrzebną informację, zamiast za każdym razem otrzymywać całą dokumentację projektu.

GitHub ReviewBench: jak porównywać narzędzia AI Code Review?

W październiku 2026 roku GitHub opublikował ReviewBench – otwarty benchmark do oceny AI Code Review. Zestaw obejmuje 219 pull requestów z 187 repozytoriów i 19 języków programowania.

Benchmark rozróżnia precision i recall. Precision określa, jaka część zgłoszonych problemów jest rzeczywiście prawidłowa. Recall – jaki odsetek znanych problemów reviewer potrafi wykryć.

Samo zwiększenie liczby komentarzy nie poprawia więc skuteczności. Reviewer zgłaszający kilkadziesiąt błędnych uwag może zabrać zespołowi więcej czasu niż taki, który znajduje kilka prawdziwych problemów. Z kolei zbyt zachowawczy reviewer nie generuje fałszywych alarmów, ale pomija istotne defekty.

ReviewBench próbuje też uwzględniać prawidłowe problemy, których nie było w pierwotnym zbiorze referencyjnym – w rzeczywistym Code Review nikt nie zna z góry listy wszystkich defektów.

Jedna metryka nie wystarczy do oceny takiego systemu.

Jak Anthropic i Intercom wdrażają AI Code Review?

Oprócz badań warto spojrzeć na wdrożenia. Dwa przykłady pochodzą od Anthropic i Intercom.

Anthropic: AI Code Review jako kilka warstw kontroli

15 października 2026 roku Anthropic opublikował How the Claude Code team does code review. Firma opisuje proces, w którym większość rutynowej analizy kodu wykonują mechanizmy automatyczne, a udział człowieka zależy od ryzyka.

Według przedstawionych danych między czerwcem a wrześniem 2026 roku:

• liczba mergowanych PR-ów w repozytorium Claude Code wzrosła ponad dwukrotnie,
• odsetek zmian wymagających wycofania spadł o ponad 40%,
• udział wewnętrznych PR-ów z merytorycznymi uwagami review wzrósł z 16% do 54% po wprowadzeniu nowego rozwiązania.

Nie dowodzi to, że wszystkie korzyści wynikają z AI Code Review – w tym czasie zmieniały się też inne elementy procesu wytwarzania oprogramowania. Ciekawsze jest samo podejście.

Weryfikacja zaczyna się przed otwarciem PR-a: agent sprawdza własną pracę, uruchamia testy i analizuje diff. Potem niezależne agenty szukają potencjalnych problemów, a kolejne mechanizmy próbują potwierdzić zgłoszenia i odsiać fałszywe alarmy. Osobno wykonywany jest Security Review. Następne warstwy kontrolują testy, integrację zmian, ryzyko wdrożenia i zachowanie systemu na produkcji.

Wewnętrzny proces Anthropic jest przy tym znacznie szerszy niż publicznie dostępne narzędzie Claude Code Review. Samo narzędzie publikuje komentarze i wyniki analizy, ale nie zastępuje mechanizmów, które decydują o merge.

Ponad 50 rund AI Review jednego PR-a

Anthropic opisuje też przypadek pull requesta, który przeszedł ponad 50 rund automatycznego review i poprawek. Jeden agent zgłaszał problemy, drugi wprowadzał zmiany i cykl zaczynał się od nowa.

Około 59% kolejnych uwag dotyczyło kodu, który istniał już w pierwszej rundzie. Problemem nie było więc tylko wprowadzanie nowych defektów, ale też odkrywanie po kawałku problemów, które reviewer mógł zgłosić od razu.

Zespół wprowadził limity iteracji, ograniczył powtarzające się komentarze i skupił ponowną analizę na nowych zmianach. Więcej iteracji nie musi oznaczać wyższej jakości.

W artykule o feedback loops dla agentów AI pisałem o podobnym problemie: agent potrzebuje nie tylko informacji zwrotnej, ale też warunków zakończenia pracy. Bez nich może optymalizować niewłaściwą metrykę albo wykonywać kolejne działania, które nie poprawiają rezultatu.

Intercom: część PR-ów zatwierdza AI, bez ludzkiego review

Inną strategię opisuje Intercom w artykule AI is approving our pull requests. Firma deklaruje, że ponad 19% pull requestów w dwóch głównych repozytoriach jest zatwierdzanych automatycznie, bez ludzkiego reviewera.

Nie znaczy to, że agenci mogą zatwierdzać dowolne zmiany. Automatyzacja opiera się na ocenie ryzyka i specjalizowanych kontrolach, a bardziej złożone zmiany nadal przechodzą dodatkową weryfikację.

Zamiast próbować zastąpić wszystkich reviewerów, Intercom automatyzuje te przypadki, dla których ma wystarczająco wiarygodne mechanizmy kontroli. To jednak opis jednego wdrożenia, a nie dowód, że podobny poziom autonomii będzie bezpieczny w każdym projekcie.

A co z wiedzą o systemie?

Code Review od zawsze pełniło jeszcze jedną funkcję, bo pozwalało programistom poznawać zmiany wprowadzane przez innych.

Przeglądając kod, dowiadujemy się nie tylko, jak coś działa, ale również dlaczego zostało zaprojektowane w określony sposób. Poznajemy decyzje, ograniczenia i zależności, które nie zawsze są opisane w dokumentacji.

Co się stanie, jeśli większość takich przeglądów przejmą agenci AI?

Możemy zmniejszyć liczbę błędów przed merge, a jednocześnie stopniowo tracić wspólną wiedzę o systemie.

Anthropic również zwraca uwagę na ten problem. Zamiast wymagać od programistów czytania każdego diffu, wykorzystuje AI między innymi do tworzenia wyjaśnień konkretnych fragmentów architektury How the Claude Code team does code review

To interesująca strategia, ale rodzi kolejne pytania. Skąd wiemy, że wygenerowane wyjaśnienie jest aktualne? Czy zespół nadal rozumie kluczowe decyzje? Kto potrafi samodzielnie zdiagnozować awarię, gdy zabraknie dostępu do agenta?

Dlatego oceniając automatyzację Code Review, nie ograniczałbym się do liczby wykrytych błędów i zaoszczędzonego czasu. Warto sprawdzać również, czy organizacja nadal potrafi utrzymywać i rozwijać system, który coraz rzadziej czyta człowiek.

Od AI Code Review do wielowarstwowej weryfikacji

Z tych przykładów da się wyprowadzić bardziej ogólne podejście. Zamiast systemu, który ma znaleźć jak najwięcej problemów w PR-ze, projektujemy proces dostarczający informacji potrzebnych do oceny ryzyka zmiany.

Przykładowa architektura:

To nie gotowa metodyka ani produkt, tylko model koncepcyjny łączący znane praktyki Quality Engineering z możliwościami agentów.

1. Kontekst i intencja zmiany

Zbieramy informacje o tym, co zostało zmienione i dlaczego. Liczy się nie tylko diff, ale też wymagania, kontrakty, wcześniejsze decyzje architektoniczne i historia podobnych problemów.

2. Klasyfikacja ryzyka

System określa, jakie obszary zostały zmienione i jakie mogą być konsekwencje błędu. Modyfikacja mechanizmu autoryzacji wymaga innych kontroli niż zmiana tekstu na stronie.

AI może pomagać w klasyfikacji, ale reguły wymaganych zatwierdzeń i mechanizmy bezpieczeństwa powinny być jawne i egzekwowane niezależnie.

3. Analiza przez odpowiednie mechanizmy

W zależności od ryzyka uruchamiamy określone kontrole: agentów sprawdzających logikę, bezpieczeństwo lub zgodność z kontraktami, ale też zwykłe testy, lintery i narzędzia analizy statycznej. Analiza ryzyka powinna uwzględniać skutki błędu, odwracalność zmiany, dostępność testów, wrażliwość danych i zakres wpływu na inne systemy.

4. Weryfikacja najważniejszych ustaleń

Potencjalne błędy potwierdzamy wszędzie, gdzie się da: testem regresyjnym, reprodukcją defektu, analizą kontraktu, sprawdzeniem uprawnień albo oceną specjalisty.

Nie każdą uwagę da się automatycznie potwierdzić. Wtedy system powinien jasno komunikować niepewność, a nie przedstawiać hipotezę jako fakt.

5. Quality Gate i decyzja

Na podstawie wyników kontroli zapada decyzja: akceptujemy zmianę, kierujemy ją do dodatkowej analizy albo blokujemy merge.

Egzekwowanie warunków powinno należeć do mechanizmów CI/CD, np. GitHub Branch Protection, a nie wyłącznie do komentarza modelu.

Quality Gate powinien uwzględniać status dowodów, a nie jedynie liczbę komentarzy lub poziom pewności modelu. Przykładowo problem potwierdzony testem, problem niepotwierdzony, brak możliwości weryfikacji oraz zaakceptowane ryzyko to różne stany.

6. Monitoring i informacja zwrotna

Po wdrożeniu nadal obserwujemy działanie systemu. Regresje, incydenty i wycofane zmiany pokazują, co trzeba poprawić w mechanizmach review.

Code Review staje się wtedy częścią szerszego procesu zarządzania jakością, a nie osobnym etapem, który kończy się zatwierdzeniem PR-a.

Risk-Based AI Code Review – nie każdy PR potrzebuje tego samego

Jak mogłoby to działać w praktyce? Weźmy trzy rodzaje zmian.

Niskie ryzyko: dokumentacja i proste zmiany UI

Agent poprawia literówkę w dokumentacji albo tekst w komponencie interfejsu. Wystarczy automatyczny lint, podstawowe kontrole i szybkie AI Review. Jeśli zmiana nie dotyka innych obszarów, może przejść uproszczoną ścieżkę.

Nawet dokumentacja bywa jednak krytyczna, np. gdy opisuje procedury bezpieczeństwa. Sam typ pliku nie powinien automatycznie przesądzać o poziomie ryzyka.

Średnie ryzyko: zmiana logiki biznesowej

Agent modyfikuje naliczanie rabatów w sklepie. Tu potrzebujemy szerszej weryfikacji: reviewer sprawdza zgodność z wymaganiami, a testy obejmują klasy równoważności, wartości brzegowe, różne waluty i reguły zaokrąglania.

Jeśli zmiana spełnia ustalone warunki, nie musi to oznaczać ręcznego przeglądu każdej linii kodu. Ważniejsze jest, jakie dowody poprawności zebraliśmy i jakie ryzyka zostały.

Wysokie ryzyko: autoryzacja i płatności

Agent zmienia weryfikację uprawnień lub obsługę transakcji płatniczych. Proces może wtedy wymagać niezależnego Security Review, dodatkowych testów, oceny zgodności z kontraktami i zatwierdzenia przez odpowiednią osobę. Po wdrożeniu można stopniowo udostępniać zmianę i dokładniej ją monitorować.

To podejście pasuje do praktyk z NIST Secure Software Development Framework (SSDF), który kładzie nacisk na włączenie bezpieczeństwa w cały proces wytwarzania oprogramowania.

AI Code Review a dojrzałość organizacji

Wracam tu do modeli dojrzałości AI. Organizacja, która dopiero eksperymentuje z agentami, nie powinna od razu wdrażać automatycznego zatwierdzania pull requestów.

Zanim zwiększymy autonomię, potrzebne są podstawy: standardy pracy, dostęp do kontekstu, testy, Quality Gates, odpowiedzialność za decyzje i pomiar skuteczności. Dopiero gdy działają, można stopniowo ograniczać udział człowieka w wybranych etapach.

Autonomia powinna wynikać z jakości mechanizmów kontroli, a nie wyłącznie z rosnących możliwości modelu.

A kto będzie sprawdzał AI Code Review?

Wielowarstwowy proces nie odpowiada na jedno pytanie: skąd wiemy, że nasz reviewer AI jest skuteczny?

Może świetnie radzi sobie z błędami składniowymi, ale regularnie pomija problemy z autoryzacją. Może wykrywa większość defektów, ale generuje tyle fałszywych alarmów, że programiści przestają czytać jego komentarze. Albo nowa wersja modelu zaczyna gorzej oceniać niektóre rodzaje PR-ów.

Problem nie kończy się na wykrywaniu defektów

Musimy też sprawdzać, czy same komentarze reviewerów są prawidłowe.

We wrześniu 2026 roku opublikowano CRJudgeBench, benchmark obejmujący 1199 przypadków poprawnych i błędnych komentarzy Code Review. Badacze sprawdzali, czy modele potrafią rozpoznać uwagi, które brzmią wiarygodnie, ale zawierają nieprawdziwe twierdzenia techniczne.

Najlepszy opisany system uzyskał 76,6% trafności na wydzielonym zbiorze testowym.

To wynik jednego benchmarku, a nie uniwersalna miara skuteczności AI. Pokazuje jednak, że nawet ocenianie komentarzy wygenerowanych przez inny model jest osobnym, trudnym zadaniem.

Dlatego warto wymagać od reviewera nie tylko wskazania problemu, ale też dowodu – konkretnej ścieżki wykonania, niespełnionego wymagania, przykładu wejścia prowadzącego do błędu albo reprodukcji.

Wykorzystajmy wcześniejsze błędy jako zestaw ewaluacyjny

Anthropic opisuje praktykę, w której historyczne PR-y prowadzące do incydentów, regresji lub wycofania zmian stają się zestawem ewaluacyjnym dla reviewera. Można wtedy sprawdzić, czy nowa konfiguracja wykrywa problemy, które wcześniej trafiły na produkcję.

Da się to zrobić w znacznie mniejszej skali. Wybieramy kilkadziesiąt wcześniejszych zmian: potwierdzone defekty, poprawne implementacje, regresje wykryte na produkcji, problemy z autoryzacją i kontraktami API. Uruchamiamy na nich różne konfiguracje reviewera – pojedynczy model, kilka wyspecjalizowanych agentów, proces z dodatkową weryfikacją ustaleń – i oceniamy je według tych samych zasad.

Nie trzeba od razu budować platformy ewaluacyjnej. Na początek wystarczy niewielki, reprezentatywny zestaw przypadków i jasne kryteria.

Feedback loop dla AI Code Review

W artykule o pętlach informacji zwrotnej dla agentów AI pisałem, że agent potrzebuje wiarygodnej informacji o rezultacie swoich działań. Reviewer też.

Załóżmy, że zmiana przechodzi Code Review, testy i wszystkie Quality Gates, a mimo to powoduje regresję na produkcji. Analiza incydentu pokazuje, że agent reviewer nie zauważył błędnego zachowania w określonym scenariuszu.

Najpierw ustalamy, dlaczego problem umknął. Może reviewer nie dostał kontekstu. Może testy nie obejmowały scenariusza. A może wymaganie było niejednoznaczne.

Potem przypadek trafia do zestawu ewaluacyjnego. Przy kolejnej zmianie modelu, promptu lub reguł review sprawdzamy, czy system wykrywa ten defekt.

Poprawić można nie tylko agenta, ale cały proces weryfikacji. Jeśli podobny problem da się wykryć deterministycznym testem, lepiej dodać taki test do CI, niż liczyć, że AI za każdym razem samo go rozpozna.

Nie każdy problem znaleziony przez AI powinien na zawsze pozostać zadaniem dla AI.

Czasem wynik pracy agenta staje się podstawą prostszego i bardziej niezawodnego mechanizmu kontroli. To praktyczne zastosowanie harness engineering, o którym pisałem w artykule o Verification Engineering.

Dobry zestaw ewaluacyjny powinien zawierać nie tylko PR-y z potwierdzonymi błędami, ale też poprawne zmiany, bezpieczne wyjątki od reguł i przypadki, w których sugestia AI mogłaby wprowadzić regresję.

Ważne jest również odróżnienie wyniku offline od wpływu na produkcję. Reviewer może poprawiać recall na benchmarku, ale niekoniecznie zmniejszać liczbę incydentów w rzeczywistym systemie.

Dlatego po ewaluacji na historycznych przypadkach warto przeprowadzić pilotaż na nowych PR-ach, porównać wyniki z dotychczasowym procesem i sprawdzić, czy zysk w wykrywaniu problemów nie jest okupiony nadmiernym kosztem dodatkowej weryfikacji.

Jak mierzyć skuteczność AI Code Review?

Wdrożenie narzędzia nie oznacza jeszcze, że proces się poprawił. Oprócz precision i recall patrzyłbym na kilka innych metryk.

Human Review Time

Ile czasu ludzie faktycznie poświęcają na analizę zmian i komentarzy AI? Czy system oszczędza ich uwagę, czy dokłada im zadań?

False Positives per PR

Ile niepotrzebnych uwag pojawia się w review? Jak często agent zgłasza problem, którego nie ma?

Time to Merge

Czy automatyzacja skraca czas potrzebny na przygotowanie zmiany do merge?

Review Rounds

Ile razy agent i reviewer wracają do tej samej zmiany? Czy proces prowadzi do rozwiązania problemu, czy kręci się w kółko?

Escaped Defects

Jakie problemy nadal trafiają na produkcję mimo wszystkich kontroli?

Revert Rate / Change Failure Rate

Jak często zmiany trzeba wycofywać lub powodują problemy po wdrożeniu?

Cost per PR

Ile naprawdę kosztuje analiza? Nie tylko tokeny, ale też czas ludzi, uruchomienia CI i przygotowanie poprawek.

Warto mierzyć także review coverage, czyli odsetek zmian faktycznie poddanych analizie. Włączenie usługi nie gwarantuje, że review obejmie każdy PR – mogą obowiązywać limity kosztów, mogą zdarzać się błędy integracji albo ograniczenia konfiguracji.

Tych metryk nie analizowałbym osobno. Można skrócić czas do merge i jednocześnie zwiększyć liczbę defektów produkcyjnych. Można poprawić recall kosztem lawiny fałszywych alarmów. Ocena musi uwzględniać naraz jakość, czas i koszt.

Jak zacząć z AI Code Review bez budowania platformy?

Nie zaczynałbym od kilku agentów, własnego systemu klasyfikacji ryzyka i automatycznych approvals. Najpierw sprawdziłbym, czy AI Code Review w ogóle pomaga w konkretnym projekcie.

Krok 1. Wybierz jeden obszar

Najlepiej repozytorium, które znamy i dla którego mamy historię zmian, testy oraz informacje o wcześniejszych błędach. Może to być aplikacja API, framework Playwright albo jeden z serwisów backendowych.

Krok 2. Zdefiniuj konkretne problemy

Instrukcja “sprawdź ten kod” nie wystarczy.

Przykładowe obszary:

• API – błędy kompatybilności, autoryzacji i walidacji danych,
• Playwright – osłabianie asercji, zależności między testami, problemy synchronizacji i zarządzania danymi,
• aplikacja frontendowa – naruszenia dostępności, błędy obsługi stanów albo niezgodność interfejsu z wymaganiami.
  Krok 3. Przygotuj przypadki referencyjne

Wybierz wcześniejsze PR-y z potwierdzonymi problemami, ale też takie, które były poprawne. Reviewer powinien rozpoznawać obie sytuacje.

Krok 4. Uruchom pilotaż

Na początku AI publikuje komentarze, ale nie może zatwierdzać ani blokować zmian. Programiści weryfikują uwagi, a zespół zbiera informacje o ich przydatności.

Krok 5. Dodawaj sprawdzalne mechanizmy

Jeśli reviewer regularnie znajduje określoną klasę błędów, rozważ test, regułę analizy statycznej lub inny niezależny mechanizm.

Krok 6. Mierz efekty

Porównaj wyniki z procesem sprzed wdrożenia. Dopiero na tej podstawie decyduj, czy rozwijać rozwiązanie i zwiększać jego autonomię.

Można zacząć od gotowych funkcji GitHub Copilot Code Review albo Claude Code Review. Warto jednak porównać je na własnych przypadkach, zamiast zakładać, że jedno narzędzie sprawdzi się we wszystkich repozytoriach.

Nowe ryzyka: ataki na AI Code Review

Automatyzacja Code Review przynosi też problemy z bezpieczeństwem. Agent czyta kod, opisy PR-ów, komentarze i dokumentację – a każdy z tych elementów może zawierać nieufne dane. Jeśli dodatkowo ma dostęp do terminala, sekretów CI/CD lub narzędzi modyfikujących repozytorium, konsekwencje mogą być znacznie poważniejsze.

W czerwcu 2026 roku Microsoft Security Research opisał problem z Claude Code GitHub Action. Odpowiednio przygotowane instrukcje umieszczone w nieufnych danych GitHuba mogły skłonić agenta do odczytania informacji środowiskowych zawierających sekrety CI/CD. Anthropic wdrożył poprawkę w Claude Code 2.1.128.

To nie jedyny taki przypadek. Badanie GitInject: Real-World Prompt Injection Attacks in AI-Powered CI/CD Pipelines analizuje różne klasy ataków na agentów działających w rzeczywistych workflow CI/CD. Autorzy wskazują m.in. problemy wynikające z niewłaściwego zarządzania uprawnieniami, sekretami i nieufnymi danymi.

Nawet repozytorium Claude Code Security Reviewer ostrzega, że akcja nie jest utwardzona przeciwko prompt injection i powinna być używana tylko do zaufanych PR-ów.

Projektując własnych reviewerów, warto więc zadbać o izolację środowiska, minimalne uprawnienia, ograniczony dostęp do sekretów i kontrolę narzędzi dostępnych dla agenta. Inaczej, poprawiając bezpieczeństwo aplikacji, dokładamy do infrastruktury nowy, słabo zabezpieczony element.

Dobrym punktem wyjścia jest zasada Agents Rule of Two, opisywana przez Microsoft Security Research. W uproszczeniu: nie powinniśmy pozwalać agentowi jednocześnie przetwarzać nieufnych danych, mieć dostępu do sekretów lub wrażliwych systemów oraz wykonywać nieograniczonych działań zewnętrznych. Securing CI/CD in an agentic world: Claude Code Github action case

Reviewer analizujący PR-y od nieznanych autorów nie potrzebuje przecież uprawnień do wdrażania aplikacji ani odczytywania sekretów produkcyjnych.

Ograniczenia powinny być egzekwowane przez środowisko wykonawcze, a nie wyłącznie instrukcją dla modelu.

Co to wszystko oznacza dla QA, SDET i Test Architectów?

Moim zdaniem rozwój AI Code Review to kolejny sygnał, że praca osób odpowiedzialnych za jakość będzie coraz mocniej obejmować projektowanie całego procesu weryfikacji.

Nie chodzi o to, żeby tester zastąpił programistę w Code Review. Ani o to, żeby każdy QA budował własnych agentów. Chodzi o umiejętność odpowiedzi na kilka pytań: jakie problemy chcemy wykrywać? Jakie informacje są potrzebne, żeby je rozpoznać? Jak potwierdzić, że problem rzeczywiście występuje? Które kontrole mogą być automatyczne, a które wymagają człowieka?

Test Architect może projektować nie tylko frameworki testowe, ale też mechanizmy wspierające agentów w ocenie kodu. SDET może rozwijać narzędzia, które automatycznie reprodukują problemy zgłoszone w review. QA Engineer może pomagać w identyfikowaniu scenariuszy ryzyka, analizie fałszywych alarmów i przygotowywaniu zestawów ewaluacyjnych.

Wszystko to wymaga znajomości testowania, architektury, ryzyka i procesu wytwarzania oprogramowania. AI tej wiedzy nie eliminuje – pozwala używać jej w nowych miejscach.

W AI Code Review spotykają się wątki z kilku moich wcześniejszych artykułów. Piramida testów 2.0 porządkuje rodzaje i poziomy weryfikacji. Verification Engineering dotyczy projektowania środowiska, w którym da się sprawdzać rezultaty pracy agentów. Feedback loop dla agentów AI pokazuje, jak wyniki tych kontroli mogą kierować kolejnymi działaniami. A modele dojrzałości AI pomagają ocenić, kiedy organizacja jest gotowa na większą autonomię i jak nią zarządzać.

Podsumowanie – nie potrzebujemy więcej komentarzy, tylko lepszej weryfikacji

AI Code Review szybko się rozwija. Modele analizują duże zmiany, wykrywają błędy logiczne, wskazują potencjalne podatności i korzystają z kontekstu repozytorium. Badania pokazują jednak, że nadal mają kłopot ze złożonymi zależnościami, kontekstem biznesowym i oceną poprawnych implementacji.

Dlatego nie sprowadzałbym przyszłości Code Review do pytania, czy AI zastąpi człowieka. Ważniejsze jest, jak zaprojektować weryfikację coraz większej liczby zmian: z wyspecjalizowanymi agentami, testami automatycznymi, analizą statyczną, kontraktami, Quality Gates i monitoringiem produkcji, z intensywnością kontroli dopasowaną do ryzyka i z historycznymi problemami jako materiałem do ewaluacji reviewerów.

Code Review jest jednym ze sposobów zbierania informacji o jakości zmiany. Nie jest samo w sobie dowodem jej poprawności.

Skoro AI generuje coraz więcej zmian, coraz ważniejsze będzie nie to, ile kodu potrafimy przygotować, ale jak szybko i wiarygodnie potrafimy go zweryfikować. To zadanie dla Quality Engineering.

---

Źródła

Artykuły na jaktestowac.pl

1. Piramida testów 2.0 – co AI zmienia w testowaniu? – o zmianie tempa tworzenia kodu, strategii testów, Quality Gates i roli AI w procesie testowania.
2. Modele dojrzałości AI – postęp czy chaos? – o rozwoju organizacji od eksperymentów z AI do zarządzanej autonomii, governance i mierzenia rzeczywistych rezultatów.
3. Testy automatyczne w erze AI – czym jest Verification Engineering? – o budowaniu mechanizmów weryfikacji pracy agentów, test oracle, harness engineering i automatycznym feedbacku.
4. Agent AI może napisać kod. Ale skąd wie, że zrobił to dobrze? – o pętlach informacji zwrotnej, testach jako sensorach, evals i ograniczeniach autonomicznych procesów.

Badania i benchmarki AI Code Review

1. Microsoft Research – (When) Should a Software Factory be Lights-off? Benchmarking Code Review Agents on Bug Detection – CRBugBench, 1800 przypadków review i wyniki skuteczności agentów.
2. GitHub – ReviewBench: An open benchmark for AI code review – otwarty benchmark i metodyka pomiaru precision oraz recall.
3. Jin & Chen – Are LLMs reliable code reviewers? Systematic overcorrection in requirement conformance judgement – badanie nad nadmiernym poprawianiem kodu i weryfikacją sugerowanych zmian.
4. OpenAI – A Practical Approach to Verifying Code at Scale – automatyczna weryfikacja kodu na dużą skalę, znaczenie precision i minimalizowania niepotrzebnych komentarzy.
5. OpenAI – Custom Code Review Rules for Codex – reguły projektowe i ewaluacja ich wpływu na wykrywanie problemów.

Narzędzia i wdrożenia w praktyce

1. Anthropic – How the Claude Code team does code review – wielowarstwowa weryfikacja, ocena ryzyka, ewaluacja reviewerów i mechanizmy ograniczania liczby iteracji.
2. Anthropic – Code Review is now generally available – informacje o produkcie Claude Code Review i poziomach analizy.
3. Claude Code – Code Review Documentation – dokumentacja działania, konfiguracji i ograniczeń narzędzia.
4. Anthropic – Automate security reviews with Claude Code – automatyczna analiza bezpieczeństwa i przykłady zastosowania.
5. Intercom – AI is approving our pull requests: Here’s how we made it safe – doświadczenia z automatycznym zatwierdzaniem części pull requestów.
6. GitHub – Using GitHub Copilot Code Review – możliwości Code Review w GitHub Copilot, konfiguracja i integracje.

Kontrole deterministyczne i proces merge

1. Pact – How Pact works – testy kontraktowe i weryfikacja zgodności między konsumentami a dostawcami API.
2. Stryker Mutator – What is mutation testing? – mutation testing jako sposób badania skuteczności testów.
3. GitHub Docs – Managing a merge queue – ponowna weryfikacja połączonych zmian przed merge.
4. GitHub Docs – About protected branches – wymagane kontrole, zatwierdzenia i zabezpieczenia gałęzi.

Bezpieczeństwo CI/CD i agentów

1. Microsoft Security Research – Securing CI/CD in an agentic world – analiza prompt injection i ryzyka ujawnienia sekretów w agentowych workflow CI/CD.
2. GitInject – Real-World Prompt Injection Attacks in AI-Powered CI/CD Pipelines – badanie rzeczywistych ataków na agenty działające w pipeline’ach CI/CD.
3. NIST – Secure Software Development Framework (SSDF) – referencyjne praktyki bezpiecznego wytwarzania oprogramowania.

Raporty branżowe

1. SmartBear – The State of Software Quality and Testing 2026 – Badanie ankietowe 1436 specjalistów i liderów. AI adoption, code quality, human oversight, governance i autonomous testing. Wrzesień 2026.
2. SmartBear – Closing the AI Software Quality Gap – Wcześniejsze badanie 273 respondentów ze stycznia 2026. Punkt odniesienia dla zmian w praktykach organizacyjnych.
3. DORA – Balancing AI tensions: Moving from AI adoption to effective SDLC use – Analiza 1110 wypowiedzi inżynierów Google. Verification tax, code review, produktywność, jakość i ograniczenia AI. Marzec 2026.