Кому нужен Spec-Driven Development в brownfield-проектах

Что такое SDD без мифов, какие три проблемы он реально решает и когда только мешает. Плюс чем отличаются OpenSpec, Superpowers, BMAD и Spec Kit, что делать со спеками в проекте с большой кодовой базой и нужен ли SDD в ноябре 2026

Егор Толстой

Инструменты для разработчиков, ведёт Podlodka Podcast

Teamlead Good Reads

Главное за минуту

SDD это инженерная практика: вместе с агентом проработать задачу, собрать спеку и вести по ней агента и при написании кода, и при проверке. Работают change specs на одно изменение, а living specs, которые всегда верно описывают систему, пока остаются мечтой на костылях.

SDD решает три проблемы. Эффективное окно около 256K, а не миллион, поэтому работу режут на короткие сессии. Агент сам заполняет дыры в интенте. Параллельные агенты выматывают переключениями, и лучше плотно поработать на старте, а потом отпустить агента надолго.

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

В большом проекте эксперимент начинают с нескольких фич или одной команды и не коммитят спеки сразу, иначе получится ад из markdown. Spec review ловит архитектурный дрифт до кода, но код читать никто не перестал.

К ноябрю 2026 окно контекста уже не довод, а плотность смысла и ментальная нагрузка остаются. Решать их можно и без SDD, а OpenSpec ценен тем, что дает готовый бейзлайн и не надо целыми днями докручивать харнес.

Я 6 лет работал над Kotlin, а сейчас делаю AI-тул стартап CodeSpeak (ну а что еще делать в 2026) и уже 10 лет подкаст Подлодка. Kotlin во многом полетел за счет эргономики, и мы вкладывались даже в супермелкие детали. В одном из релизов заменили ключевое слово until в рейнджах на оператор ..<, и одно это уменьшило количество ошибок при чтении такого кода на 90%.