Spec-Driven Development: обзор инструментов

Опубликовано 01.10.2026 06:12:00 в категории Искусственный интеллект

Вступление

Сценарий, наверное, знакомый. Вы открываете чат с агентом, описываете фичу в двух абзацах, и через пару минут получаете несколько сотен строк кода. Код компилируется, тесты (если их попросили) проходят, всё выглядит прилично. Такой стиль работы получил название «вайб-кодинг» (vibe coding) — пишем не по плану, а по ощущению.

Проблемы начинаются на второй итерации. Вы просите добавить к фиче ещё одно правило, и агент:

1. Переписывает половину того, что уже работало, потому что «так чище»;
2. Забывает ограничение, которое вы озвучили в самом начале, — оно осталось где-то в истории чата;
3. Принимает архитектурное решение, о котором вы не просили и узнаёте о нём только на ревью.

Причина всех трёх пунктов одна: договорённости между вами и агентом нигде не зафиксированы. Они живут в контекстном окне (context window), а контекстное окно — вещь временная. Закрыли сессию, сменили агента, подключили коллегу — и всё, что было «понятно по ходу разговора», пропало.

Отсюда и простая идея: прежде чем просить агента писать код, зафиксировать намерение в документе, который одинаково читают и человек, и агент. Этот документ называют спецификацией (specification), а подход — разработкой через спецификацию (spec-driven development, SDD). Спецификация становится единственным источником правды (single source of truth): агент сверяется с ней, вы ревьюите её, а код становится производным от неё артефактом.

Кстати, звучит это подозрительно похоже на техническое задание (ТЗ) — и об этом в следующем разделе.

Что было раньше

Идея «сначала описать, потом делать» старше большинства языков программирования, на которых мы сегодня пишем. Менялось только то, кто читает описание и насколько строго он ему следует.

Техническое задание

Классика отечественной разработки — ТЗ по ГОСТ 34.602 (сейчас действует редакция 2020 года). Документ на десятки страниц, который согласовывается до начала работ и потом лежит в папке. Проблема известна всем, кто такие ТЗ писал или читал: к середине проекта код и документ расходятся, а актуализировать ТЗ никто не хочет, потому что это долго, скучно и ни на что не влияет.

CASE-средства и MDA

В 90-е появилась мысль: если документ всё равно расходится с кодом, пусть код генерируется из документа. Сначала это были CASE-средства (Computer-Aided Software Engineering), затем, в 2001 году, консорциум OMG оформил подход в модельно-ориентированную архитектуру (Model Driven Architecture, MDA). Схема такая: платформенно-независимая модель (Platform Independent Model, PIM) описывает предметную область на UML, из неё получается платформенно-зависимая модель (Platform Specific Model, PSM), а уже из неё генерируется код. Rational Rose, Enterprise Architect и подобные им инструменты обещали, что программисту останется только дописать тела методов.

Не взлетело по двум причинам. Во-первых, UML оказался недостаточно выразительным для бизнес-логики: всё, что сложнее CRUD, всё равно писалось руками. Во-вторых, обратное проектирование (round-trip engineering) — синхронизация ручных правок кода обратно в модель — работало плохо, и модель опять превращалась в «документ в папке».

Проектирование по контракту

Параллельно Бертран Мейер в языке Eiffel предложил проектирование по контракту (design by contract): предусловия, постусловия и инварианты прямо в коде. Здесь спецификация не может разойтись с реализацией, потому что проверяется при выполнении. Но и масштаб у неё — один метод, а не система.

Contract-first

С веб-сервисами пришёл подход «сначала контракт» (contract-first): сначала WSDL, позже OpenAPI, и только потом реализация. Из контракта генерируются клиенты, заглушки сервера и документация. Этот подход прижился, потому что контракт описывает узкую и строго формализуемую вещь — интерфейс.

BDD

Наконец, разработка через поведение (behavior-driven development, BDD) с языком Gherkin: «Дано… Когда… Тогда…» (Given/When/Then). Сценарии пишутся почти человеческим языком, но при этом исполняются как тесты. Пожалуй, это ближайший предок SDD по духу.

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

Кстати, SDD предлагает новый вариант компромисса: спецификация пишется свободным текстом, как ТЗ, но читает и исполняет её агент. Получится ли у него то, что не получилось у генераторов кода из UML, — вопрос, к которому вернёмся в «Заключении».

Что такое SDD

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

Общий цикл SDD: каждый артефакт ревьюит человек, исполняет агент

