Benchmark agentów code review: jak oceniać recenzenta i uruchomić c-CRAB na własnym kodzie

Jak ocenić, czy agent do przeglądu kodu jest dobry? Przez większość krótkiej historii tej dziedziny odpowiedź brzmiała: „zmierz, jak blisko jego komentarze są do komentarzy ludzkiego recenzenta” — co brzmi rozsądnie, dopóki nie spróbujesz tego w praktyce, ponieważ dwóch recenzentów może zgłosić ten sam problem zupełnie innymi słowami. Code Review Agent Benchmark — artykuł to arXiv:2603.23448, a zbiór danych to c-CRAB — to pierwsza poważna próba oceny recenzji na podstawie tego, co przynosi jej zastosowanie, a nie jej sformułowania. Przekształcono w nim 234 ludzkie komentarze recenzyjne w wykonywalne testy, uruchomiono czterech powszechnie używanych recenzentów — PR-Agent, Devin, Claude Code i Codex — i stwierdzono, że wszyscy czterej razem przechodzą 41,5% tych testów, „tylko około 40%”, jak to ujęto w artykule. Ta strona to instruktaż: jak odczytać ten wynik bez przeinaczeń, jak samemu uruchomić c-CRAB i co zrobić, gdy Twojego kodu nie ma w tym benchmarku.

Liczba w nagłówku to najmniej przydatna rzecz na tej stronie. Przydatne są metoda i tryby awarii: dlaczego każdy wcześniejszy schemat oceniania mierzył niewłaściwą rzecz, ile kosztuje ocena recenzji za pomocą testów wykonywalnych i dlaczego stwierdzenie, że „agenci do przeglądu wyłapują tylko 40% błędów”, jest potrójnym błędnym odczytaniem rzeczywistego wyniku. Wszystko tutaj jest społecznościowym odczytaniem opublikowanego benchmarku i doświadczeń praktyków z jego uruchamianiem — a nie wskazówkami producentów narzędzi, których dotyczy.

Dlaczego oczywiste metryki nie działają

Przed c-CRAB oceny agentów przeglądu kodu dzieliły się na niewielką liczbę rodzin, a tabela porównawcza w artykule (Tabela 1) przedstawia ich genealogię. Najstarsza z nich to nakładanie się tekstu — BLEU, ROUGE, chrF i im podobne, stosowane przez benchmarki takie jak CodeReviewer i ContextCRBench. Zgodnie z tym podejściem komentarz agenta jest dobry, gdy jego n-gramy pokrywają się z n-gramami człowieka. Podejście to załamuje się jednak w przypadku, który w przeglądzie kodu występuje na każdym kroku: ten sam defekt opisany różnymi słowami.

Studium przypadku w artykule jest najczystszym przykładem. W pull requeście w python-telegram-bot (PR #3514) zarówno ludzki recenzent, jak i Codex wskazali ten sam błąd odporności na zagnieżdżone indeksowanie. Recenzja Codexa była behawioralnie poprawna — agent kodujący, który się nią kierował, wygenerował poprawkę przechodzącą test wykonawczy. Mimo to metryki tekstowe oceniły ją na BLEU-4 0.00, ROUGE-L 7.02, chrF 20.74 i podobieństwo osadzeń 54.59. Zerowe nakładanie się n-gramów, a recenzja była słuszna. Ta sama obawa, inne słowa: metryki łańcuchowe nie mogły jej dostrzec. Podobieństwo osadzeń to częściowy krok naprzód — 54.59 wobec potwierdzonego przejścia wciąż daleko do użytecznego progu — i dziedziczy ten sam problem w łagodniejszej formie.

LLM jako sędzia, gdzie model porównuje recenzję agenta z recenzją człowieka i głosuje, rozwiązuje problem słownictwa, ale wprowadza trzy nowe, które artykuł wprost nazywa: stronniczość, niestabilność i wrażliwość na konstrukcję promptu. Przeprowadź to samo porównanie dwa razy, a sędzia może wydać ci różne werdykty; przeformułuj prompt sędziowski, a rankingi się przesuną. Gdy wybierasz między dwoma recenzentami, którzy na tym samym benchmarku różnią się o trzy punkty, sędzia o takiej zmienności nie może poprzeć decyzji — a wynik, którego nie można odtworzyć, nie jest wynikiem.

Co daje wykonywalna wyrocznia — i ile kosztuje

Idea, na której zbudowano c-CRAB, jest prosta i radykalna zarazem: zamiast pytać „czy recenzja brzmi jak ludzka?”, pytamy „czy jeśli zastosujesz się do recenzji, kod zostanie naprawiony?”. Każdy zachowany komentarz z ludzkiej recenzji jest przekształcany w wykonywalny test, który oddaje sedno problemu. Komentarz recenzji uznaje się za poprawny, jeśli działanie na jego podstawie prowadzi do behawioralnie poprawnej poprawki, która sprawia, że test przechodzi — a każda instancja jest dostarczana z gotowym do uruchomienia środowiskiem Docker, dzięki czemu „sprawia, że test przechodzi” jest faktem, a nie oceną.

Artykuł definiuje dwa rodzaje testów. Testy behawioralne „importują i wykonują testowany kod w czasie działania”, wywołując funkcje „z konkretnymi danymi wejściowymi” i sprawdzając „wyniki lub weryfikując wyjątki”. Testy strukturalne „badają 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%) — i ta dysproporcja zasługuje na szczere zdanie: większość tej wyroczni to dopasowywanie wzorców w tekście źródłowym, a nie wykonywanie kodu. Złotym standardem jest test behawioralny; większość zbioru danych stanowi jego pragmatyczna wersja.

