GitHub Spec Kit против Kiro и Claude Code: сравнение SDD-процессов

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Сотрудничество команды — Могут ли несколько человек ревьюить одни и те же артефакты спецификации в пулл-реквестах? Можете ли вы комбинировать агентов, не переписывая процесс?

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

GitHub Spec Kit

GitHub Spec Kit — это open-source CLI-набор инструментов, который создаёт каркас цикла SDD в вашем репозитории и передаёт выполнение тому кодинг-агенту, которым вы уже пользуетесь. CLI specify размещает шаблоны, slash-команды и стандартную структуру папок. Типичные команды следуют последовательности constitution-specify-clarify-plan-tasks-implement, с явным шагом «clarify» для устранения неоднозначностей перед началом архитектурной работы.

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

Компромиссы реальные. Spec Kit может породить большое дерево артефактов — constitution, spec, plan, tasks, contracts — что оправдывает себя на фичах, длящихся несколько сессий, но кажется громоздким для небольшой правки 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. Требования, дизайн и задачи — это объекты первого класса в пользовательском интерфейсе рядом с вашим кодом, а не файлы, которыми вы управляете через отдельный 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 slash-командами или изобрести минимальный рабочий процесс, подходящий одному репозиторию. Claude Code читает CLAUDE.md для постоянного контекста проекта и подтягивает навыки, когда задача совпадает. Эта постепенная раскрытие информации сохраняет сессии сфокусированными, не загружая полный устав при каждом промпте.

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

Для серьёзной реализации прочитайте [Навыки Claude и SKILL.md для разработчиков](https://www.glukhov.org/ru/ai-devtools/claude-code/claude-skills-for-developers/ “Навыки Claude и SKILL.md для разработчиков”}) и закодируйте ваши фазы как навыки с явными точками ревью. SDD на Claude Code — правильный выбор, если вы уже живёте в Claude Code, хотите максимальную гибкость и будете поддерживать рабочий процесс сами. Для этапа точек ревью конкретно, субагенты Claude Code могут выполнять независимый проход ревью с изолированным контекстом сгенерированного кода перед тем, как вы объедините задачу — это лёгкая замена для роли верификации, которую нативно обеспечивают Agent Hooks в Kiro.

Superpowers: Упакованная версия DIY-стека навыков

Если самостоятельная сборка этого стека навыков звучит как раз как та проблема дисциплины, на которую указывает таблица выше, стоит посмотреть на Superpowers. Это open-source пакет навыков — мозговой штурм, написание планов, разработка, управляемая субагентами, разработка, управляемая тестами, запрос ревью кода и дюжина поддерживающих навыков — распространяется в виде устанавливаемого плагина, а не чего-то, что нужно писать с нуля. Он напрямую атакует ограничение «качество полностью зависит от дисциплины автора»: навыки срабатывают автоматически и предназначены для того, чтобы быть обязательным рабочим процессом, а не опциональными предложениями, которые агент может пропустить.

Рабочий процесс, который он накладывает, тесно соответствует пятифазному циклу, описанному в Рабочий процесс разработки по спецификациям: от требований к коду: мозговой штурм дорабатывает грубую идею в ревьюируемый документ дизайна, написание планов разбивает её на небольшие проверяемые задачи, разработка, управляемая субагентами, запускает свежего субагента на задачу с двухэтапным ревью, а разработка, управляемая тестами, принуждает к строгому циклу «красный-зелёный-рефакторинг», прежде чем что-либо считается завершённым. Эта последняя часть строже, чем большинство навыков SDD на Claude Code заботятся об этом — Superpowers явно удаляет код, написанный до того, как для него существовал падающий тест.

В отличие от локального в репозитории навыка, который вы пишете сами, Superpowers не только для Claude Code. Он поставляется с манифестами плагинов для Claude Code, Cursor, Codex, Gemini CLI, GitHub Copilot CLI, Devin, Factory Droid и нескольких других агентов, так что одна и та же методология следует за вами между обвязками, а не живёт в одной папке .claude/skills/. Это делает его средним вариантом между созданием собственного навыка Claude Code и принятием более тяжёлого, специфичного для IDE инструмента, такого как Kiro: вы получаете убедительный, принуждаемый цикл, не отказываясь от своего редактора и не привязываясь к формату спецификаций одного вендора.

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

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

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

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

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

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

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

gstack заходит дальше слоя спецификаций: он оборачивает кодинг-агента в полную виртуальную инженерную команду — ревью продукта, ревью архитектуры и дизайна, браузерное QA, аудиты безопасности и цепочка релизов «запустить-развернуть», — так что спецификация становится одним из нескольких принудительных этапов, а не фундаментом. Он работает на Claude Code и девяти других агентах, и руководство описывает, как позволить Spec Kit (или OpenSpec) владеть фундаментом планирования, пока gstack обеспечивает те слои, которые инструмент спецификаций не принуждает.

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

Какой набор SDD вы должны использовать?

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

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

Хотите подход навыков Claude Code, но постоянно пропускаете свои точки ревью. Установите Superpowers вместо написания кастомного навыка с нуля. Вы жертвуете некоторой настройкой под проект в обмен на принудительный цикл «мозговой штурм-план-реализация-ревью», который не зависит от вашей дисциплины в этот день.

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

Маленькая команда, смешанные редакторы. Spec Kit. Чистые Markdown-спецификации в Git, ревью в пулл-реквестах, выполняемые тем агентом, которого предпочитает каждый разработчик.

Корпоративная команда, 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, а не заменяет их. Если ваша команда работает с терминал-ориентированным агентом, а не интегрированным в IDE, практическое руководство по CLI OpenCode показывает более лёгкую, промпт-уровневую версию той же дисциплины «план перед реализацией» — полезно, когда полное дерево Spec Kit — это больший церемониал, чем заслуживает задача.

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

Что действительно определяет успех

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

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

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

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

Заключение

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

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

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

• Документация GitHub Spec Kit — официальный справочник по рабочему процессу Spec Kit
• Быстрый старт Superpowers: установка, рабочий процесс и пробная эксплуатация — open-source пакет навыков, налагающий методологию от мозгового штурма до TDD для Claude Code, Cursor, Codex и других агентов
• gstack: Убедительный стек для ИИ-инженерии ПО — вариант с полной виртуальной инженерной командой и то, как он комбинируется с Spec Kit, OpenSpec и Superpowers
• Мартин Фаулер об инструментах SDD — анализ Kiro, Spec Kit и Tessl