Идея «сначала спецификация, потом код» стала мейнстримом работы с AI-агентами: OpenSpec, Spec Kit от GitHub, Kiro от AWS собирают десятки тысяч звёзд. Use Case Pattern тоже строится вокруг спецификации — поэтому вопрос «чем ваша спека отличается» мы слышим часто. Отличие принципиальное: они описывают изменение, мы описываем систему. Разберём, что это значит на практике.
Как устроены spec-driven инструменты
При всех различиях трёх инструментов схема общая. В репозитории появляется папка спецификаций; на каждое изменение создаётся набор артефактов: зачем меняем (proposal), что именно (требования со сценариями «WHEN пользователь делает X THEN система отвечает Y»), как технически (design) и чеклист задач (tasks). Агент реализует по чеклисту; после мержа изменение архивируется. OpenSpec делает это легковесно и работает с любым AI-инструментом; Spec Kit — жёстче по фазам; Kiro встраивает тот же цикл в собственную IDE.
Это честное улучшение по сравнению с «вайб-кодингом»: агент получает согласованные требования, а не устный пересказ, и у изменения появляется след.
В чём разница с Use Case спецификацией
Единица описания. У spec-driven инструментов единица — изменение: спека живёт от предложения до архива. У UCP единица — Bounded Context: спецификация описывает домен целиком — агрегаты, их жизненный цикл, инварианты, команды и события, критерии приёмки — и живёт столько же, сколько сервис.
Язык описания. Сценарии WHEN/THEN фиксируют наблюдаемое поведение, но молчат о модели: из них не видно, что «заказ» — агрегат с инвариантом «сумма позиций равна итогу», что «отменён» — терминальное состояние. UCP-спека описывает именно систему понятий — то, из чего потом механически выводятся и код, и тесты.
Связь с кодом. Spec-driven инструменты заканчиваются на «агент реализовал чеклист» — как именно устроен код, решает агент. В UCP спецификация продолжается в архитектуру (слоистый паттерн, уровни зрелости) и в исполняемые стандарты: ревью-скиллы проверяют каждый PR по правилам с кодами.
| OpenSpec / Spec Kit / Kiro | Use Case Pattern | |
|---|---|---|
| Единица | изменение (change) | Bounded Context |
| Жизнь артефакта | до мержа, затем архив | вместе с системой |
| Содержание | сценарии поведения | домен: агрегаты, инварианты, события |
| Архитектура кода | на усмотрение агента | зафиксирована паттерном |
| Проверка результата | чеклист задач выполнен | rule-coded ревью на каждом PR |
Что стоит позаимствовать у них
Честность требует признать сильное место spec-driven инструментов: дельта изменения как первоклассный артефакт. Долгоживущая спецификация отвечает «как система устроена», но вопрос «что именно мы меняем в этом заходе и почему» они оформляют аккуратнее — предложение, дифф требований, чеклист, архив. Эта механика хорошо ложится поверх UCP-спеки: изменение предлагается как дельта к Bounded Context, реализуется, спецификация обновляется, дельта архивируется. Лёгкий вход для мелких изменений — второй урок: не всякая правка заслуживает полного цикла.
Коротко
- OpenSpec, Spec Kit и Kiro — спецификация изменения: proposal → сценарии → design → tasks → архив; UCP — спецификация системы: Bounded Context с доменной моделью, живущий вместе с сервисом.
- Сценарии WHEN/THEN описывают поведение, но не модель: агрегаты, инварианты и жизненный цикл в них не выразить — а именно из них выводятся код и тесты.
- Spec-driven инструменты заканчиваются на реализации чеклиста; UCP продолжается в архитектуру и rule-coded ревью каждого PR.
- Их сильная сторона — оформление дельты изменения; эта механика совместима с UCP и дополняет долгоживущую спеку.
- Выбор: след изменений для агента — любой из трёх инструментов; источник правды о домене и одинаково правильный код — UCP.
Что почитать дальше
- Use Case спецификация: как устроена — структура спеки Bounded Context.
- UCP и BMAD-METHOD — первая часть сравнения: процессные фреймворки.
- Исполняемый стандарт — что происходит после спеки: правила и скиллы.