Budowa wyroczni to czteroetapowy lejek, a każdy etap coś odrzuca:

• Początkowy zbiór danych — 671 PRs, 1,313 komentarzy z przeglądu.

• Filtrowanie recenzji — 410 PR-ów, 595 komentarzy. Klasyfikator LLM, skalibrowany względem złotego zestawu 100 ręcznie oznaczonych komentarzy, zatrzymuje tylko obiektywnie weryfikowalne problemy i odrzuca konwersacyjne lub subiektywne opinie.

• Budowa środowiska wykonawczego — 410 PR-ów, 595 komentarzy. Jeden obraz Dockera na PR, przy czym w razie niepowodzenia automatyzacji rozwiązywanie zależności wraca do agenta kodującego.

• Konwersja komentarzy NL na testy — 339 PR-ów, 481 komentarzy. Wygenerowano z GPT-5.2 w pętli udoskonalania sterowanej wykonaniem (do trzech prób); test jest zachowywany tylko wtedy, gdy kończy się niepowodzeniem na wersji przed zmianą, a przechodzi na wersji po zmianie.

• Walidacja z agentem kodującym — 184 PR-y, 234 komentarze (finalnie). Claude Code na backendzie Sonnet-4.6 próbuje naprawić kod, mając do dyspozycji wyłącznie komentarz z przeglądu ludzkiego; przypadki, w których nie udaje mu się zaliczyć testu, są odrzucane.

Przetrwa około 27% początkowych pull requestów. Trzeba to powiedzieć wprost, bo to uczciwa cena wyroczni opartej na testach: jeśli komentarz nie jest na tyle konkretny, by stać się niezaliczonym testem, albo środowiska nie da się zbudować, albo kompetentny agent programistyczny nie potrafi naprawić kodu na podstawie samego komentarza, instancja jest odrzucana. To również powód, dla którego benchmark jest mały. 184 instancje pull requestów i 234 zwalidowane komentarze to zbiór danych, który można przeczytać, a nie korpus, w którym można utonąć — a dla wyroczni, która musi uruchamiać prawdziwe środowiska Docker, małość to zaleta.

Dla skali: przeciętny przypadek obejmuje 418,1 zmodyfikowanych linii, testy mają średnio 31,8 linii, a na jeden przypadek przypada 1,27 testów. Dwóch anotatorów zgodziło się w 84% przypadków — na podstawie 50 próbkowanych przypadków — co do tego, czy wygenerowany test wiernie oddał zastrzeżenie recenzenta.

Jedną bibliograficzną niedogodnością, na którą natkniesz się, jeśli sam przeczytasz artykuł, jest to, że tabela z danymi (Tabela 4) wymienia 67 repozytoriów, podczas gdy sekcja Threats to Validity mówi o „184 instancjach pull requestów z 234 weryfikowalnymi oracle’ami w 56 repozytoriach”. Artykuł podaje obie liczby w różnych miejscach i nie godzi ich ze sobą. Nie wybieraj żadnej z nich ani nie uśredniaj — cytuj każdą tam, gdzie występuje. Tego typu rozbieżności to właśnie szczegóły, na podstawie których czytelnicy decydują, czy benchmark jest wart ich czasu.