Главное правило цикла — пунктирная стрелка на схеме. Если в реализации обнаружилось расхождение с ожиданиями, исправляется спецификация, а код перегенерируется или дорабатывается по ней. Если править код в обход документа, через неделю вы снова получите «ТЗ в папке».

Различаются инструменты прежде всего тем, какую роль спецификация играет после того, как код написан. Удобную классификацию предложила Бригитта Бёкелер в статье на сайте Мартина Фаулера (Understanding Spec-Driven Development: Kiro, spec-kit, and Tessl):

1. Spec-first — спецификация пишется до кода и направляет реализацию, а дальше может устареть. Документ нужен для конкретной задачи.
2. Spec-anchored — спецификация остаётся после реализации и меняется вместе с кодом при каждой доработке.
3. Spec-as-source — спецификация является основным артефактом. Человек правит только её, а код генерируется и вручную не редактируется.

Три уровня SDD, инструменты на каждом из них и их «предки» из прошлого

Обратите внимание на нижний ряд схемы: у каждого уровня есть вполне узнаваемый предшественник. Это пригодится, когда будем отвечать на вопрос про MDA.

GitHub Spec Kit

GitHub Spec Kit — открытый (MIT) набор шаблонов и CLI от GitHub, который превращает любого поддерживаемого агента в исполнителя SDD-процесса. Проект появился в сентябре 2025 года (анонс в блоге GitHub), за год дошёл до версии 1.0 и стал, по сути, эталоном, с которым сравнивают остальных. Документация: github.github.com/spec-kit.

Принцип работы

Spec Kit не содержит своей модели и своего редактора. CLI specify устанавливает в проект шаблоны документов, скрипты и набор команд (slash commands) для выбранного агента: Copilot, Claude Code, Gemini CLI, Cursor, Codex и ещё нескольких десятков. Дальше вы работаете в привычном чате агента:

uv tool install specify-cli
specify init my-project --integration claude

/speckit.constitution Проект на .NET 9, Clean Architecture, без сторонних мапперов, тесты на xUnit.
/speckit.specify Сервис заказов: создание заказа, проверка остатков, отмена в течение 30 минут.
/speckit.plan ASP.NET Core Minimal API, .NET Aspire, PostgreSQL через EF Core, обмен событиями через RabbitMQ.
/speckit.tasks
/speckit.implement
/speckit.converge

Артефакты Spec Kit: конституция проекта и цепочка spec → plan → tasks → код → сверка

Ключевая идея — «конституция» (constitution): файл .specify/memory/constitution.md с принципами проекта, который создаётся один раз и читается на каждом шаге. Дальше для каждой фичи создаётся отдельная ветка и папка specs/NNN-feature/, в которую по очереди ложатся:

• spec.md — что и зачем, без упоминания технологий;
• plan.md — как, со стеком и архитектурными решениями, плюс вспомогательные data-model.md, contracts/, research.md;
• tasks.md — список задач, где независимые помечены [P] для параллельного выполнения;
• код, который /speckit.implement пишет, отмечая задачи как выполненные.

Последний шаг, /speckit.converge, сверяет реализацию со спецификацией, планом и задачами и дописывает в tasks.md то, что осталось сделать. Цикл implement → converge повторяется, пока сверка не скажет, что расхождений нет. Есть и необязательные команды: /speckit.clarify задаёт уточняющие вопросы по спецификации, /speckit.analyze проверяет согласованность документов до начала реализации.

Плюсы

1. Независимость от агента. Один и тот же набор спецификаций работает с разными агентами. Если в команде кто-то сидит в Copilot, а кто-то в Claude Code, это лучший вариант.
2. Бесплатно и открыто. Лицензия MIT, всё хранится в репозитории обычными Markdown-файлами.
3. Чёткое разделение «что» и «как». spec.md не должна содержать технологий, plan.md — содержит. Это дисциплинирует и, как увидим в «Заключении», очень похоже на PIM и PSM из MDA.
4. Экосистема. Есть каталог расширений сообщества: проверка реализации по спецификации, изоляция через git worktree, проверка версий пакетов и другое.

Минусы

