Spec-Driven Development с ИИ: как разрабатывать от спецификации, а не наугад

Коротко (TL;DR)

Spec-Driven Development (SDD) — это подход, при котором вы сначала пишете формальную спецификацию (что и как должно работать), а ИИ-агент по ней генерирует план, а затем код, сверяя результат с заданными критериями. Спека становится контрактом между вами и агентом.

Зачем это нужно: обычный «вайб-кодинг» часто выдаёт код, который работает, но делает не то, что вы имели в виду. SDD закрывает этот разрыв — ценой оверхеда. Формальная спека добавляет к разработке часы работы и десятки страниц markdown, и это оправдано не всегда.

Что важно знать сразу:

• Основные инструменты — GitHub Spec Kit (open-source, MIT) и Kiro от AWS (платный, со своей нотацией требований). Плюс подход «CLAUDE.md как носитель спеки» — с важной оговоркой, о которой ниже.
• SDD — не новинка ИИ-эпохи: формат тестируемых требований EARS пришёл из авиационной инженерии, а сама идея «код из спецификации» уже проваливалась раньше под названием Model-Driven Development.
• Главная развилка — где это оверкилл. Есть задокументированные кейсы, где спека на тривиальную фичу разрослась до 1300 строк, а ревью документа заняло 3,5 часа. Правило простое: задача целиком влезает в контекст агента — SDD скорее лишний.

Что такое SDD и чем это отличается от подробного промпта

Сначала предупреждение о терминах. Как отмечает Биргитта Бёкелер из Thoughtworks, само понятие SDD уже семантически размыто: часть индустрии называет «спекой» просто подробный промпт. Это не одно и то же. Подробный промпт — разовая инструкция; спецификация в SDD — живой документ, против которого агент сверяет каждый шаг плана и по которому потом проверяется результат.

BYBIT EARNЗаставь крипту работатьПроценты на USDT и BTC без блокировки — деньги остаются под рукой.Разместить

Откуда вообще взялся подход. По оценке аналитика RedMonk Рэйчел Стивенс, SDD — это прямой ответ индустрии на провалы вайб-кодинга в проде. Триггером стали громкие инциденты вроде удаления рабочей базы данных ИИ-агентом — когда стало ясно, что «пиши код как чувствуешь» плохо масштабируется на серьёзные проекты. Формальная спека возвращает в процесс то, что вайб-кодинг убрал: явно зафиксированное намерение.

Монтаж видео кодом: пайплайн из Deepgram, FFmpeg и Remotion

Supabase и Stripe за вечер с Claude Code — и три вещи, которые агент сделает не так

Деплой на Vercel через GitHub: как выложить проект по шагам

Spec-driven development: от идеи до архитектуры продукта с ИИ

AWS Continuum придёт в Claude Code и Codex: поиск дыр прямо в редакторе

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

Анатомия спеки: из чего она состоит

Формальная спека — это не «пожелания в свободной форме», а структура:

• Цель — какую проблему решаем и для кого.
• Пользовательские сценарии (user stories) — что и в какой ситуации делает пользователь.
• Критерии приёмки (acceptance criteria) — проверяемые условия «сделано». Именно по ним агент (и вы) понимаете, что задача закрыта.
• Нефункциональные требования — производительность, безопасность, ограничения.

Критерии приёмки можно писать обычным языком, а можно — в нотации EARS, которую использует Kiro. Формат жёсткий: «WHEN [событие] THE SYSTEM SHALL [поведение]». Выглядит непривычно, но за ним десятилетия практики: EARS придумали в авиационном подразделении Rolls-Royce, чтобы формулировать требования, которые можно однозначно протестировать. Для ИИ-агента это удобно — меньше простора для «творческой интерпретации».

Как агент генерирует план и проверяет его

Возьмём GitHub Spec Kit как эталонный воркфлоу. Он разбит на четыре фазы: Specify → Plan → Tasks → Implement. Сначала вы формулируете спеку, затем агент строит из неё технический план, дальше план разбивается на конкретные задачи, и только потом пишется код.

Важная деталь — constitutional gates (конституционные гейты). План не проходит дальше, пока не пройдёт заданные проверки или пока исключение не задокументировано явно. Это и есть механизм «агент сверяется с контрактом»: не просто написал код, а прошёл ворота, которые вы поставили. Управляется всё слэш-командами — /speckit.specify, /speckit.plan, /speckit.tasks, /speckit.implement и другими.

Самые надёжные ворота — не текстовые, а исполняемые: тест, который либо зелёный, либо нет. Как строить такой цикл, чтобы агент писал код под уже согласованную проверку, а не подгонял проверку под свой код, разбираем в уроке про Test-Driven Development с ИИ.

BYBITВсё ещё смотришь со стороны?Рынок работает без выходных. Счёт на Bybit открывается за 2 минуты.Начать сейчас

Среди инструментов, где это работает, — VS Code, Cursor и сам Claude Code: в официальном воркфлоу Spec Kit его CLI используют как пример агента. Тулкит не привязан к одному редактору и поддерживает несколько ИИ-агентов.

Annotation cycle: как уточнять спеку

Спека почти никогда не рождается полной. В Spec Kit есть аккуратный механизм уточнения: прямо в файле вы (или агент) ставите маркер [NEEDS CLARIFICATION: вопрос] там, где не хватает данных. Команда /speckit.clarify затем проходит по этим местам и задаёт до пяти уточняющих вопросов за один проход — это короткая сессия уточнений, а не бесконечный опросник.

