c-CRAB, benchmark agentów przeglądu kodu: co mierzy, co wykazał i co naprawdę oznacza 41,5%

Agent do przeglądu kodu i ludzki recenzent przyjrzeli się temu samemu pull requestowi i zgłosili tę samą uwagę. Zastosowanie się do komentarza agenta naprawia błąd; test przechodzi. A każda metryka podobieństwa tekstu obliczona przez autorów oceniła recenzję agenta jako zasadniczo niezwiązaną z recenzją człowieka: BLEU-4 0.00, ROUGE-L 7.02, chrF 20.74, podobieństwo embeddingów 54.59. Ta sama uwaga, inne słowa, a standardowy sposób oceny recenzji nie potrafił dostrzec, że się ze sobą zgadzają. Ten jeden przykład to argument stojący za c-CRAB (wymawiane „si-krab”), czyli benchmarkiem agentów do przeglądu kodu opublikowanym jako arXiv:2603.23448.

c-CRAB ocenia agentów przeglądu kodu, a nie agentów piszących kod. Biorąc pull request — który może pochodzić od człowieka lub od agenta kodującego — agent przeglądu generuje recenzję, a c-CRAB ocenia tę recenzję pod kątem tego, czy działanie na jej podstawie prowadzi do behawioralnie poprawnej poprawki. Benchmark został stworzony przez badaczy inżynierii oprogramowania: Yuntong Zhang, Zhiyuan Pan, Imam Nur Bani Yusuf, Haifeng Ruan, Ridwan Shariffdeen i Abhik Roychoudhury, i ocenia cztery narzędzia: PR-Agent, Devin, Claude Code i Codex. Jeden z autorów jest związany z SonarSource, a artykuł wprost wyjaśnia, co to oznacza, a czego nie, własnymi słowami: „Poglądy i wnioski wyrażone w tym artykule są wyłącznie poglądami autorów i nie reprezentują oficjalnych polityk ani rekomendacji SonarSource. Ponadto przedstawione tutaj ustalenia są niezależne i nie powinny być interpretowane jako ocena jakości produktów SonarSource.”

Dwie uwagi zanim przejdziemy do szczegółów. Niektóre teksty zewnętrznych autorów nazywają to samo opracowanie “CR-bench”; to ten sam benchmark i na tej stronie konsekwentnie używamy nazwy c-CRAB. Każdy poniższy wykres to wynik zgłoszony w samej pracy, odczytany dziś z pracy i pakietu replikacyjnego — nie był niezależnie uruchamiany ponownie — a interpretacja jest nasza, wzbogacona o dyskusję praktyków, którą ta praca już wzbudziła. Żadna z tych informacji nie jest wytyczną od dostawców, których narzędzia były oceniane. A jeśli wciąż zastanawiasz się, czy w ogóle wdrożyć agenta do przeglądu kodu, nasz poradnik kupującego na temat agentów do przeglądu kodu będzie lepszym punktem wyjścia; ta strona dotyczy tego, jak mierzy się te agenty.

Dlaczego c-CRAB ocenia recenzje testami, a nie sędzią LLM

Zwykły sposób oceny agenta dokonującego przeglądu kodu polega na porównaniu jego recenzji z recenzją człowieka, przy użyciu LLM-a jako sędziego lub metryki podobieństwa tekstu. Autorzy c-CRAB odrzucają oba te podejścia. Twierdzą, że LLM jako sędzia cierpi na stronniczość, niestabilność i wrażliwość na prompt, co utrudnia powtarzalną i spójną ocenę. A studium przypadku powyżej pokazuje, co metryki tekstowe faktycznie mierzą: dobór słów, a nie skuteczność. W przypadku tego pull requesta w python-telegram-bot recenzja Codexa mówiła to samo co recenzja człowieka, a BLEU-4 i ROUGE-L nie były w stanie tego rozpoznać.

c-CRAB działa więc odwrotnie. Każdy ludzki komentarz z przeglądu kodu jest zamieniany na wykonywalny test, który oddaje sedno problemu. Komentarz z przeglądu jest uznawany za poprawny, jeśli działanie na jego podstawie daje behawioralnie poprawną poprawkę — taką, która sprawia, że test przechodzi. Każda instancja jest dostarczana z wykonywalnym środowiskiem Docker, więc decyzję o zaliczeniu lub niezaliczeniu podejmuje uruchomiony kod, a nie inny model pytany o to, jak podobne są dwa teksty. I właśnie dlatego to ważne: zadaniem przeglądu jest zmiana tego, co robi programista, a test jest jedynym sygnałem punktacji, który mierzy tę zmianę bezpośrednio.

