Самый частый риск в коде от ассистента — не ошибка в новой функции. Он «заодно» меняет соседний слой: переименовывает интерфейс, тащит зависимость, переписывает обработку ошибок.
Поэтому перед задачей я задаю границы изменений. Это как попросить мастера заменить кран, а не обновить всю ванную.
Добавь экспорт отчёта в CSV.
Не меняй публичные API, схему БД и формат существующих ответов.
Не добавляй зависимости.
Изменения — только в модуле reports и его тестах.
Если без изменения границ задача не решается, сначала объясни почему, не пиши код.Такой промпт не делает модель умнее. Но резко сокращает пространство её инициативы — а значит, и число сюрпризов на ревью.
После ответа отдельно проверьте: какие файлы затронуты, не изменились ли контракты и не появился ли «временный» обходной путь.
Приём не нужен для нового изолированного прототипа. Там свобода полезнее. Но в рабочем сервисе ограничения часто ценнее самого описания фичи.