GitHub Spec Kit против Kiro против рабочих процессов Claude Code SDD

Разработчики, сравнивающие настройки спецификации-ориентированной разработки (Spec-Driven Development, SDD) в 2026 году, обычно не спрашивают, какая модель самая умная. Они спрашивают, какой рабочий процесс позволит сохранить согласованность работы ИИ-агентов, не погружая их в бюрократические ритуалы.

GitHub Spec Kit, AWS Kiro и пользовательские рабочие процессы Claude Code реализуют одну и ту же общую идею — требования, дизайн, задачи, реализация, валидация — но они по-разному балансируют между портативностью, глубиной интеграции и степенью принудительного соблюдения процессов.

Если вам сначала нужны концепции, прочитайте статью Что такое спецификация-ориентированная разработка? и нейтральное к инструментам руководство Рабочий процесс спецификации-ориентированной разработки в кластере документации по Архитектуре приложений. Это сравнение находится в хабке Инструменты для ИИ-разработчиков наряду с обзорами ассистентов и руководствами по рабочим процессам. В нем рассматриваются три настройки, которые чаще всего обсуждают разработчики на Hacker News и в форумах в стиле Reddit, а также более легкие и тяжелые альтернативы, вращающиеся вокруг них.

SDD становится категорией инструментов

Спецификация-ориентированная разработка перестала быть просто теоретическим упражнением где-то в конце 2025 года. Каждый крупный вендор ИИ для написания кода теперь предлагает свою версию цикла «определить-спланировать-реализовать», и растущий список автономных инструментов соревнуется в том, какую структуру они добавляют вокруг этого цикла.

Сравнение, которое имеет значение — это не «какой инструмент побеждает». Это глубина процесса против портативности. Kiro интегрирован. Spec Kit портативен. Рабочие процессы Claude Code можно легко адаптировать. Плохие спецификации делают каждого агента хуже, независимо от того, какую оболочку вы выберете. Хорошие спецификации перемещаются между инструментами.

Как сравнивать настройки SDD

Прежде чем выбрать инструмент, определите, на что вы оптимизируетесь. Одна и та же функция может казаться effortless (легкой) в одной настройке и бюрократической в другой, в зависимости от размера команды, возраста кодовой базы и количества необходимых проверок.

Портативность — могут ли спецификации существовать как обычный markdown в вашем репозитории и работать с агентом, который вы предпочтете в следующем квартале? Или они привязаны к одной IDE, одному облаку или одному проприетарному формату?

Трение при настройке — сколько времени проходит от «я хочу попробовать SDD» до рабочего цикла «определить-спланировать-задачи»? CLI-каркас, установка IDE или создание собственных слэш-команд имеют разную энергию активации.

Качество спецификации — помогает ли инструмент писать точные требования и критерии приемки, или он в основном генерирует длинные документы? Структура полезна. Объем — нет.

Исполнение задач — как инструмент разбивает работу на проверяемые фрагменты? Могут ли задачи выполняться параллельно? Сопротивляет ли он взрывному росту списков задач до пятидесяти пунктов?

Контрольные точки проверки — есть ли естественные человеческие ворота между этапами определения, планирования, задач и реализации? SDD без проверки — это просто более медленное «вайб-кодирование».

Привязка к репозиторию — читает ли рабочий процесс конвенции проекта, записи о решениях, ADR, AGENTS.md и существующий код перед планированием? Агенты без привязки к контексту изобретают архитектуру заново, потому что они никогда не видят проверенное намерение, стоящее за предыдущими решениями.

Командное сотрудничество — могут ли несколько человек проверять одни и те же артефакты спецификации в pull request? Можете ли вы смешивать агенты, не переписывая процесс?

Привязка к платформе (Lock-in) — что вы теряете, если смените редактор, модель или облачного провайдера через шесть месяцев?

GitHub Spec Kit

