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