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