GitHub Spec Kit — это набор инструментов CLI с открытым исходным кодом, который создает каркас для цикла спецификации-ориентированной разработки в вашем репозитории и передает выполнение тому агенту для написания кода, который вы уже используете. CLI specify создает шаблоны, слэш-команды и стандартную структуру папок. Типичные команды следуют последовательности конституция-определить-уточнить-спланировать-задачи-реализовать, с явным шагом уточнения для разрешения неоднозначностей перед началом работы над архитектурой.

Определенное преимущество Spec Kit — независимость от агента. Официальная документация позиционирует его как инструмент, который работает с Claude Code, GitHub Copilot, Cursor, Gemini CLI, Codex и десятками других агентов. Вы пишете спецификации один раз в markdown, коммитите их как код и меняете исполнитель без переписывания процесса. Это делает Spec Kit рекомендацией по умолчанию для команд, которые хотят SDD без ставок на одного вендора.

Компромиссы реальны. Spec Kit может создать большое дерево артефактов — конституция, спецификация, план, задачи, контракты — что окупается на многозадачных функциях, но кажется тяжелым для небольшого изменения в CLI. В потоках Hacker News регулярно сравнивают эти накладные расходы с церемонией водопадного метода. Spec Kit также слабее, если вы хотите полностью интегрированную IDE, где спецификации, задачи и реализация живут на одном управляемом интерфейсе. Он накладывает процесс поверх вашего существующего редактора, а не заменяет его.

Spec Kit подходит командам, у которых уже есть предпочтительный ИИ-ассистент для написания кода и который хочет стандартизированный каркас SDD поверх него. Он особенно силен для новых функций (greenfield), многоагентных команд и всех, кто отказывается от привязки к редактору.

AWS Kiro

Kiro — это IDE для спецификации-ориентированной разработки от AWS, построенная на форке VS Code / Code OSS. Если Spec Kit приносит SDD в ваш существующий стек, то Kiro предполагает, что SDD заслуживает специальной среды. Промпт генерирует структурированные артефакты — обычно requirements.md в нотации EARS-стиля, design.md и tasks.md с последовательностью зависимостей — прежде чем агенты напишут продакшен-код.

Управляемый опыт — главная продающая точка Kiro. Требования, дизайн и задачи являются первоклассными объектами UI рядом с вашим кодом, а не файлами, которые вы управляете через отдельный CLI. Kiro также поставляется с Agent Hooks — событийными автоматизациями, которые могут обновлять тесты, документацию или связанные артефакты при изменении реализации. Этот двунаправленный цикл — то, что Spec Kit не предоставляет из коробки — спецификации Spec Kit остаются статичными, пока человек не обновит их.

Затраты — это глубина интеграции в обмен на портативность. Kiro работает внутри своего редактора, использует модели на базе AWS Bedrock и тарифицируется по кредитной модели с поэтапными планами. Корпоративные команды, уже использующие инфраструктуру AWS, часто находят это приемлемым. Соло-разработчики и команды с несколькими редакторами — возможно, нет. U Kiro также есть шероховатости, типичные для новой IDE — совместимость расширений, сюрпризы в рабочем процессе и обычный вопрос «а действительно ли мне нужен еще один редактор?».

Kiro подходит разработчикам, которые хотят самый управляемый опыт SDD и готовы принять нативную IDE для спецификаций. Это сильный вариант для корпоративных команд, сред с упором на AWS и всех, кто мигрирует из Amazon Q Developer и хочет дисциплину спецификаций без ручной сборки цепочки инструментов. Если вы сегодня живете в стандартном VS Code и любите свою текущую настройку, Kiro требует более серьезного переключения, чем Spec Kit.

Пользовательские команды и навыки Claude Code

