BMAD vs Spec Kit vs OpenSpec: выбираем spec-driven фреймворк для AI-разработки

Команда Reenbit в Q1 2026 опробовала пять spec-driven фреймворков на трёх реальных клиентских проектах. К началу 2026 года в сообществе насчитывалось уже более 30 инструментов для агентной разработки, но честных сравнений между ними почти нет: маркетинговые страницы всех обещают одно и то же — предсказуемый AI и код, готовый к продакшену. Реальность иная, и её стоит разобрать без рекламного глянца: на кону BMAD, GitHub Spec Kit, OpenSpec, а также более лёгкие GSD и Hermes и полноценная IDE AWS Kiro.

Что такое spec-driven development за одну минуту

Spec-driven development (SDD) — методология, в которой единственным источником истины для AI-агентов становится письменная спецификация, а не промпт и не история чата. Сначала вы описываете, что хотите получить, планируете реализацию, разбиваете её на задачи — и только потом разрешаете AI писать код. Спецификация превращается в контракт, код — в артефакт.

Этот сдвиг решает три главные проблемы «vibe coding»:

• Потеря контекста. Спецификация сохраняется между сессиями и между участниками команды.
• Дрейф требований. Каждое изменение прослеживается до версионированного документа, а не до забытого треда в Slack.
• Аудируемость. Когда регулятор или QA спрашивает, почему принято то или иное решение, у вас есть документальный след.

BMAD: где силён и где ломается

BMAD-METHOD (Breakthrough Method for Agile AI-Driven Development) — самый амбициозный фреймворк категории. Он имитирует целую agile-команду: 12+ специализированных AI-агентов в ролях аналитика, PM, архитектора, UX-дизайнера, скрам-мастера, разработчика, QA и технического писателя. Каждый агент получает узко очерченное контекстное окно и создаёт версионированный артефакт — PRD, документ архитектуры, sprint-истории — прежде чем работу подхватит следующий. У проекта 37 000+ звёзд на GitHub, а V6 поддерживает кроссплатформенные агентные команды в Claude Code, Cursor, Codex, Copilot и Windsurf.

Где BMAD раскрывается:

• Сложные greenfield-проекты с ясным скоупом. Когда вы строите что-то с нуля и цена «почти правильного» результата высока, тяжёлое планирование окупается за два спринта.
• Команды, которым нужна формальная документация. При масштабировании с 5 до 25 инженеров артефактные хендоффы сами по себе становятся онбординг-документацией.
• Регулируемые отрасли. PRD, архитектурные диаграммы и тест-планы на уровне историй заодно служат доказательствами комплаенса.

Где BMAD ломается:

• Мелкие задачи. Фикс на четыре часа не должен требовать PRD и sprint-истории. Трёхтрековая система (Quick Flow, Standard, Enterprise) помогает, но senior-инженеры всё равно чувствуют трение.
• Стоимость токенов. Реальное использование BMAD — в среднем около 31 667 токенов на прогон workflow, крупные проекты съедают до 230 млн токенов в неделю. Расходы на API достигают $800–2000 в месяц на разработчика; авторы фиксировали недели по $3200 на Claude Opus, пока не настроили workflow.
• Скорость на мелочах. В реальном кейсе со сборкой CRM-дашборда та же задача заняла 12 минут на OpenSpec, 90 минут на Spec Kit и 5,5 часов на BMAD.
• Трение на brownfield. Открытые GitHub issues №446 и №563 подтверждают то, что команда видела на рефакторинге legacy-кода: документация-first предположения BMAD плохо ложатся на десятилетний монолит.

BMAD хорош, но дорог и избыточен для большинства еженедельных инженерных задач. Знать, когда его не использовать, так же важно, как уметь его настроить.

Остальные фреймворки: честные мини-обзоры

GitHub Spec Kit

Выпущенный GitHub в конце 2025 года, Spec Kit имеет самую сильную дистрибуцию в категории: 80 000+ звёзд и шаблоны для 24+ AI-агентов, включая Copilot, Claude Code, Gemini CLI, Cursor и Windsurf. Workflow построен на четырёхфазном цикле: specify → plan → tasks → implement. Ключевая фича — «конституция»: общепроектный свод правил, который наследует каждая спецификация и который обеспечивает единообразие без повторного прописывания конвенций в каждом промпте. Установка через specify init, слэш-команды вроде /specify и /plan появляются прямо в редакторе.

Кому подходит: стандартизация качества AI в существующей команде; фичи среднего размера, где нужна строгость, но не целая симулированная команда. Нюанс: первоначальная настройка требует «множества вопросов» — фреймворк opinionated и предполагает вложенное время в сильную конституцию.

OpenSpec

Минималист группы. Вместо генерации полных архитектурных документов OpenSpec использует дельта-спеки: вы описываете только то, что меняется, завершённые спеки архивируются в растущий документ-источник истины, а проектная документация эволюционирует вместе с кодом. Никаких персона, агентных церемоний и спринт-метафор — просто spec → change → archive.

Кому подходит: модернизация legacy-систем и brownfield-проекты, где тяжёлые фреймворки буксуют; команды со ставкой на скорость. Нюанс: скудость церемоний режет в обе стороны — если нужны явные хендоффы между ролями (PM → архитектор → разработчик), лёгкость OpenSpec будет ощущаться как недостающие куски.

