Niezależne porównanie narzędzi do AI code review: protokół, który uruchomicie na własnym repozytorium

Kto skorzysta z tego przewodnika.

• CTO i szefowie inżynierii, którzy muszą wybrać jedno narzędzie do AI code review dla całej organizacji i mają do dyspozycji tylko rankingi dostawców
• Zespoły platformowe i zespoły usprawniające pracę programistów, które mają uzasadnić subskrypcję per stanowisko czymś więcej niż demo
• Menedżerowie inżynierii, których recenzenci skarżą się, że obecne narzędzie jest rozwlekłe, komentuje kod, którego nikt nie zmieniał, albo myli się z pewnością siebie
• Zespoły, które prowadzą równolegle dwa albo trzy narzędzia i płacą za wszystkie, bo nikt nie zmierzył, które zasługuje na swoje miejsce

Czego brakuje w porównaniach od dostawców

Wyszukiwanie najlepszego narzędzia do AI code review zwraca listy pisane przez firmy, które je sprzedają, a na takiej liście autor zwykle jest pierwszy. Benchmarki za tymi listami mają jeden kształt: dostawca wybiera pull requesty, dostawca wstrzykuje albo oznacza błędy, model dostawcy ocenia komentarze, a publikowaną miarą jest liczba znalezionych znanych błędów. Miarą, której te listy nie podają, jest liczba błędnych komentarzy.

Ta asymetria zgadza się z tym, co zgłaszają praktycy. W dyskusjach inżynierów o tych narzędziach powtarzają się trzy zastrzeżenia: rozwlekłość, komentarze do kodu spoza pull requesta i ustalenia opisujące zachowanie, którego kod nie ma. Wszystkie trzy dotyczą precyzji, a precyzja to liczba, której listy dostawców nie pokazują. Otwarty benchmark w tej kategorii, Code Review Bench od Martian, publikuje zbiór danych, prompty sędziego, pipeline i definicje precyzji oraz czułości. Przy starcie w lutym 2026 autorzy benchmarku podali, że żadne narzędzie nie znalazło więcej niż 63% ze 137 znanych problemów w zbiorze. Mówią też wprost, że zbiór wzorcowy zawiera błędy i że statyczny zbiór mógł zostać zobaczony przez narzędzia w treningu.

Nawet uczciwy benchmark mierzy własne repozytoria. Opublikowany zbiór to projekty open source w pięciu językach, z własnymi konwencjami i wielkością pull requestów; waszego rozkładu defektów, waszej kultury przeglądu i konfiguracji, którą naprawdę byście uruchomili, nie ma w żadnym z nich. Jedyne porównanie, które odpowiada na wasze pytanie zakupowe, to porównanie na waszym kodzie.

Decydujące miary i dlaczego trzeba je mierzyć na własnym repozytorium

Platforma analizy statycznej Google, Tricorder, ustaliła roboczą definicję szumu, której narzędzia do przeglądu kodu używają do dziś: ustalenie jest skutecznie fałszywym alarmem, jeśli programista po jego zobaczeniu nie podejmuje żadnego działania. Analizator, w którym udział takich alarmów przekracza 10%, jest wyłączany z przeglądu kodu. Ten próg mierzy się na zachowaniu programistów w jednym repozytorium, dlatego nie da się go skopiować ze strony dostawcy.

Druga liczba, która zmienia decyzję, to wpływ narzędzia na sam przegląd. Badanie przemysłowe narzędzia do przeglądu opartego na open source PR Agent (Cihan i współautorzy, ICSE SEIP 2025) objęło 4 335 pull requestów w trzech projektach: 73,8% automatycznych komentarzy zostało oznaczonych jako rozwiązane, a średni czas zamknięcia pull requesta wzrósł z 5 godzin 52 minut do 8 godzin 20 minut. Większość komentarzy została rozwiązana, a przegląd trwał dłużej. Obie liczby muszą być w arkuszu. Każda miara poniżej jest zdefiniowana raz i liczona dla każdej klasy ustalenia osobno, bo narzędzie, które ma rację o sprawdzaniu wartości pustych, a myli się o współbieżności, to dwa różne narzędzia, zależnie od tego, jakie macie defekty.

