В статье рассмотрим SDD фреймворки (Spek-Kit, OpenSpec, Kiro, BMAD) и решения не являющиеся полностью SDD, но решающие вопросы упорядочивания разработки с ИИ (Cursor Memory Bank, TaskMaster, Tessl, Supercode, Claude-flow).
Слово "вайбкодинг" в современном мире прижилось плотно, но у большинства разработчиков с опытом вызывает безусловный рвотный рефлекс. С одной стороны ИИ пишет код очень хорошо. Современные модели в алгоритмике уже почти всегда лучше разработчиков.
Но если дело касается большого проекта и Production, всплывают многочисленные проблемы:
Проект выглядит как разрозненные куски кода
Код ИИ не соответствует правилам безопасности, публичным или корпоративным стандартам.
При разработке новой фичи ИИ очень часто ломает старую
Расход контекста и токенов чрезмерно большой
ИИ пишет новую фичу вместо того чтобы внести модификацию в уже разработканную
ИИ нужно каждый раз заново "объяснять" всю логику проекта
Ну и многие другие схожие проблемы.
Их наличие заставляет компании и команды отказываться от использования ИИ, несмотря даже на очевидные преимущества последнего.
Решение давно есть и очевидно на поверхности - SDD. Вся разработка ведётся строго в соответствии со спецификациями. Есть Workflow. Всё строго последовательно - спецификация, план, задачи, код. Творчество моделей ограничено. Этими же фреймворками обеспечивается память моделей и хоть какое то обращение их к предыдущим разработкам. Также есть отдельные фреймворки для памяти проекта (Cursor Memory Bank) и работы с задачами (TaskMaster).
Конечно это делает работу разработчика не столь впечатляющей и "вайбовой" (написал что хочешь и ждёшь). Нужно читать спецификации, при необходимости их корректировать. Работа предельно структурная и в чём то даже нудная. Да, это существенно эффективнее чем ручной набор кода. Но нет, это уже трудно назвать "вайбкодингом" - потому что процесс всё больше напоминает классическую разработку, просто ускоренную до предела. Поэтому для разработки с ИИ всё таки крайне рекомендую пользоваться хоть каким то фреймворком, даже для инди проектов. Это делает вашу работу более устойчивой и позволяет создавать полноценные крупные Production-ready решения ничуть не хуже опытных команд разработки, но существенно быстрее.
Итак, перейдём собственно к обзору:
Spek-Kit
https://github.com/github/spec-kit
63 тысячи звёзд на Github
Поддерживается самим Github
Основной цикл выглядит как то так:
Выбирать этот фреймворк имеет смысл если вы решили что SDD - ваше всё. Вы с ним всерьёз и надолго. И у вас комада, большой или планируется большой проект. Либо вы хотите "вот прямо лучший и правильный SDD".
OpenSpec
https://github.com/Fission-AI/OpenSpec
17 тысяч звёзд на гитхабе
Поддерживается сообществом
Основной цикл примерно такой:
Вцелом я бы рекомендовал начинать с этого фреймворка. Он простой, легковесный, при этом полностью классический Spec-Driven.
Kiro
Не является конечно фреймворком. Kiro - это AI IDE.
Форк VSCode
Поддерживается Amazon
Выглядит как то так:
Основная фишка - поддержка SDD на уровне IDE. Удобство работы намного лучше за счет разделения в одном окне спецификаций по фазам (в интерфейсе мы видим одну спецификацию, в структуре файлов создаются разные файлы). Если вы не привязаны к какому либо агенту или IDE - прекрасная мысль попробовать сразу Kiro
BMAD
https://github.com/bmad-code-org/BMAD-METHOD
30 тысяч звёзд на Github
Поддерживается сообществом.
Выглядит Workflow примерно так:
Как по мне так "попытка впихнуть невпихуемое" - включить в т.ч. Agile процессы разработки.
В итоге фреймворк чрезмерно усложнён. А команды вряд ли спрыгнут с излюбленного инструментария управления проектом\продуктом\задачами. Я бы не рекомендовал пока использовать этот фреймворк. Но 30 тысяч старов на гитхабе говорят что очень многие со мной не согласны.
Cursor Memory Bank
https://github.com/vanzan01/cursor-memory-bank
3 тысячи звёзд на Github
Поддерживается по сути одним автором
Флоу выглядит как то так
Фреймворк ориентирован не на SDD - спецификации можно использовать но они не требуются, а на сохранении памяти о ваших решениях и о проекте. Главным образом нужен чтобы модель не теряла контекст. Контекст запоминается для постоянного хранения и подгружается динамически по требованию. Этим конечно существенно снижаем ошибки и улучшаем качество кода.
Task Master
https://github.com/eyaltoledano/claude-task-master
25 тысяч звёзд на github
Как такового Workflow нет.
По сути предоставляет очень удобный инструмент с отдельной моделью (можно настроить) который разбивает написанный вами PRD на задачи и далее отслеживает их выполнение. Если у вас крупный проект и агент должен работать долго, но при этом вы не хотите внедрять что то более серьёзное штука крайне полезная. Экономит контекст, сохраняет фокус, управляет задачами. К SDD тоже по сути не имеет большого отношения
Tessl
По сути дела большой динамический репозиторий контекста для различных фреймворков.
Для меня он не сильно релевантен в силу того что у меня в основном 1С, которой тут нет.
Но для классических языков разработки позволит конечно решить массу вопросов
Claude-Flow
https://github.com/ruvnet/claude-flow
12 тысяч звёзд на github
Поддерживается по сути одним автором
Совмещает в себе очень много всего:
Агенты, память, задачник, MCP и многое другое.
Фреймворком назвать наверное трудно, как и SDD (хотя конечно может использовать для SDD).
Я бы просто сказал Must have набор для любителей CC. У меня основная среда - Cursor, так что мне данный репозиторий менее актуален
Supercode
Незаменимая штука для любителей Cursor
Авторы расширения устраняют косяки которые вносит команда разработки Cursor.
В частности, возвращают внезапно снесенные ввиду какого то дебилизма Custom Modes
А также добавляют Smart Actions, Workflows и кучу других полезных фич, до которых команда разработки Cursor почему то не додумалась.
Выглядит это всё примерно вот так:
В бесплатном варианте не доступны голосовые команды и улучшение промптов, но главное что нужно доступно. Как минимум Memory Bank позволяет установить именно с Custom Modes (что несомненно лучше и удобнее) и одной кнопкой.
Итого
ИИ разработка уже давно переросла период "написал промпт и получил случайны почти работающий код". Если у вас "не работает вайб кодинг" значит "вы просто не умеете его готовить". Используйте нужный инструментарий, пишите спеицификации, ну и конечно же подписывайтесь на мой канал https://t.me/comol_it_does_matter, а если хотите детально этот инструментарий изучить - тоже Welcome
Комментарии (10)
evomed
16.01.2026 19:06ИИ пишет код очень хорошо. Современные модели в алгоритмике уже почти всегда лучше разработчиков.
Сразу вспоминается вчерашняя простыня "лучшей в мире модели для кодинга" Опус 4.5, полностью состоящая из дублирования кода, с хардкодом значений вместо констант..
Dieseluk
16.01.2026 19:06Два месяца активно на claude code с опусом, ни разу такого не попадалось.В правилах clean code и ddd. Может, поэтому?
evomed
16.01.2026 19:06ИИ пофиг на эти правила с mcp с ростом контекста. Ещё, как вероятность сработает. Но чего ожидать, их обучали на говнокоде, вот они и воспроизводят паттерны. Я уже привык ко всякой тупости и говнокоду от ИИ, уже знаю, что будет много итераций исправлений. Все равно в итоге в 3 раза быстрее.
Antra
16.01.2026 19:06Спасибо!
Очень схожие ощущения (BMAD слишком заумный для меня, SpecKit - для моих задач избыточен, OpenSpec - самое то).
И небольшая добавка - я часто сначала пишу будущий Proposal. Потом скармливаю Gemini 3, и она выдает нормальный текст для /openspec:proposal.
У меня Gem есть для преобразования. Начинается как
Act as a 'Senior Technical Product Manager and Prompt Architect'. Your specialty is translating high-level, sometimes vague human ideas into rigorous, machine-readable specifications. You are the bridge between a user's vision and an AI Agent's execution. Your tone is professional, analytical, and highly structured, but you use simple language to ensure clarity.
...
И он сначала задает несколько уточняющих вопросов по "моей" спеке, уточняет какие-то моменты, и формирует уже более четкий текст, по которому проще генерится proposal, с меньшим количеством уточнений и вольностей.
Разумеется, можно и другую модель использовать для подобной цели. Но предварительно из своего потока сознания получить нечто структурированное и без неоднозначностей, на основании чего уже реально с OpenSpec работать, существенно улучшает следующие этапы.
Druzd
16.01.2026 19:06для экономии токенов и мемори банк использую допиленную под bsl serena. Очень полезный mcp, советую.
aborouhin
Ну это не обзор получился, а скорее перечисление :) Попробовать бы с помощью каждого фреймворка (а) создать некий проект и (б) допилить фичу в существующий - и поделиться результатами, возникавшими непонятками в процессе и потраченным временем... Такое тоже находил, но по нескольким фреймворкам только.
В копилку добавлю:
Agent OS
GSD
Beads + Gas Town
А вот Tessl пока из этого списка, IMHO, можно бы исключить. Существующий продукт у них очень нишевый, закрывает одну задачу и не сильно понятно, зачем вообще нужен при живом Context7. Но они пилят (в приватной бете пока) какую-то вундервафлю, которая якобы перенесёт всё на совершенно новый уровень, где спецификация исчерпывающе описывает код... про это было вот в этой статье, после которой все их и начали в контексте SDD фреймворков упоминать, хотя пока, вроде, рановато.
А так тема безусловно интересная, ну и развивается буквально на глазах, любопытно, что в итоге выживет и во что превратится в процессе.
comol85 Автор
Ну я всё это проделал. А если описать в статье - получится не статья а учебник. Я вроде поделился результатми применимости того или иного фреймворка и косяками. Ну правда несколько из последних не трогал - там да, в конце перечисление. Tessl в том числе. Но показался интересным. Context7 закрывает только базовый контекст фрейвморков. В Tessl кейсов побольше насколько могу судить.
Я отбирал по популярности... Agent OS и GSD - по 3000 старов - моловато. Memory Bank просто под Cursor и используется всем окружением, поэтому попал.
Beads писали уже видел пробовал, результат у меня лично получился никакой, поэтому его не упоминал
aborouhin
Мне кажется, на этом этапе, когда всем инструментам ещё по несколько месяцев от роду, количество звёзд вообще не показатель. Весьма вероятно, что industry standard станет вообще не существующий пока что фреймворк, но вот основываться он будет на тех или иных концепциях, которые сейчас появляются, и не факт, что только в самых популярных продуктах.
Для себя пока что понял, что BMAD - оверкилл (но надо вернуться к этому вопросу после обещанной v6 с радикальными изменениями); из очень похожих Spec-Kit и OpenSpec для нового проекта выигрывает первый, для уже существующего - второй; Beads и частично GSD представляют собой концептуально интересную альтернативу, но при этом у автора Beads уже на этапе написания этого инструмента крышу изрядно снесло, а когда он переключился на Gas Town - то окончательно :), так что этим можно вдохновляться, но вряд ли использовать. Остальное надо ещё пробовать.
Мне тема интересна, т.к. я хороший аналитик, но посредственный программист :), для меня подготовка спек - понятное и интересное занятие. Тогда как многие программисты плюются на SDD именно потому, что, мол, зачем вычитывать/править кучу текста, если можно сразу к коду приступать.
По Tessl - они добавляют в контекст свои спецификации, как правильно использовать фреймворк/библиотеку. Но современные LLM достаточно умны, чтобы и сами разобраться в этом, если подсунуть им актуальную документацию (что и делает Context7). При этом спецификации от Tessl полной документации не заменяют, так что экономией токенов это тоже не объяснить. Ну и, в конце концов, если действительно так нужна роль "сделать выжимку из документации и запихнуть в контекст" - что мешает именно для этой роли запустить отдельного агента, не плодя фреймворки? Вряд ли Tessl свои спецификации вручную писали тоже.
maxim_ge
Тут есть определённая проблема с "кучей". "Кучу текста" трудно понять и гарантировать, что реализация соответствует этой самой куче.
LLM тут отчасти помогают - можно сделать review на соответствие - но на "куче" весьма высок процент ложно-положительных срабатываний.
PS. Сам постоянно пишу спеки, перечень проблем примерно такоей- сделать покороче, убрать дублирование и описание очевидных моментов, добиться согласованности.
Bardakan
промпт был "дай список из 10 SDD фреймворков и кратко распиши каждый из них"?