GSD (Get Stuff Done)

Мета-промптинговый фреймворк поверх нативных возможностей Claude Code. Трёхфазная воронка и всего два промпта: PLANNING делает gap-анализ и генерирует приоритизированный TODO-список, BUILDING реализует задачи и гоняет тесты по кругу, пока всё не станет зелёным. Философия GSD: сложность должна жить в системе, а не в workflow.

Кому подходит: быстрая итерация на небольших проектах с текучими требованиями; соло-разработчики и маленькие продуктовые команды, уже живущие в Claude Code. Нюанс: ограниченная мультиагентная оркестрация — если нужна настоящая специализация ролей, лёгкость GSD становится потолком.

Hermes

Структурированный коммуникационный слой для сложных мультиагентных систем. Пока другие фреймворки определяют процесс, Hermes определяет протокол того, как агенты передают друг другу контекст, артефакты и решения.

Кому подходит: команды, строящие собственные агентные пайплайны, особенно там, где аудит-grade передача контекста критична — финансовые сервисы, healthcare AI. Нюанс: Hermes ближе к тулкиту, чем к turnkey-методологии; установить и запустить «на сегодня» не выйдет.

AWS Kiro

Kiro — спек-ориентированная агентная IDE от AWS, «джокер» этого обзора: это не методология, а полноценная среда разработки со встроенным фреймворком. Прежде чем написать код, агент создаёт три структурированных документа: requirements.md (пользовательские истории с критериями приёмки в EARS-нотации), design.md (архитектура, sequence-диаграммы, разбор компонентов) и tasks.md (нумерованный чеклист реализации). Анонсированная фича «spec check» математически доказывает непротиворечивость требований до написания кода, а Quick Plan mode с параллельным выполнением задач сокращает время реализации на крупных проектах примерно на 75%.

Кому подходит: AWS-ориентированные магазины, не желающие выбирать методологию сами; команды, уже стандартизированные на одной IDE. Нюанс: vendor lock-in — внутри AWS Kiro отличен, снаружи теряются интегрированный каталог MCP и преимущества параллельного выполнения.

Матрица выбора: какой фреймворк когда

Переменные, которые имеют значение больше прочих, — не фичи фреймворка, а размер команды, тип проекта и требования комплаенса.

Пути миграции: когда перерастаете текущий фреймворк

Хорошая новость: это методологии, а не глубоко связанные платформы, поэтому миграция почти всегда безболезненна. Артефакты (PRD, спеки, истории) переносятся между инструментами, потому что лежат в markdown и JSON.

• OpenSpec → BMAD. Когда brownfield-модернизация удалась и вы строите новое поверх, дельта-модели становится тесно. Архив спек переносится как входной документ для агента-архитектора BMAD.
• Spec Kit → BMAD. Типично после Series A: стартап нанимает первого PM и нуждается в явном разделении ролей. Конституция Spec Kit аккуратно ложится на мастер-промпты агентов BMAD.
• BMAD → GSD. Да, и в обратную сторону: когда сложный BMAD-проект выпущен и команда уходит в режим поддержки, лёгкий двухпромптовый цикл GSD лучше подходит ритму фиксов и мелких фич.
• Всё что угодно → Kiro. Если стек консолидируется на AWS, Kiro привлекает встроенной в IDE методологией. Вы жертвуете гибкостью — получаете интегрированный тулинг.

Пять вопросов, которые стоит задать перед выбором

1. Greenfield или brownfield? Brownfield склоняет к OpenSpec с точечным BMAD brownfield-режимом; greenfield открывает BMAD и Spec Kit.
2. Размер и структура команды? Соло или малая команда — GSD или OpenSpec; растущая команда с явными ролями — Spec Kit; мультикомандный enterprise — BMAD.
3. Требования комплаенса? SOC 2, HIPAA, EU AI Act или Colorado AI Act (вступает в силу в июне 2026) — аудит-дружелюбные артефакты BMAD. Внутренние инструменты — подходит любой фреймворк.
4. Бюджет токенов? BMAD — самый дорогой в эксплуатации, OpenSpec и GSD — самые дешёвые. Если $2000 в месяц на разработчика — не вариант, фильтр сработал сам.
5. Насколько привязаны к одной IDE или облаку? AWS-only — серьёзно посмотрите на Kiro. Мульти-IDE и мульти-модель — BMAD (V6 кроссплатформенный), Spec Kit (24+ агента) или OpenSpec (агностичен к CLI).

Итог

После трёх клиентских проектов и пяти фреймворков самый частый ответ — не BMAD, а «зависит от вопросов выше», причём большинству команд стоит смешивать два-три фреймворка в портфеле, а не стандартизироваться на одном. BMAD — для сложной регулируемой greenfield-работы, OpenSpec выигрывает на brownfield, Spec Kit — самый безопасный выбор для растущей команды, Kiro — простейший путь внутри AWS, GSD — лёгкий инструмент соло-разработчика, Hermes — для собственных пайплайнов. Лучше всего шипят не те команды, что выбрали «правильный» фреймворк, а те, что выбрали уместный для конкретного проекта — и скорректировали его, когда проект изменился.