c-CRAB, бенчмарк агентов проверки кода: что он измеряет, что он обнаружил и что на самом деле означает 41.5%

Агент проверки кода и человек-ревьюер посмотрели один и тот же pull request и высказали одно и то же замечание. Следование комментарию агента исправляет ошибку; тест проходит. И каждая вычисленная авторами метрика текстового сходства оценила ревью агента как практически не связанное с ревью человека: BLEU-4 0.00, ROUGE-L 7.02, chrF 20.74, сходство эмбеддингов 54.59. Одна и та же проблема, разные слова — и стандартный способ оценки ревью не смог увидеть, что они согласны. Этот единственный пример — аргумент, стоящий за c-CRAB (произносится «see-crab»), бенчмарком Code Review Agent Benchmark, опубликованным как arXiv:2603.23448.

c-CRAB оценивает агентов рецензирования кода, а не агентов его написания. Получив pull request — который может исходить от человека или от агента написания кода, — агент рецензирования создаёт рецензию, и c-CRAB оценивает эту рецензию по тому, приводит ли её применение к поведенчески корректному исправлению. Бенчмарк создан исследователями программной инженерии Юньтуном Чжаном, Чжиюанем Паном, Имамом Нур Бани Юсуфом, Хайфэном Жуанем, Ридваном Шариффдином и Абхиком Ройчоудхури; он оценивает четыре инструмента: PR-Agent, Devin, Claude Code и Codex. Один из авторов связан с SonarSource, и в статье прямо сказано, что это означает и что не означает, её собственными словами: «Мнения и выводы, выраженные в этой статье, принадлежат только авторам и не отражают официальную политику или одобрение SonarSource. Кроме того, представленные здесь результаты независимы и не должны рассматриваться как оценка качества продуктов SonarSource».

Два примечания перед деталями. Некоторые сторонние публикации называют эту же работу «CR-bench»; это тот же бенчмарк, и на этой странице везде используется c-CRAB. Каждый график ниже — это собственный заявленный результат статьи, взятый сегодня из статьи и репликационного пакета и не перезапущенный независимо; интерпретация — наша, плюс практическое обсуждение, которое статья уже вызвала. Ничто из этого не является рекомендацией от вендоров, чьи инструменты оценивались. И если вы всё ещё решаете, стоит ли вообще запускать агента код-ревью, наш гайд покупателя по агентам код-ревью — лучшая отправная точка; эта страница о том, как измеряются эти агенты.

Почему c-CRAB оценивает обзоры с помощью тестов, а не LLM-судьи

Обычный способ оценить агента проверки кода — сравнить его рецензию с человеческой, используя LLM-as-judge или метрику текстового сходства. Авторы c-CRAB отвергают оба подхода. LLM-as-judge, утверждают они, страдает от предвзятости, нестабильности и чувствительности к промптам, что делает воспроизводимую и стабильную оценку затруднительной. А приведённый выше пример показывает, что на самом деле измеряют строковые метрики: формулировку, а не эффективность. В том pull request проекта python-telegram-bot рецензия Codex говорила то же, что и человек, а BLEU-4 и ROUGE-L не смогли этого распознать.

Итак, c-CRAB делает обратное. Каждый комментарий человека-ревьюера превращается в исполняемый тест, который отражает суть проблемы. Комментарий ревью считается корректным, если его применение приводит к поведенчески корректному исправлению — такому, которое проходит тест. Каждый экземпляр поставляется с исполняемым Docker-окружением, поэтому решение о прохождении/непрохождении принимается запуском кода, а не запросом другой модели о том, насколько похожи два текста. Вот почему это важно: задача ревью — изменить действия разработчика, и тест — единственный сигнал оценки, который измеряет это изменение напрямую.