• Czułość: udział wstrzykniętych defektów, które narzędzie znalazło, dla każdej klasy osobno, żeby klasy, których narzędzie nigdy nie widzi, były nazwane, a nie uśrednione.
• Precyzja: udział komentarzy ocenionych jako trafne wśród wszystkich komentarzy, dla każdej klasy ustalenia.
• Szum na czystych pull requestach: komentarze na zmianach bez wstrzykniętego defektu, ocenione jako nietrafne albo bez działania po stronie autora, liczone na pull request.
• Udział komentarzy poza diffem: komentarze, których tematem jest kod, którego pull request nie dotknął, z osobnym oznaczeniem, czy ustalenie wynika ze zmiany.
• Zweryfikowane fałszywe ustalenia: komentarze twierdzące o kontrakcie, zachowaniu albo podatności, których kod nie ma, sprawdzone z kodem.
• Koszt na pull request z faktury. GitHub rozlicza przegląd Copilota w kredytach AI zależnych od poziomu nakładu; CodeRabbit rozlicza per programista z godzinowym limitem przeglądów (cenniki wskazane w źródłach). Ile kosztuje jeden pull request, wiadomo dopiero po przebiegu.
• Czas recenzenta: minuty, które człowiek spędza nad pull requestem z narzędziem i bez niego, oraz czas zamknięcia w tym samym oknie, mierzone w pilotażu na bieżących zmianach.

Protokół

Protokół ustala wszystko, co benchmarki dostawców zostawiają dostawcy. Zestaw pull requestów jest wasz, zamrożony, zanim uruchomi się jakiekolwiek narzędzie. Defekty wstrzykuje inżynier, który przed przebiegiem zapisuje każdy w rejestrze z klasą i lokalizacją. Czyste pull requesty to prawdziwe scalone zmiany, które drugi inżynier przeczytał ponownie i potwierdził. Każde narzędzie działa na tym samym zestawie w tym samym tygodniu, w konfiguracji, którą dokumentacja dostawcy opisuje jako zalecaną. Żadne narzędzie nie widzi komentarzy innego.

Ocena odbywa się bez znajomości autora komentarza. Komentarze są pozbawione nazwy narzędzia i formatowania, przetasowane i oceniane przez inżyniera, który zna kod, wobec rejestru wstrzykniętych defektów i samego kodu. Sędzią jest człowiek, bo opublikowane benchmarki dopasowują komentarze do poprawek modelem językowym, a sędzia z tej samej rodziny modeli co oceniane narzędzie może faworyzować jego styl. Drugi oceniający ocenia próbkę, więc zgodność między oceniającymi jest liczbą w arkuszu, a nie założeniem.

Wpływ na bieżącą pracę mierzy osobny pilotaż: przez okno przebiegu rekomendowane narzędzie komentuje bieżące pull requesty, recenzenci zapisują minuty na próbce, a czas zamknięcia porównuje się z tygodniami bazowymi przed pilotażem.

Jak uruchomić to na własnym repozytorium

Protokół jest zaprojektowany tak, żeby zespół powtarzał go bez pomocy z zewnątrz, bo odpowiedź zmienia się za każdym razem, gdy dostawca podmienia model. Wielkość zestawu wynika z liczby klas defektów do pokrycia i z pewności, jakiej potrzebujecie od wyniku. Zestaw z rejestrem defektów i czystą grupą kontrolną daje liczbę; nieoznaczone pull requesty, nawet liczne, dają tylko wrażenie.

• Weźcie pull requesty z ostatniego kwartału, które odpowiadają waszemu prawdziwemu rozkładowi wielkości i języków, a nie te najciekawsze.
• Wstrzykujcie defekty ręcznie i zapisujcie każdy przed przebiegiem: plik, linia, klasa i zdanie, które musiałby zawierać trafny komentarz.
• Zostawcie w zestawie czyste pull requesty. Bez nich szum jest niewidoczny i każde narzędzie wygląda na ostrożne.
• Skonfigurujcie każde narzędzie raz według jego dokumentacji i zamroźcie konfigurację. Strojenie w trakcie przebiegu zamienia porównanie w demo.
• Uruchomcie wszystkie narzędzia w tym samym tygodniu na tych samych commitach i zapiszcie model albo wersję, którą raportuje każdy dostawca.
• Usuńcie tożsamość narzędzia przed oceną i trzymajcie oceniającego z dala od osoby, która konfigurowała narzędzia.
• Wpiszcie koszt przebiegu do arkusza z faktury, na pull request, obok liczby defektów wykrytych za tę cenę.
• Gdy narzędzie ogłosi zmianę modelu, uruchomcie ten sam zestaw ponownie i porównajcie arkusze.

