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

Dla kogo jest ten przewodnik.

• CTO i szefowie inżynierii, którzy mają wybrać jedno narzędzie do AI code review dla całej organizacji, a do ręki dostają wyłącznie rankingi pisane przez dostawców
• Zespoły platformowe i developer experience, od których ktoś chce uzasadnienia abonamentu per stanowisko czymś więcej niż demem
• Kierownicy inżynierii, których reviewerzy skarżą się, że obecne narzędzie jest gadatliwe, komentuje kod, którego nikt nie zmieniał, albo myli się z pełnym przekonaniem
• Zespoły, które mają włączone dwa albo trzy narzędzia naraz i płacą za wszystkie, bo nikt nie zmierzył, które zarabia na swoje stanowisko

Dlaczego porównania dostawców nie są porównaniami

Wyszukiwanie najlepszego narzędzia do AI code review zwraca listy pisane przez firmy, które te narzędzia sprzedają, i każda lista stawia autora na pierwszym miejscu. Benchmarki stojące za tymi listami mają jeden kształt: dostawca wybiera pull requesty, dostawca zaszywa albo etykietuje błędy, model dostawcy ocenia komentarze, a publikowaną metryką jest liczba znalezionych błędów spośród znanych. Metryką, której nikt nie publikuje, jest liczba komentarzy, które były błędne.

Ta asymetria zgadza się z tym, co mówią praktycy. W dyskusjach inżynierów o tych narzędziach powtarzają się trzy zarzuty: gadatliwość, komentowanie kodu spoza pull requesta i ustalenia opisujące zachowanie, którego kod nie ma. Wszystkie trzy są skargami na precyzję, a precyzja jest liczbą, której w rankingach brakuje. Jedyny benchmark w tej kategorii, który publikuje zbiór danych, prompty sędziego i cały pipeline na otwartej licencji, Code Review Bench firmy Martian, podaje, że żadne narzędzie nie znalazło więcej niż 63% znanych problemów w jego zbiorze, i mówi wprost, że zbiór wzorcowy zawiera błędy, a statyczny zbiór mógł trafić do danych treningowych narzędzi.

Nawet uczciwy benchmark mierzy własne repozytoria. Opublikowane zbiory to projekty open source w pięciu językach, z własnymi konwencjami i wielkością pull requestów; waszej mieszanki defektów, waszej kultury przeglądu i konfiguracji, którą faktycznie byście uruchomili, nie ma w żadnym z nich. Na pytanie zakupowe odpowiada tylko porównanie uruchomione na waszym kodzie.

Metryki, które rozstrzygają, i dlaczego mierzy się je per repozytorium

Platforma analizy statycznej Google, Tricorder, dała roboczą definicję szumu, której narzędzia do przeglądu kodu używają do dziś: ustalenie jest efektywnie fałszywe, jeśli po jego zobaczeniu deweloper nie podjął żadnego działania, a analizator, który przekracza 10% efektywnie fałszywych ustaleń, wypada z przeglądu kodu albo zostaje wyłączony. Ten próg mierzy się na zachowaniu deweloperów w jednej bazie kodu i dlatego nie da się go przepisać ze strony dostawcy.

Druga liczba, która zmienia decyzję, mówi, co narzędzie robi z samym przeglądem. Badanie przemysłowe narzędzia zbudowanego na otwartoźródłowym PR Agent (Cihan i in., ICSE SEIP 2025) objęło 4335 pull requestów w trzech projektach: 73,8% automatycznych komentarzy zostało rozwiązanych, a średni czas zamknięcia pull requesta wzrósł z 5 godzin 52 minut do 8 godzin 20 minut. Komentarze były brane pod uwagę, a przegląd zwolnił. Obie liczby muszą stać w arkuszu obok siebie.

• Precyzja per klasa ustaleń: narzędzie, które ma rację przy sprawdzaniu wartości pustych i myli się przy współbieżności, to dwa różne narzędzia w zależności od tego, jakie są wasze defekty.
• Czułość na zaszytych defektach per klasa, żeby klasy, których narzędzie nigdy nie widzi, były nazwane, a nie uśrednione.
• Szum na czystych pull requestach: komentarze do zmian bez zaszytego defektu, liczone na pull request.
• Udział komentarzy spoza diffu: komentarze, których przedmiotem jest kod, którego pull request nie dotknął.
• Ustalenia zweryfikowane jako fałszywe: komentarze twierdzące o kontrakcie, zachowaniu albo podatności, których kod nie ma, sprawdzone na kodzie, nie na komentarzu.
• Koszt na pull request z faktury. GitHub rozlicza przegląd Copilota w kredytach AI, których ilość zależy od poziomu wysiłku przeglądu; CodeRabbit rozlicza per deweloper z limitem przeglądów na godzinę. Ile kosztuje jeden pull request, wiadomo dopiero po przebiegu.
• Czas reviewera: minuty, które człowiek spędza nad pull requestem z narzędziem i bez niego, oraz czas zamknięcia w tym samym oknie.

Protokół

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

