Как принимать изменения, которые подготовил ИИ-агент: чек-лист для ревью кода
ИИ-агент способен подготовить патч, запустить часть тестов и коротко описать сделанное. Это ускоряет черновую работу, но не заменяет ревью: модель могла затронуть соседний модуль, изменить поведение по умолчанию или написать тест, который повторяет её же ошибочное предположение. Надёжная приёмка начинается не с вопроса «работает ли приложение?», а с проверки того, совпадает ли изменение с задачей и не добавляет ли оно незапрошенный риск.
Полезно разделить проверку на несколько проходов. Сначала подтвердить объём изменений, затем оценить поведение, тесты, зависимости и возможность восстановления. Такой порядок особенно важен, если агенту разрешено менять файлы и запускать команды. Он не требует специальной платформы: достаточно diff, воспроизводимой команды сборки и человека, который понимает, кто будет отвечать за итоговый merge.
1. Зафиксируйте исходную задачу
Перед тем как читать патч, сформулируйте критерии приёмки простыми проверяемыми предложениями. Например: «при отсутствии поля экран показывает сообщение и не отправляет запрос», «пользователь без роли редактора не может изменить запись», «старый формат файла продолжает открываться». Избегайте критерия «сделать удобнее»: он не задаёт проверяемого состояния и позволяет агенту интерпретировать задачу слишком широко.
Сверьте критерии с запросом и ограничениями: какие файлы можно менять, какая версия API поддерживается, должны ли сохраниться совместимость и публичные URL. Если агент сам предложил изменить схему базы или заменить библиотеку, это не становится обязательной частью решения. Отделите необходимое от необязательного и запросите объяснение для каждой дополнительной правки.
2. Проверьте границы diff
Начните с перечня изменённых, удалённых и новых файлов. Убедитесь, что каждый из них связан с задачей. Внимательно посмотрите на конфигурацию, lock-файл, миграции, права доступа, переменные окружения и автоматические скрипты. Большой diff не всегда плох, но необъяснимые изменения — повод остановиться до запуска.
Проверьте, не попали ли в патч ключи, токены, локальные пути, дампы данных или временные файлы. Отдельно изучите удаление: агент мог убрать обработчик, проверку или fallback, потому что не увидел его связи с основным сценарием. Если кодгенератор менял форматирование во всём модуле, попросите разделить механическую часть и функциональные изменения, чтобы ревью не потеряло важный смысл среди шума.
3. Пройдите путь данных
Проследите входные данные от границы системы до места, где они меняют состояние или показываются пользователю. Для каждой новой ветки спросите: что произойдёт при пустом значении, неправильном типе, дубликате, тайм-ауте и повторном запросе? Есть ли проверка прав непосредственно там, где выполняется действие, или интерфейс только скрывает кнопку? Не полагайтесь на одно клиентское ограничение, если операция доступна через API.
Посмотрите, как обрабатываются ошибки внешнего сервиса и частичный успех. Повторный вызов платежа, создание второй записи или потеря ответа после успешного сохранения могут иметь последствия, отличные от ошибки вёрстки. Там, где действие нельзя безопасно повторить, нужна идемпотентность или явная проверка текущего статуса. Если агент добавил логирование, убедитесь, что туда не попадают личные данные и секреты.
4. Не считайте тесты доказательством сами по себе
Запустите существующие тесты и сборку, но проверьте, что они действительно покрывают критерии приёмки. Новый тест может проверять только счастливый путь и использовать мок, который всегда возвращает ожидаемый ответ. Прочитайте входные данные, утверждения и поведение при ошибке. Полезно вручную придумать контрпример, который агенту не давали: пустой файл, повтор события, неправильная кодировка, отсутствие разрешения.
Если тест не запускался или был пропущен, причина должна быть записана. Не называйте изменение проверенным только потому, что инструмент завершился кодом 0: он мог выполнить не тот набор тестов. Сохраните точные команды и версию среды, чтобы ревьюер мог повторить результат. Для изменения, затрагивающего деньги, права или пользовательские данные, предусмотрите отдельную проверку на тестовой копии.
5. Оцените зависимости и внешние эффекты
Для новой библиотеки выясните, зачем она нужна, как часто поддерживается и нет ли уже подходящего инструмента в проекте. Проверьте лицензию и размер добавленного пакета, если это важно для продукта. Для фоновой задачи или интеграции выясните, когда она запускается, какие данные отправляет наружу и как её отключить. Агент может успешно скомпилировать код, который создаёт неподходящую сетевую связь или лишнюю нагрузку.
Попросите краткую карту последствий: пользовательские маршруты, схема хранения, внешние API, права и конфигурация. Сопоставьте её с diff. Если описание и фактические изменения расходятся, доверяйте коду, а не резюме модели.
6. Проведите приёмку на отдельной ветке
Не запускайте патч сразу на рабочем сервере. Создайте ветку или изолированную копию, установите зависимости по lock-файлу и выполните сборку. Пройдите сценарии из критериев приёмки и несколько негативных случаев. Для интерфейса проверьте узкую ширину, пустые состояния и ошибку загрузки. Для API — отсутствие прав, тайм-аут и повтор. Для миграции — резервную копию и обратный путь.
До слияния договоритесь, кто принимает результат и как откатить изменение. Откат — не просто команда в инструкции: проверьте, можно ли вернуть прежнюю версию без потери пользовательских данных. Если изменение затрагивает необратимую миграцию, план восстановления должен быть понятен заранее.
Вывод. Хорошая приёмка оценивает не красоту ответа агента, а соответствие задачи, ограниченность diff и наблюдаемое поведение при сбоях. Патч можно принять, когда команда способна повторить проверки, объяснить важные решения и восстановить прежнее состояние.
FAQ
Достаточно ли успешной сборки? Нет: сборка подтверждает компиляцию, а не корректность поведения. Можно ли попросить агента проверить собственный код? Можно использовать его как дополнительного рецензента, но это не независимая проверка. Что делать с необъяснённой правкой? Не принимать её до выяснения назначения. Как снизить риск при первом пилоте? Ограничить репозиторий, права и команды, работать в отдельной ветке и заранее определить критерии остановки.
Проверка прав перед выдачей доступа описана в чек-листе пилота агента; особенности отдельного отчёта агента — в материале о cloud canvases и средах разработки.