Spec-Driven Development работает потому, что выносит неясность вперёд — в файлы, которые можно читать, ревьюить, версионировать и использовать повторно, — вместо того чтобы оставлять её запертой в последнем окне чата. Чат удобен. Память у него хуже, чем кажется.
Память чата
План живёт в последнем разговоре.
- намерение плывёт между сессиями
- архитектура каждый раз придумывается заново
- handoff зависит от памяти и вкуса
След в файлах
Работа оставляет устойчивый след в репозитории.
- другой инженер может проследить ход мысли позже
- tickets наследуют архитектуру, а не гадают о ней
- agents исполняют понятный путь, а не импровизируют
1. Почему SDD всё ещё важен в 2026
AI coding ускорился, но не отменил старую проблему engineering: неясное намерение.
SDD полезен тем, что даёт и человеку, и агенту устойчивый след:
- что именно нужно сделать
- как выглядит хороший результат
- какое исследование важно
- какая архитектура выбрана
- какие tickets ещё открыты
Без этого каждая новая сессия быстро превращается в театр памяти.
2. Текущий цикл стал компактнее и строже
Полезная версия SDD сейчас достаточно маленькая:
- инициализировать workspace
- написать project brief
- собрать repo-aware prompts
- получить research и architecture artifacts
- синхронизировать backlog files
- реализовать по открытому backlog
- прогнать janitor и status
Важно не имя script, а то, что каждый этап оставляет за собой файл, который потом можно проверить.
3. Агент не должен быть первым шагом
Открывать разговор с «build X» — почти гарантированный способ получить правдоподобный, но слегка cursed output.
Более здоровый порядок такой:
- описать задачу в
.sdd/project.md - собрать research в
.sdd/best_practices.md - зафиксировать решения в
.sdd/architect.md - материализовать work items в
.sdd/backlog/open/ - только потом запускать implementation agent
Так роль агента меняется с guesser на executor.
4. Tickets — мост между архитектурой и кодом
Слой tickets недооценивают чаще всего.
Когда архитектурный шаг выдаёт machine-readable appendix, репозиторий может превратить его в backlog files вместо того, чтобы надеяться на память.
Это даёт:
- меньший объём реализации
- явные условия готовности
- более чистую работу janitor
- более понятный handoff между людьми и агентами
5. Research и архитектура должны сжимать решения
Лучшие SDD-артефакты не пытаются звучать исчерпывающе. Они делают решения видимыми.
Хороший research doc отвечает:
- какие practices актуальны сейчас
- какие trade-offs важны
- какие constraints не обсуждаются
Хороший architecture doc отвечает:
- какой путь выбран
- почему именно он
- какие интерфейсы или сценарии меняются
- как работа дробится на implementable tickets
6. Janitor важнее, чем кажется
Workflow, который умеет открывать tickets, но плохо умеет закрывать их по repo evidence, очень быстро начинает выращивать красивую пыль.
Janitor нужен именно для того, чтобы active backlog оставался правдоподобным. Это особенно важно, когда в цикле участвуют несколько инженеров или несколько agents.
7. Итог
SDD не про paperwork. Он про то, чтобы неясность и архитектурный замысел жили не в памяти чата, а в reviewable files. Для агентных рабочих процессов это не украшение, а одна из главных форм устойчивости.