W ramach należytej staranności w kwestii niezależności: artykuł ujawnia, że jeden z autorów jest powiązany z SonarSource, i stwierdza, że wyników nie należy interpretować jako „oceny jakości produktów SonarSource”. To jest ich zastrzeżenie, zacytowane, a nie sparafrazowane.

Jak odczytać wynik w c-CRAB bez jego przeinaczania

Najważniejszą metryką jest wskaźnik zdawalności: dla każdej instancji udział testów tego PR, które przechodzą, uśredniony dla 184 instancji. Oto pełna tabela wyników z artykułu, jeden wiersz na recenzenta. Wiersz z człowiekiem jest raczej punktem odniesienia niż konkurentem — to ludzie napisali orakulum, więc uzyskują 100% z definicji:

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

• Devin — 1,344 komentarzy, 7.3 na PR, ogółem 24.8% (behawioralne 31.0%, strukturalne 23.4%).

• PR-Agent — 524 komentarze, 2,8 na PR, ogółem 23,1% (behawioralne 38,1%, strukturalne 19,8%).

• Codex — 324 komentarze, 1,8 na PR, ogółem 20,1% (behawioralne 38,1%, strukturalne 16,1%).

• Człowiek — 234 komentarze, 1,3 na PR, 100% z założenia.

Trzy poprawki, ponieważ „tylko około 40%" z abstraktu to obecnie najczęściej przeinaczana liczba w tej części rozmów o koderach AI. Po pierwsze, wynik 41,5% — 97 z 234 testów zaliczonych przez co najmniej jedno narzędzie — to suma zbiorcza wszystkich czterech recenzentów: test liczy się raz, jeśli zaliczył go jakikolwiek agent. Żaden pojedynczy agent nie uzyskał 41,5%; najlepszy pojedynczy wynik to 32,1% Claude Code'a. Po drugie, wiersz z wynikami człowieka to wyrocznia, a nie uczestnik; powtarzanie, że „ludzie pokonują boty", to błąd kategorii. Po trzecie, i najważniejsze: c-CRAB nie przyznaje punktów za rzeczywisty problem, którego recenzent-człowiek nie zgłosił. Wyrocznia to intencja ludzkiej recenzji. Agent, który znajdzie prawdziwy błąd, o którym nikt nie wspomniał, otrzymuje za to zero punktów. Zatem „agenci recenzujący AI wykrywają tylko 40% błędów" jest błędne na trzy sposoby — to suma zbiorcza, to nie wskaźnik wykrywania błędów, i mierzy zgodność z recenzentami-ludźmi, a nie całkowitą poprawność.

Liczba komentarzy to pułapka.

Najciekawszą liczbą w wynikach nie jest zwycięzca. Claude Code i Devin opublikowały po ponad 1300 komentarzy — około 7,3 na PR — aby osiągnąć 32,1% i 24,8%. Codex opublikował 324 komentarze, około 1,8 na PR, i osiągnął 20,1%. Dla człowieka średnia bazowa to 1,3 komentarza na PR. Ilość to nie pokrycie: mniej więcej pięć razy więcej komentarzy daje znacznie mniej niż podwójny wskaźnik zaliczeń. Jeśli wybierasz recenzenta, prawdziwym kosztem tych wszystkich dodatkowych komentarzy jest zmęczenie człowieka przeglądającego kod — każdy komentarz opublikowany przez agenta to ocena, którą człowiek musi rozpatrzyć.

Wniosek dotyczący użyteczności działa w drugą stronę i to właśnie ten element sprawia, że nie jest to tania historyjka w stylu „boty są hałaśliwe”. Autorzy ręcznie przejrzeli 92 komentarze w 6 PR-ach i ocenili 84% (77/92) jako przydatne — PR-Agent 94%, Codex 88%, Devin 85%, Claude Code 78%. Więc większość komentarzy, które nie zdają testu, to nie szum; dotyczą one czegoś, czego ludzki recenzent nie poruszył. Próba jest mała — 92 komentarze, 6 PR-ów — i warto o tym powiedzieć jednym tchem obok tych procentów.

