Агент по умолчанию не задаёт уточняющих вопросов. И вот здесь начинается самое интересное.

Человек, наткнувшись на дыру в спецификации, скорее всего придёт и спросит, что имелось в виду. Агенту же нужно продолжать работу, поэтому он вполне способен закрыть эту дыру самостоятельно. Молча, правдоподобно и так, что вы заметите принятое за вас решение только на приёмке.

Хуже того: в следующем прогоне он может закрыть ту же дыру уже иначе.

Есть три места, где я особенно часто вижу такие проблемы.

1. «И так далее». Если список не дописан, агенту приходится решить, что именно скрывается за этими словами. В итоге вы получаете не продолжение своего списка, а вполне логичную интерпретацию модели.

2. Отсутствующие границы. В спецификациях хорошо описывают, что система должна делать, и гораздо реже — чего она делать не должна. Для человека часть этих границ может быть очевидна из контекста. Агент этого контекста не знает и начинает вполне добросовестно достраивать функциональность, которую никто не заказывал.

3. Молчаливые решения. «Тут и так понятно», «мы это обсуждали на встрече», «все знают, почему выбрали именно так». Пока решение живёт в голове команды, для агента его просто не существует. Он примет своё, а через месяц уже никто не вспомнит, откуда вообще взялось текущее поведение системы.

Поэтому перед тем, как отдавать спецификацию агенту, я теперь проверяю не только то, что в ней написано, но и то, что агенту придётся додумать самому.

Собрал 12 таких мест в один чек-лист. Проверка занимает примерно минуту на пункт — и делать её лучше до того, как агент начал писать код, а не после того, как его интерпретация превратилась в работающую систему.

👉 Чек-лист:https://analystcraft.ru/blog/checklist-spec-dlya-agenta?utm_source=tg_spherical&utm_medium=social&utm_campaign=lm02_checklist&utm_content=20260811-checklist-spec