Ocena jest ślepa. Komentarze tracą nazwę narzędzia i formatowanie, są tasowane i oceniane wobec rejestru defektów i kodu przez inżyniera, który zna repozytorium. Sędzią jest człowiek, bo opublikowane benchmarki dopasowują komentarze do poprawek modelem językowym, a model oceniający model z tej samej rodziny ma znaną skłonność do zgadzania się z samym sobą. Drugi oceniający punktuje próbkę, więc zgodność ocen jest liczbą w arkuszu, a nie założeniem.

Jak powtórzyć pomiar 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. Konstrukcja zbioru znaczy więcej niż jego wielkość: kilkadziesiąt pull requestów z rejestrem defektów i czystą grupą kontrolną bije tysiąc nieoznaczonych, i tak samo są zbudowane otwarte benchmarki.

• Weźcie pull requesty z ostatniego kwartału, które oddają wasz realny rozkład wielkości i języków, a nie te najciekawsze.
• Zaszywajcie defekty ręcznie i zapisujcie każdy przed przebiegiem: plik, linia, klasa i zdanie, które trafny komentarz musiałby zawierać.
• Zostawcie w zbiorze czyste pull requesty. Bez nich szumu nie widać i każde narzędzie wygląda na ostrożne.
• Skonfigurujcie każde narzędzie raz, z 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ą dostawca raportuje.
• Zdejmijcie tożsamość narzędzia przed oceną, a oceniającego trzymajcie z dala od osoby, która narzędzia konfigurowała.
• Wpiszcie koszt przebiegu do arkusza z faktury, na pull request, obok czułości, którą za niego kupiliście.
• Powtórzcie ten sam zbiór, gdy narzędzie ogłosi zmianę modelu, i porównajcie arkusze.

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

Zlecenie kończy się dokumentem protokołu, zamrożonym zbiorem z rejestrem defektów, arkuszem ślepych ocen ze zgodnością oceniających, jednym arkuszem wyników na narzędzie i rekomendacją, która wskazuje narzędzie, konfigurację, klasy, których nie pokrywa, i to, ile ta luka kosztuje przy waszym wolumenie. Rekomendacja mówi dlaczego, liczbami z arkusza, więc kolejny zespół może się nie zgodzić z uzasadnieniem, a nie tylko 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, które jest na tym serwisie, opisuje to, czego narzędzie nie widzi: system, który już działa, jego architekturę, testy i granice zaufania. Arkusz wyników zasila ten audyt, bo klasy, których narzędzie nie pokrywa, to dokładnie te, które bierze na siebie audyt kodu tworzonego z AI i przegląd pokrycia testowego.

Gdzie to się psuje i co z tym robimy.

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

   Benchmark dostawcy zaszywa błędy w pull requestach i liczy, ile z nich narzędzie znalazło. Nikt nie uruchamia tego samego narzędzia na pull requestach bez zaszytego błędu, więc komentarze, które tam zostawia, czyli te, które wasi reviewerzy 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 zbiór z czystą grupą kontrolną realnych, scalonych zmian, które drugi inżynier przeczytał ponownie, i liczymy komentarze na czysty pull request obok czułości na zaszytych. Tam, gdzie klasa ustaleń spada poniżej reguły Tricordera o 10% efektywnie fałszywych, wyłączamy tę klasę w konfiguracji narzędzia i powtarzamy zbiór, żeby potwierdzić, ile czułości przy tym ubyło.

   Co zostaje u was: arkusz wyników per narzędzie z czułością i szumem obok siebie per klasa oraz konfiguracja wyłączająca hałaśliwą klasę
2. 2
   Komentarze do kodu, którego pull request nie dotknął

   Narzędzia, które czytają całe repozytorium jako kontekst, komentują też całe repozytorium. Pull request zmieniający jedną funkcję wraca z uwagami do modułu dookoła, a reviewer nie widzi po komentarzu, czy ustalenie dotyczy zmiany, czy kodu, który działa na produkcji od dwóch lat. Narzędzie robi to, na co pozwala mu okno kontekstu; proces przeglądu nigdy nie dostał informacji, że ma się tego spodziewać.

   Co z tym robimy

   Każdy komentarz w arkuszu ocen oznaczamy, czy jego przedmiot leży w diffie, raportujemy udział komentarzy spoza diffu per narzędzie i sprawdzamy opcje konfiguracji ograniczające zakres, które każdy dostawca dokumentuje. Ustalenia spoza diffu, które są prawdziwe, idą do osobnego backlogu dla właściciela utrzymania, a nie do pull requesta.

   Co zostaje u was: udział komentarzy spoza diffu per narzędzie przed konfiguracją i po niej oraz backlog zweryfikowanych ustaleń spoza diffu z właścicielem
