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

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

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

Контекст

Разработчик сразу указывает функции, библиотеку и порядок вызовов, хотя ещё не объяснил цель задачи.

Проблема

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

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

• Подробная инструкция создаёт ощущение контроля над результатом.
• Продиктовать уже придуманный план кажется быстрее, чем объяснить цель.
• Разработчик переносит в запрос свой первый вариант решения без сравнения альтернатив.

Последствия

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

Признаки

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

Как лучше

Сначала опишите цель, ограничения и критерии готовности. Попросите агента предложить подход. Конкретную реализацию задавайте там, где она следует из обязательного контракта или требования совместимости, и объясняйте это ограничение.

Пример

Было

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

Стало

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

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

• Четыре фазы позволяет исследовать задачу перед выбором реализации.