Эра «вайб-кодинга» мертва: Полный гид по Spec-Driven Development (SDD) фреймворкам
Эра «вайб-кодинга» мертва. Откройте для себя фреймворки Spec-Driven Development (SDD) - полное руководство по дисциплинированной разработке ПО с ИИ, категоризирующее инструменты по строгости: от гибкого Spec-First до генерирующего код Spec-as-Source.
Авторы: slavb18
Эра «вайб-кодинга» мертва: Полный гид по Spec-Driven Development (SDD) фреймворкам
В 2026 году писать код простым накидыванием промптов в чат («вайб-кодинг») стало таким же антипаттерном, как использование goto в 1970-х. Бесконечные циклы правок, деградация контекста (context rot) и галлюцинации ИИ-агентов заставили индустрию вспомнить про старую добрую инженерию требований.
Так на стыке LLM и классического проектирования родился Spec-Driven Development (SDD) - подход, где ИИ-агент жестко дисциплинируется спецификацией.
Сегодня на рынке существует как минимум 15 активно развивающихся SDD-инструментов: от плагина Superpowers со 166 000 звезд на GitHub до хардкорного MUSUBI всего с 28 звездами. Популярность здесь не равна качеству - она лишь отражает уровень строгости процесса.
В этой статье мы разберем всю экосистему SDD, разложим инструменты по трем уровням строгости таксономии Пискалы и поймем, что внедрять в вашем проекте.
⚖️ Три уровня строгости: Какого типа ваш контракт?
Дипак Бабу Пискала в своей работе 2026 года классифицировал SDD-фреймворки по трем уровням строгости. Это лучшая ментальная модель для выбора инструмента:
✨ Уровень 1: Spec-First --> Предварительный контракт (написал, сгенерировал, забыл)
🔗 Уровень 2: Spec-Anchored --> Живая документация (синхронизация кода и спеки, трассировка)
✍️ Уровень 3: Spec-as-Source --> Спека как исходный код (код руками трогать ЗАПРЕЩЕНО)
🚀 Level 1: Spec-First (Письмо о намерениях)
Спецификация пишется до кода, живет в цикле фича-бранча, а после мержа становится исторической документацией. Главный плюс - гибкость и низкий порог входа. Здесь живет большинство популярных утилит: Spec-Kit, Superpowers, BMAD-METHOD, GSD, SpecSwarm, cc-sdd, Don Cheli SDD, Agent OS v3, Shotgun CLI, WordPress SDD, OWASP Skill.
⚓ Level 2: Spec-Anchored (Проектирование с аддендумами)
Спека живет на протяжении всего жизненного цикла проекта. Любое изменение требует обновления требований, которое каскадом протухает в дизайн, код и тесты. Главный плюс - аудируемость и прослеживаемость. Представители: MUSUBI, Intent (от Augment Code, $252 млн инвестиций), OpenSpec.
🤖 Level 3: Spec-as-Source (Модель ЧПУ)
Спецификация - единственный редактируемый артефакт. Разработчик вообще не трогает код. Файлы буквально начинаются с комментированного капслока: // GENERATED FROM SPEC - DO NOT EDIT. Плюс - гарантия корректности по определению. В 2026 году это передний край коммерческой разработки: Tessl (проект основателя Snyk Гая Поджарного, $125 млн инвестиций) и академическая методология CSDD.
📦 Что на самом деле лежит внутри .specify/?
Многие думают, что SDD-фреймворки - это просто набор промптов. На самом деле это жесткие артефакты. Например, при инициализации популярного Spec-Kit (specify init --ai claude) в репозиторий разворачивается целая конституция:
text .specify/memory/constitution.md .specify/templates/spec-template.md .specify/templates/plan-template.md .specify/templates/tasks-template.md
constitution.md - это ядро системы, содержащее 9 статей с уровнями критичности (MUST/SHOULD/MAY). Любое несоответствие кода конституции блокирует мерж.
Статья I - Принцип Library-First: Любая фича должна начинать свое существование как независимая библиотека. Запрещено имплементировать логику напрямую в код приложения, не выделив ее в переиспользуемый компонент.
Пайплайн фреймворка физически не позволит агенту запустить команду /implement, пока не созданы и не валидированы spec.md, plan.md и tasks.md. Агент не может обойти эти правила, потому что они зашиты в CLI, а не в промпт. В итоге время работы ИИ-агента над задачей увеличивается (в среднем с 8 до 33 минут), но на выходе вы получаете предсказуемый архитектурный код вместо костылей.
🥊 Разбор полярных подходов: Superpowers против MUSUBI
Чтобы понять разницу в строгости, сравним самый популярный инструмент и самый формализованный.
✨ Superpowers (166k звезд) - Железная дисциплина для Claude Code
Этот плагин любят за установку в одну команду и абсолютную бескомпромиссность. У него нет тяжелых конфигов, но есть HARD-GATE в промптах и TDD как догма.
Работа делится на 4 волны, каждую из которых выполняет субагент в изолированном контексте (это решает проблему context rot):
🧠 Brainstorming (Socratic-вопросы, выбор 2-3 подходов, обязательное аппрув пользователя).
📝 Plan (генерация пошагового плана).
🛠️ Implementation Prep (подготовка тестов).
🔄 Dev Task (цикл Red-Green-Refactor для каждой подзадачи).
Между 1-й и 2-й волной стоит тот самый HARD-GATE. Инструкция плагина гласит:
«НЕ вызывай навыки имплементации, НЕ пиши код и НЕ делай наброски проекта, пока дизайн не будет одобрен пользователем».
Вторая догма - никаких изменений в продакшн-коде без предварительно написанного падающего теста. Субагенты проверяют реальный вывод тест-раннера, а не верят ИИ на слово.
🏯 MUSUBI (28 звезд) - Мечта регулятора и кошмар «вайб-кодеров»
28 звезд на GitHub - не ошибка, а признак того, что этот инструмент нужен только там, где за баги можно сесть в тюрьму. MUSUBI внедряет стандарты авиакосмической отрасли Rolls-Royce.
Требования пишутся строго в формате EARS (Easy Approach to Requirements Syntax), где запрещены слова should, may, could, а используются только SHALL и MUST по 5 паттернам:
text REQ-AUTH-001 [Ubiquitous]: Система SHALL хешировать все пароли с помощью bcrypt (cost ≥ 12). REQ-AUTH-002 [Event-Driven]: WHEN пользователь отправляет форму с валидными кредами, система SHALL вернуть JWT-токен. REQ-AUTH-003 [Unwanted Behaviour]: IF логин фейлится 5 раз за 15 минут, THEN система SHALL заблокировать аккаунт на полчаса.
На основе этого субагент @traceability-auditor строит автоматическую Traceability Matrix (матрицу прослеживаемости), которая связывает идентификатор требования с разделом дизайна, конкретной строчкой кода и строчкой в тест-файле:
REQ-AUTH-001 → design/auth.md § 2 → src/auth/service.ts:45 → tests/auth.test.ts:12
Если покрытие матрицы падает ниже 100%, CI автоматически блокирует PR. Для легаси-кода предусмотрен режим sdd-change-init, генерирующий дельта-спецификации (диффы бизнес-требований). Оверхед огромный, но перед аудитом SOC2 или ISO у вас на руках будет идеальный след разработки.
⚙️ Spec-as-Source: Когда код больше не пишут руками
На третьем уровне строгости, где правят Tessl и методология CSDD, ручное редактирование кода запрещено.
Фреймворк Tessl работает с файлом .spec.md, размеченным инлайновыми аннотациями:
Сервис авторизации
@generate src/auth/jwt-service.ts @test src/auth/tests/jwt-service.test.ts
Требования
Система SHALL валидировать JWT-токены при каждом запросе. [REQ-AUTH-001]
Вы запускаете tessl build - и код генерируется автоматически. Нужны изменения? Вы меняете человекочитаемую спеку, а не лезете в TypeScript или Go.
Чтобы ИИ не галлюцинировал с внешними библиотеками, Tessl использует Spec Registry (своего рода npm, но для спецификаций). В него уже упаковано более 10 000 верифицированных спецификаций популярных библиотек. Архитектура построена на Split Manifest System: tessl.json управляет версиями для машины, а KNOWLEDGE.md скармливается контексту LLM.
При этом подход CSDD (Constitutional Spec-Driven Development) добавляет слой безопасности Security-by-Construction. Если ИИ пытается написать SQL-запрос обычной конкатенацией строк, статический анализатор (например, настроенный Semgrep) триггерит правило конституции SEC-001 (CWE-89) и жестко реджектит сборку, заставляя переписывать код с использованием ORM или параметризации. В банковских микросервисах это снизило уязвимости на 73% без потери скорости разработки фич.
🎯 Матрица выбора: Что применять в вашем проекте?
Выбор фреймворка зависит не от его крутизны, а от вашей зоны ответственности.
| Контекст проекта | Рекомендуемый стек | Главная фишка | Команда для старта |
|---|---|---|---|
| Solo-разработчик, MVP, стартап | Spec-Kit (lean-пресет) или Superpowers | Быстрый старт, нулевой оверхед, защита от глупых ошибок ИИ за счет HARD-GATE. | specify init --ai claude |
| Команда > 10 человек, Enterprise | MUSUBI (large-режим) + Intent | 100% аудит-трейл, генерация архитектуры C4 и ADR-документов. | npx musubi-sdd@latest init |
| Brownfield, тяжелое легаси | OpenSpec + Shotgun CLI | Дельта-спецификации. Shotgun сначала индексирует кодовую базу и строит граф зависимостей. | uvx shotgun plan "My Feature" |
| Security-critical (Финтех, Медтех) | CSDD + MUSUBI + OWASP Skill | Снижение дефектов безопасности на 73%. Защита от уязвимостей на этапе генерации. | Настройка правил CWE в constitution.md |
🔮 Горизонт 2026-2027: Что нужно внедрять уже сейчас
Индустрия SDD стремительно стандартизируется благодаря двум вещам:
🔌 MCP (Model Context Protocol) - открытый протокол от Anthropic (переданный под крыло Linux Foundation). Это своего рода USB-C для ИИ-агентов. Он заменяет зоопарк форматов (Markdown/TOML/YAML) стандартизированным слоем общения через JSON-RPC. Инструменты вроде Tessl уже используют MCP как универсальный транспорт.
📄 AGENTS.md - файл в корне проекта, описывающий контракт и правила поведения для любых внешних ИИ-агентов (от OpenAI Codex до Cursor). Сейчас его поддерживают более 60 000 open-source проектов.
✅ Вердикт: Навык «инженерии спецификаций» (spec engineering) становится ключевым для архитекторов. Если вы продолжите скармливать ИИ «голые» промпты, вы погрязнете в рефакторинге собственного легаси.
👉 Начните с малого: выделите один некритичный микросервис и прогоните его через Spec-Kit с пресетом lean в течение двух недель. Результаты в виде чистой архитектуры и отсутствия багов вас удивят.