To, o czym faktycznie mówią obie strony, wyjaśnia kształt wyników. Recenzenci-ludzie skłaniali się ku utrzymywalności, projektowaniu i dokumentacji; narzędzia ku niezawodności, testowaniu i obsłudze błędów. Artykuł odczytuje to jako argument za współpracą człowieka z agentem, a nie zastąpieniem go — a jest to również najlepsze dostępne wyjaśnienie, dlaczego wyniki wyglądają na niskie. Recenzent, który jest bystry w kwestii przypadków brzegowych, ale milczy na temat projektu, będzie systematycznie pomijać kategorie wskazywane przez ludzi, a wyrocznia zbudowana jest w całości z ludzkich wskazań.

Praktycy, którzy przez to przeszli, dochodzą do tego samego miejsca. Szczegółowy artykuł Daniela Vaughana, który określa to przedsięwzięcie jako CR-bench, dochodzi do tego samego wniosku i zamienia je w przepływ pracy: pozwól agentowi przeprowadzić przegląd solidności i poprawności, pozostaw ludzi przy projektowaniu, konwencjach i architekturze — kategoriach, w których agenci wypadają najgorzej — i kieruj agentem za pomocą instrukcji przeglądu, które wymieniają słabe kategorie. Jego najbardziej przydatna uwaga dla każdego, kto czyta ranking: „użyteczność to nie to samo co wskaźnik zaliczeń", ponieważ zestaw testów wymaga dopasowania do zamierzonej przez człowieka poprawki, a poprawna alternatywna poprawka nie zdaje testu. Według niego droga od 20% do znacząco wyższego wyniku to nie ulepszenie modelu — to praca nad konfiguracją.

Uruchamianie c-CRAB samodzielnie

Wszystko powyżej to czytanie cudzych wyników. Pakiet reprodukcyjny umożliwia uruchomienie benchmarku — znajduje się pod adresem c-CRAB-Benchmark/dataset w serwisie GitHub — a plik README uczciwie opisuje, czego to wymaga.

Wymagania: code>uv sync/code>; Docker; oraz jedno z code>OPENAI_API_KEY/code> lub code>ANTHROPIC_API_KEY/code> (Claude Code dodatkowo odczytuje poświadczenia z code>~/.claude/.credentials.json/code>, domyślnie montowanego do kontenerów). Struktura składa się z pięciu katalogów: code>pipeline//code> (logika potoku i prompty), code>execution//code> (narzędzia do budowania obrazów Dockera i pomocnicze narzędzia środowiska uruchomieniowego), code>results_preprocessed//code> (wydany podzbiór benchmarku), code>results_pipeline_funnel//code> (pliki JSONL etapów 0–4 i podsumowanie lejka) oraz code>raw_results_compressed//code> (surowe wyniki eksperymentów). Pięć kroków, w kolejności:

1. Zbuduj środowiska Docker — code>uv run python -m execution.build_swe_care --split test --instance results_preprocessed/instance-ids.txt --max-workers 4/code>. Gotowe obrazy są również publikowane w organizacji pakietów GitHub c-CRAB-Benchmark, jeśli wolisz pominąć budowanie.

2. Wygeneruj testy — code>./run_testgen_full.sh --instances-file results_preprocessed/instance-ids.txt --workers 4 --output-dir results_testgen/code>.

3. Zbierz recenzje bazowe — code>uv run python run_batch_baselines.py --split test --instances-file results_preprocessed/instance-ids.txt --tools pr-agent devin claude-code codex --output-dir baselines_output --workers 4/code>. Skonfiguruj poświadczenia odpowiednich narzędzi zewnętrznych przed tym krokiem.

4. Uruchom rozwiązywanie agentów — code>uv run python run_batch_agent_resolution.py --stage3-file results_pipeline_funnel/stage3_testgen_verified.jsonl --testgen-dir results_testgen --output-dir results_agent_resolution --workers 4/code>.

5. Oceń — powtórz raz dla każdego narzędzia: code>uv run python run_batch_tool_eval.py --tool pr-agent --stage3-file results_pipeline_funnel/stage3_testgen_verified.jsonl --testgen-dir results_testgen --tool-results-dir baselines_output --output-dir results_eval_pr-agent --workers 4/code>.

Dwie rzeczy, o których README nie wspomina. Dodanie piątego recenzenta wymaga edycji pliku code>run_batch_baselines.py/code> — to tam znajdują się prompty bazowej recenzji dla poszczególnych narzędzi i nie ma żadnego interfejsu wtyczek; README nie dokumentuje żadnego czystszego punktu rozszerzeń. Repozytorium nie zawiera też jawnego pliku licencji, więc nie zakładaj, że kod jest na licencji MIT lub Apache — artykuł jest na CC BY 4.0, a warunki licencyjne samego kodu nie są określone.