Co dostaje zespół i jak to się ma do audytu

Zlecenie kończy się dokumentem protokołu, zamrożonym zestawem z rejestrem defektów, arkuszem ocen ze zgodnością oceniających, jednym arkuszem wyników dla każdego narzędzia i rekomendacją, która nazywa narzędzie, konfigurację, niepokryte klasy defektów oraz koszt narzędzia przy waszym wolumenie. Rekomendacja mówi dlaczego, w liczbach z arkusza, żeby późniejszy zespół mógł nie zgodzić się z rozumowaniem, a nie z wnioskiem.

Narzędzie wybrane w ten sposób nadal przegląda diff. Porównanie narzędzia do AI code review z niezależnym audytem na tej stronie opisuje to, czego narzędzie nie widzi: architekturę, testy i granice zaufania całego systemu, także przed jego uruchomieniem. Arkusz wyników zasila ten audyt, bo klasy, których narzędzie nie pokrywa, biorą na siebie praktyki Audyt kodu pisanego przez AI i Pokrycie testowe.

Co może pójść nie tak i co z tym robimy.

1. 1
   Czułość na zbiorze dostawcy, precyzja na niczyim

   Benchmark dostawcy wstrzykuje błędy do pull requestów i liczy, ile z nich narzędzie znajduje. Nikt nie uruchamia tego samego narzędzia na pull requestach bez wstrzykniętego błędu, więc komentarze, które tam zostawia, czyli te, które wasi recenzenci będą czytać codziennie, nigdy nie wchodzą do wyniku. Narzędzie, które mówi najwięcej, wygrywa publikowaną liczbę, a zespół, który je kupuje, dziedziczy szum.

   Co z tym robimy

   Budujemy zestaw z czystą grupą kontrolną prawdziwych scalonych zmian przeczytanych ponownie przez drugiego inżyniera i liczymy nietrafne komentarze na czysty pull request obok czułości na wstrzykniętych defektach. Tam, gdzie w klasie ustalenia udział skutecznie fałszywych alarmów przekracza 10% (reguła Tricordera), wyłączamy tę klasę w konfiguracji narzędzia i uruchamiamy zestaw ponownie, żeby potwierdzić, ile czułości przy tym ubyło.

   Co zostaje u was: arkusz wyników dla każdego narzędzia z czułością i szumem obok siebie dla każdej klasy oraz konfiguracja, która wyłącza szumiącą klasę
2. 2
   Komentarze do kodu, którego pull request nie dotknął

   Narzędzia, które czytają całe repozytorium dla kontekstu, także je komentują. Pull request zmieniający jedną funkcję wraca z uwagami do modułu wokół niej, a recenzent nie umie z komentarza rozpoznać, czy ustalenie dotyczy zmiany, czy kodu, który jest na produkcji od dwóch lat. Narzędzie robi to, na co pozwala mu okno kontekstu; procesowi przeglądu nikt nie powiedział, żeby się tego spodziewał.

   Co z tym robimy

   Każdy komentarz w arkuszu ocen oznaczamy tym, czy jego temat leży w diffie i czy ustalenie wynika z tej zmiany, bo uwaga do niezmienionej linii bywa skutkiem zmiany obok. Raportujemy udział komentarzy poza diffem dla każdego narzędzia i testujemy opcje konfiguracji ograniczające zakres, które dokumentuje każdy dostawca. Ustalenia poza diffem, które są prawdziwe i nie wynikają ze zmiany, trafiają na osobną listę zadań dla właściciela utrzymania, a nie do pull requesta.

   Co zostaje u was: udział komentarzy poza diffem dla każdego narzędzia przed konfiguracją i po niej oraz lista zweryfikowanych ustaleń poza diffem z właścicielem
