Преждевременная спецификация

Также известен как

Premature Specification, «решение вместо задачи».

Контекст

Разработчик ставит задачу агенту и вместо цели сразу описывает конкретную реализацию: какие функции вызвать, какую библиотеку взять, в каком порядке выполнять шаги.

Проблема

Агенту передают технические подробности «как делать», минуя «что нужно и зачем». Задача формулируется как готовый план реализации, а не как проблема, которую надо решить.

Почему так делают

• Иллюзия контроля: кажется, что подробная инструкция снижает риск.
• Ощущение скорости: проще продиктовать свой план, чем объяснять цель.
• Перенос собственного черновика решения — возможно, не самого удачного.

Последствия

• ➖ Агент не привлекает свои знания к выбору подхода — вы теряете более простые или надёжные варианты, которые он мог бы предложить.
• ➖ Фиксируется преждевременное, часто неоптимальное решение; потом вы отлаживаете собственные ранние допущения.
• ➖ Сужается пространство решений: агент оптимизирует указанный механизм, а не исходную цель.
• ➖ Труднее заметить, что задача вообще сформулирована неверно.

Признаки

• В промпте больше «как», чем «что» и «зачем».
• Перечислены конкретные функции/библиотеки/шаги без обоснования.
• Названы приёмы реализации раньше, чем описан желаемый результат.

Как лучше

Сначала опишите цель, контекст, ограничения и критерии готовности — а «как» оставьте агенту. Фиксируйте реализацию только там, где это настоящее ограничение (контракт API, инвариант, совместимость), и помечайте такие места явно.

Пример

Было:

Добавь дебаунс на 300 мс через lodash.debounce в обработчике onChange поля поиска.

Стало:

Поле поиска шлёт запрос на каждый ввод символа и перегружает бэкенд. Хочу, чтобы запрос уходил только когда пользователь закончил печатать. Предложи подход; внешний контракт компонента менять нельзя.

Связанные паттерны и анти-паттерны

• Четыре фазы — паттерн, фаза плана которого вырождается в преждевременную спецификацию, если требовать детализации до понимания задачи.