Автоматизация Code Review: как нейросети забирают рутину у разработчиков

Почему нужна автоматизация

На Авито создаётся тысяча пул-реквестов в неделю — в пиковые часы до 300 одновременно. Это создаёт огромную нагрузку на разработчиков, которые отвлекаются с основной работы на code review. Результат: PR могут дни стоять в очереди на ревью, увеличивается time-to-market новых фичей, команда устаёт и может пропустить критичные баги.

Команда LLM-инженеров сформулировала три цели автоматизации:

• Ускорить разработку — убрать очереди на ревью • Снизить влияние человеческого фактора — при постоянном переключении разработчики теряют сосредоточение • Унифицировать процесс — разные ревьюеры дают разные замечания, часто возникает субъективность

Архитектура системы

Система состоит из трёх компонентов, связанных в чёткий workflow:

1. Stash — интерфейс, где разработчик оставляет комментарий ai_review в PR 2. Go-сервис — получает событие из Data Bus, парсит команду, берёт diff и метаданные репозитория, кладёт ревью в БД со статусом STATE_REQUESTED и отправляет RPC в ML-сервис 3. Python ML Pipeline service — обрабатывает контекст и возвращает сгенерированные комментарии

ML-сервис отвечает 200 OK сразу, чтобы не блокировать Go-сервис — генерация может длиться долго.

ML-пайплайн: три этапа

RuleChecker (генерация). Модель выявляет все потенциальные проблемы — опирается на таксономию ошибок из реальных PR команды. Оптимизирована на высокую полноту (Recall), даже если false positives. На выходе — JSON с номерами строк и рекомендациями.

ReviewFilter (валидация). Второй проход повышает точность (Precision). Модель работает в паттерне Conclusion First — получает тот же контекст плюс конкретный комментарий и отвечает: важно ли это замечание или нет. Отсекает 90% галлюцинаций и false positives.

CommentAggregator (дедупликация). Система строит эмбеддинги комментариев через BAAI/bge-m3, вычисляет косинусную близость. Если similarity выше 0.85 — комментарии группируются. Из каждой группы остаётся один, самый содержательный. На выходе — финальный список уникальных замечаний.

Выбор модели и производительность

По бенчмарку MERA-RuCodeReviewer (689 примеров на Java, Python, Scala, Go) лидирует Gemini 2.5 flash, но команда выбрала Qwen3-Coder-30B-Instruct-FP8 (второе место) — она опенсорс и позволяет хостить на собственной инфраструктуре. Это критично: код не уходит во внешние API, плюс селф-хостинг дешевле на больших объёмах (PR требуют 2000–10 000 токенов).

Производительность: • Малые PR (до 3 файлов): 10–20 секунд • Большие PR (10+ файлов): ~60 секунд • Максимум 650 параллельных ревью

Метрики качества собираются через лайки разработчиков: • Precision: 85% комментариев классифицированы как хорошие • Outdated rate: 32% (комментарии, которые разработчик закрыл исправлением). Для Infra и DevOps достигает 60%.

Ключевые выводы

Основная идея: разделение Recall и Precision работает лучше единого запроса. Даже с длинным контекстом модель теряется, поэтому нужна многоэтапная система. Валидация отсекает галлюцинации критично — это опора доверия пользователей.

Модель должна видеть полный код файлов и структуру репозитория — diff недостаточно для качественного анализа. AI берёт рутину, но люди должны контролировать процесс.