Koszt to druga nieujawniona kwestia. Artykuł nie podaje żadnych liczb dotyczących tokenów ani dolarów za uruchomienie potoku, więc każdą liczbę kosztów, którą zobaczysz w sieci, traktuj jako niezweryfikowaną. To, co wynika ze struktury, jest wystarczająco jasne: jeden obraz Dockera na PR w 184 instancjach, plus przejście rozwiązywania zadań przez agenta kodującego i przejście ewaluacyjne dla każdego narzędzia. To nie jest popołudnie na laptopie — trzeba przeznaczyć budżet na prawdziwą moc obliczeniową.

Gdy nie możesz sobie pozwolić na wykonywalne wyrocznie.

Uczciwe stanowisko większości zespołów jest takie: benchmark ma rację, że sędzia LLM nie może oceniać recenzji, ale zbudowanie wyroczni opartej na testach dla własnych PR-ów to duże wyzwanie. Warto rozróżnić sędziego LLM jako oceniającego od sędziego LLM jako filtra. Odrzucenie przez c-CRAB sędziego jako wyroczni nie czyni sędziego bezużytecznym w recenzencie — sędzia, który grupuje zduplikowane ustalenia i odrzuca słabe, może nadal zwiększyć precyzję. Trybem awarii, przed którym należy się zabezpieczyć, jest niezależność.

Sędzia działający na modelu samego recenzenta zgadza się z samym sobą: czyta recenzję, uznaje ją za wiarygodną i raportuje sukces, niczego nie zmieniając. Sędzia od innego dostawcy ogranicza tę samozgodność — nie zamienia sędziego w test, ale powstrzymuje automatyczne przystawianie pieczątki. Możemy pokazać konkretny, weryfikowalny przykład dokładnie tego zabezpieczenia, ponieważ nasze własne środowisko testowe jest otwarte: Orca-Code-Review na GitHubie jest na licencji MIT, a jego przepis routingu podaje tę zasadę słowami samego repozytorium — sędzia „NIE MOŻE WYMIENIAĆ NAZWY DOMYŚLNEGO MODELU”, ponieważ „na modelu samego recenzenta zgadza się z samym sobą, więc przejście staje się bezczynne, wciąż raportując sukces”. Akcja nigdy nie wymienia nazwy modelu; decyduje przepis. Zgodnie z konfiguracją domyślnym recenzentem jest deepseek/deepseek-v4-flash-0731, a reguła, która dopasowuje code>x-cr-lens: judge/code> jako nagłówek, wysyła werdykt sędziego do z-ai/glm-5.3 — innego dostawcy. To projektowy odpowiednik argumentu c-CRAB, a nie wynik: nie jesteśmy w benchmarku i nie ma żadnego wyniku c-CRAB dla naszego recenzenta. To jednak praktyczne złagodzenie dostępne dla każdego, kto nie może zbudować wykonywalnych wyroczni, a jest tanie, gdy sędzia i recenzent mogą działać u różnych dostawców za jednym kluczem — do tego właśnie służy router. W OrcaRouter recenzent i jego sędzia to dwie linie w DSL routingu, a Ty płacisz cenę katalogową dostawcy z zerową marżą.

Kiedy twój kod nie jest w benchmarku.

184 PR-y w 56 lub 67 publicznych repozytoriach to nie twoja baza kodu i nigdy nie miała nią być. Przenośną częścią jest metoda i możesz uruchomić ją na własnej historii w znacznie mniejszej skali. Weź scalone PR-y, które miały ludzkie komentarze z przeglądu. Dla próbki tych komentarzy napisz test, który nie przechodzi przed uwzględnieniem recenzji, a przechodzi po niej — właściwość „najpierw fail, potem pass” to cała gra. Uruchom swojego kandydata na recenzenta na diffie sprzed recenzji. Następnie sprawdź, czy wprowadzenie zmian zgodnie z jego komentarzami sprawia, że test przechodzi. To, co otrzymujesz, to liczba obliczona na kodzie, który faktycznie wdrażasz, co jest warte więcej niż pozycja w rankingu. Koszt to dokładnie ta ściana, o którą rozbił się artykuł: potrzebujesz powtarzalnych środowisk dla każdego PR-a, ponieważ test, który działa tylko na twoim laptopie, nie jest wyrocznią.

