25 мая 2026
Я вёл задачи через Spec Kit и OpenSpec и хотел увидеть весь ландшафт spec-driven development целиком. Обзор Jarek Wąsowski «Comparing 15 Spec-Driven Development Frameworks, Artifacts, and Decision Paths» (Medium, апрель 2026) даёт то, чего не хватало: карту из 15 фреймворков и ось, по которой их имеет смысл сравнивать. Главная мысль автора: SDD-фреймворки решают разные задачи - дают гибкость, аудируемость или гарантию по построению, - поэтому сравнивать их «кто лучше» бессмысленно. Популярность на GitHub (у Superpowers 166 тысяч звёзд, у MUSUBI 28) показывает лишь то, какой уровень строгости выбрало большинство команд, а не качество инструмента.
Полный разбор Spec-Driven Development как подхода и сравнение шести фреймворков с точки зрения процесса - в статье SDLC для AI-агентов; детальный разбор одного из них - в Spec Kit.
Сравнивать по строгости, а не по звёздам
Superpowers ставится одной командой и даёт блокировку прямо в промптах. MUSUBI требует конституцию из девяти статей, формат требований EARS, матрицу трассируемости и диаграммы C4. Разница в популярности - 166 000 звёзд против 28 - не значит, что один лучше другого: они стоят на разных уровнях строгости и решают задачу разной цены. Эту ось Wąsowski берёт из таксономии Deepak Babu Piskala (arXiv:2602.00180, 2026): каждый уровень - свой тип инженерного контракта.
| Уровень | Контракт (аналогия) | Что обещает | Цена | Кто здесь |
|---|---|---|---|---|
| Spec-First (L1) | Письмо о намерениях | Гибкость | Низкая | ~10 из 15 (Spec-Kit, Superpowers, BMAD, GSD...) |
| Spec-Anchored (L2) | Проектная документация с поправками (BIM) | Аудируемость, трассируемость | Процессные накладные | MUSUBI, Intent, OpenSpec |
| Spec-as-Source (L3) | Модель ЧПУ - код генерируется | Гарантия по построению, нулевой drift | Пока горизонт, не дефолт | Tessl, CSDD |
На L1 спека пишется до кода, а после мёрджа остаётся исторической документацией. На L2 спека живёт весь жизненный цикл: каждое изменение оформляется поправкой и распространяется на дизайн, код и тесты. На L3 спека - единственный редактируемый артефакт, а код содержит комментарий // GENERATED FROM SPEC - DO NOT EDIT и переписывается генерацией, а не руками.
Таблица сравнения
Уровень строгости в первой колонке: L1 (Spec-First) - спека пишется до кода и после мёрджа архивируется; L2 (Spec-Anchored) - спека живёт весь жизненный цикл и меняется поправками; L3 (Spec-as-Source) - код генерируется из спеки и руками не правится. Звёзды, финансирование и лицензии - по данным обзора на апрель 2026.
| Уровень | Фреймворк | Метрика | Ключевая черта | Лицензия |
|---|---|---|---|---|
| L1 Spec-First |
Superpowers | 166k★ | Блок на код без дизайна + обязательный TDD | MIT |
| Spec-Kit | ~90k★ | Пайплайн из 5 команд, конституция проекта | Apache 2.0 | |
| GSD | ~48k★ | Генерация кода из спеки | MPL 2.0 | |
| BMAD-METHOD | ~45k★ | Многоролевой полный lifecycle | Creative Commons | |
| cc-sdd | 1.5k★ | Спеки через semantic commits, brownfield-first | MIT | |
| OWASP Security Skill | 145★ | Интеграция security-спецификаций | OWASP | |
| SpecSwarm | 57★ | Распределённый консенсус по спекам | Apache 2.0 | |
| Don Cheli SDD | 93+ команд | Spec-driven DevOps, TDD-гейт на покрытие | ISC | |
| Agent OS v3 | - | Слой стандартов для автономных агентов | Proprietary | |
| Shotgun CLI | - | Генератор спек для быстрого прототипирования | GPL-3.0 | |
| WordPress SDD | - | Spec-workflow для CMS | GPLv2+ | |
| L2 Spec-Anchored |
OpenSpec | 5.8k★ | Самый лёгкий L2, delta specs, brownfield | Apache 2.0 |
| Intent (Augment Code) | $252M | Двунаправленный Living Spec | Proprietary | |
| MUSUBI | 28★ | EARS, C4 + ADR, трассируемость 100% - высшая строгость | BSD-3-Clause | |
| L3 Spec-as-Source |
Tessl (Guy Podjarny) | $125M | Код генерируется из .spec.md, Spec Registry |
Proprietary |
| CSDD | академический | Безопасность по построению, -73% дефектов | Research |
Сноска для точности: автор пишет «десять» фреймворков уровня L1, но в перечне их одиннадцать. OWASP Skill часто считают security-надстройкой поверх другого инструмента, а не самостоятельным фреймворком.
Структура рынка сама по себе говорит о многом: пять фреймворков перешагнули 10 000 звёзд, пять не дотягивают до 1000, и у пяти вообще нет публичной метрики. Самая высокая формальная строгость живёт именно в «невидимой» когорте - MUSUBI, CSDD, Intent. Если смотреть только на пару популярных кандидатов, эти три исчезают с радара. Помимо оси строгости автор раскладывает фреймворки и по операционному принципу: процедурные (пайплайны команд), контекстные (инъекция принципов и шаблонов) и верификационные (гейты, блокирующие мёрдж).
Ключевые механизмы за уровнями
Конституция проекта
Шесть из пятнадцати фреймворков реализуют Constitution Pattern: файл constitution.md с нерушимыми принципами проекта, который агент грузит в каждую сессию, как внутренний устав команды. Конфликт кода с любым принципом блокирует мёрдж. У Spec-Kit это девять статей с уровнями MUST/SHOULD/MAY (Library-First, Test-First, Simplicity Gate и далее). Паттерн дебютировал в Spec-Kit во второй половине 2025-го; академическую формализацию дал Constitutional SDD (Marri, arXiv:2602.02584).
Гейты и обязательный TDD
Superpowers держит два жёстких правила. Первое: агент не пишет ни строки кода, пока не предложил дизайн и человек его не одобрил. Второе: нет production-кода без предварительно написанного падающего теста, причём это проверяет отдельный сабагент по реальному выводу тестов, а не по словам основного агента. TDD здесь - скрытая разделяющая ось всей экосистемы: он обязателен в Superpowers, Don Cheli SDD и MUSUBI и опционален в Spec-Kit, BMAD, GSD, cc-sdd. Выбор фреймворка с обязательным TDD - это решение, доверять агенту или блокировать его. Кент Бек формулировал проблему так: агент, как и человек, охотнее напишет код и потом подгонит под него тесты, поэтому надёжнее блокировать, а не просить.
EARS и матрица трассируемости
MUSUBI выводит L2-строгость через два механизма. EARS (Easy Approach to Requirements Syntax, родом из аэрокосмической Rolls-Royce) - формат требований, который убирает двусмысленность: каждое требование использует SHALL или MUST и запрещает should, may, could. Матрица трассируемости связывает требование с дизайном, конкретной строкой кода и тестом и блокирует мёрдж, если покрытие падает ниже 100%. Это то, что нужно показать аудитору, - и причина, по которой 28 звёзд MUSUBI не отражают его ценности для регулируемых команд.
Когда код перестают писать руками
L3 - это отказ от ручного редактирования кода. У Tessl (Guy Podjarny, ветеран Snyk, $125M) редактируется только .spec.md; после сборки сгенерированный файл начинается с // GENERATED FROM SPEC - DO NOT EDIT, и чтобы изменить поведение, правят спеку, а не код. Второй элемент - Spec Registry, реестр проверенных спецификаций библиотек («npm для AI-ready знаний»): вместо галлюцинации API агент берёт готовую спеку. CSDD добавляет к L3 безопасность как ограничение: нарушение правила отклоняет код, а не ловится постфактум аудитом. На банковских микросервисах это дало снижение security-дефектов на 73% без потери скорости команды.
Стабильного L3 в 2026 ещё нет, и автор это подчёркивает: Tessl в closed beta, Spec Registry в open beta, CSDD - академическая методология, а не продукт. Сам Wąsowski относит уровень к горизонту, а не к production-дефолту: Spec-as-Source он наблюдает, но не внедряет, пока Tessl не выйдет из closed beta и не появится третий независимый enterprise-кейс. Пока подход работает в узких нишах - OSS-библиотеки и security-critical, - а не как массовый выбор.
Четыре контекста - четыре ответа
Автор сводит выбор к четырём типовым контекстам. Если контекст известен, решение занимает минуты.
| Контекст | Ситуация | Что брать |
|---|---|---|
| A | Solo или малая команда, greenfield, эксперимент/MVP | Spec-Kit, опционально + Superpowers ради гейта и TDD |
| B | Команда 10+, enterprise, compliance (SOC2, ISO 42001, NIST AI RMF) | MUSUBI + CSDD как security-слой |
| C | Brownfield, legacy, фича в существующий продукт | OpenSpec + Shotgun CLI |
| D | Security-critical (финтех, медицина, embedded/automotive) | CSDD + MUSUBI + OWASP Security Skill |
Горизонт 2026+
Три тренда, по автору, через полтора года изменят сам выбор фреймворка. MCP (Model Context Protocol, Anthropic) становится универсальным протоколом интеграции инструментов с агентами - любой SDD-фреймворк с MCP-сервером сразу работает со всеми MCP-совместимыми агентами. AGENTS.md в корне репозитория превращается в кросс-тулзовый стандарт описания правил для агентов - аналог package.json, но для их поведения. Living Spec (пионер - Intent) превращает спеку из документа в синхронизированную с кодом базу намерений. Параллельно vibe-coding из отдельной категории становится антипаттерном: писать production-код через голые LLM без спецификаций в 2026-м, по мысли автора, - то же самое, что не перейти на систему контроля версий в 2005-м.
Где на этой карте Spec Kit и OpenSpec
Spec Kit на этой карте - L1, Spec-First: спека первична, но после мёрджа превращается в историю; для большинства фич этого хватает. OpenSpec - самый лёгкий L2 с delta specs под brownfield. Работая с обоими, я ходил между двумя уровнями строгости, не называя эту ось напрямую, и на разных задачах они ощущались по-разному именно потому, что это разные типы контракта.
Wąsowski держит такую раскладку для себя: Spec-First на 80% проектов, Spec-Anchored для регулируемых, Spec-as-Source наблюдает, но не внедряет, пока Tessl не выйдет из closed beta. Для меня ценность обзора в самой оси: она переводит вопрос «какой фреймворк взять» в «что должна гарантировать спека».
Детальный разбор L1-базы - в статье Spec Kit, а шесть фреймворков с точки зрения процесса и ролей - в SDLC для AI-агентов.
Источники
- Jarek Wąsowski (Jaroslaw Wasowski). «Comparing 15 Spec-Driven Development Frameworks, Artifacts, and Decision Paths - SDD». Medium, 24 апреля 2026. Первоисточник, на котором построен этот разбор.
- Deepak Babu Piskala. Трёхуровневая таксономия строгости SDD - arXiv:2602.00180 (2026).
- S. R. Marri. Constitutional Spec-Driven Development (CSDD) - arXiv:2602.02584 (2026).
Смежные статьи на сайте
- SDLC для AI-агентов - шесть фреймворков с точки зрения процесса и ролей.
- Spec Kit - детальный разбор базового L1-фреймворка.