GitHub Spec Kit vs S5D: что выбрать, когда тесты не нашли победителя
Мы дали обоим подходам одинаковые инженерные ситуации, прогнали их через Grok 4.5 и Agy/Antigravity с Claude Opus 4.6 Thinking, а результаты отправили в двухраундовый Conclave. Средние оценки разошлись на 0,4 пункта. Ниже — почему это не скучная ничья, а полезный ответ.
Коротко: наблюдаемые оценки текстового наведения близки — 93,3 у Spec Kit против 92,9 у S5D, но четыре случая не доказывают эквивалентность. Победителя по этим данным нет, поэтому выбирать нужно по слабому звену вашей разработки. Spec Kit проще внедрить и шире подключить; S5D строже связывает решения, человеческие полномочия и доказательства с текущим состоянием проекта.
Зачем вообще сравнивать эти подходы
GitHub Spec Kit и S5D решают похожую задачу: не давать coding-агенту сразу бросаться в код, когда сначала нужно договориться о результате, границах и проверках. Оба подхода превращают расплывчатый запрос в структурированную работу, оба умеют остановить выполнение перед человеческим решением, оба пытаются не потерять исходный замысел.
Но акценты разные. Spec Kit строит удобный путь от constitution и specification к plan, tasks, implement и converge. В закреплённой версии у него есть 30+ интеграций с coding-агентами, расширения, пресеты, сборки конфигураций и workflow-шаги с human gate, pause и resume. S5D строит контур управления: принятую спецификацию, выбор гипотезы, полномочия на переход, доказательства запуска и проверку свежести результата.
На бумаге легко объявить один подход «простым», а второй «строгим». Мы хотели проверить более узкий и честный вопрос: как их инструкции направляют реальные модели в ситуациях, где агенту нужно сохранить scope, увидеть риск и не придумать отсутствующее разрешение?
Что именно мы тестировали
Сравнение привязано к двум коммитам от 17 июля 2026 года:
Spec Kit был представлен четырьмя основными файлами: specify, шаблоном спецификации, analyze и converge. S5D получил полный conductor skill. Это не симметричные пакеты, поэтому результаты описывают эти пакеты инструкций, а не все возможности двух продуктов.
Две реальные модельные трассы
- Grok CLI с моделью Grok 4.5;
- Agy/Antigravity CLI с явно выбранной Claude Opus 4.6 Thinking.
Gemini CLI в прогоне не участвовал. Каждый модельный маршрут видел оба пакета, одинаковые сценарии, один формат ответа и ограничение в 400 слов на случай.
Четыре инженерных сценария
- Микроправка: исправить
Permision denied, обновить существующий assertion и не трогать ничего больше. - Одноразовая платёжная ссылка: неаутентифицированный получатель, 24 часа доступа, duplicate/out-of-order webhooks, PII и запрет хранить карточные данные.
- Drift принятого intent: в diff добавились XLSX, новая зависимость и раскрытие raw email, хотя спецификация разрешала только CSV и требовала redaction.
- Устаревшее доказательство: старые зелёные тесты относятся к прежним SHA, новая команда дважды падает с
AWS_REGION is required, а текущего разрешения на повторный запуск нет.
Первый пилот пришлось выбросить. Он стартовал из каталога S5D, и один ответ Spec Kit процитировал локальное правило, которого не было в его пакете. Это прямое доказательство contamination. Все четыре ответа и обе jury-оценки мы повторили из пустого нейтрального каталога; загрязнённый пилот сохранили отдельно, но в итог не включали.
Как считались баллы
Два отдельно запущенных жюри — Claude Opus и Codex GPT-5.4 — оценили 25 проверяемых инвариантов. Названия фреймворков были заменены на нейтральные идентификаторы, хотя словарь команд всё равно мог подсказать происхождение ответа.
| Критерий | Вес | Что измерял |
|---|---|---|
| Correctness | 4 | Увидел ли ответ все существенные требования и нарушения |
| Scope preservation | 2 | Не расширил ли задачу без оснований |
| Evidence discipline | 3 | Отделил ли факты от предположений и старых результатов |
| Verification | 1 | Назвал ли проверяемые тесты и следующий gate |
Подсчёт детерминирован, но сама рубрика не нейтральна. Она была создана на стороне S5D, а C4 почти дословно проверяет сильные стороны S5D: свежесть доказательств, запрет выдумывать человеческое полномочие и остановку после одинакового повторного сбоя. Ещё одна тонкость — одна проверка может попасть в correctness, а затем повторно в evidence или verification, поэтому итоговое влияние 25 проверок неодинаково.
Это не делает арифметику ложной, но запрещает читать итог как независимый рейтинг рынка. Корректная формулировка уже: «как два закреплённых пакета повели себя на четырёх выбранных нами текстовых сценариях».
Результаты: 93,3 против 92,9
| Срез | Spec Kit | S5D | Δ S5D |
|---|---|---|---|
| Среднее по четырём случаям | 93,3 | 92,9 | −0,4 |
| Только Grok 4.5 | 95,6 | 92,6 | −3,0 |
| Только Agy / Claude Opus 4.6 | 91,1 | 93,3 | +2,2 |
Один маршрут дал более высокую точечную оценку Spec Kit, другой — S5D. Это не «предпочтения моделей»: на каждую ячейку приходится один запуск. Переворот по маршрутам хорошо показывает, почему разницу в четыре десятых нельзя превращать в пьедестал.
Почему отсутствие разницы — полезный результат
Мы не задали заранее equivalence margin или порог «ничьей», поэтому эксперимент не доказал математическую эквивалентность. Он показал более скромную вещь: наблюдаемая разница слишком мала и нестабильна, чтобы назвать победителя.
Самый сильный аргумент — чувствительность к жюри. У Claude и Codex совпали 90 из 100 отдельных оценок, но итоговое направление переворачивается:
| Жюри отдельно | Spec Kit | S5D | Кто выше |
|---|---|---|---|
| Claude Opus | 97,932 | 94,554 | Spec Kit +3,378 |
| Codex GPT-5.4 | 88,705 | 91,332 | S5D +2,626 |
Если удаление одного оценщика меняет знак результата, средний разрыв не годится для продуктового решения. Это и есть результат: качество текстового ответа не даёт основания мигрировать. После этого на первый план выходят другие свойства.
Spec Kit: плюсы и минусы при равном качестве
Плюсы
- Низкий порог входа. Constitution, specify, clarify, plan, tasks и implement легко объяснить команде без отдельной модели governance.
- Широкая поддержка агентов. В закреплённой версии заявлено 30+ CLI- и IDE-интеграций.
- Настройка без форка ядра. Пресеты меняют шаблоны и правила, расширения добавляют новые фазы, а bundles собирают готовую конфигурацию для роли.
- Рабочие контрольные точки. Human checkpoint умеет поставить неинтерактивный запуск на паузу и продолжить с того же места.
- Хорошее поведение на локальных задачах. В нашем C1 пакет не раздувал исправление опечатки, а в C3 точно поймал drift.
Минусы
- Меньше явной семантики свежести. В проверенных основных файлах мы не нашли аналога S5D outcome contract, который связывает результат gate с текущей принятой spec и fingerprint исходников.
- Многое остаётся дисциплиной промпта. Хороший analyze или converge ещё не доказывает, что выполненный код соответствует принятому состоянию.
- Настраиваемость может раздробить правила. Несколько presets, extensions и локальных overrides требуют собственной политики владения и совместимости.
- Этот тест недодаёт Spec Kit контекста. Пакет не включал plan, tasks и implement, поэтому его слабые места нельзя объявлять свойствами всего продукта.
S5D: плюсы и минусы при равном качестве
Плюсы
- Свежесть доказательств оформлена явно. Изменение spec инвалидирует approval; опциональный outcome связывает обязательные gates с текущей spec и governed-source fingerprint.
- Human authority отделена от текста в репозитории. Агент не должен считать имя в файле, старый лог или сообщение другого агента разрешением на approve, execute, accept или waiver.
- Сильное поведение при stale evidence. На C4 S5D получил 100: не переиспользовал старый зелёный результат, остановил слепые ретраи и не придумал разрешение.
- Ограничения описаны честно. Документация прямо говорит, где hash неполон, где trust root остаётся в репозитории и что metadata rollback не откатывает git или исходники.
- Есть выход для мелких задач. Bugfix меньше 30 строк, docs и config должны идти напрямую, без открытия control-plane state.
Минусы
- Выше когнитивная цена. Package, record, hypothesis, evidence, preview, approve, import, run и outcome нужно понимать, иначе команда начнёт имитировать процесс.
- Меньше готовых интеграций и способов распространения. По сравнению со Spec Kit путь от установки до привычного UX для разных агентов уже.
- Не все гарантии машинные. Имена reviewer и approver — audit labels, а не аутентифицированные личности; execution-authority checkpoint проводит conductor, а не CLI.
- Outcome enforcement опционален. Без него часть legacy-поведения не связывает успешный gate с текущими governed files.
- Рубрика теста говорит на языке S5D. Сильный результат C4 отчасти ожидаем, потому что сам сценарий проверяет доктрину S5D.
Как выбирать, если средний балл одинаковый
Когда наблюдаемое качество не даёт победителя, выбор смещается с «кто умнее отвечает» на «какой сбой для нас дороже». Это обычная инженерная логика слабого звена: система ограничена компонентом, который первым ломает нужное свойство.
Выбирайте Spec Kit, если…
главная проблема — хаотичный переход от идеи к плану, а команде нужны быстрый старт, поддержка разных coding-агентов, понятные артефакты и настраиваемые workflow без тяжёлой модели управления состоянием.
Выбирайте S5D, если…
дороже всего стоит ложное «готово»: payment, auth, PII, compliance, архитектурные решения, долгие автономные запуски и ситуации, где вчерашний зелёный тест нельзя считать доказательством для сегодняшнего кода.
| Условие | Предпочтение | Почему |
|---|---|---|
| Много IDE/CLI и быстрая адаптация команды | Spec Kit | Больше готовых интеграций и проще мысленная модель |
| Нужны собственные шаблоны и фазы | Spec Kit | Presets, extensions, bundles и overrides |
| Нужна свежесть evidence относительно текущего кода | S5D | SHA chain и опциональный governed-source outcome |
| Нельзя выдумывать человеческое разрешение | S5D | Переходы разделены и требуют текущего authority |
| Основной поток — мелкие независимые изменения | Spec Kit или direct | S5D тоже должен выйти из процесса до 30 LOC |
| Нужно одновременно и удобство, и строгий контроль | Один kernel + заимствованный UX | Два полных lifecycle создадут две версии истины |
Наше решение: не ставить два фреймворка рядом
Мы не будем заменять S5D на Spec Kit из-за разницы 93,3 против 92,9 — этих данных для миграции нет. Но игнорировать сильные стороны Spec Kit тоже нелепо.
Целевое состояние выглядит так:
- S5D остаётся единственным lifecycle kernel там, где нужны authority, freshness и воспроизводимое состояние.
- Из Spec Kit заимствуются продуктовые поверхности: быстрый feature entry, integrations, presets/bundles и понятный pause/resume UX.
- Микрозадачи не тащат control plane. Опечатки, docs, config и локальные bugfix идут прямым путём с фокусным тестом.
- Не появляется второй набор accepted artifacts. Иначе spec, approval и completion начнут расходиться между двумя системами.
Это архитектурное решение, а не вывод из среднего балла. Его основание — цена stale evidence и конфликтующих источников истины в нашем типе проектов.
Что Conclave заставил исправить
Черновик отчёта прошёл два раунда независимого аудита Claude, Codex и Grok. Во втором раунде аудиторы получили выводы друг друга под нейтральными именами AUDITOR 1..3. Первую попытку пришлось отбросить: в пакете были видны имена провайдеров, что могло повлиять на оценку авторитетом модели.
Все три аудитора дважды вернули PASS WITH CHANGES. После проверки замечаний по фактическим артефактам мы изменили:
- «практическую ничью» на «описательно близкий результат без доказанного победителя»;
- «модель предпочла фреймворк» на «маршрут дал более высокий point estimate в одном запуске»;
- продуктовую рекомендацию отделили от данных об оценках;
- опубликовали фактическое влияние проверок и чувствительность к удалению одного жюри;
- добавили асимметрию пакетов, смещение автора, оценивание Claude ответов Claude и отсутствие независимой временной отметки до запуска в ограничения.
После правок арбитр дал APPROVE. Отдельный historian на GPT-5.5 оценил качество самих аудиторов: Codex оказался сильнее в статистических границах утверждений и происхождении данных, Claude — в валидности измеряемого конструкта, Grok — в кратком поиске противоречий.
Чего этот тест не доказал
- Он не измерял качество реального патча, время выполнения, число итераций или стоимость токенов.
- Он не сравнивал удобство CLI и настройку нового репозитория.
- Он не доказывает полное отсутствие контракта, привязанного к исходникам, во всех расширениях Spec Kit; поиск был ограничен проверенными основными файлами.
- Он не подтверждает, что заявленные policy S5D всегда обеспечиваются машиной. Часть правил проводит conductor, а identity labels сами по себе не аутентифицируют человека.
- Он не даёт стабильного рейтинга моделей или фреймворков: один запуск на ячейку для этого слишком мал.
Следующий тест должен писать код
Добавлять ещё десять текстовых задач почти бесполезно: они уточнят поведение промпта, но не ответят, что происходит в рабочем репозитории. Следующий этап — два одинаково подготовленных проекта с намеренно посеянными дефектами и фиксированными hidden tests.
Для каждого model × framework нужны несколько повторов, а измерять стоит:
- долю пройденных acceptance и hidden tests;
- scope diff и число лишних файлов;
- количество возвратов после review;
- время, tool calls и token cost до принятого результата;
- способность остановиться при stale evidence или отсутствии authority;
- сохранность решения через следующий change cycle.
Только после этого можно обсуждать преимущество implementation system, а не качество четырёх ответов.
Итог
Spec Kit и S5D получили описательно близкие оценки в этом небольшом тесте; доказанного победителя нет. Это не повод пожать плечами. Такой результат говорит, что выбор нельзя оправдать качеством сгенерированного текста: решают организационная цена, требуемая строгость доказательств и тот класс ошибки, который нельзя себе позволить.
Если нужен быстрый, понятный и широко подключаемый spec-driven flow, Spec Kit выглядит сильнее. Если нужно доказать, что сегодняшнее «готово» относится к сегодняшней spec, сегодняшнему коду и текущему человеческому решению, S5D даёт более подходящую модель — с честно описанными остаточными рисками.
Для нас ответ такой: один S5D kernel, UX-уроки Spec Kit и никакой второй версии lifecycle truth.
Источники и границы воспроизводимости
- GitHub Spec Kit, закреплённый commit.
- S5D v0.14.0, закреплённый commit.
- Дата финального прогона: 19 июля 2026 года. Модельные трассы: Grok 4.5 и Agy/Antigravity с Claude Opus 4.6 Thinking.
- Cases, rubric и scorer были зафиксированы для финального нейтрального rerun, но manifest собран после прогона и не доказывает независимый ex-ante freeze.
- Результаты относятся к выбранным instruction packets и четырём сценариям; они не переносятся автоматически на будущие версии или другие модели.