Artykuł definiuje dwa rodzaje testów, własnymi słowami: “Testy behawioralne importują i wykonują testowany kod w czasie działania. Wywołują testowane funkcje z konkretnymi danymi wejściowymi oraz sprawdzają wyniki lub weryfikują wyjątki. Z drugiej strony testy strukturalne analizują tekst kodu źródłowego, dopasowują wzorce i sprawdzają powierzchnie API, aby ustalić, czy wprowadzono pożądane zmiany w kodzie.” Ostateczny podział to 42 testy behawioralne (17,9%) i 192 strukturalne (82,1%). Warto dodać zdanie uczciwości: większość wyroczni opiera się na dopasowywaniu wzorców w tekście źródłowym, a nie na wykonywaniu kodu. Ta dysproporcja to realne ograniczenie, o którym należy pamiętać.

Jak zbudowano benchmark i ile kosztował lejek.

c-CRAB jest zbudowany na istniejącym zbiorze danych inclusionAI/SWE-CARE, który dostarcza instancje pull requestów z metadanymi commitów; wkładem samego c-CRAB jest oracle, a nie korpus PR. Potok selekcji uruchamia cztery filtry, a każdy z nich kosztuje instancje. Artykuł przedstawia lejek w następujący sposób:

• Początkowy zbiór danych — 671 PR-ów, 1 313 komentarzy.

• Filtrowanie recenzji — 410 PR-ów, 595 komentarzy. Klasyfikator LLM, skalibrowany na złotym zbiorze 100 ręcznie oznaczonych komentarzy, zachowuje tylko obiektywnie weryfikowalne problemy i odrzuca konwersacyjne lub subiektywne opinie.

• Budowa środowiska wykonywalnego — 410 PR-ów, 595 komentarzy. Jeden obraz Dockera na PR, z rozwiązywaniem zależności przechodzącym na agenta kodującego, gdy automatyzacja zawiedzie.

• Zamiana komentarzy w języku naturalnym na testy — 339 PR-ów, 481 komentarzy. Testy są generowane przez GPT-5.2 w pętli dopracowywania sterowanej wykonaniem, z maksymalnie trzema próbami; test jest zachowywany tylko wtedy, gdy nie przechodzi na oryginalnym kodzie, a przechodzi po poprawce.

• Walidacja z agentem kodującym — 184 PR-y, 234 komentarze. Claude Code na backendzie Sonnet-4.6 próbuje naprawić kod, mając do dyspozycji wyłącznie komentarz z recenzji człowieka; przypadki, w których nie udaje mu się sprawić, by test przeszedł, są odrzucane. To ostateczny zestaw.

Około 27% początkowych pull requestów przetrwa. To uczciwa cena wyroczni opartej na testach, a także powód, dla którego benchmark jest mały, a nie rozległy. Zestaw, który przetrwał: 184 instancje PR, 234 zweryfikowane komentarze z recenzji, 1,27 testów na instancję, średnio 418,1 zmodyfikowanych linii na PR, 31,8 linii na test. Dwóch anotatorów niezależnie oceniało, czy wygenerowany test wiernie oddawał uwagę ludzkiego recenzenta, na próbie 50 instancji, i zgadzało się w 84% przypadków.

Jedną rozbieżność zauważysz, jeśli czytasz uważnie: tabela zbioru danych wymienia 67 repozytoriów, podczas gdy sekcja dotycząca zagrożeń trafności mówi “184 instancje pull requestów z 234 weryfikowalnymi wyroczniami w 56 repozytoriach.” Artykuł podaje obie liczby w różnych miejscach, a my nie zamierzamy ich uśredniać ani po cichu wybierać tej wygodniejszej. Czytelnicy właśnie na podstawie tego rodzaju szczegółów oceniają, czy benchmark jest wart ich czasu, dlatego obie przytaczamy tu w wersji opublikowanej.

Wyniki i jak je interpretować

Wskaźnik zdawalności to zagregowany wskaźnik zdawalności testów: dla pojedynczego przypadku jest to odsetek testów danego PR, które kończą się powodzeniem, a główny wynik to średnia dla wszystkich przypadków. W artykule podano, dla każdego narzędzia:

• Claude Code — 1,336 komentarzy, 7.3 na PR — behawioralne 38.1%, strukturalne 30.7%, ogółem 32.1%

• Devin — 1 344 komentarze, 7.3 na PR — behawioralne 31.0%, strukturalne 23.4%, ogółem 24.8%

• PR-Agent — 524 komentarze, 2.8 na PR — behawioralne 38.1%, strukturalne 19.8%, ogółem 23.1%

• Codex — 324 komentarze, 1.8 na PR — behawioralne 38.1%, strukturalne 16.1%, ogółem 20.1%

• Człowiek — 234 komentarze, 1,3 na PR — 100% z założenia. Ludzie napisali orakulum, więc ten wiersz jest znacznikiem skali, a nie konkurentem.

