Code review агенты: находят ли они реальные баги

За последний год в пул-реквесты пришли автоматические ревьюеры: GitHub выкатил Copilot code review, отдельно раскрутились CodeRabbit, Qodo (бывший Codium), Graphite и Greptile. Все они делают одно и то же на первый взгляд — читают дифф, оставляют комментарии, иногда предлагают правку прямо в коде. Вопрос, который волнует любого тимлида, звучит иначе: находят ли они баги, которые пропустил бы человек, или просто добавляют шума в и без того перегруженный процесс ревью.

Что вообще делает code review агент

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

Разница принципиальная. Линтер не поймёт, что вы поменяли знак сравнения местами и цикл теперь никогда не выполнится, если синтаксически всё корректно. Агент — потенциально может, потому что он видит не только строку, но и то, зачем эта строка написана. Потенциально — ключевое слово.

Большинство агентов работают по одной схеме:

• получают дифф пул-реквеста и, как правило, часть окружающего кода в контекстное окно¹;
• прогоняют его через модель (обычно семейства GPT или Claude) с промптом ревьюера;
• оставляют комментарии построчно, часто с предложением конкретной правки;
• некоторые дополнительно подтягивают файлы из репозитория через поиск — это ближе к RAG², чем к простому диффу.

Что они ловят, а что придумывают

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

Ловят стабильно

Опечатки в логике, которые компилятор пропускает: перепутанные аргументы одного типа, забытый await, обращение к переменной до присваивания в редкой ветке, копипаста с несменённым индексом (arr[i] вместо arr[j]). Это скучные, но дорогие в проде баги, и агенты на них действительно хороши — потому что паттерн локальный и виден прямо в диффе.

Ловят через раз

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

Придумывают регулярно

Ложные срабатывания — главная боль. Агент уверенно предлагает «исправить» корректный код, ссылается на несуществующий метод API, советует обернуть в try/except то, что и так безопасно. Это не редкий сбой, а системное свойство: модель обязана что-то написать, и если багов нет, она найдёт то, что похоже на баг.

Ценность ревьюера измеряется не числом комментариев, а их точностью. Инструмент, который на десять замечаний даёт восемь мимо, обучает команду закрывать все его комментарии не глядя — и тогда он пропустит девятое, настоящее.

Сравнение популярных агентов

Ниже — ориентир по возможностям на конец 2024 — начало 2025 года. Модели под капотом и цены меняются часто, поэтому тарифы сверяйте на официальных страницах перед покупкой.

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

Есть ли измеримые доказательства

С публичными бенчмарками именно для code review агентов ситуация скромная. Ближайший релевантный ориентир — SWE-bench, набор реальных задач из GitHub, где модель должна починить баг по описанию issue. Он измеряет способность править код, а не ревьюить его, так что переносить эти проценты напрямую на качество ревью некорректно.

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

Кому это пригодится, а кому нет

Пригодится:

• командам, где ревью — узкое место и PR висят днями: агент проходит по очевидному, человек включается на спорном;
• проектам с большим потоком внешних контрибьюторов (open source), где первый проход по стилю и типовым ошибкам можно автоматизировать;
• джуниорам как быстрая обратная связь до того, как код увидит сеньор — но с прямым предупреждением, что советы агента бывают неверными.

Скорее навредит или бесполезен:

• маленьким командам из двух-трёх сильных инженеров, которые и так хорошо ревьюят друг друга: шум перевесит пользу;
• кодовым базам с сильной доменной спецификой, где половина замечаний будет мимо контекста;
• в проектах, где нельзя отдавать код во внешний облако-сервис — тут смотрите только на self-hosted варианты и читайте их политику обработки данных.

Как внедрить, чтобы не утонуть в шуме

1. Включите на одном активном репозитории, а не на всех сразу.
2. Две недели никто не обязан закрывать комментарии агента — их только собирают.
3. Посчитайте вручную: сколько замечаний оказались реальными багами, сколько — стилем, сколько — мимо. Если доля «мимо» выше половины, крутите настройки или меняйте инструмент.
4. Зафиксируйте правило: агент не блокирует мёрж. Финальное слово за человеком — иначе одно уверенное ложное срабатывание остановит релиз.

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

¹ Контекстное окно — объём текста (кода), который модель способна учитывать за один запрос. Чем оно больше, тем больше окружающего кода агент видит, но тем дороже обходится запрос.

² RAG (retrieval-augmented generation) — подход, при котором модель перед ответом подтягивает релевантные куски из внешнего источника (здесь — из репозитория), а не полагается только на то, что ей передали в промпте.