Как проверять код, написанный ИИ: от diff до работающего сценария
Neaptide · 20 сентября 2026 г. · 8 мин чтения
Как принимать код от ИИ: читать diff, проверять тесты и проходить пользовательский сценарий. Шаблоны ревью и отчёта о готовности.
В этой статье
Сообщение агента «тесты прошли» отвечает только на часть вопросов. Нужно понять, какие тесты выполнялись, проверяли ли они исходную проблему и не появились ли изменения за границами задачи. Приёмка начинается с условий результата, которые можно сопоставить с кодом и поведением приложения.
Проверка ИИ-кода включает три уровня: изменения в файлах, автоматические проверки и пользовательский сценарий. Это предложенная схема работы, а не гарантия отсутствия ошибок. Она помогает увидеть, каких доказательств пока не хватает.
Запишите критерии до начала работы
Для формы заявки недостаточно поручения «исправь отправку». Опишите наблюдаемое поведение:
Если сервер вернул ошибку, значения полей сохраняются и появляется понятное сообщение. Во время отправки повторный запрос не создаётся. После успеха пользователь видит подтверждение.
Разделите обязательные условия и пожелания. Тогда красивый рефакторинг не заменит исправление ошибки, ради которой началась задача.
Для сложной работы предложите агенту сначала найти затронутые участки и существующие проверки. Подход с явным способом проверки описан и в рекомендациях Anthropic.
Уровень 1: прочитайте diff
Посмотрите список изменённых файлов и объясните себе роль каждого. Условно небольшая правка формы не должна незаметно менять аутентификацию, зависимости и конфигурацию развёртывания.
Проверьте:
- Сохранены ли прежние условия доступа и обработки ошибок.
- Не заменена ли реальная проверка безусловным успешным результатом.
- Не исчезли ли тесты, которые раньше находили проблему.
- Не появились ли секреты, лишние логи или временные обходы.
Для просмотра используйте `git diff` и `git diff --stat`. Если агент сделал коммит, сравнивайте нужные коммиты: обычный diff незакоммиченных изменений тогда может быть пустым. Руководство git diff.
Уровень 2: выполните подходящие проверки
Попросите назвать команды и показать исход каждой проверки. Отделяйте «запустил», «завершилось» и «успешно». Процесс может завершиться ошибкой окружения, которая не подтверждает и не опровергает исправление.
| Проверка | На какой вопрос отвечает |
|---|---|
| Проверка типов | Соответствует ли код проверяемым ограничениям типов |
| Тест функции | Получается ли нужный результат на выбранных входных данных |
| Интеграционный тест | Согласованы ли взаимодействующие части |
| Сборка | Собирается ли приложение в данной конфигурации |
| Браузерный сценарий | Работает ли наблюдаемый путь пользователя |
Ни одна строка не заменяет все остальные. Например, успешная сборка не подтверждает, что письмо дошло до адресата.
При исправлении воспроизводимого дефекта полезно убедиться, что соответствующий тест обнаруживает старое поведение и проходит после изменения. Иначе тест может проверять удобное для новой реализации условие, пропуская исходную ошибку.
Уровень 3: пройдите пользовательский сценарий
Для формы проверьте пустой ввод, неверное значение, ошибку сервера и успешную отправку. Используйте тестовые данные и тестовый приёмник, чтобы результат можно было наблюдать без реальных обращений клиентов.
При браузерной автоматизации проверяйте видимое поведение и устойчивые ориентиры интерфейса. Playwright рекомендует изолированные тесты и локаторы, связанные с тем, что видит пользователь. Практики Playwright.
Скриншот подтверждает видимое состояние, но не всю цепочку. Для заявки дополнительно проверьте, что обработчик получил нужные поля, запись появилась в тестовой системе, а повторное нажатие не создало дубль.
Как использовать второго агента для ревью
Дайте ему исходное задание, diff и доступные результаты проверок. Попросите искать нарушения условий и объяснять, как их воспроизвести. Не сообщайте заранее, что первый агент «всё исправил правильно».
Полезная формулировка:
Проверь изменения относительно условий задачи. Для каждого замечания укажи файл, условие возникновения ошибки и способ проверки. Не перечисляй общие рекомендации без связи с этим diff. Отдельно отметь, что нельзя подтвердить по доступным данным.Ревью второго агента — дополнительный источник вопросов. Решение о корректности всё равно должно опираться на код и проверки. Если замечание спорное, воспроизведите сценарий вместо голосования между моделями.
Что включить в отчёт о готовности
Сохраните короткий документ, который можно проверить позже:
Изменение: что исправлено и в каких файлах.
Проверено: команды, условия и результаты.
Сценарий: какие действия выполнены в приложении.
Не проверено: ограничения окружения и оставшиеся вопросы.
Решение: принять, доработать или запросить дополнительные данные.Не маскируйте неопределённость формулировкой «в целом работает». Если тестовый сервис недоступен, прямо укажите, что конечная доставка не подтверждена. Это позволяет принять осознанное решение о следующем шаге.