Przeczytaj uważnie te wiersze, zanim zacytujesz którykolwiek z nich. Formułowanie „tylko około 40%” z abstraktu to suma: 41,5% z 234 testów zostało zaliczonych przez co najmniej jedno z czterech narzędzi. Nie jest to wynik pojedynczego agenta — najlepszym pojedynczym wynikiem jest 32,1% Claude Code — i nie oznacza, że cztery narzędzia razem wykryły 40% rzeczywistych defektów. Poniższa sekcja wyjaśnia dlaczego.

Najciekawsza liczba to nie zwycięzca. Claude Code i Devin zamieścili po ponad 1300 komentarzy — około 7,3 na PR — osiągając 32,1% i 24,8%. Codex zamieścił 324, około 1,8 na PR, osiągając 20,1%. Bazowy poziom człowieka to 1,3 komentarza na PR. Wykonaj obliczenia: mniej więcej czterokrotna objętość komentarzy daje wynik znacznie poniżej dwukrotności zdawalności. Objętość to nie pokrycie. Gadatliwy recenzent to nie to samo co przydatny, a c-CRAB to pierwszy benchmark stworzony, aby to pokazać.

Użyteczność działa w drugą stronę.

Niskie wskaźniki zdawalności są odczytywane jako potępienie, dopóki nie spojrzy się na to, co jeszcze zmierzyli autorzy. Ręcznie przejrzeli 92 komentarze w 6 pull requestach i uznali 84% z nich za przydatne (77 z 92) — PR-Agent 94%, Codex 88%, Devin 85%, Claude Code 78%. Więc większość komentarzy, które nie przechodzą testu c-CRAB, to nie szum; dotyczą one czegoś, czego nie poruszył ludzki recenzent. Próba jest mała — 92 komentarze, 6 pull requestów — i artykuł to przyznaje, a my też powinniśmy.

Ten sam wzorzec pojawia się w tym, o czym mówią recenzenci. Ludzcy recenzenci skłaniali się ku utrzymywalności, projektowaniu i dokumentacji; narzędzia ku niezawodności, testowaniu i obsłudze błędów. Artykuł interpretuje to jako argument za współpracą człowieka z agentem, a nie zastąpieniem go. Jest to również najlepsze dostępne wyjaśnienie, dlaczego wyniki wyglądają na niskie: agenci i ludzie często nie patrzą na te same rzeczy, a wyrocznia nagradza jedynie listę człowieka.

Czego c-CRAB nie widzi

Benchmark jest jednoznaczny co do swojego ślepego punktu, a my również. c-CRAB nie przyznaje żadnych punktów za prawdziwy problem, którego ludzki recenzent nie poruszył. Wyrocznią jest intencja ludzkiej recenzji: agent, który znajdzie prawdziwy błąd, o którym nikt nie wspomniał, otrzymuje za niego zero punktów. W artykule ujęto to wprost — zautomatyzowane narzędzia do przeglądu kodu mogą generować inne cenne komentarze, których ludzcy recenzenci nie zidentyfikowali, ale “podobnie jak inne istniejące benchmarki, c-CRAB nie ocenia bezpośrednio tych dodatkowych komentarzy.”

To pojedyncze zdanie jest korektą większości relacji na temat tego wyniku. Każdy, kto cytuje “{{1}}agenci przeglądowi rozwiązują tylko 40%{{/1}}” tak, jakby mierzyło to, ile rzeczywistych defektów wykrywają agenci, błędnie interpretuje tę liczbę. Mierzy ona, ile uwag zgłoszonych przez ludzi agenci łącznie zdołali rozwiązać — to węższe i znacznie bardziej uczciwe twierdzenie.

Uruchomienie go samodzielnie

Jeśli chcesz odtworzyć wyniki lub dodać własnego recenzenta, pakiet replikacyjny jest publicznie dostępny pod adresem c-CRAB-Benchmark/dataset. README jest faktyczną dokumentacją i uczciwie opisuje, jak ta rzecz wygląda. Konfiguracja to code>uv sync/code>; potrzebujesz Dockera i klucza code>OPENAI_API_KEY/code> lub code>ANTHROPIC_API_KEY/code>, a Claude Code dodatkowo odczytuje poświadczenia z code>~/.claude/.credentials.json/code>. Organizacja publikuje również gotowe obrazy Dockera dla tych środowisk.

Układ: code>pipeline//code> zawiera logikę pipeline i prompty, code>execution//code> narzędzia do budowania obrazów Dockera i pomocnicze narzędzia uruchomieniowe, code>results_preprocessed//code> opublikowany podzbiór benchmarku (410 wstępnie przetworzonych instancji), code>results_pipeline_funnel//code> pliki JSONL stage0–stage4 i podsumowanie lejka oraz code>raw_results_compressed//code> surowe wyniki eksperymentów.