В статье определяются два вида тестов, её собственными словами: «Поведенческие тесты импортируют и выполняют тестируемый код во время исполнения. Они вызывают тестируемые функции с конкретными входными данными и проверяют выходные результаты или подтверждают исключения. С другой стороны, структурные тесты исследуют текст исходного кода, сопоставляют образцы и проверяют API-поверхности, чтобы определить, были ли внесены желаемые изменения в код». Итоговое распределение: 42 поведенческих (17,9%) и 192 структурных (82,1%). Стоит честно признать: большая часть оракула — это сопоставление с образцом по тексту исходников, а не выполнение кода. Этот перекос — реальное ограничение, которое следует учитывать.

Как был построен бенчмарк, и сколько стоила воронка

c-CRAB построен поверх существующего набора данных inclusionAI/SWE-CARE, который поставляет pull-request-инстансы с метаданными коммитов; собственный вклад c-CRAB — это оракул, а не корпус PR. Конвейер курирования включает четыре фильтра, и каждый из них сокращает число инстансов. В статье воронка описана следующим образом:

• Исходный набор данных — 671 PR, 1 313 комментариев.

• Фильтрация отзывов — 410 PR, 595 комментариев. Классификатор на основе LLM, откалиброванный на золотом наборе из 100 вручную размеченных комментариев, сохраняет только объективно проверяемые проблемы и отбрасывает разговорные или субъективные отзывы.

• Создание исполняемого окружения — 410 PR, 595 комментариев. Один Docker-образ на каждый PR: если автоматизация не срабатывает, разрешение зависимостей переходит к кодинг-агенту.

• Преобразование комментариев на естественном языке в тесты — 339 пул-реквестов, 481 комментарий. Тесты генерируются с помощью GPT-5.2 в цикле уточнения, управляемом выполнением, где допускается не более трех попыток; тест сохраняется только в том случае, если он не проходит на исходном коде и проходит после исправления.

• Валидация с помощью кодирующего агента — 184 PR, 234 комментария. Claude Code на бэкенде Sonnet-4.6 пытается исправить код, имея только комментарий человека-рецензента; случаи, когда ему не удаётся пройти тест, отбрасываются. Это финальный набор.

Выживает около 27 % исходных пул-реквестов. Такова честная цена оракула, основанного на тестах, и это также причина того, что бенчмарк небольшой, а не разросшийся. Выживший набор: 184 экземпляра PR, 234 подтверждённых комментария к ревью, 1,27 теста на экземпляр, в среднем 418,1 изменённых строк на PR, 31,8 строк на тест. Два аннотатора независимо оценивали на 50 отобранных экземплярах, отражает ли сгенерированный тест замечание человека-ревьюера, и приходили к согласию в 84 % случаев.

Одно несоответствие, которое вы заметите при внимательном чтении: в таблице набора данных указано 67 репозиториев, тогда как в разделе об угрозах валидности сказано: “184 экземпляра pull request с 234 проверяемыми оракулами в 56 репозиториях”. В статье приведены обе цифры в разных местах, и мы не будем усреднять их или молча выбирать удобную. Читатели используют именно такие детали, чтобы судить, стоит ли бенчмарк их времени, поэтому обе цифры воспроизведены здесь так, как они опубликованы.

Результаты и как их читать

Процент прохождения — это совокупный показатель прохождения тестов: для каждого экземпляра это доля тестов данного PR, которые проходят, а итоговый показатель — среднее по всем экземплярам. В статье для каждого инструмента приводится:

• Claude Code — 1,336 комментариев, 7.3 на PR — поведенческие 38.1%, структурные 30.7%, общие 32.1%

• Devin — 1,344 комментариев, 7.3 на PR — поведенческие 31.0%, структурные 23.4%, в целом 24.8%

• PR-Agent — 524 комментария, 2.8 на PR — поведенческие 38.1%, структурные 19.8%, общие 23.1%

• Codex — 324 комментария, 1.8 на PR — поведенческие 38.1%, структурные 16.1%, общие 20.1%

• Человек — 234 комментария, 1.3 на PR — 100% по построению. Люди написали оракул, поэтому эта строка — маркер масштаба, а не конкурент.