3. 3
   Ustalenie opisujące zachowanie, którego kod nie ma

   Komentarz czyta się jak precyzyjne zgłoszenie defektu: funkcja, która rzekomo ignoruje błąd, nagłówek, który rzekomo nie jest walidowany. Kod nie robi ani jednego, ani drugiego, ale zdanie jest płynne i konkretne, więc autor spędza dwadzieścia minut na dowodzeniu, że czegoś nie ma, albo, co gorsza, zmienia działający kod, żeby zadowolić komentarz. Inżynierowie mówią o tym, że narzędzie zmyśla, i jest to najdroższy rodzaj pomyłki, bo najbardziej przypomina trafienie.

   Co z tym robimy

   Oceniamy wobec kodu, nie wobec komentarza, więc ustalenie zweryfikowane jako fałszywe jest osobną klasą w arkuszu z własną liczbą per narzędzie. Dziesięć najbardziej przekonujących błędnych ustaleń z przebiegu zachowujemy jako zestaw szkoleniowy dla reviewerów, żeby zespół nauczył się, jak wygląda pewne siebie i błędne w wykonaniu tego narzędzia, zanim pójdzie ono na produkcję.

   Co zostaje u was: liczba ustaleń zweryfikowanych jako fałszywe na sto komentarzy per narzędzie oraz opisany zestaw najbardziej przekonujących błędnych ustaleń
4. 4
   Model ocenia model z własnej rodziny

   Opublikowane benchmarki dopasowują komentarze narzędzi do ludzkich poprawek modelem językowym, bo ręczna ocena tysięcy komentarzy jest wolna. Model sędzia ocenia komentarze pisane przez model z tej samej rodziny tak, jak oceniałby kolegę: rozpoznaje frazowanie i się zgadza. Wynik przesuwa się razem z wersją modelu sędziego, a zespół, który przepisuje liczbę, nie wie, ile w niej było sędziego.

   Co z tym robimy

   Oceniamy na ślepo, inżynierem, który zna repozytorium, a drugi inżynier ocenia próbkę, więc zgodność oceniających jest mierzona per klasa. Dopiero tam, gdzie zgodność jest dostatecznie wysoka, pozwalamy modelowi wstępnie sortować komentarze, a jego sortowanie sprawdzamy na ludzkiej próbce, zanim zacznie się liczyć.

   Co zostaje u was: zgodność oceniających per klasa 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 zbudowanego na PR Agent pokazało 73,8% rozwiązanych automatycznych komentarzy i czas zamknięcia pull requesta dłuższy 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. Reviewerzy wiedzą, metryka nie.

   Co z tym robimy

   Zapisujemy minuty reviewerów na próbce pull requestów w trakcie przebiegu i bierzemy czas zamknięcia z systemu kontroli wersji dla okna przebiegu i tygodni bazowych przed nim. Narzędzie, które wydłuża czas zamknięcia, rekomendujemy tylko tam, gdzie jego czułość w klasach ważnych dla zespołu opłaca to opóźnienie, a rekomendacja mówi, ile tego opóźnienia jest.

   Co zostaje u was: minuty reviewerów i czas zamknięcia per narzędzie wobec bazy, z czułością kupioną za każdą dodaną godzinę

Co zostaje u was.

• Dokument protokołu: konstrukcja zbioru, zasady zaszywania, zamrożenie konfiguracji, procedura ślepej oceny, definicje metryk i progi
• Zamrożony zbiór pull requestów z rejestrem zaszytych defektów (plik, linia, klasa, oczekiwane ustalenie) i czysta grupa kontrolna z potwierdzeniem drugiego czytającego
• Arkusz ślepych ocen z każdym komentarzem, jego klasą, werdyktem i oceniającym; zgodność oceniających per klasa na próbce
• Arkusz wyników per narzędzie: czułość i precyzja per klasa, szum na czystych pull requestach, udział spoza diffu, liczba zweryfikowanych jako fałszywe, koszt na pull request, minuty reviewerów i czas zamknięcia wobec bazy
• Rekomendacja z uzasadnieniem: narzędzie, konfiguracja, klasy, których nie pokrywa, i ile ta luka kosztuje przy waszym wolumenie
• Instrukcja powtórzenia, żeby zespół powtórzył pomiar po zmianie modelu u dostawcy i porównał arkusze

Jak pracujemy.

1. 1
   1. Zakres i budowa zbioru

   Ustalamy z wami klasy defektów, które liczą się w waszej bazie kodu, wybieramy pull requesty z ostatniej historii, zaszywamy defekty i piszemy rejestr, a drugi inżynier potwierdza czystą grupę kontrolną. Nic nie rusza, dopóki zbiór nie jest zamrożony.

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

   Konfigurujemy każdego kandydata z 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. Ślepa ocena

   Zdejmujemy z komentarzy tożsamość i formatowanie, oceniamy je wobec kodu i rejestru, a drugi inżynier ocenia próbkę. Minuty reviewerów i czas zamknięcia zbieramy dla okna przebiegu i dla bazy.

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

   Składamy arkusz wyników per narzędzie, powtarzamy zbiór z wyłączonymi hałaśliwymi klasami tam, gdzie liczby tego wymagają, i przekazujemy rekomendację, protokół, rejestr i instrukcję powtórzenia.

   Tydzień 3-4

Pozostałe strony z tej serii.

Gdzie to zamienia się w usługę.

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, 173 komentarze wzorcowe, 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