Начните с изменения, а не с роли
Фраза «почини страницу» оставляет агенту слишком много решений. Опишите наблюдаемое поведение: на узком экране кнопка остаётся видимой, форма отправляется клавиатурой, ошибка связана с полем. Укажите файлы или модуль, которые можно менять, и отдельно перечислите запреты. Чем выше риск, тем уже первая задача. Агент не получает право переписывать архитектуру только потому, что так короче.
Подготовьте чистую точку старта
Создайте отдельную ветку или рабочую копию, сохраните статус тестов и зафиксируйте версии зависимостей. Секреты замените тестовыми значениями. Если проект уже имеет несвязанные ошибки, перечислите их, иначе агент может приписать себе старое падение или начать чинить постороннее. Исходное состояние должно восстанавливаться одной понятной операцией.
Дайте минимальные права
Для чтения репозитория не нужны ключи продакшена. Для теста платежа нужен фиктивный шлюз, а не реальная карта. Разрешите только нужные команды и каталоги, ограничьте сеть и ресурсы. Не полагайтесь на просьбу в промпте «ничего не удаляй»: опасные действия блокируются окружением. Журнал должен сохранять вызовы инструментов и коды завершения.
Определите пакет результата
Попросите краткое объяснение причины, список изменённых файлов, diff, выполненные команды, результаты тестов и то, что не проверялось. Для интерфейса добавьте снимки ключевых состояний; для данных — контрольные суммы и примеры отклонённых строк. Пакет не должен включать длинный пересказ процесса. Проверяющему нужны координаты, по которым он воспроизводит результат.
Читайте diff по риску
Сначала смотрите зависимости, авторизацию, запросы к базе, обработку ошибок и удаление данных. Затем — бизнес-условия и интерфейс. Большой механический форматирующий diff отделяйте от смыслового изменения. Если агент обновил десятки файлов ради маленькой задачи, верните работу на сокращение. Малый прозрачный патч легче проверить и откатить.
Запускайте тесты независимо
Не принимайте скопированный зелёный вывод. В чистом окружении установите зависимости по lock-файлу, соберите проект и запустите обязательный набор. Добавьте хотя бы один тест, которого не было в задании: пограничное значение, повторный запрос или отсутствие сети. Это проверяет, что решение следует смыслу, а не только известному примеру.
Проверьте пользовательский маршрут
Откройте страницу как новый пользователь, пройдите клавиатурой, включите узкий экран и медленную сеть. Для API отправьте корректный, пустой и ошибочный запрос. Сравните состояние до и после. Снимок результата дополняет тесты, но не заменяет их: он показывает один момент и может скрывать ошибку в консоли.
Ищите ослабленные проверки
Распространённый ложный успех — агент удаляет падающий тест, расширяет допустимый тип, глотает исключение или подставляет значение по умолчанию. Сравните количество тестов, настройки линтера и уровень предупреждений. Ошибка должна быть исправлена, а не спрятана. Любое изменение политики безопасности или валидации требует отдельного согласования.
Проверьте зависимости и лицензию
Новый пакет может решить задачу в одну строку и добавить десятки транзитивных компонентов. Убедитесь, что имя не перепутано, владелец и репозиторий настоящие, версия поддерживается, а лицензия совместима с проектом. Посмотрите изменение lock-файла и известные уязвимости. Если функция проста, небольшой собственный код иногда прозрачнее новой зависимости.
Отделите авторство от ответственности
В журнале можно отметить, что черновик подготовлен агентом, но владельцем изменения остаётся сотрудник, который его принял. Он отвечает за соответствие требованиям и может объяснить решение. Нельзя назначать ревьюером человека, который не имеет времени открыть diff: формальная галочка не снижает риск и создаёт ложное чувство контроля.
Проведите ревью без подсказки агента
Сначала ревьюер читает задачу и diff, затем — пояснение исполнителя. Иначе уверенный отчёт задаёт рамку и мешает заметить пропущенное. Попросите человека кратко сформулировать риск своими словами и назвать тест, который он добавил бы. Если изменение невозможно объяснить без нового запроса модели, принимать его рано.
Соберите стоп-лист задач
Не все работы подходят для первой автоматизации. Миграции без резервной копии, изменение доступа, удаление данных и срочный патч в незнакомом модуле оставьте человеку. Стоп-лист пересматривают после накопления доказательств, но не обходят ради скорости. Один удачный безопасный патч не подтверждает готовность агента к необратимым операциям.
Выпускайте постепенно
Даже прошедший патч сначала попадает на малую долю трафика или внутреннюю группу. Наблюдайте ошибки, задержку и выбранную бизнес-метрику. Подготовьте обратимое переключение до релиза и назначьте владельца. Если откат требует снова просить агента написать код, это не откат.
Закройте цикл
После приёмки сохраните найденную ошибку как регрессионный тест и обновите короткую инструкцию агенту. Измерьте время постановки, работы, проверки и исправлений. Частые возвраты по одной причине говорят о плохом контракте или слабой среде. Хороший регламент делает следующую задачу предсказуемее, а не просто добавляет ещё один отчёт. Раз в месяц удаляйте устаревшие исключения и проверяйте, что процедура соответствует реальному CI, ролям и способу выпуска. Иначе документ останется красивым, но команда снова начнёт принимать работу по сообщению в чате.