Код-ревью с ИИ пропускает бизнес-логику: 7 ошибок, ведущих к боевым инцидентам

Сергей Прощаев, техлид в финтехе и преподаватель ОТУС, разобрал семь конкретных ошибок код-ревью с ИИ, которые приводят к боевым инцидентам, и объяснил, почему автоматический ревьюер молчит там, где ломается бизнес-логика.

Тема код-ревью с ИИ перешла из разряда экспериментов в повседневную практику. По опросу LeadDev за 2026 год, 68% инженеров признают, что ИИ изменил их подход к проверке кода, а внутри этой группы 86% запускают модель до того, как код увидит живой человек. Но 29% при этом говорят, что ревью стало занимать больше времени, а не меньше. Прощаев на примерах из платёжных сервисов показывает, почему так происходит и где именно автоматика подводит.

Что происходит на практике?

Типичный сценарий выглядит так: разработчик ставит задачу ИИ-агенту (программе, которая сама выполняет последовательность действий для достижения цели), тот за несколько минут собирает патч на 600 строк, прогоняет тесты, отчитывается об успехе. В пулл-реквесте уже сидит автоматический ревьюер и оставил девять комментариев: три про именование переменных, два про отсутствующую документацию, один про потенциальную ошибку обращения к пустому объекту. Остальные про стиль.

Автор исправляет, бот помечает замечания закрытыми, автотесты зелёные. Человек открывает изменения, видит восемь аккуратных файлов и ставит одобрение.

Через неделю приходит расхождение по балансам. На разборе выясняется, что изменение сломало контракт, которого в списке изменённых файлов вообще не было.

Прощаев разводит два понятия, которые часто путают:

• Код-ревью с ИИ (AI Code Review) означает автоматическую проверку пулл-реквеста моделью или агентом
• ИИ-код означает код, который агент написал или существенно изменил

Это независимые вещи. Автоматический ревьюер одинаково проверяет и полностью человеческий код.

Какие аргументы в пользу автоматического код-ревью?

Скорость и охват. ИИ-ревьюер обрабатывает сотни пулл-реквестов без очереди и усталости. Для команд, где один старший разработчик проверяет код за пятерых, это реальная разгрузка.

Стандартизация стиля. Замечания по именованию, форматированию, документации модель выдаёт надёжно и без субъективности. По данным опроса LeadDev, 86% инженеров, изменивших подход к ревью, используют модель именно для первичного прохода.

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

Где автоматика подводит?

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

Хуже другое: человек подстраивается под инструмент и тоже начинает читать только подсвеченные строки.

Конкретный пример из платёжного сервиса на Java. Метод подтверждения платежа вызывает внешний сервис проводок через синхронный HTTP-клиент. В изменённых строках код выглядит безупречно: исключение обработано, лог есть. Но исключение подавлено, метод завершается штатно, транзакция в базе данных фиксируется. Результат: платёж помечен подтверждённым, а проводки нет.

Обнаружиться это может через дни или недели, по сверке балансов или по алерту на отсутствующую проводку, если такой алерт вообще заведён.

Модель-ревьюер этот дефект пропускает, потому что проблема не в изменённом коде, а в разъехавшихся бизнес-состояниях между двумя системами.

Что говорят цифры о качестве ИИ-кода?

По данным отчёта CodeRabbit (на выборке из 470 открытых пулл-реквестов), код с признаками ИИ-соавторства получает в среднем 10,83 замечания против 6,45 у полностью человеческого кода. Прощаев сразу приводит две оговорки:

• Авторство определялось по косвенным признакам
• Находки считал анализатор самого CodeRabbit, то есть вендора инструмента для код-ревью

Данные GitClear добавляют структурную картину. Доля изменений, классифицированных как «перемещённые или рефакторённые», упала с 21% в 2022 году до 3,8% в 2026-м. Это значит, что новый код всё реже переиспользует существующий и всё чаще дублирует его.

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

Переведу на язык дежурства: изменений больше, они чаще дублирующие и требуют больше внимания, а ревьюеров столько же. : Сергей Прощаев, Tech Lead, FinTech & E-commerce

Что делать с этим прямо сейчас, по ролям

Разработчику и автору технического контента на Дзене. Если пишете про ИИ-инструменты для кода, учитывайте: «бот одобрил» не равно «код безопасен». Конкретный кейс Прощаева с платёжным сервисом показывает, что самое опасное в коде, написанном ИИ, не синтаксис, а бизнес-логика на стыке систем. Это материал для честных обзоров, а не для восторженных заголовков.

Маркетологу и менеджеру продукта. Рост замечаний на 68% (10,83 против 6,45 по данным CodeRabbit) означает, что ИИ-генерация кода ускоряет разработку, но увеличивает нагрузку на проверку. Обещание «в два раза быстрее» работает только если заложить время на ревью.

Предпринимателю в РФ. Инструменты автоматического код-ревью (CodeRabbit, аналоги от GitHub) доступны российским командам. Но ключевой урок: нельзя сокращать штат ревьюеров, наращивая генерацию. Формула Прощаева простая: подавайте модели не только изменённые строки, а контекст вызывающего кода и контрактов.

Рост объёма ИИ-кода продолжится, а вместе с ним вырастет спрос не на автоматических ревьюеров, а на людей, которые умеют задавать им правильный контекст и читать то, что бот не видит, стыки между системами, бизнес-инварианты, последствия за пределами изменённых файлов.