Можно ли заменить часть код-ревью на ИИ и какие ошибки появляются в проде после такого внедрения

Что произошло, почему это важно и что взять в работу.

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

Связанные услуги: каталог, AI Boost Team, стать клиентом.

Вердикт сразу: ИИ забирает первый проход, но не ответственность

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

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

Рынок продаёт другую историю. «Точность выше 90% на бенчмарке» — фраза из презентации, а не из вашего бэклога. Бенчмарки собраны на синтетике, где диффы аккуратные, а контекст системы как будто приложен к каждому файлу. В реальном репозитории 10–50 разработчиков контекст живёт в головах, в старых тикетах и в двухлетних комментариях к PR. Это и есть главный подвох внедрения.

Что ИИ-ревью делает хорошо, а что пропускает

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

Слепые зоны начинаются ровно там, где нужен взгляд «а как это работает в целом».

• Сильные стороны: стиль, типовые баги, уязвимости вроде SQL-инъекций и XSS, отсутствие тестов на новый код.
• Слепые зоны: транзакционные границы, конкурентный доступ, обратная совместимость контрактов, утечки соединений и дескрипторов.
• Ключевое: высокая точность на тестовых наборах не переносится на архитектурные решения — это разные виды задач.

Есть простой способ проверить границу на своём материале, без вендорских обещаний. Возьмите 10 реальных инцидентов за последние 6–12 мес и прогоните те диффы, которые к ним привели. Отметьте, какие дефекты ИИ нашёл бы по патчу. Оставшиеся — это и есть ваш список проверок, которые нельзя отдавать автомату. Часто выясняется, что список короткий, но именно он держит прод в рабочем состоянии.

Какие ошибки доходят до прода после автоматизации ревью

Разберём по категориям, чтобы у вас был не абстрактный «риск качества», а конкретика для чек-листа. Все четыре типа объединяет одно: дифф выглядит нормально, и ревьюер-модель формально права — код корректен в отрыве от системы.

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

Гонки ведут себя похоже. Нагрузочный тест в песочнице на 50 запросов ничего не покажет. В проде при пиковой очереди два воркера читают одинаковое состояние и оба пишут. Дальше — дубли списаний, двойные письма, потерянные статусы. На ревью такое ловится вопросом «а кто гарантирует, что этот блок не выполнится дважды», и вопрос этот задаёт человек, знающий про очередь.

Границы автоматизации: первый проход и второй проход

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

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

Чек-лист для зон высокого риска держите коротким, иначе его начнут имитировать. Рабочий минимум:

1. Транзакции: какие операции должны быть атомарны и где проходит граница.
2. Идемпотентность: что произойдёт при повторном вызове или ретрае.
3. Обратная совместимость: какие внешние потребители сломаются и есть ли переходный период.
4. Лимиты ресурсов: соединения, таймауты, размеры ответов, поведение при деградации.

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

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

Метрики, которые показывают реальный эффект, а не ощущение

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

Ориентиры, на которые можно смотреть как на направление, а не как на обещание: время сеньора на одном PR сокращается с 40–60 до 15–25 минут за счёт разделения проходов. Доля дефектов, пойманных на ревью, растёт с 60–70% до 75–85% примерно за 3 мес. Время до мержа падает с 1–2 дней до 4–8 часов примерно за 2 мес. Любая из этих цифр зависит от вашего baseline, размера PR и дисциплины команды — без стартовых замеров сравнивать не с чем, и отчитываться такими числами перед руководством нельзя.

Что действительно информативно с первого дня: категории продовых инцидентов. Если после автоматизации выросла доля инцидентов именно в транзакциях и конкурентности, значит граница проведена неверно, и это видно по данным, а не по мнениям на ретро. Обратная ситуация тоже показатель: если инциденты не изменились, а время до мержа упало, схема работает.

Внедрение на 90 дней без героизма

Месяц 1 — аудит и пилот на одном модуле. Соберите статистику инцидентов за 6–12 мес, разметьте их по категориям, проверьте, какие из них ИИ поймал бы по диффу. Параллельно включите ассистента на первом проходе в одном сервисе и замерьте baseline: время сеньора, время до мержа, доля дефектов на ревью.

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

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

Если хотите пройти этот путь с внеш