3. 3
   Ustalenie opisujące zachowanie, którego kod nie ma

   Komentarz czyta się jak precyzyjny raport o defekcie: funkcja, która rzekomo ignoruje błąd, nagłówek, który rzekomo nie jest walidowany. Kod nie robi żadnej z tych rzeczy, ale zdanie jest płynne i konkretne, więc autor spędza dwadzieścia minut na udowadnianiu, że czegoś nie ma, albo, gorzej, zmienia działający kod, żeby zadowolić komentarz. Inżynierowie opisują to jako zmyślanie przez narzędzie i jest to najdroższy rodzaj pomyłki, bo najbardziej przypomina trafienie.

   Co z tym robimy

   Oceniamy wobec kodu, a nie wobec komentarza, więc zweryfikowane fałszywe ustalenie jest osobną klasą w arkuszu z własnym licznikiem dla każdego narzędzia. Najbardziej przekonujące błędne ustalenia z przebiegu zachowujemy jako zestaw szkoleniowy dla recenzentów, żeby zespół nauczył się, jak wygląda pewne siebie i błędne z tego narzędzia, zanim ono wejdzie do użycia.

   Co zostaje u was: liczba zweryfikowanych fałszywych ustaleń dla każdego narzędzia na sto komentarzy oraz opisany zestaw najbardziej przekonujących błędnych ustaleń z przebiegu
4. 4
   Model oceniający model z własnej rodziny

   Opublikowane benchmarki dopasowują komentarze narzędzi do poprawek ludzi modelem językowym, bo ręczna ocena tysięcy komentarzy jest wolna. Sędzia z tej samej rodziny modeli co oceniane narzędzie może faworyzować jego styl, a wynik przesuwa się razem z wersją modelu sędziego. Zespół, który kopiuje liczbę, nie umie powiedzieć, ile w niej było sędziego.

   Co z tym robimy

   Oceniamy bez znajomości autora komentarza, inżynierem, który zna kod, a drugi inżynier ocenia próbkę, więc zgodność między oceniającymi jest mierzona dla każdej klasy. Tylko tam, gdzie zgodność jest wystarczająco wysoka, pozwalamy modelowi wstępnie posortować komentarze, a jego sortowanie sprawdzamy z ludzką próbką, zanim zostanie policzone.

   Co zostaje u was: zgodność oceniających dla każdej klasy na próbce oraz reguła, kiedy wolno użyć wstępnego sortowania modelem
5. 5
   Rozwiązane komentarze rosną, czas przeglądu rośnie, nikt nie patrzy na drugą liczbę

   Badanie przemysłowe narzędzia do przeglądu opartego na PR Agent znalazło 73,8% automatycznych komentarzy oznaczonych jako rozwiązane i czas zamknięcia pull requesta wydłużony z 5 godzin 52 minut do 8 godzin 20 minut. Dashboard z rozwiązanymi komentarzami czyta się jak sukces; czas zamknięcia siedzi w innym narzędziu. Recenzenci odczuwają opóźnienie, dashboard go nie pokazuje.

   Co z tym robimy

   W pilotażu na bieżących pull requestach zapisujemy minuty recenzentów na próbce i bierzemy czas zamknięcia z systemu kontroli wersji dla okna pilotażu i tygodni bazowych przed nim. Narzędzie, które wydłuża czas zamknięcia, rekomendujemy tylko tam, gdzie wykrywa defekty w klasach ważnych dla zespołu, a rekomendacja podaje wprost, ile opóźnienia przypada na wykryte defekty.

   Co zostaje u was: minuty recenzentów i czas zamknięcia dla każdego narzędzia wobec punktu bazowego, obok defektów wykrytych za każdą dodaną godzinę

Co zostaje u was.

