Промптинг заканчивается. Начинается инженерия спецификаций
Промптинг заканчивается. Начинается инженерия спецификаций
Последние полтора года нас учили правильно разговаривать с AI:
«Дайте модели роль».
«Добавьте больше деталей».
«Сформулируйте хороший промпт».
Но чем сложнее становятся AI-агенты, тем меньше результат зависит от магии формулировок.
Проблема чаще всего не в промпте. Агенту просто не хватает контекста.
Сегодня Claude, Codex и другие агенты уже не отвечают на один изолированный вопрос. Они читают репозиторий, открывают файлы, меняют код, запускают тесты и создают pull request.
То есть работают не внутри промпта, а внутри проекта.
И здесь быстро выясняется неприятная вещь: если команда не умеет описывать задачу, ограничения, архитектуру и критерии готовности, никакая модель это не исправит.
Плохая постановка задачи остаётся плохой постановкой задачи. Просто теперь она быстрее превращается в плохой код.
Поэтому на первый план выходит не Prompt Engineering, а Context Engineering. Или, точнее, инженерия спецификаций.
Агенту нужны:
- понятный README;
- правила проекта;
- архитектурные ограничения;
- ADR и Decision Log;
- описание API и бизнес-логики;
- соглашения по именованию;
- Definition of Ready и Definition of Done;
- проверяемые критерии приёмки;
- примеры правильного и неправильного поведения.
Раньше документация помогала разработчикам быстрее разобраться в проекте. Теперь она становится ещё и интерфейсом между командой и AI-агентами.
Причём хороший контекст полезнее длинного промпта. Если архитектурные решения нигде не записаны, агент начнёт их угадывать. Если критерии готовности размыты, он сам решит, когда задача закончена. Если бизнес-правила существуют только в голове у разработчика, модель о них не узнает.
Можно сколько угодно улучшать формулировку запроса. Но нельзя промптом компенсировать отсутствие спецификации.
Поэтому самый полезный AI-инструмент следующего года может оказаться не новой моделью.
А хорошей документацией.
Кажется, мы постепенно переходим от умения «правильно попросить» к умению точно описать, что нужно построить, в каких границах и как проверить результат.
От Prompt Engineering к Context Engineering.
И это уже не навык общения с моделью. Это обычная инженерия, которую мы слишком долго откладывали.
Последние полтора года нас учили правильно разговаривать с AI:
«Дайте модели роль».
«Добавьте больше деталей».
«Сформулируйте хороший промпт».
Но чем сложнее становятся AI-агенты, тем меньше результат зависит от магии формулировок.
Проблема чаще всего не в промпте. Агенту просто не хватает контекста.
Сегодня Claude, Codex и другие агенты уже не отвечают на один изолированный вопрос. Они читают репозиторий, открывают файлы, меняют код, запускают тесты и создают pull request.
То есть работают не внутри промпта, а внутри проекта.
И здесь быстро выясняется неприятная вещь: если команда не умеет описывать задачу, ограничения, архитектуру и критерии готовности, никакая модель это не исправит.
Плохая постановка задачи остаётся плохой постановкой задачи. Просто теперь она быстрее превращается в плохой код.
Поэтому на первый план выходит не Prompt Engineering, а Context Engineering. Или, точнее, инженерия спецификаций.
Агенту нужны:
- понятный README;
- правила проекта;
- архитектурные ограничения;
- ADR и Decision Log;
- описание API и бизнес-логики;
- соглашения по именованию;
- Definition of Ready и Definition of Done;
- проверяемые критерии приёмки;
- примеры правильного и неправильного поведения.
Раньше документация помогала разработчикам быстрее разобраться в проекте. Теперь она становится ещё и интерфейсом между командой и AI-агентами.
Причём хороший контекст полезнее длинного промпта. Если архитектурные решения нигде не записаны, агент начнёт их угадывать. Если критерии готовности размыты, он сам решит, когда задача закончена. Если бизнес-правила существуют только в голове у разработчика, модель о них не узнает.
Можно сколько угодно улучшать формулировку запроса. Но нельзя промптом компенсировать отсутствие спецификации.
Поэтому самый полезный AI-инструмент следующего года может оказаться не новой моделью.
А хорошей документацией.
Кажется, мы постепенно переходим от умения «правильно попросить» к умению точно описать, что нужно построить, в каких границах и как проверить результат.
От Prompt Engineering к Context Engineering.
И это уже не навык общения с моделью. Это обычная инженерия, которую мы слишком долго откладывали.