ИИ-ревью кода на 4000 PR в день: как Яндекс устроил NeuroReview и какие баги он находит

ИИ-ревью кода обычно обсуждают абстрактно: может ли модель заметить баг, который пропустили тесты. Яндекс опубликовал на Хабре цифры из эксплуатации. Их внутренний сервис NeuroReview каждый день проверяет около 4 тысяч пул-реквестов. Это примерно 40% всех PR, которые разработчики создают в Аркадии, монорепозитории компании.

Автор материала — Витя Плошихин, руководитель ML Laboratory в Yandex Infrastructure. За ML и качество сервиса отвечает команда Константина Моксина. Статья короткая, около восьми минут чтения, но плотная. В ней есть устройство пайплайна, сравнение моделей с ценой одной проверки, распределение найденных багов по типам и честный список слабых мест.

Ниже конспект без оценок по ходу изложения. Все утверждения принадлежат команде Яндекса и описывают их собственный пайплайн. Короткая оценка того, что из этого применимо за пределами Яндекса, собрана в последнем разделе.

Зачем Яндексу ИИ ревью кода

До NeuroReview процесс был обычным. Сначала обязательные тесты и статические анализаторы, потом человек. Автоматика ловила типовые ошибки, а ревьюер разбирался в логике изменения и контексте проекта.

Сломалась эта схема на объёме. Поток PR рос, а внимание ревьюеров нет. Первого комментария приходилось ждать несколько часов, и за это время автор успевал переключиться на другую задачу. Ревьюер весь день искал одно и то же: необработанные исключения, перепутанные параметры, забытые крайние случаи. К вечеру часть таких дефектов проходила дальше.

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

Два агента вместо одного: как устроен NeuroReview

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

Сам пайплайн построен по схеме «генерация кандидатов → фильтрация»:

• Генератор читает дифф и нужные файлы и ищет как можно больше проблем. Его задача — ничего важного не пропустить. На момент сбора данных это Qwen 3.6 27B на внутреннем инференсе.
• Валидатор получает замечания генератора вместе с исходным диффсетом, перепроверяет находки и отбрасывает спорное, дубли и недоказанное. Его задача — точность. Сейчас это MiniMax-M2-7.

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

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

Как выбирали модель: метрика TSPR и цена проверки

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

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

За baseline взяли конфигурацию, где генератором и валидатором был MiniMax-M2-7. Результаты относительно него такие:

Opus оказался лучшим по качеству и примерно в 83 раза дороже за проверку. Команда пересчитала это на свой поток: даже если каждый из 4 тысяч PR проверять один раз, выйдет около $13,7 тыс. в день. На деле проверок больше, потому что после правок автора NeuroReview смотрит новую версию кода заново, и каждый запуск оплачивается отдельно. В продакшен пошёл Qwen как лучший баланс качества и цены.

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

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

Какие баги находит автоматическое ревью кода

Первый результат касается скорости. Комментарий NeuroReview появляется в среднем через 2–3 минуты после публикации PR, человек обычно подключается через несколько часов. Автор уточняет, что это время до первой обратной связи, а не длительность самой проверки.

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

Чтобы оценить несовпавшие замечания, взяли сигнал из продакшена: разработчики принимают примерно 30% замечаний NeuroReview. Если у несовпавших та же доля принятия, их ожидаемый вклад составит около 8% дополнительных принятых замечаний относительно ручного ревью. Это расчёт на допущении, и в статье он так и подан.

Распределение по типам у людей и у агента заметно отличается:

Категории в статье определены так. Бизнес-логика — функциональный баг: неверное условие или расчёт, потерянный случай с пустыми данными, перепутанные параметры, race condition, утечка ресурса. Language bug — поломка на уровне языка: нет импорта, вызов несуществующего метода, разыменование null, небезопасный каст, ошибка компиляции. Рефакторинг и minor касаются структуры и косметики без смены поведения. Каждому замечанию назначали одну категорию. Если для доказательства проблемы требовался код за пределами диффа, замечание шло в отдельную категорию large context.

Вывод автора: агент чаще людей ловит дефекты, которые меняют поведение программы, а внимание людей сильнее уходит в структуру и стиль.

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

Под каждым комментарием есть лайк и дизлайк, и за полгода доля лайков выросла с 50 до 70%. Отдельно команда прогоняла через сервис код, написанный Claude Code, и NeuroReview находил баги и там. Объяснение автора: агент, который пишет код, держит в голове задачу и ошибается так же, как человек, а ревьюер смотрит на готовый дифф снаружи.

Слабые места и планы развития

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

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

Главный сдвиг в планах касается метрики. Сейчас она одинаково ценит замечание, принятое автором PR, и замечание, принятое ревьюером. Команда считает, что узкое место смещается с написания кода на проверку, поэтому метрику сдвинут в сторону экономии времени ревьюера. Техническая часть планов такая:

1. Дать агентам больше релевантного контекста, а именно структурный AST вокруг изменений.
2. Выделить специализированных сабагентов под классы рисков: security, performance, бизнес-логика, миграции.
3. Ввести risk-routing, чтобы тяжёлый пайплайн запускался только там, где он нужен.
4. Усилить финальный отбор замечаний координатором.

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

Коротко

• NeuroReview проверяет около 4 тысяч PR в день, это примерно 40% потока Аркадии. Первое замечание появляется через 2–3 минуты, человек обычно подключается через несколько часов.
• Ревью делят два агента: генератор (Qwen 3.6 27B) ищет максимум кандидатов, валидатор (MiniMax-M2-7) отсекает шум. Перед публикацией каждую привязку к строке сверяют с репозиторием.
• Opus дал TSPR примерно на 30% выше, но обходился в 83 раза дороже за проверку. Побеждает узкая постановка задачи и обвязка, а не самая сильная модель.
• Разработчики принимают около 30% замечаний. Половина принятых относится к бизнес-логике, то есть к багам, которые люди находят реже.
• Сервис не делает архитектурного ревью, слабо работает на PR в сотни файлов, и его LGTM не гарантирует корректность. Финальное слово остаётся за человеком.

Что из этого следует

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

Сравнение моделей стоит читать с оговоркой, которую делает сам автор. Цифры получены на внутреннем коде Яндекса, на их промптах и с их валидатором, а метрика отражает реакцию разработчиков, а не измеренное время. На другой кодовой базе и с другой обвязкой порядок моделей может оказаться иным. Перед запуском у себя полезно посчитать цену на свой поток с учётом повторных проверок. Именно этот расчёт развёл Opus и Qwen.

Ожидания по пересечению с людьми тоже лучше держать скромными. 7,5% совпадений с людьми и около 30% принятых замечаний означают, что агент добавляет ревьюера, а не заменяет его. Ценнее всего он на локальных багах в небольших PR: исключения, пустые данные, перепутанные условия. Архитектуру, межсервисные связи и неписаные бизнес-правила по-прежнему проверяет человек.

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