1. Много церемоний для маленьких задач. Чтобы поправить валидацию одного поля, придётся пройти весь цикл или обходить его. Spec Kit заточен под новые фичи и новые проекты (greenfield).
2. Многословность. Генерируемые документы получаются длинными, и ревьюить их бывает утомительнее, чем сам код. На это обращают внимание практически во всех обзорах.
3. Нет встроенной проверки. Кроме сверки converge, контроль качества остаётся на вас и вашем агенте: тесты, ревью, CI.
4. Спецификация фичи «отработана» после слияния. Spec Kit относится к уровню spec-first: папка specs/NNN-feature/ описывает изменение, а не систему целиком.

Kiro

Kiro — агентная IDE от AWS на базе Code OSS (то есть совместимая с VS Code), в которую SDD встроен как основной режим работы. Публичный предварительный выпуск (preview) появился летом 2025 года, общедоступной (GA) версия стала в ноябре 2025-го. Есть также Kiro CLI.

Принцип работы

Вы описываете задачу, а Kiro создаёт в .kiro/specs/<feature>/ три файла и проводит вас через три этапа с подтверждением на каждом:

1. requirements.md — пользовательские истории (user stories) с критериями приёмки в нотации EARS (Easy Approach to Requirements Syntax);
2. design.md — технический дизайн: диаграммы, интерфейсы, схемы данных, обработка ошибок, стратегия тестирования;
3. tasks.md — задачи, упорядоченные по зависимостям, каждая со ссылкой на конкретное требование.

EARS — это структурированный шаблон требования, который легко читается и легко превращается в тест:

WHEN пользователь отправляет заказ без товаров
THE SYSTEM SHALL отклонить заказ с сообщением «Пустой заказ»

Помимо спецификаций, у Kiro есть ещё два механизма:

• Управляющие файлы (steering files) в .kiro/steering/ — product.md, tech.md, structure.md — это аналог конституции Spec Kit: правила проекта, которые агент читает всегда или по условию.
• Хуки агента (agent hooks) — автоматизация по событиям: сохранили файл — запустились тесты, создали компонент — обновилась документация. Документация по спецификациям: kiro.dev/docs/specs.

Плюсы

1. Всё из коробки. Не нужно собирать процесс из CLI, шаблонов и агента — открыли IDE и работаете.
2. Строгие требования. EARS заставляет формулировать требования однозначно, а Kiro умеет строить по ним тесты на основе свойств (property-based testing).
3. Трассируемость. Каждая задача ссылается на требование, поэтому видно, зачем написан тот или иной кусок кода.
4. Корпоративные возможности. SSO, управление доступом, аудит — то, без чего крупная компания инструмент просто не купит.

Минусы

1. Привязка к IDE. Спецификации лежат в репозитории в Markdown, но процесс завязан на Kiro. Работать в Rider или Visual Studio не получится.
2. Ценообразование на кредитах. Есть бесплатный тариф и несколько платных, но расход считается в кредитах за действия агента, и предсказать стоимость фичи заранее сложно. Цены меняются, поэтому перед выбором загляните на страницу тарифов.
3. Ограниченный выбор моделей. Модели доступны через Amazon Bedrock, подключить любую понравившуюся нельзя.
4. Тяжеловесность для мелочей. Как и у Spec Kit, три документа ради однострочной правки — перебор. Для таких случаев в Kiro есть обычный «вайб»-режим без спецификаций.

OpenSpec

OpenSpec от Fission AI — лёгкий открытый (MIT) инструмент, созданный прежде всего для работы с существующим кодом (brownfield). Ставится через npm и работает с двумя десятками агентов через команды.

Принцип работы

Главное отличие OpenSpec — в том, что он разделяет «как система работает сейчас» и «что мы в ней меняем»:

openspec/
├── specs/              # источник правды: текущее поведение системы
│   └── orders/spec.md
└── changes/            # предлагаемые изменения, по папке на каждое
    └── add-order-cancel/
        ├── proposal.md
        ├── design.md
        ├── tasks.md
        └── specs/orders/spec.md   # дельта-спецификация

Дельта-спецификация описывает не систему целиком, а только разницу: какие требования добавляются, меняются и удаляются.

## ADDED Requirements

### Requirement: Отмена заказа
Система ДОЛЖНА позволять отменить заказ в течение 30 минут после создания.

#### Scenario: Отмена в пределах окна
- **WHEN** пользователь отменяет заказ через 10 минут после создания
- **THEN** заказ переходит в статус «Отменён», резерв товаров снимается

OpenSpec: изменение живёт в отдельной папке, а при архивации дельта сливается в основные спецификации

Рабочий цикл короткий:

npm install -g @fission-ai/openspec@latest
cd your-project && openspec init