Внимательно прочитайте эти строки, прежде чем цитировать любую из них. «Только около 40%» из аннотации — это объединение: 41,5% из 234 тестов были пройдены хотя бы одним из четырёх инструментов. Это не результат какого-либо одного агента — лучший одиночный результат у Claude Code — 32,1% — и это не означает, что четыре инструмента вместе выявили 40% реальных дефектов. В разделе ниже объясняется, почему.

Самое интересное число — не победитель. Claude Code и Devin каждый оставил более 1300 комментариев — около 7,3 на PR — чтобы достичь 32,1% и 24,8%. Codex оставил 324, примерно 1,8 на PR, чтобы достичь 20,1%. Базовый уровень человека — 1,3 комментария на PR. Посчитайте сами: примерно четырехкратный объем комментариев дает менее чем двойной процент прохождения. Объем — это не охват. Болтливый рецензент — не то же самое, что полезный, и c-CRAB — первый бенчмарк, созданный, чтобы это показать.

Полезность действует в обратную сторону

Низкие показатели прохождения воспринимаются как приговор, пока не посмотришь, что ещё измеряли авторы. Они вручную проверили 92 комментария в 6 PR и сочли 84% из них полезными (77 из 92) — PR-Agent 94%, Codex 88%, Devin 85%, Claude Code 78%. Таким образом, большинство комментариев, не проходящих тест c-CRAB, — не шум; они касаются того, чего человек-ревьюер не поднял. Выборка мала — 92 комментария, 6 PR — и в статье об этом сказано, и нам тоже стоит об этом говорить.

Та же закономерность проявляется в том, о чём говорят рецензенты. Рецензенты-люди отдавали предпочтение сопровождаемости, дизайну и документации; инструменты — надёжности, тестированию и обработке ошибок. Статья интерпретирует это как аргумент в пользу сотрудничества человека и агента, а не замены. Это также лучшее из имеющихся объяснений того, почему оценки выглядят низкими: агенты и люди часто смотрят на разные вещи, а оракул вознаграждает только список человека.

Чего не видит c-CRAB

Бенчмарк прямо говорит о своей слепой зоне, и мы тоже. c-CRAB не даёт баллов за валидную проблему, которую человек-рецензент не поднимал. Оракул — это намерение рецензента-человека: агент, находящий реальный баг, о котором никто не упомянул, получает за него ноль. В статье сказано прямо — инструменты автоматического рецензирования могут генерировать другие ценные комментарии, которые рецензенты-люди не выявили, но “как и другие существующие бенчмарки, c-CRAB не оценивает напрямую эти дополнительные комментарии.”

Это одно-единственное предложение исправляет большую часть освещения этого результата. Любой, кто цитирует “агенты ревью решают только 40%” так, будто эта цифра показывает, сколько реальных дефектов находят агенты, читает её неверно. Она показывает, сколько замечаний, поднятых людьми, агенты совместно сумели разрешить, — более узкое и гораздо более честное утверждение.

Запуск самостоятельно

Если вы хотите воспроизвести числа или добавить своего рецензента, пакет для воспроизведения доступен по адресу c-CRAB-Benchmark/dataset. README — это фактическая документация, и она честно описывает, что собой представляет этот инструмент. Установка: code>uv sync/code>; вам понадобится Docker и code>OPENAI_API_KEY/code> или code>ANTHROPIC_API_KEY/code>, а Claude Code также считывает учетные данные из code>~/.claude/.credentials.json/code>. Организация также публикует готовые Docker-образы для этих сред.

Структура: code>pipeline//code> содержит логику конвейера и промпты, code>execution//code> — сборщики Docker-образов и вспомогательные средства времени выполнения, code>results_preprocessed//code> — выпущенное подмножество бенчмарка (410 предобработанных экземпляров), code>results_pipeline_funnel//code> — JSONL-файлы этапов stage0–stage4 и сводку по воронке, а code>raw_results_compressed//code> — исходные результаты экспериментов.

