Что это
Spec-Driven Development (SDD) переворачивает привычную иерархию: спецификация не обслуживает код — код обслуживает спецификацию. Ты начинаешь с детального спека (контракт того, как должна вести себя система), и он становится источником истины, по которому агенты генерируют, тестируют и валидируют код. Спека — живой исполняемый артефакт, а не документ «после факта».
Откуда пошло
- 2 сентября 2025 — GitHub анонсировал Spec Kit, open-source тулкит для SDD, как осознанный «антидот хаотичному vibe-coding».
- Базовый процесс:
Specify → Plan → Tasks → Implement(опиши «что и зачем» → план под стек → разбивка на проверяемые задачи → реализация). - Параллельно ту же идею «спека-как-контракт» продвигали методологии вроде Quest-конвейера (EARS-требования + дизайн → план → исполнение с проверкой).
Почему взлетело
- Чистый вайб не масштабируется: на проде нужен артефакт, который проверяет и человек, и агент.
- Спека даёт агенту рамку — резко меньше «творческой отсебятины» и проще ревью (смотришь на изменения относительно контракта).
- Поддержка из коробки: Spec Kit работает с 30+ агентами (Claude Code, Copilot, Gemini CLI, Cursor, Codex), репозиторий быстро набрал ★90k+.
Как применить сейчас
- Перед крупной фичей напиши короткий спек: цель, поведение, критерии приёмки (а не сразу «напиши код»).
- Прогоняй цикл Spec → Plan → Tasks → Implement; ревьюй на каждом стыке.
- Держи спеку в репозитории рядом с кодом — обновляй её первой при смене требований.
На что обратить внимание
- Для мелкой правки SDD — оверкилл; применяй на нетривиальном.
- Спека без verify — просто текст; ценность в том, что из неё выводятся проверяемые задачи и тесты.
- Риск «спека ради спеки»: держи её исполняемой (критерии приёмки → тесты), иначе она устаревает.