/opsx:propose add-order-cancel   # агент готовит proposal, дельту, design и tasks
/opsx:apply                      # агент реализует задачи
/opsx:archive                    # дельта сливается в openspec/specs/, папка уходит в архив

После архивации openspec/specs/ снова описывает систему такой, какая она есть, а в changes/archive/ остаётся история всех изменений с датами.

Кстати, … CLI OpenSpec сам не обращается к языковой модели. Всю работу выполняет ваш агент, а OpenSpec отвечает только за структуру файлов, валидацию и слияние дельт. Поэтому ему не нужен API-ключ.

Плюсы

1. Создан для существующего кода. Не нужно сначала описывать всю систему — достаточно описать изменение. Для проекта с десятилетней историей это решающий аргумент.
2. Спецификация живёт. Это инструмент уровня spec-anchored: после каждого изменения основная спецификация обновляется, и через полгода по ней можно понять, как система должна работать.
3. Лёгкость. Минимум церемоний, короткий цикл, быстро осваивается. В сравнительных обзорах OpenSpec стабильно оказывается самым быстрым на мелких и средних задачах.
4. Ревью изменений. Дельта в формате ADDED/MODIFIED/REMOVED читается как diff требований — удобно обсуждать в pull request.

Минусы

1. Расхождение спецификаций нужно контролировать самим. Если кто-то поправил код в обход changes/, specs/ об этом не узнает. Синхронизация держится на дисциплине команды.
2. Нет жёстких шлюзов между фазами. Ничто не мешает агенту перейти к реализации, не дождавшись вашего одобрения дельты.
3. Меньше строгости. Формат требований проще, чем EARS у Kiro, а отдельного шага архитектурного анализа, как plan.md у Spec Kit, нет — есть только design.md внутри изменения.

BMAD Method

BMAD Method (сейчас расшифровывается как Build More Architect Dreams) — открытый фреймворк, который строит SDD вокруг гибкой (agile) методологии и набора специализированных агентов-ролей. Документация: docs.bmad-method.org.

Принцип работы

BMAD моделирует не процесс, а команду. Каждая роль — отдельный агент со своими командами и даже именем:

1. Анализ (analysis) — аналитик проводит мозговой штурм, исследует предметную область, пишет краткое описание продукта (project brief);
2. Планирование (planning) — менеджер продукта (PM) создаёт PRD (Product Requirements Document) и разбивает его на эпики;
3. Проектирование решения (solutioning) — архитектор пишет архитектурный документ: стек, API, схемы БД;
4. Реализация (implementation) — для каждой истории создаётся отдельный файл истории (story file) с ровно тем контекстом, который нужен разработчику, после чего агент-разработчик реализует историю в новом чате.

Документы передаются от роли к роли через файлы: PM пишет PRD, архитектор его читает и пишет архитектуру, из обоих получаются истории. Нарезка больших документов на атомарные файлы историй — главный приём экономии контекста в BMAD. В шестой версии фреймворк стал «масштабируемым»: для небольших задач есть упрощённый путь без полного цикла, а роли Scrum Master и QA были объединены с агентом-разработчиком.

Плюсы

1. Полный цикл. Единственный из рассмотренных инструментов, который начинается не со спецификации фичи, а с анализа продукта и исследования рынка.
2. Разделение ответственности. Каждый агент-роль работает со своим документом и своим набором инструкций, а не «один агент делает всё».
3. Контроль контекста. Файлы историй и работа каждой истории в новом чате решают проблему переполненного контекстного окна на больших проектах.
4. Независимость от IDE и бесплатность. Работает с Claude Code, Cursor, Copilot и другими.

Минусы

1. Тяжеловесность. Для мелкой задачи BMAD — это стрельба из пушки по воробьям. В сравнительных обзорах он заметно проигрывает OpenSpec по времени на небольших задачах.
2. Порог входа. Ролей, команд и артефактов много, освоение занимает недели, а не дни.
3. Расход токенов. Многоэтапный процесс с несколькими агентами съедает существенно больше токенов, чем однопроходные инструменты.
4. Спецификации одноразовые. Как и Spec Kit, BMAD относится к уровню spec-first: PRD и архитектура описывают продукт на момент планирования.

Tessl

Tessl — компания, которая заявила самую амбициозную цель в SDD: сделать спецификацию основным артефактом разработки, а код — генерируемым.

Принцип работы

