Как мы запустили ИИ-ревьюера на 4000 PR в день — и какие баги он находит

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

Такими руками стал NeuroReview — автоматический ревьюер пул-реквестов, который работает в продакшене и находит часть дефектов до человеческого ревью или мержа. Над продуктом работают несколько команд. За ML и качество отвечает команда Константина Моксина @kamoksin — отдельное спасибо Косте и коллегам за разработку и развитие. Мы используем NeuroReview только на внутреннем коде, подключение добровольное. Сейчас каждый день через него проходит примерно 4 тысячи пул-реквестов — около 40% от всех созданных разработчиками в Аркадии, монорепозитории Яндекса. 

Привет! Я Витя Плошихин, руководитель ML Laboratory в Yandex Infrastructure. В этой статье расскажу, как устроен внутренний сервис NeuroReview: почему ревью делают два агента, какие баги сервис ловит там, где молчат компилятор, тесты и дополнительные проверки, и как мы тестировали разные модели. 

Почему мы взялись за автоматическое ревью

Процесс ревью строился привычным способом: сначала обязательные тесты и статические анализаторы, затем ручное ревью. Автоматические проверки хорошо подходили для поиска типовых ошибок, а человек разбирался в логике изменения и контексте проекта.

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

Одного конкретного бага, после которого появился NeuroReview, не было. Триггером стал сам повторяющийся сценарий, в котором значительную часть проверок можно было выполнить автоматически, быстро и до того, как к PR подключится человек. 

Как устроен NeuroReview 

NeuroReview работает поверх Comrade — нашей платформы для запуска LLM-агентов. Процесс ревью реализован как управляемый workflow на Temporal: платформа хранит его состояние, оркестрирует этапы, обрабатывает повторные попытки и отмены. Сбор контекста, работа агентов, техническая валидация и публикация комментариев выполняются как отдельные контролируемые этапы. Comrade также предоставляет агентам инструменты для чтения кода, управляет лимитами и поддерживает A/B-эксперименты. 

Сам пайплайн — два агента, работающие в связке «генерация кандидатов → фильтрация». 

• Агент 1 — генератор. Читает дифф и нужные файлы, ищет как можно больше проблем. Его задача — не пропустить ничего важного. На момент сбора данных для статьи это Qwen 3.6 27B на нашем внутреннем инференсе. 

• Агент 2 — валидатор. Получает замечания от генератора и исходный диффсет, перепроверяет находки и отбрасывает шум: спорное, дубли, недоказанное. Его задача — повысить точность того, что в итоге попадёт в PR. Сейчас это MiniMax-M2-7. 

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

Перед публикацией каждое замечание проходит техническую проверку: агент указывает точный файл, строку и фрагмент кода, а сервис сверяет их с содержимым репозитория. Это помогает отсечь ошибки в привязке комментария к коду. Затем агент-валидатор отдельно проверяет смысловую обоснованность замечания и отбрасывает спорные находки. 

Как мы выбрали конфигурацию

Изменения в NeuroReview мы проверяем на реальном потоке с помощью A/B-экспериментов. Единицей разбиения служит PR: каждый пул-реквест детерминированно попадает в одну из групп, и все его последующие итерации проверяются той же конфигурацией. Так мы можем сравнивать модели генератора и валидатора, промпты, инструменты и их комбинации. При выборе конфигурации учитываем полезность замечаний в расчёте на PR, время ответа и стоимость обработки.

Для оценки конфигураций используем метрику Time Saved per PR (TSPR) — оценку экономии инженерного времени на один PR. Принятый code suggestion и закрытый issue добавляют оценку сэкономленного времени, а отклонённый issue — штраф за время, потраченное на лишнее замечание. Это прокси-метрика: она отражает наблюдаемую реакцию разработчика на замечание, а не фактически измеренное рабочее время. Поэтому её используем для сравнения конфигураций внутри одного продуктового контура.

Мы тестировали разные вариации. Изначально и генератором, и валидатором у нас был MiniMax-M2-7 — это и стало baseline, от которого мы начали перебирать варианты. Все приросты в таблице — относительно этого baseline. 

Среди протестированных конфигураций вариант с Opus показал самый высокий TSPR — примерно на 30% выше конфигурации с Qwen. При этом одна проверка стоила $3,42 против $0,041 — примерно в 83 раза дороже. Один PR может состоять из нескольких диффсетов: после изменений автора NeuroReview проверяет новую версию кода повторно, и каждый такой запуск оплачивается отдельно. Даже при одной проверке каждого из 4 тысяч PR стоимость составила бы около $13,7 тыс. в день, а повторные проверки увеличили бы эту сумму. Поэтому для продакшена мы выбрали Qwen: у него лучший баланс качества и стоимости.

Мы предполагаем, что Qwen помогает узкая постановка задачи: подготовленный дифф и контекст, ограничения системного промпта и структурированный формат результата. В этом эксперименте мы сравнивали две production-конфигурации целиком — модель плюс промпт, инструменты, проверки и валидатор. Отдельно вклад компонентов не измеряли. Поэтому результат относится к нашему пайплайну, а не к универсальным возможностям моделей. В такой системе генератору и не нужно быть лучшей универсальной моделью. Ему нужно хорошо решать узкую задачу — находить кандидатов на реальные дефекты. Остальное добирает инженерная обвязка вокруг модели. 

Помимо роста метрики, у перехода на Qwen был дополнительный эффект: стало легче железу, раньше генератор работал на MiniMax-M2-7, которому нужен хост с х4 большим числом карт, чем для Qwen 3.6 27B. На тех же мощностях мы держим весь поток NeuroReview с запасом около 25% на собственном железе и подключаем новые команды без расширения GPU-парка. 

