SDD: почему все туда идут и что там на самом деле

Spec-Driven Development (SDD) за год стал главным словом в разработке с агентами: AWS выпустил Kiro, GitHub — Spec Kit, появились OpenSpec и Tessl, доклады про SDD идут на каждой конференции. Идея простая → перед тем как агент пишет код, человек пишет спецификацию, и агент работает по ней, а не по чату из десяти сообщений. Озвучу интересный тезис → SDD в его нынешнем виде — это очередная инкарнация водопада, только артефакты теперь в markdown, а исполнитель — LLM. Разберу, почему все туда идут, что в SDD работает, где он ломается и какие есть альтернативы.

Откуда хайп: старая теория под новую практику

Любая новация в отрасль приходит по одному сценарию. Сначала появляется успешная практика → ИИ-copilot у разработчика, вайбкодинг у бизнеса. Практика работает, но её никто не понимает, и под неё достают старую теорию. Для агентной разработки такой теорией стал SDD: «сначала спецификация, потом код» — это ровно то, чему учили в 90-е. Теория работает плохо, и сквозь неё прорастает уже другая практика. Мы сейчас на второй стадии.

Почему достали именно спецификации → потому что вайбкодинг упирается в предел. Пока задача на один промпт, контекст живёт в чате. Как только фича растягивается на дни и десятки сессий, агент теряет намерение, переписывает уже сделанное и уверенно делает не то. Одна строчка в тикете, которая раньше стоила десять минут недопонимания, теперь стоит три часа работы агента и убедительный PR с неправильной фичей. Отсюда естественная реакция → давайте всё запишем заранее.

Что такое SDD на практике

