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