Tessl Framework, анонсированный осенью 2025 года в закрытой бете, работал на уровне spec-as-source. Спецификация описывала компонент, теги вроде @generate и @test подсказывали, что из неё генерировать, команда tessl build создавала код, а в начале сгенерированного файла появлялся комментарий // GENERATED FROM SPEC - DO NOT EDIT. Одна спецификация соответствовала одному файлу кода.

Параллельно вышел Tessl Spec Registry — реестр из более чем 10 000 «спецификаций использования» (usage specs) популярных библиотек, чтобы агенты не выдумывали несуществующие API.

Дальше история повернулась интересно. В начале 2026 года реестр спецификаций превратился в реестр навыков (skills) для агентов, а в 2026 году функциональность фреймворка была убрана из CLI Tessl — компания сосредоточилась на реестре и инфраструктуре для агентов. Старая версия CLI с фреймворком осталась доступной, но не развивается.

Плюсы

1. Самая последовательная идея. Если вы хотите, чтобы человек вообще не правил код, только Tessl пытался это сделать всерьёз.
2. Реестр знаний о библиотеках. Актуальные описания API для агента — полезная вещь сама по себе, независимо от SDD.

Минусы

1. Фреймворк фактически свёрнут. Строить процесс на инструменте, который его создатели перестали развивать, — сомнительная идея.
2. Недетерминированность генерации. Одна и та же спецификация на входе языковой модели может дать разный код на выходе. Для spec-as-source это фундаментальная проблема.
3. Закрытость. Продукт проприетарный, а самая интересная часть так и не вышла из закрытой беты.

Tessl в этой статье — не столько рекомендация, сколько показательный пример. К нему вернёмся в «Заключении».

Кратко о других

Экосистема SDD растёт очень быстро, поэтому упомяну ещё несколько заметных проектов.

• Spec Kitty — ответвление (fork) Spec Kit с открытой лицензией MIT. Добавляет то, чего не хватает оригиналу для параллельной работы: изоляцию задач через git worktree, локальную kanban-доску и цикл review → accept → merge. Если вы запускаете несколько агентов одновременно, стоит посмотреть.
• Traycer — коммерческое расширение для VS Code, которое работает поверх вашего агента по схеме «план → выполнение → проверка» (Plan → Execute → Verify). Акцент на проверке результата против плана.
• Superpowers — открытый набор навыков (skills) и методология для агентов: мозговой штурм, план, реализация через разработку через тестирование (TDD) с подагентами. Формально не SDD-инструмент, но решает ту же задачу.
• Встроенный режим планирования. У Claude Code, Cursor, Copilot и других агентов есть режим, в котором агент сначала составляет план и ждёт подтверждения. Это не SDD — план живёт в чате и исчезает вместе с ним, — но для небольших задач его часто достаточно (я использую именно этот режим). Хорошая точка отсчёта, чтобы понять, нужен ли вам отдельный инструмент вообще (полагаю, что для больших проектов возможно потребуется хороший инструмент, а пока...).

Тем, кто хочет сравнить инструменты на одних и тех же сценариях, рекомендую интерактивное сравнение spec-compare: там один и тот же пример (новая фича, рефакторинг, исправление ошибки) проводится через разные инструменты параллельно.

Сравнительная таблица и как выбрать

Инструмент	Форма	Уровень SDD	Где спецификации	Лучше всего для	Лицензия / цена
GitHub Spec Kit	CLI + шаблоны для агента	spec-first	specs/, .specify/	новых проектов и команд с разными агентами	MIT, бесплатно
Kiro	IDE (+ CLI)	spec-first	.kiro/specs/	компаний с требованиями к безопасности и аудиту	проприетарная, кредиты
OpenSpec	CLI + команды для агента	spec-anchored	openspec/specs/, openspec/changes/	доработки существующего кода	MIT, бесплатно
BMAD Method	фреймворк агентов-ролей	spec-first	PRD, архитектура, файлы историй	больших продуктов с полным циклом	открытая, бесплатно
Tessl	платформа + реестр	spec-as-source (свёрнут)	спецификации рядом с кодом	экспериментов	проприетарная
Spec Kitty	CLI, fork Spec Kit	spec-first	репозиторий	параллельной работы агентов	MIT, бесплатно

Если коротко, выбор сводится к нескольким вопросам:

Упрощённое дерево выбора SDD-инструмента

Критерии выбора

