Чек-лист code review для кода, написанного ИИ: что проверить перед merge

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

Проблему, стоящую за этим списком, мы описали в статье о долге знаний: код есть, но никто не знает, почему он работает именно так. Этот материал дополняет ту статью. Вместо диагноза здесь конкретные проверки, которые можно выполнять в каждом pull request.

Разбейте PR и докажите, что можете объяснить код

ИИ может изменить десятки файлов одним запросом. Слишком большой для проверки pull request на практике означает непроверенный pull request. Начните с размера изменения.

• Один PR - одна цель. Новая функциональность, рефакторинг и обновление зависимостей не должны попадать в один PR.
• Отделяйте переименования и форматирование от изменений логики. Ревьюер должен видеть реальную разницу в поведении.
• Удаляйте код, который вы не просили. ИИ часто добавляет неиспользуемые вспомогательные функции, лишние абстракции и дублирующиеся блоки.

Тест объяснения: автор PR должен суметь объяснить код коллеге, не обращаясь к ИИ. Если он не может ответить на эти вопросы, код не сливается: как этот код ведёт себя на заданном входе? Почему выбран именно такой подход и какова была альтернатива? Что сломается, если удалить эту строку? Тот, кто не может объяснить код, не сможет исправить его, когда он даст сбой в продакшене.

Выводите тесты из требования, а не из кода

ИИ нередко пишет и код, и тесты к нему. Такие тесты обычно подтверждают то, что делает код, а не то, чего требует задача. В итоге одна и та же ошибка записана дважды. Выводите тесты из требования.

1. Превратите требование в критерии приёмки: «при таком входе возвращается такой результат».
2. Составьте тестовые сценарии по критериям приёмки, не читая реализацию.
3. Добавьте граничные случаи: пустой ввод, null, очень большие значения, два одновременных запроса, пользователь без прав.
4. Докажите, что тест способен упасть. Намеренно сломайте код и убедитесь, что тест краснеет.

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

Проверка зависимостей, секретов и безопасности

Предлагая код, ИИ заодно добавляет пакеты. Каждая новая зависимость - новый риск, который берёт на себя команда.

• Существует ли пакет и тот ли это пакет? ИИ может предложить несуществующие пакеты или пакеты с похожими названиями. Сверяйте название с официальным источником и помните о риске установить вредоносный пакет из-за опечатки.
• Проверьте лицензию, состояние поддержки и дату последнего релиза. Не добавлена ли тяжёлая зависимость ради мелкой задачи?
• Видно ли изменение lock-файла в PR и совпадает ли оно с ожидаемым? Запустите сканер зависимостей на известные уязвимости.
• Нет ли в коде, тестах или примерах конфигурации API-ключа, токена или пароля? Реальные значения, вставленные в промпт, могли попасть в код.
• Запускайте поиск секретов (secret scanning) в pre-commit и в CI. Если вы подозреваете утечку ключа, мало его удалить: его нужно перевыпустить (rotate). Он остаётся в истории git.
• Проверяются ли все пользовательские данные? Выполняется ли проверка прав на сервере? Нет ли конкатенированного запроса, уязвимого для SQL-инъекции или инъекции команд?

Более широкий список есть в нашем чек-листе безопасности перехода от vibe code к продакшену.

Обработка ошибок, логирование, производительность и целостность данных

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

• Обработка ошибок: пустые блоки catch, молча проглатывающие ошибки, и общие сообщения, отвечающие на всё одинаково, недопустимы. Ошибку нужно либо обработать, либо передать выше. У вызовов внешних сервисов должны быть таймаут, ограниченное число повторов и понятный путь отказа.
• Логирование: хватает ли контекста для отладки сбоя (идентификатор запроса, название операции)? Пароли, токены и персональные данные не должны попадать в логи.
• Производительность: ищите запросы к базе внутри циклов (N+1), списки без пагинации, фильтры без индекса и лишние повторные вычисления. Код, работающий на 10 локальных записях, в продакшене будет работать с миллионами.
• Целостность данных: находятся ли несколько записей в одной транзакции? Если один и тот же запрос придёт дважды, появятся ли дубликаты (идемпотентность)? Можно ли откатить миграцию? Удаляет ли операция данные безвозвратно?

Запись архитектурных решений и критерии перед merge

ИИ принимает архитектурные решения молча: новый слой, другой подход к управлению состоянием, другая библиотека. Чтобы сделать их видимыми, ведите короткую запись архитектурного решения (ADR): контекст, принятое решение, отвергнутые альтернативы и последствия. Достаточно нескольких предложений, и запись постоянно хранится в репозитории. Через полгода ответ на вопрос «почему мы так сделали» будет там.

Для решения о merge используйте такие критерии:

1. PR имеет одну цель и размер, пригодный для проверки.
2. Автор объясняет код, не обращаясь к ИИ.
3. Тесты выведены из требования и покрывают граничные случаи.
4. Новые зависимости проверены, в коде и истории нет секретов.
5. На вопросы об ошибках, логах, производительности и целостности данных есть ответы.
6. Решение, влияющее на архитектуру, записано.

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

Часто задаваемые вопросы

Нужен ли отдельный процесс code review для кода, написанного ИИ? Отдельный процесс не нужен, но тот же процесс стоит применять строже. Поскольку автор сам не выстраивал логику, тест объяснения и вывод тестов из требований становятся ещё важнее.

Можно ли делать merge, если тесты проходят? Нет. Если тесты тоже написал ИИ, они могут лишь подтверждать то, что делает код. Убедитесь, что тесты выведены из требования и действительно падают, когда вы ломаете код.

Можно ли использовать ИИ для самого code review? Как первый проход - да, он помогает находить очевидные ошибки и пропущенные проверки. Но решение о merge принимает человек, который за него отвечает.

Что делать, если я случайно закоммитил секрет? Немедленно отзовите ключ и выпустите новый (rotate). Удаления из файла недостаточно, потому что ключ остаётся в истории git и в возможных клонах. Затем выясните, как произошла утечка, и подключите secret scanning.

Если вам нужно подготовить кодовую базу, созданную с помощью ИИ, к продакшену или выстроить такую дисциплину ревью в команде, посмотрите нашу услугу vibe-code-to-production и опишите ситуацию через форму быстрого запроса.