Полезный приём сверх официальной документации: прогонять готовую спеку через отдельного субагента «холодным взглядом», который ищет в ней дыры и противоречия. Свежий взгляд ловит то, что автор спеки уже не видит.

Инструменты: Spec Kit, Kiro и CLAUDE.md

Три основных способа делать SDD — с разной ценой и степенью привязки к вендору.

Spec Kit — самый популярный: около 120 тысяч звёзд на GitHub и больше 30 встроенных интеграций с агентами на 11 июля 2026 года, лицензия MIT, актуальная версия v0.12.11. Открытый и не привязан к вендору.

Kiro работает на моделях Claude (Opus, Sonnet, Haiku) и других через AWS Bedrock. Тарифы на 11 июля 2026 года: бесплатный уровень (50 кредитов), Pro за $20 (1000 кредитов), Pro+ за $40, Pro Max за $100, Power за $200; перерасход — по $0,04 за кредит. За это вы получаете более «ведомый» трёхфазный воркфлоу и EARS-нотацию из коробки.

CLAUDE.md как носитель спеки — самый доступный путь, но с критической оговоркой, о которой почти никто не пишет. По официальной документации Claude Code, CLAUDE.md — это не enforced-конфигурация, а user-сообщение: агент читает его в начале сессии, но строгое соблюдение не гарантировано. То есть спека в CLAUDE.md — это сильная рекомендация, а не жёсткое правило. Если нужно именно принуждение (агент физически не может нарушить критерий), одного файла мало — нужен механизм проверки на уровне хука. Как устроен сам файл, разбираем в отдельном уроке курса; здесь важно именно ограничение: не путайте «агент прочитал» и «агент обязан».

Помимо большой тройки есть альтернативы — BMAD, OpenSpec, Tessl (подход «спека как исходник»). Они нишевее, но показывают, что рынок инструментов SDD активно растёт.

Greenfield против brownfield: где спека буксует

Полная спецификация отлично ложится на новый проект с нуля (greenfield). А вот на legacy-код (brownfield) «описать всю систему заранее» практически не работает — системы слишком велики и запутаны. Рабочий подход здесь — change-level спека: формализуем не всю систему, а конкретное изменение.

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

Где SDD — оверкилл

Самый честный раздел, которого не хватает у евангелистов. Формальная SDD стоит времени, и на мелких задачах цена превышает пользу. Два независимых инженерных теста это показали:

• Команда marmelab (12 ноября 2025 года) описала, как SDD на тривиальную фичу развернулся в 8 файлов и около 1300 строк документации.
• Scott Logic (26 ноября 2025 года), прогнав Spec Kit на реальной задаче, получил 2577 строк markdown против 689 строк кода — и 3,5 часа только на ревью самой спецификации.

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

Риски и честная критика

У подхода есть системные слабые места, о которых важно знать заранее.

• Waterfall под новым именем. Критики (та же marmelab) прямо проводят параллель: «вся документация до кода» противоречит недетерминированной природе разработки. Историческая память тоже настораживает — идея «код из спецификации» уже проваливалась как Model-Driven Development. Опытная аудитория должна держать это в уме: у подхода есть шанс повторить старые грабли.
• Устаревшая спека хуже её отсутствия. Если спека разошлась с кодом, она активно вводит агента в заблуждение — он верит документу, а не реальности.
• Двойной ревью. Теперь вы проверяете и спеку, и код. На больших документах это ощутимая нагрузка (те самые 3,5 часа).
• Полярные отзывы об инструментах. О Kiro пишут и «подаёт надежды», и «худший ИИ-редактор, который пробовал». Личный опыт сильно варьируется — не берите ни евангелизм, ни разгром за истину, тестируйте на своей задаче.

Чем это отличается от повседневного метода работы

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

FAQ

Чем спека отличается от подробного промпта? Промпт — разовая инструкция, которую агент исполняет и забывает. Спека — постоянный документ-контракт, против которого сверяется каждый шаг плана и итоговый результат. Плюс в SDD есть механизм проверки (гейты), которого у обычного промпта нет.

С чего начать — Spec Kit или Kiro? Spec Kit бесплатен, открыт и не привязан к вендору — логичная точка входа, если вы уже работаете в VS Code или Cursor. Kiro стоит денег, но даёт более «ведомый» воркфлоу и EARS-нотацию из коробки — имеет смысл, если нужна структура «за руку». Начать дешевле со Spec Kit.

Можно ли просто держать спеку в CLAUDE.md? Можно, но помните: CLAUDE.md по официальной документации не гарантирует строгого соблюдения — это рекомендация, а не жёсткое правило. Для критичных требований нужен реальный механизм проверки (хук), а не только текст в файле.

Когда SDD точно не нужен? Когда задача мелкая и целиком помещается в контекст агента, а описать её можно парой предложений. Формальная спека на такое — потерянное время: документации выйдет больше, чем кода.

SDD — это не тот же самый Waterfall? Риск есть, и критики на него прямо указывают. Разница в том, что спека в SDD — живой документ, который меняется по ходу (annotation cycle), а не замороженное ТЗ на год вперёд. Но если превратить спеку в неизменную «библию», подход действительно вырождается в Waterfall со всеми его проблемами.