1. Код уже есть и его нужно менять — начните с OpenSpec. Он не требует описывать всю систему заранее.
2. Нужна готовая среда и корпоративный контроль — Kiro, особенно если вы и так в экосистеме AWS.
3. Большой новый продукт, где нужно пройти путь от идеи до архитектуры — BMAD Method, но будьте готовы к порогу входа.
4. Всё остальное — GitHub Spec Kit как самый универсальный вариант, а для параллельной работы нескольких агентов — Spec Kitty.

Кстати, ничто не мешает комбинировать. Вполне рабочая схема: новый сервис стартует на Spec Kit, а когда он уходит в эксплуатацию и начинается поток мелких доработок, команда переходит на OpenSpec.

Заключение

SDD — не новая идея, а новая попытка решить старую проблему: как сделать так, чтобы намерение разработчика пережило первую итерацию. Разница с прошлыми попытками в том, что «читателем» спецификации стал агент, который понимает свободный текст и не устаёт от длинных документов. Инструменты при этом очень разные: от лёгкого OpenSpec до целой «команды» агентов в BMAD, и универсального лидера среди них нет — каждый оптимизирован под свою ситуацию.

Можно ли использовать SDD как MDA?

Вопрос естественный: раз спецификация первична, а код из неё «получается», не вернулись ли мы к модельно-ориентированной архитектуре, только с ИИ вместо генератора? Короткий ответ: как дисциплину — да, как генератор — нет.

Что совпадает. Структура Spec Kit почти дословно повторяет MDA:

MDA	Spec Kit	Kiro	OpenSpec
профиль, стандарты	constitution.md	steering-файлы	конвенции проекта
PIM — платформенно-независимая модель	spec.md (без технологий)	requirements.md	specs/
PSM — платформенно-зависимая модель	plan.md, data-model.md, contracts/	design.md	design.md
генерация кода	tasks.md → /speckit.implement	tasks.md	tasks.md → /opsx:apply

Если держать spec.md строго свободной от технологий, вы получаете настоящую PIM: сменили стек — перегенерировали plan.md под другую платформу, а требования остались прежними. Это ровно то, что обещала MDA.

Что не совпадает

Принципиальных отличий три:

1. Формальность модели. В MDA модель строилась на UML и метамодели, а преобразования PIM → PSM → код описывались формально. В SDD спецификация — свободный текст, и её «компилятором» выступает языковая модель.
2. Детерминированность. Генератор MDA из одной модели всегда выдавал один и тот же код. Агент из одной спецификации может дважды написать разный код. Поэтому «удалил код и перегенерировал» в SDD — это не пересборка, а новая реализация, которую снова нужно проверять.
3. Обратная синхронизация. Проблема round-trip engineering, похоронившая MDA, никуда не делась — она теперь называется дрейфом спецификаций (spec drift). OpenSpec решает её слиянием дельт, Spec Kit — сверкой converge, но в обоих случаях это дисциплина, а не гарантия.

Показательна история Tessl: единственный инструмент, который всерьёз пошёл по пути spec-as-source, то есть ближе всех подошёл к MDA, за год свернул свой фреймворк. Похоже, «код как генерируемый артефакт, который никто не правит» и с языковыми моделями пока остаётся мечтой.

Как получить от SDD лучшее из MDA

Если вам близка идея модельно-ориентированной разработки, можно взять из неё работающие части:

1. Держите спецификацию «что и зачем» отдельно от «как», и следите, чтобы в неё не просачивались технологии.
2. Восполняйте недостающую формальность тестами. Требования в EARS или сценарии в стиле Gherkin превращаются в автоматические тесты — и именно тесты, а не генератор, гарантируют, что код соответствует спецификации.
3. Формализуйте то, что формализуется: контракты API в OpenAPI, схемы сообщений, модель данных. Там, где возможен строгий формат, contract-first работает лучше свободного текста.
4. Не правьте код в обход спецификации. Это единственное правило, нарушение которого гарантированно превращает любую спецификацию — хоть UML, хоть Markdown — в «документ в папке».

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

Ссылки

• GitHub Spec Kit: репозиторий, документация
• Kiro: сайт, документация по спецификациям, тарифы
• OpenSpec: репозиторий
• BMAD Method: репозиторий, документация
• Tessl: сайт
• Spec Kitty: репозиторий
• Traycer: сайт
• Superpowers: репозиторий
• Бригитта Бёкелер: Understanding Spec-Driven Development: Kiro, spec-kit, and Tessl
• Интерактивное сравнение инструментов: spec-compare
• OMG: Model Driven Architecture