Воспроизведение полного прогона состоит из пяти шагов: собрать окружения Docker (code>execution.build_swe_care/code>), сгенерировать тесты (code>run_testgen_full.sh/code>), собрать baseline-ревью (code>run_batch_baselines.py --tools pr-agent devin claude-code codex/code>), запустить решение задач агентами (code>run_batch_agent_resolution.py/code>), затем оценить (code>run_batch_tool_eval.py --tool <name>/code>). Если вы хотите добавить пятого ревьюера, учтите, что точка расширения не является плагинным интерфейсом: промпты baseline-ревью для каждого инструмента находятся в code>run_batch_baselines.py/code>, а в README не описан более чистый способ — вам придётся отредактировать этот скрипт.

Ещё два факта, прежде чем его клонировать. Статья распространяется по лицензии CC BY 4.0; на странице репозитория не указана лицензия на код, поэтому не исходите из того, что она есть. И в статье не публикуются данные о стоимости или расходе токенов для запуска бенчмарка — они не опубликованы, так что мы не собираемся их выдумывать. Что конвейер действительно подразумевает: один Docker-образ на каждый PR для 184 инстансов плюс прогон агента по решению задач — это не «полдня на ноутбуке».

Что это значит для тех, кто поставляет конвейер рецензирования.

Основной аргумент c-CRAB заключается в том, что LLM-судья является ненадежным оракулом. Если вы не можете создать исполняемые оракулы — а большинство команд не может — лучшая доступная мера — никогда не позволять судье работать на модели, которая создала рецензию. Судья, который использует ту же модель, что и рецензент, соглашается сам с собой, и процесс проверки превращается в формальность, которая тем не менее возвращает число.

Это ровно тот сбой, от которого защищает роутинговый рецепт, лежащий в основе поставляемого нами ревьюера, — и это конструктивная параллель с критикой c-CRAB, а не результат бенчмарка. Харнесс всё равно запускает LLM-судью вторым проходом: тот кластеризует находки, оценивает каждый кластер от 0 до 1 на предмет того, является ли он конкретным дефектом в этом изменении, и отбрасывает всё ниже порога. Рецепт, который им управляет, — code>recipes/orcacode-review.dsl.yaml/code> — это публичный файл. Action никогда не называет модель: он вызывает алиас роутера, а решение принимает рецепт. В поставляемой конфигурации рецепт состоит из четырёх строк — модель ревьюера по умолчанию: code>deepseek/deepseek-v4-flash-0731/code>, а правило, соответствующее заголовку code>x-cr-lens: judge/code> отправляет судейский проход на code>z-ai/glm-5.3/code> — от другого вендора. Собственные слова рецепта требуют, чтобы судья «НЕ НАЗЫВАЛ МОДЕЛЬ ПО УМОЛЧАНИЮ», потому что на собственной модели ревьюера он «согласен с самим собой, поэтому проход становится инертным, хотя и продолжает сообщать об успехе».

Судья от другого вендора снижает самосогласованность; это не превращает LLM-судью в тест. c-CRAB не тестировал нашего ревьюера, и мы не собираемся утверждать обратное.OrcaCode Review выполняет проход ревью и задействует независимого судью-верификатора, оплата за токен, а не за рабочее место, и все промпты в нём публичны — так что вы можете применить его к такому бенчмарку, как этот, и получить собственный результат вместо нашего.

Суть

c-CRAB — это первый бенчмарк для ревью кода, чью оценку в основном можно понимать буквально: ревью считается успешным, только если его применение исправляет код. Ключевые цифры действительно низкие — лучший отдельный инструмент 32.1%, объединённый результат 41.5% — но они измеряют пересечение с замечаниями, поднятыми людьми, а не качество самих ревью, и данные о полезности показывают, что большинство комментариев — реальный сигнал. Устойчивые выводы — те, которые отстаивает сама статья: объём не равен покрытию, агенты и люди смотрят на разные вещи, а правильное применение — это коллаборация человека и агента. И бенчмарк открыт, так что честный следующий шаг — прогнать на нём собственного ревьюера и получить собственный результат.