Claude Code не выпускает единый официальный продукт SDD, как Spec Kit или Kiro. Если вы новичок в самом инструменте, начните с руководства по установке и настройке Claude Code для настройки, разрешений и локальных бэкендов. Сам паттерн SDD живет в пользовательских командах, навыках и локальных для репозитория шаблонах markdown, которые поддерживают разработчики. Anthropic объединила старые файлы .claude/commands/*.md в механизм Skills, поэтому устойчивый паттерн — это SKILL.md (или эквивалент), который определяет ваш чек-лист «определить-спланировать-реализовать», загружаемый по запросу.

Этот подход самый легкий и самый «хакерский». Вы можете перенести структуру из трех файлов в стиле Kiro, отразить фазы Spec Kit с помощью слэш-команд или изобрести минимальный рабочий процесс, который подходит для одного репозитория. Claude Code читает CLAUDE.md для постоянного контекста проекта и подтягивает навыки, когда задача совпадает. Эта прогрессивная раскрытие информации держит сессии сфокусированными, не загружая полную конституцию при каждом промпте.

Минус — дисциплина. Ничто не заставляет вас проходить через ворота уточнения или проверки, если вы сами не построите эти ворота. Потоки Reddit и Hacker News о «спецификации-ориентированной разработке внутри Claude Code» полны разработчиков, которые скопировали чужой навык, запустили его один раз и вернулись к неструктурированному промптингу, когда навык казался медленным. SDD в Claude Code работает, когда вы относитесь к навыкам как к коду — версионируете, проверяете и поддерживаете их, а не как к одноразовой загрузке промпта.

Для серьезной реализации прочитайте Claude Skills и SKILL.md для разработчиков и закодируйте ваши фазы как навыки с явными контрольными точками проверки. SDD в Claude Code — правильный выбор, когда вы уже живете в Claude Code, хотите максимальной гибкости и будете поддерживать рабочий процесс самостоятельно.

BMAD, OpenSpec и другие рабочие процессы

Не каждой команде нужно дерево артефактов Spec Kit или IDE Kiro. В сравнениях 2026 года постоянно появляются две альтернативы.

OpenSpec (Fission AI) использует подход, ориентированный на изменения, с меньшим количеством генерируемых файлов, чем Spec Kit. Сообщество сообщает о существенно меньшем использовании токенов для сопоставимых задач, ценой меньшей предварительной структуры. OpenSpec часто побеждает, когда вы модифицируете существующую кодовую базу и хотите проверяемые спецификации без фазы планирования на 800 строк. Он соревнуется со Spec Kit в портативности, а не с Kiro в интеграции с IDE.

BMAD-METHOD (сообщество) движется в противоположном направлении — многоагентные рабочие процессы на основе ролей, которые симулируют персоны владельца продукта, архитектора, разработчика и ревьюера. BMAD может быть мощным в крупных новых проектах (greenfield), где явное разделение ролей помогает. Он также тяжелый. Команды часто сообщают, что церемония окупается только тогда, когда боль координации уже острая.

Tessl рассматривает спецификацию как буквальный источник генерируемого кода, маркируя вывод как производный и отговаривая от ручных правок. Это самая сильная позиция «спецификация как источник» среди основных инструментов, но Tessl остается в бете и несет самый высокий уровень привязки к продукту в группе.

Spec Kitty и другие каркасы сообщества занимают среднюю позицию между OpenSpec и Spec Kit по весу. На них стоит обратить внимание, если вам нужны шаблоны без принятия полного инструментария GitHub.

Паттерн во всех них один и тот же. Больше процесса помогает, когда неоднозначность дорогая. Больше процесса вредит, когда скорость обратной связи важнее согласованности. Сопоставляйте вес инструмента с размером задачи, а не с хайпом.

Какую настройку SDD вам следует использовать?

Универсального победителя нет. Правильная настройка зависит от того, кто вы, что вы строите и какую структуру вы на самом деле будете поддерживать.

Соло-разработчик, существующая кодовая база, мелкие функции. Начните с навыков Claude Code или OpenSpec. Напишите короткий блок требований, минимальный список задач и одну контрольную точку проверки. Не устанавливайте полное дерево Spec Kit для изменения в пятьдесят строк.

Соло-разработчик, новая функция (greenfield), несколько сессий. Spec Kit или хорошо поддерживаемый навык SDD для Claude Code. Вам нужны долговечные артефакты больше, чем помощь IDE.

Маленькая команда, смешанные редакторы. Spec Kit. Обычные спецификации в markdown в Git, проверяемые в pull request, выполняемые тем агентом, который предпочитает каждый разработчик.

Корпоративная команда, нативная AWS, давление соответствия. Kiro. Управляемые артефакты, прослеживаемость требований и хуки, которые держат документацию и тесты ближе к реализации.

Регулируемая среда. Kiro или Spec Kit плюс ваш собственный чек-лист валидации — не только навыки Claude Code, если вы явно не закодируете ворота соответствия. Инструментарий не заменяет аудиторские следы. Он только облегчает их создание.

Существующая кодовая база, изменение в существующем проекте (brownfield). OpenSpec или легкий рабочий процесс Claude Code. Полная церемония Spec Kit для каждого исправления ошибки будет казаться водопадом. Оставьте более тяжелую структуру для сквозных функций.

Новый продукт (greenfield), много агентов. Spec Kit. Портативность важнее полировки IDE, когда Copilot, Claude Code и Cursor могут касаться одного и того же репозитория.

Командам, экспериментирующим с оркестрацией нескольких агентов, также стоит посмотреть на Oh My OpenCode Agents для паттернов разделения ролей между агентами — дополнения к артефактам SDD, а не их замены.

Практическая таблица решений

Что на самом деле определяет успех

Выбор инструмента имеет меньшее значение, чем качество артефактов. Файл требований в Kiro с размытыми критериями приемки приведет к тому же дрейфу, что и небрежный промпт в Claude Code. План Spec Kit, в котором перечислено пятьдесят избыточных задач, будет казаться водопадом, независимо от того, какой агент его реализует.

Практики, которые работают в каждой настройке, скучны и эффективны. Держите спецификации достаточно маленькими, чтобы проверить их за одно сидение. Явно пишите нецели (non-goals). Разбивайте задачи на диффы, которые человек может прочитать. Валидируйте против критериев приемки перед слиянием. Обновляйте спецификацию, когда реализация находит лучший путь.

Если вы все еще выбираете между SDD и неструктурированным промптингом для данной функции, прочитайте Спецификация-ориентированная разработка против вайб-кодирования. Сравнение инструментов в этой статье имеет значение только после того, как вы решили, что функция заслуживает спецификации вообще.

Плохие спецификации делают каждого агента хуже. Хорошие спецификации перемещаются между инструментами.

Заключение

GitHub Spec Kit, Kiro и рабочие процессы Claude Code — это три ответа на один и тот же вопрос — как сохранить согласованность работы ИИ-агентов между сессиями — с разными ставками на портативность против интеграции. Spec Kit оптимизируется для агностичного к агентам markdown в вашем репозитории. Kiro оптимизируется для управляемой нативной IDE для спецификаций с агентами на базе AWS. Навыки Claude Code оптимизируются для «хакерских», легковесных рабочих процессов, которые успешны только тогда, когда вы их поддерживаете.

Выберите самую легкую настройку, которая все еще устраняет неоднозначность для текущей функции. Добавляйте структуру, когда появляется боль координации, а не когда блог-пост говорит вам это сделать. Разработчики, которые получают ценность от SDD в 2026 году, — это не те, у кого самая сложная цепочка инструментов. Это те, кто пишет спецификации, которые стоит реализовывать, — а затем позволяет выбранному ими инструменту выполнять их.

Полезные ссылки

• Документация GitHub Spec Kit — официальный справочник по рабочему процессу Spec Kit
• Мартин Фаулер об инструментах SDD — анализ Kiro, Spec Kit и Tessl