Spec-Driven Development: что происходит, когда бизнес перестаёт ждать инженеров

Средний цикл разработки новой корпоративной фичи — от трёх до шести месяцев. К моменту выпуска рынок сдвинулся, приоритеты поменялись, часть исходных требований больше не отражает реальность. Никто не виноват. Процесс работает именно так, как спроектирован. В этом и проблема.

Spec-Driven Development — попытка сломать модель, а не залатать её.

Где на самом деле ломается традиционная разработка

Классический процесс создания ПО — испорченный телефон. Бизнес формулирует идею. Аналитик её интерпретирует. Архитектор переводит в техническую спецификацию. Разработчик читает эту спецификацию через призму собственной ментальной модели. QA тестирует то, что построено, а не то, что подразумевалось. На каждом переходе сигнал деградирует — и к моменту выхода продукт реализует нечто близкое к первоначальному замыслу, но не совсем его.

Это не проблема таланта. Это проблема архитектуры. Слишком много интерпретаторов между намерением и результатом.

Второй режим отказа — стоимость изменений. Исследования в области управления требованиями стабильно показывают: исправление ошибки, допущенной на этапе требований, обходится в 5–10 раз дороже, когда она уже встроена в рабочий код. Бизнес это знает — и избегает менять требования. Инженерия это знает — и сопротивляется изменениям объёма. Обе стороны работают с устаревшей картиной реальности — лишь бы не получить счёт за переделку.

Что на самом деле меняет SDD

Центральная идея обманчиво проста: спецификация становится главным управляющим артефактом всего проекта, а ИИ-агенты выполняют техническую реализацию.

Бизнес описывает, что должна делать система — простым языком, без технического жаргона. ИИ-агент определяет, как это реализовать. Инженер контролирует качество и корректность перевода. Код становится производной спецификации — а не наоборот.

Три вещи меняются фундаментально.

Скорость. Рабочий прототип новой фичи — за дни, не недели. Параллельное тестирование нескольких гипотез одновременно. Быстрая валидация бизнес-идей без запуска полноценного спринта. Bain & Company сообщают, что инструменты ИИ уже сжимают циклы разработки на 20–30%. SDD идёт дальше: автоматизирует не только генерацию кода, но и трансляцию требований — самый медленный и дорогой этап всего процесса.

Стоимость изменений. В традиционной разработке изменение требований посреди проекта — почти кризис. В SDD — рутинная операция. Поскольку код генерируется из спецификации, а не пишется вручную, его регенерация практически ничего не стоит. Это полностью меняет логику принятия решений: команды могут экспериментировать, проверять гипотезы и менять направление, не опасаясь счёта за переделку.

Конкретный пример: команда строит архитектуру вокруг определённой бизнес-модели, а через месяц обнаруживает, что модель ошибочна. В традиционной разработке это три-четыре месяца выброшенной работы. В SDD спецификация корректируется за день. Код регенерируется за часы.

Прозрачность. Спецификация — не технический документ, а бизнес-документ. Нетехнические стейкхолдеры могут её читать, проверять и менять. Бизнес видит, что именно будет построено, ещё до начала разработки. Любое отклонение от бизнес-логики всплывает на уровне спецификации, а не после релиза. Вся история изменений требований версионирована и прозрачна.

Что это делает с командой

SDD не устраняет инженеров. Он меняет то, что делает их ценными. Глубина стека значит меньше. Архитектурное мышление и способность формализовать требования — больше. Один инженер, оркестрирующий ИИ-агентов, теперь покрывает объём, который раньше требовал трёх-четырёх специалистов.

McKinsey фиксирует рост производительности на 20–45% в организациях, системно внедривших ИИ в свои процессы разработки. SDD усиливает этот эффект, автоматизируя полный цикл — от требований до кода.

Есть менее очевидный эффект, который стоит назвать: сохранение знаний. В традиционной модели бизнес-логика живёт в головах людей. Когда ключевой инженер уходит, критическое институциональное знание о том, почему система работает именно так, уходит вместе с ним. В SDD спецификация — живой документ, содержащий полное описание бизнес-логики системы. Новый член команды читает её и сразу понимает всю систему.

Где работает лучше всего

SDD даёт максимальный эффект в определённых ситуациях. Стартапы с высокой неопределённостью требований и частыми пивотами — стоимость экспериментов падает почти до нуля. Конкурентные рынки с быстрыми релизными циклами — скорость доставки новых фич напрямую влияет на долю рынка. Регулируемые среды — требования комплаенса встраиваются в спецификацию и автоматически проверяются при каждом изменении. Модернизация legacy-систем — спецификация существующей системы пишется один раз и становится основой для управляемой миграции.

Честная оговорка

SDD не решает плохо сформулированные требования — он их обнажает. Если бизнес не может чётко описать, что должна делать система, ни один ИИ-агент эту лакуну не заполнит. Качество спецификации становится критическим узким местом. Это новая компетенция, которую нужно развивать — и со стороны бизнеса, и со стороны инженерии.

Но именно в этом смысл сдвига. SDD не автоматизирует мышление. Он убирает всё, что стоит между мышлением и результатом.