Сервис должен снова принять запрос
За сотни бизнес-задач я увидел один повторяющийся риск: агент может аккуратно решить соседнюю задачу. Возьму собирательный пример. После обновления сервис работает на компьютере разработчика, а запрос в тестовом окружении падает. Если я прошу просто «разобраться с конфигурацией», агент может привести файлы в порядок и не починить запрос.
В таком случае я формулирую результат иначе: сервис принимает запрос в тестовом окружении, прежний способ подключения продолжает работать, ошибка не возвращается. Теперь понятно, что проверять. Изменение в файле остаётся одним из шагов.
Для этой задачи я даю агенту сообщение об ошибке, рабочие настройки и одно условие: сохранить прежний способ подключения. Остальные подробности он ищет, только если они понадобятся.
Другой участник проверяет последствие
В этом собирательном сценарии проверку я бы отдал другому агенту. Он открыл бы тестовый адрес и отправил тот же запрос. Автор изменения ждёт увидеть успех, а новый взгляд легче замечает расхождение.
Этой одной проверки достаточно. Пока запрос падает там, где сервисом будут пользоваться, аккуратный файл на компьютере разработчика не решает задачу.
Как этот опыт меняет Arcanada
Я строю Arcanada как общую среду для своих долгих проектов с агентами. Она появилась, когда два больших замысла пришлось вести рядом с коммерческой работой и необходимостью поддерживать семью. Сейчас Arcanada помогает мне держать исходную просьбу рядом с изменением и замечать расхождение до того, как я приму результат.
Получив аккуратное изменение, я задаю один последний вопрос: принимает ли сервис нужный запрос там, где им будут пользоваться? Если запрос всё ещё падает, задача не закончена.