Что NeuroReview берёт на себя

NeuroReview даёт автору раннюю обратную связь: комментарий от него появляется в среднем через 2–3 минуты после публикации PR, тогда как человек обычно подключается через несколько часов. Автор может проверить замечания агента и исправить найденные ошибки, не дожидаясь человеческого ревью. Это время до первой обратной связи, а не длительность самой проверки.

Мы сравнивали замечания NeuroReview с человеческими в два этапа. Сначала отбирали комментарии к одной строке кода, затем LLM-судья определял, описывают ли они одну и ту же проблему. Для 7,5% человеческих замечаний нашлось совпадающее замечание NeuroReview. У метода есть ограничение: человек и агент могут указать на одну проблему в разных местах — например, внутри функции и в месте её вызова. Такие совпадения мы не учитывали, поэтому фактическая доля совпадений может быть выше. Несовпавшие замечания агента нельзя автоматически считать дополнительными находками. При этом человеческое ревью тоже не является абсолютным эталоном: замечание агента, которого нет у человека, может указывать на реальную ошибку.

Полезность несовпавших замечаний мы оценили через production-сигнал. В онлайн-экспериментах разработчики принимают примерно 30% замечаний NeuroReview. Если предположить такой же acceptance rate для несовпавших замечаний из офлайн-выборки, их ожидаемый вклад составляет около 8% дополнительных принятых замечаний относительно ручного ревью.

Около 50% принятых замечаний NeuroReview относятся к бизнес-логике, ещё 16% — language bug. И то, и другое — важные дефекты, которые меняют поведение программы. К слову, люди реже замечают подобные проблемы: 31% принятых замечаний приходится на бизнес-логику и 1,8% на language bug. Заметно больше человеческого внимания уходит в рефакторинг (35%) и minor (23%) — структуру и стиль. 

Пример из продакшена 

Недавно NeuroReview оставил замечание к коду Comrade — платформы, на которой сам же и работает. В одну из функций добавили вызов parse_service_ticket без обёртки в try/except. Типы сходились, компилятор был доволен, юнит-тесты этот путь не покрывали. 

NeuroReview заметил: вызов может кинуть исключение при сетевой ошибке или битом сервис-тикете, и оно бесконтрольно улетит наверх до пользовательского запроса. И сразу предложил готовый фикс: обернуть вызов и при ошибке вернуть значение по умолчанию. Разработчик принял. В обычном процессе такие вещи ловятся уже на ручном ревью или в проде. 

Реакции разработчиков

Автоматическому ревьюеру легко скатиться в шум, поэтому за реакцией людей мы пристально следим. Почти каждое третье замечание NeuroReview разработчики принимают. А ещё под каждым комментарием есть лайк и дизлайк: за полгода доля лайков выросла с 50 до 70%. 

NeuroReview страхует команду от багов, но финальное слово и ответственность за код остаются за человеком.

NeuroReview vs код AI-агентов 

В качестве теста мы прогоняли код, написанный Claude Code, — баги в нём NeuroReview всё равно находит. Это ожидаемо: писать код и ревьюить код — разные режимы. Когда агент пишет, он держит в голове задачу и контекст, поэтому ошибается так же, как человек: не учёл крайний случай, перепутал условие, сломал совместимость. NeuroReview смотрит на готовый дифф как внешний проверяющий и сравнивает старое поведение с новым. 

Чем больше кода пишут агенты, тем нужнее независимая проверка на выходе. 

Где NeuroReview пока слаб 

Лучше всего NeuroReview находит локальные дефекты, которые можно доказать по диффу и окружающему коду. Ему сложнее, когда причина проблемы находится далеко за пределами изменений: в архитектуре системы, взаимодействии нескольких сервисов или незафиксированных бизнес-правилах.

Ещё одна слабая зона — очень большие PR на сотни файлов. В них полезный контекст разреживается, связей становится слишком много, поэтому агент может пропускать проблемы или, наоборот, создавать больше шума.

Архитектурного ревью NeuroReview пока не делает — это сознательное ограничение. Его LGTM также не означает, что корректность кода доказана: агент лишь сообщает, что в текущем контексте не нашёл достаточно обоснованных проблем.

Куда движемся

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

Технически развитие понятное: 

1. Дать агентам больше релевантного контекста — структурный AST вокруг изменений. 

2. Выделить специализированных сабагентов под классы рисков: security, performance, бизнес-логика, миграции. 

3. Ввести risk-routing, чтобы тяжёлый пайплайн запускался только там, где он нужен. 

4. Усилить с помощью координатора финальный отбор замечаний. 

Это закроет нынешнюю слабость на очень больших PR в сотни файлов, где контекст разреживается, а шума становится больше. Похожим путём недавно прошёл Cloudflare: от одного агента к набору специализированных ревьюеров с координатором и многоуровневым routing — это показывает, что направление рабочее, и позволяет подсмотреть детали реализации. 

Вместо выводов

Теперь баги в коде встречает ещё один проверяющий, задача которого — забрать рутинные проблемы, съедающие много времени. Заменять ревьюера мы не собираемся: финальное слово остаётся за ним. Наша же задача — сделать так, чтобы разговор шёл о смысле изменений, а не о необработанных исключениях.

Кстати о разговорах: у нас есть канал, в котором мы говорим о том, что под капотом платформы Yandex Cloud. Присоединяйтесь, если хотите узнать больше.