Odtworzenie pełnego przebiegu to pięć kroków: zbuduj środowiska Docker (code>execution.build_swe_care/code>), wygeneruj testy (code>run_testgen_full.sh/code>), zbierz przeglądy bazowe (code>run_batch_baselines.py --tools pr-agent devin claude-code codex/code>), uruchom rozwiązywanie przez agenta (code>run_batch_agent_resolution.py/code>), a następnie oceń (code>run_batch_tool_eval.py --tool <name>/code>). Jeśli chcesz dodać piątego recenzenta, pamiętaj, że punkt rozszerzenia nie jest interfejsem wtyczek: monity przeglądów bazowych dla każdego narzędzia znajdują się w code>run_batch_baselines.py/code>, a README nie dokumentuje prostszego sposobu — edytujesz ten skrypt.

Jeszcze dwa fakty, zanim to sklonujesz. Artykuł jest na licencji CC BY 4.0; strona repozytorium nie podaje licencji dla kodu, więc nie zakładaj jej. Artykuł nie publikuje też żadnych danych o kosztach ani zużyciu tokenów przy uruchamianiu benchmarku — to nie zostało opublikowane, więc nie będziemy tego wymyślać. To, co sugeruje pipeline: jeden obraz Dockera na PR dla 184 instancji, plus przebieg rozwiązania przez agenta, to nie jest popołudnie w skali laptopa.

Co to oznacza dla każdego, kto wdraża potok recenzji.

Głównym argumentem c-CRAB jest to, że sędzia LLM jest niewiarygodną wyrocznią. Jeśli nie można zbudować wykonywalnych wyroczni — a większość zespołów nie może — najlepszym dostępnym środkiem zaradczym jest nigdy nie pozwolić sędziemu działać na modelu, który wygenerował recenzję. Sędzia, który korzysta z tego samego modelu co recenzent, zgadza się z samym sobą, a etap weryfikacji staje się formalnością, która wciąż zwraca liczbę.

To jest dokładnie ta usterka, przed którą chroni przepis routingu stojący za recenzentem, którego dostarczamy — i jest to projektowa paralela do krytyki c-CRAB, a nie wynik benchmarku. Platforma i tak uruchamia sędziego LLM jako drugi przebieg, który grupuje wnioski, ocenia każdą grupę w skali 0–1 pod kątem tego, czy jest to konkretna wada w tej zmianie, i odrzuca wszystko poniżej progu. Przepis, który to reguluje, code>recipes/orcacode-review.dsl.yaml/code>, to plik publiczny. Akcja nigdy nie wymienia modelu z nazwy: wywołuje alias routera, a decyzję podejmuje przepis. W dostarczonej konfiguracji przepis ma cztery linie — domyślnym modelem recenzenta jest code>deepseek/deepseek-v4-flash-0731/code>, a reguła pasująca do nagłówka code>x-cr-lens: judge/code> wysyła przebieg sędziego do code>z-ai/glm-5.3/code>, inny dostawca. Sam przepis wymaga: „NIE WOLNO WYMIENIAĆ MODELU DOMYŚLNEGO”, ponieważ na własnym modelu recenzenta sędzia „zgadza się sam ze sobą, więc przebieg staje się bezwładny, a mimo to raportuje sukces”.

Sędzia od innego dostawcy zmniejsza samozgodność, ale nie zamienia sędziego LLM w test. c-CRAB nie przetestował naszego recenzenta i nie zamierzamy sugerować, że było inaczej.OrcaCode Review przeprowadza przegląd oraz niezależnego sędziego weryfikującego, za token, a nie za stanowisko, a każda podpowiedź w nim jest publiczna — więc możesz skierować go na benchmark taki jak ten i otrzymać własny wynik zamiast naszego.

Sedno sprawy

c-CRAB to pierwszy benchmark przeglądu kodu, którego wyniki można w większości traktować dosłownie: recenzja przechodzi tylko wtedy, gdy podjęcie na jej podstawie działań naprawia kod. Główne liczby są rzeczywiście niskie — najlepsze pojedyncze narzędzie: 32,1%, a łącznie: 41,5% — ale mierzą one nakładanie się na problemy wskazane przez ludzi, a nie jakość recenzji, a dane o użyteczności pokazują, że większość komentarzy to prawdziwy sygnał. Trwałe wnioski to te, za którymi opowiada się sam artykuł: ilość to nie pokrycie, agenci i ludzie zwracają uwagę na różne rzeczy, a właściwe wdrożenie to współpraca człowieka z agentem. A benchmark jest otwarty, więc uczciwym następnym krokiem jest uruchomienie na nim własnego recenzenta i uzyskanie własnego wyniku.