Под одним словом живут три разных подхода, и это главный источник путаницы. В январе 2026 вышел практический гайд на arXiv, где их наконец назвали (Piskala, Spec-Driven Development: From Code to Contract (https://arxiv.org/abs/2602.00180)):

→ Spec-first — спека пишется до кода и служит входом для агента, дальше живёт как документация. Так работают Kiro и Spec Kit.

→ Spec-anchored — спека хранится рядом с кодом и обновляется при каждом изменении. Так устроен OpenSpec с его delta specs.

→ Spec-as-source — спека и есть исходник, код генерируется из неё и в идеале не правится руками. Это Tessl, самый радикальный вариант.

У инструментов похожий скелет. Kiro от AWS ведёт через три стадии → requirements (в нотации EARS), design, tasks. GitHub Spec Kit добавляет «конституцию» — неизменяемые принципы проекта, и команды /specify → /plan → /tasks → /implement. OpenSpec хранит запросы на изменение в виде proposal.md, design.md, tasks.md и spec.md, после внедрения спека мержится в основную и уходит в архив. Во всех случаях артефакты — это markdown в репозитории, который читают и люди, и агенты.

SDD — очередная инкарнация водопад

Теперь положим артефакты OpenSpec на классическую схему водопада. Requirements → proposal.md. Design → design.md плюс tasks.md. Implementation → код по спеке specs/spec.md. Verification → проверка, что сделано по спеке. Maintenance → архив изменения. Совпадение один в один, только раньше по этапам шли люди, а теперь — агент, и этап занимает часы, а не месяцы.

Почему это важно → водопад проиграл не потому, что был плохо реализован, а потому, что требования невозможно зафиксировать заранее: понимание задачи появляется в процессе её решения. Agile был ответом именно на это. SDD возвращает фиксацию требований «до», просто потому что агенту так удобнее. Принцип zero assumption — агент не должен ничего додумывать — требует в постановке гораздо больше деталей, чем нужно живому разработчику. Живой разработчик додумает по контексту и переспросит; агента надо этому научить, либо он галлюцинирует, либо требует, чтобы всё было написано.

Есть и честный контраргумент → цикл стал коротким. Если итерация водопада занимает день, а не год, многие его болезни не успевают проявиться. Это правда, но она работает только до тех пор, пока спека помещается в голову ревьюера. А вот с этим у SDD проблема.

Где SDD реально работает

Было бы нечестно сводить всё к «водопад, расходимся». У SDD есть зона, где он даёт результат, и она понятная.

→ Длинные задачи с агентом. Фича на неделю и десять сессий без письменного намерения не живёт: агент забывает, что уже решили. Спека здесь — внешняя память, и это её главная функция, а не «документация».

→ Brownfield и архитектурные границы. Эксперименты Thoughtworks со Spec Kit шли в основном на существующих системах, и «конституция» с ограничениями по стеку, структуре репозитория и стандартам кода реально удерживала агента в архитектуре. Это работает лучше, чем правила в системном промпте, потому что проверяется на каждом шаге.

→ Параллельная работа. Когда одна фича декомпозирована на tasks.md, несколько агентов могут идти параллельно, не ломая друг друга. Без спеки параллелизм превращается в конфликты.

→ Регулируемые отрасли. Где нужен след «требование → реализация → проверка», SDD даёт его бесплатно: артефакты уже лежат в репозитории и привязаны к коммитам.

→ Ревью становится предметным. Ревьюить спеку на одну страницу легче, чем PR на две тысячи строк, который агент сгенерировал за полчаса. Хотя бы потому, что в спеке видно намерение, а в diff — нет.

Общее у всех пунктов → SDD хорош там, где спека короткая, а ограничения стабильные. Проблемы начинаются, когда она растёт.

Где SDD ломается: спецификацию некому проверить

Главная проблема внедрения SDD — не инструменты, а проверка спеки. Если в спецификации технический дизайн (а zero assumption толкает именно туда), то для хорошего результата нужно много деталей, и спека становится плохо проверяемой.

→ Бизнес её точно не проверит, и она ему не нужна → он хочет знать, что фича делает, а не как устроены таблицы.

→ Разработчики проверяют её тяжело → читать чужой технический дизайн на десять страниц сложнее, чем написать свой.

→ Проверка не гарантирует, что сделано то, что нужно бизнесу → можно идеально реализовать неправильное намерение.

→ Проверка не гарантирует, что код соответствует спеке → агент по-прежнему может отклониться, и это ловят только тесты.

→ Разработчики теряют мотивацию → их учили писать код, а не ревьюить технический дизайн. Есть и системный эффект, который я бы сформулировал → внедрение по площади не ускорит бизнес, узкое место будет последним.

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

И последнее → спеки растут. Спека и контекст проекта может раздуваться до тех пор, пока агент не начинает терять нить. Выигрывали те, кто держал спеку худой и оставлял ревью в процессе, а не те, кто описывал всё.

Альтернативы есть

Первая → спека намерения вместо технического дизайна. Опыт Райффайзена, о котором рассказывал Андрей Усенко на AI Native: спецификация должна снижать неопределённость намерения, а не описывать реализацию. Что хотим получить, какие граничные случаи, что считаем ошибкой. Как это устроено внутри — решает агент в рамках архитектурных ограничений. Такую спеку может проверить бизнес, и она не раздувается.

Вторая → TDD/BDD: тест-кейсы вместо дизайна. Acceptance criteria и тест-кейсы проверять легче, чем дизайн-документ, бизнес их понимает и готов обсуждать. Тест-кейсы могут писать агенты — нужны только критерии хороших сценариев. Вместо дизайна задаём архитектуру и шаблоны, дальше работают агенты, а проверять полезно точки выбора и принятия решений, а не каждую строчку. Показательный пример → доклад Виталия Левченко «SDD, или Как кратно ускорить разработку с LLM» на Codefest-2026: в названии SDD, а по сути — архитектурные принципы и тесты, по которым спецификацию и код итеративно доводят агенты. То есть успешная практика уже прорастает сквозь теорию и называется по-старому.

Третья → рельсы и harness для типовых задач. Сайт-визитка, типовой интернет-магазин, типовая CRM малого бизнеса — таких задач много, и раньше их делала пара аналитик + разработчик на базовом решении с точками кастомизации. Теперь разработчик строит скелет решения с ограничениями и проверками, аналитик вайбкодит специализированное решение поверх, а разработчик смотрит, где возникают проблемы, и докручивает скаффолдинг.

Общее у трёх альтернатив → они не фиксируют решение заранее. Они фиксируют границы и критерии приёмки, а решение оставляют итерациям. Это и есть то, чему agile научил нас двадцать лет назад.

Что с этим делать

SDD — не ошибка, а естественная стадия освоения новой практики отраслью. Через год термин, скорее всего, останется, а содержание сменится: от «подробная спека до кода» к «короткая спека намерения + тесты + harness».

Для команд это значит → не внедрять SDD по площади. Взять инструмент на одну длинную фичу, где он сильнее всего, держать спеку на одну-две страницы и смотреть, где реально узкое место. Если оно в принятии решений, а не в написании кода, SDD его не сдвинет.

А что про тестировщиков. Тут говорю прямо, шанс в том → тестировщик может стать прикладным разработчиком. Acceptance criteria, тест-кейсы и пирамида тестирования ему знакомы; если писал автотесты — разбирается в коде; навыки аналитика должны быть. В мире, где спецификацией становятся критерии приёмки и тесты, тот, кто умеет их писать и проверять точки принятия решений агента, оказывается в центре процесса, а не на его хвосте. А вот в мире рельсов и harness место тестировщика ещё предстоит искать — и лучше искать его активно.