Бенчмарк v1 от CodeVetter прогоняет 27 синтетических сценариев через конвейер ревью кода на базе ИИ и фиксирует, обнаруживает ли инструмент внедренные баги. Затем он подсчитывает количество успешных и неудачных попыток для каждого случая.

Почему этот бенчмарк важен

Тест ставит узкий вопрос: сможет ли конкретный инструмент ревьюера распознать именно те дефекты, которые разработчики бенчмарка заложили в этот фиксированный набор фрагментов кода? Разработчики могут использовать результат как быструю проверку охвата проблем. Поскольку репозиторий содержит пакеты задач и скрипт оценки, любой желающий может перезапустить тест и получить те же самые цифры.

Что этот бенчмарк не доказывает

Синтетический набор из 27 сценариев не является заменой тысячам pull-запросов, с которыми команда работает ежедневно. Бенчмарк ничего не говорит о:

  • Разнообразие реальных условий — он охватывает лишь несколько языков и ограниченный набор категорий багов.
  • Производительность — он не предоставляет данных о времени выполнения или вычислительных затратах.
  • Надежность на различных кодовых базах — без тестирования на живых репозиториях мы не можем знать, будет ли инструмент пропускать тонкие дефекты или генерировать ложноположительные срабатывания в продакшене.

Сочетание опубликованных результатов с файлами инфраструктуры и обещаниями будущих «широких и реалистичных данных» создает маркетинговый нарратив о том, что единый показатель отражает готовность к использованию в продакшене, хотя сами данные этого не подтверждают.

Место этого бенчмарка в общей экосистеме тестирования

Бенчмарки на распознавание, подобные CodeVetter, определяют область возможностей инструмента. Они дополняют функциональные бенчмарки, такие как SWE-bench, которые проверяют, действительно ли патч, созданный ИИ, исправляет реальную проблему в существующей кодовой базе. Вместе они дают более полную картину: охват против эффективности.

Хороший бенчмарк для агентов должен раскрывать весь стек:

  1. Набор данных — исходные входные данные и ожидаемые результаты.
  2. Документация по каждому случаю — страница для каждого теста, демонстрирующая баг, правильное исправление и ответ инструмента.
  3. Результаты ревьюера — конкретные комментарии или предложения, созданные ИИ.
  4. Методология оценки — как оцениваются совпадения, включая допуски для частичного балла.
  5. Инструкции по воспроизводимости — фиксация версий, сведения об оборудовании и скрипты для повторного запуска теста.

Только когда все эти элементы прозрачны, мы можем доверять единому агрегированному показателю.

Ограничения, указанные в самом бенчмарке

  • Синтетические сценарии, а не взятые из живых репозиториев.
  • Узкий выбор языков и типов багов.
  • Отсутствие данных о времени или стоимости, поэтому эффективность неизвестна.
  • Ограничения точности, которые могут скрывать пограничные ошибки.

На что обратить внимание дальше

Следующим шагом для CodeVetter — и для всех, кто использует ИИ-ревьюеров — является предоставление повторяющихся доказательств на более крупных и разнообразных корпусах данных. Это означает публикацию результатов на реальных потоках pull-запросов, отчетность о задержках и потреблении вычислительных ресурсов, а также классификацию типов ошибок по категориям. Пока такие данные не появятся, относитесь к результату в 27 сценариев как к раннему индикатору, а не как к гарантии готовности.

Итог: Бенчмарк, который лишь показывает, может ли инструмент обнаружить горстку заранее написанных багов, полезен для базовой проверки (sanity-check), но он не гарантирует, что инструмент справится с более хаотичной и чувствительной к затратам реальностью ревью кода в продакшене.