Nie potrzebujesz 234 testów. Kilkanaście dobrze dobranych w pull requestach, o które wasz zespół faktycznie się spierał, powie ci więcej o twoim recenzencie niż wynik benchmarku. A równoległa analiza praktyków tej rodziny benchmarków mówi wprost o bramce: precyzja klasyfikatora LLM w ocenie, czy komentarz jest ważnym, weryfikowalnym problemem, wynosi od 66% do 85%, więc traktuj filtrowanie maszynowe jako listę wstępną i zachowaj ludzki krok arbitrażu, zanim cokolwiek stanie się testem. Ten sam artykuł zauważa, że ReviewBench od LangChain, zbudowany niezależnie na tym samym pomyśle komentarz-do-testu, odzyskuje co najwyżej około 30% swoich bazowych problemów — to ten sam przedział co 20–32% c-CRAB, i przypomnienie, że jednocyfrowe różnice w rankingach narzędzi są często mniejsze niż szum we własnym środowisku.

Jeśli w ogóle zastanawiasz się, które narzędzie do przeglądu kodu kupić, to już inne pytanie — nasz poradnik zakupu agenta do przeglądu kodu omawia bota kontra agenta, ceny za stanowisko versus za token oraz to, kiedy samodzielne hostowanie ma przewagę — a gdy już masz takie narzędzie, koszt działania środowiska do przeglądu kodu przy każdym pushu jest omówiony w naszym artykule wyjaśniającym, jak działa zautomatyzowany przegląd kodu. Ta strona dotyczy wyłącznie pomiarów, a towarzyszący jej artykuł omawia anatomię benchmarku: lejek konstrukcyjny, statystyki zbioru danych i pełną tabelę wyników.

Często zadawane pytania

Czy 41,5% to najlepszy wynik agenta? Nie. 41,5% to suma wszystkich czterech narzędzi — test liczy się raz, jeśli którekolwiek z nich go zdało. Najlepszy pojedynczy wynik należy do Claude Code i wynosi 32,1%.

Czy c-CRAB mierzy, ile błędów wychwytuje recenzent? Nie. Mierzy, jak dobrze przegląd odpowiada temu, co zgłosił ludzki recenzent, przekształconemu w testy wykonywalne. Rzeczywisty błąd, którego recenzent nigdy nie wspomniał, otrzymuje zero punktów, jakkolwiek zasadny by nie był.

Czy ludzcy recenzenci "pokonali" boty? Wiersz 100% ludzki jest samą wyrocznią — to ludzie napisali testy — więc jest to znacznik skali, a nie konkurent.

Czy c-CRAB to to samo co CR-bench?Tak. Zbiór danych to c-CRAB; niektóre zewnętrzne relacje nazywają go CR-bench, ale istnieje tylko jeden taki benchmark.

Ile kosztuje jego uruchomienie? Artykuł nie podaje danych o kosztach. Jeden obraz Dockera na PR w 184 instancjach, plus przebieg rozwiązywania przez agenta, oznacza realną moc obliczeniową — a nie popołudnie na laptopie.

Sedno sprawy

Wkład c-CRAB to nie leaderboard — to demonstracja, że recenzję można ocenić, wykonując jej zalecenia, oraz że wcześniejsze schematy oparte na podobieństwie tekstu i sędzim LLM oceniały niewłaściwą rzecz. Jeśli masz zapamiętać jedną rzecz, niech to będzie trójczęściowa korekta: 41,5% to suma, wiersz ludzki to wyrocznia, a benchmark nie przyznaje punktów za defekty, których ludzie nigdy nie zgłosili. A jeśli chcesz liczby, na której możesz działać, metoda jest przenośna — testy fail-then-pass na własnych zmergowanych PR-ach, etap rozstrzygania przez człowieka, a jeśli nie możesz zbudować wykonywalnych wyroczni, przynajmniej sędzia, którego model jest niezależny od modelu recenzenta.

Jeśli wolisz zmierzyć recenzenta, niż spierać się o niego, zacznij od środowiska testowego, które możesz przeczytać. OrcaCode Review uruchamia przegląd oraz niezależnego sędziego weryfikującego, per token, a nie per stanowisko, i każdy prompt w nim jest publiczny — dzięki czemu możesz skierować go na benchmark taki jak ten i uzyskać własny wynik zamiast naszego.