• Dokument protokołu: budowa zestawu, zasady wstrzykiwania defektów, zamrożenie konfiguracji, procedura oceny bez znajomości autora, definicje miar i progi
• Zamrożony zestaw pull requestów z rejestrem wstrzykniętych defektów (plik, linia, klasa, oczekiwane ustalenie) i czystą grupą kontrolną z potwierdzeniem drugiego czytającego
• Arkusz ocen z każdym komentarzem, jego klasą, werdyktem i oceniającym; zgodność oceniających dla każdej klasy na próbce
• Arkusz wyników dla każdego narzędzia: czułość i precyzja dla każdej klasy, szum na czystych pull requestach, udział komentarzy poza diffem, liczba zweryfikowanych fałszywych ustaleń, koszt na pull request, minuty recenzentów i czas zamknięcia wobec punktu bazowego
• Rekomendacja z uzasadnieniem: narzędzie, konfiguracja, niepokryte klasy defektów oraz koszt narzędzia przy waszym wolumenie
• Instrukcja ponownego przebiegu, żeby zespół powtórzył pomiar po zmianie modelu u dostawcy i porównał arkusze

Jak pracujemy.

1. 1
   1. Zakres i budowa zestawu

   Uzgadniamy klasy defektów ważne dla waszego kodu, wybieramy pull requesty z waszej niedawnej historii, wstrzykujemy defekty i piszemy rejestr, a drugi inżynier potwierdza czystą grupę kontrolną. Nic nie rusza, dopóki zestaw nie jest zamrożony.

   Tydzień 1
2. 2
   2. Przebiegi narzędzi

   Konfigurujemy każdego kandydata według jego dokumentacji, zapisujemy model albo wersję, którą raportuje, uruchamiamy wszystkie na tych samych commitach w tym samym tygodniu i zbieramy każdy komentarz razem ze zużyciem kredytów albo fakturą za przebieg.

   Tydzień 2
3. 3
   3. Ocena i pilotaż

   Usuwamy tożsamość i formatowanie z komentarzy, oceniamy je wobec kodu i rejestru, a drugi inżynier ocenia próbkę. Równolegle biegnie pilotaż na bieżących pull requestach, z minutami recenzentów i czasem zamknięcia wobec punktu bazowego.

   Tydzień 2-3
4. 4
   4. Wyniki i rekomendacja

   Składamy arkusz wyników dla każdego narzędzia. Tam, gdzie liczby tego wymagają, uruchamiamy zestaw ponownie z wyłączonymi szumiącymi klasami. Przekazujemy rekomendację, protokół, rejestr i instrukcję ponownego przebiegu.

   Tydzień 3-4, zależnie od liczby narzędzi i klas

Pozostałe strony z tej serii.

Usługi, które to wdrażają.

Skąd pochodzą daty i liczby.

• Martian, Code Review Bench v0: niezależny benchmark narzędzi do AI code review, otwarty zbiór i pipeline, deklarowane ograniczenia zbioru wzorcowego
• withmartian/code-review-benchmark na GitHubie: 50 PR-ów z 5 projektów open source, 137 komentarzy wzorcowych przy starcie w lutym 2026 i 173 po późniejszych zmianach, definicje precyzji i czułości, zastrzeżenie o wycieku do danych treningowych
• Cihan i in., Automated Code Review In Practice (ICSE SEIP 2025, arXiv 2412.18531): 4335 PR-ów, 73,8% rozwiązanych komentarzy, czas zamknięcia z 5 h 52 min do 8 h 20 min
• Zhang i in., Code Review Agent Benchmark (arXiv 2603.23448): agenci przeglądu rozwiązują około 40% zadań wyprowadzonych z ludzkich przeglądów
• Software Engineering at Google, rozdział 20, Static Analysis: definicja efektywnie fałszywego ustalenia, próg 10%, sygnały Not useful i Please fix
• GitHub Docs, Copilot code review: rozliczanie w kredytach AI według poziomu wysiłku, kontekst całego repozytorium, brak gwarancji wykrycia wszystkich problemów
• Cennik CodeRabbit: rozliczanie per deweloper z limitem przeglądów na godzinę, darmowe przeglądy dla repozytoriów publicznych
• Przykład rankingu pisanego przez dostawcę: CodeRabbit o swojej pozycji w benchmarku Martian
• Przykład rankingu pisanego przez dostawcę: Kilo o tym samym benchmarku, z własnym narzędziem na pierwszym miejscu