Technical Context
Я смотрю на SpecKit и OpenSpec не как на «ещё две CLI», а как на попытку стандартизировать разговор между человеком, репозиторием и кодовым ассистентом. В обоих подходах ядро одно: фиксируем намерение в spec.md, держим правила игры в constitution.md (или аналогах), а затем заставляем ассистента работать по этим рамкам, а не «в стиле как получится».
Что мне нравится в SpecKit (github/spec-kit) как архитектору: он мыслит фазами и дисциплинирует команду. В типовом сценарии там есть команда уровня /specify, которая генерирует достаточно объёмный пакет артефактов (спецификация, принципы, декомпозиция задач, проверки). Да, это может быть сотни строк, но это как раз тот случай, когда «многословие» снижает стоимость ошибок на ранней архитектуре — особенно в greenfield монорепо.
У OpenSpec акцент другой: я вижу его как удобный механизм итеративных change proposals для уже живого кода. Логика «предложил изменение → применил → заархивировал как единый источник правды» хорошо ложится на brownfield и на команды, которые не готовы каждый раз проходить тяжёлую фазу предварительного проектирования. Технически это обычно выражается в структуре папок изменений и нескольких AI-командах, которые помогают применить спецификацию к коду.
Но я полностью согласен с практическим фидбеком сообщества: оба тулкита пока «не про агентность». В них нет нативного понимания мультирепозитория, нет встроенной модели передачи одной и той же фичи по цепочке субагентов, нет вшитых механизмов вроде plan mode/подагентов. Они агент-агностичны — и в этом их сила для простых потоков, и слабость для сложных.
- SpecKit лучше ощущается в монорепо, где можно автосоздавать ветки, жёстко держать стандарты и проверять зависимости задач.
- OpenSpec выигрывает там, где нужно быстро и аккуратно проводить серию изменений, не превращая каждое в «мини-проект на неделю».
- Для продвинутых AI-агентных систем оба требуют внешней оркестрации: отдельные промпты, роли, команды, правила handoff.
Business & Automation Impact
В моих проектах внедрение SDD почти всегда окупается не «красотой документов», а сокращением пересборок и конфликтов в команде. Если вы делаете ИИ решения для бизнеса, то главная боль — не скорость генерации кода, а управляемость изменений: кто принял решение, где зафиксированы допущения, как проверяем результат.
SpecKit и OpenSpec помогают именно здесь: они создают контракт между продуктом, архитектурой и реализацией. На практике я вижу три быстрых эффекта:
- Стабильнее ревью: спорим не о том, «почему ассистент так написал», а о том, «что мы просили в spec.md».
- Проще онбординг: новый разработчик читает constitution/spec и быстрее попадает в контекст.
- Меньше регрессий: когда проверки и acceptance criteria вытащены в явный текст, ассистенту сложнее «срезать углы».
Кто выигрывает от SpecKit/OpenSpec уже сейчас? Команды, которые строят greenfield продукт в одном репозитории, хотят дисциплины и готовы инвестировать час-два в нормальную спецификацию перед реализацией. Проигрывают те, кто ожидает «автопилот»: поставил CLI — и дальше агентная фабрика сама разнесла фичи по сервисам, репам и окружениям.
Если говорить про автоматизацию с помощью ИИ внутри разработки, то эти инструменты скорее про управляемую полуавтоматизацию. В них человек остаётся диспетчером. И лично я считаю это плюсом для бизнеса: ответственность и контроль остаются у команды, а не у «магии» агента.
В Nahornyi AI Lab я обычно внедряю такие тулкиты не «как есть», а как часть архитектуры процесса: добавляю шаблоны под домен, правила именования, политики тестирования, ограничения на миграции, требования к логированию/наблюдаемости. Без этого SpecKit/OpenSpec становятся просто ещё одним форматом markdown, который через месяц перестают обновлять.
Strategic Vision & Deep Dive
Мой главный вывод на 2026 год: SpecKit и OpenSpec — это хороший фундамент для SDD, но они пока не решают ключевую проблему агентных проектов — управление контекстом и передачей ответственности между частями системы. В «обычной» разработке достаточно спецификации и задач. В агентных системах нужна ещё и операционная модель: роли агентов, протоколы handoff, политика памяти, критерии остановки, контуры безопасности.
Поэтому я всё чаще строю гибрид: беру их артефакты как «скелет» (spec/constitution/tasks), а поверх делаю слой команд и навыков под конкретный проект. По сути, я собираю внутренний «командный набор» для команды и ассистента: как мы планируем, как декомпозируем, как оформляем интерфейсы, как проводим миграции, как валидируем. Это и есть реальная архитектура ИИ-решений на уровне процесса, а не только на уровне микросервисов.
Отдельно отмечу узкое место, которое всплывает почти всегда: мультирепо и интеграции. Бизнес редко живёт в идеальном монорепо. Есть ERP, есть 1–3 сервиса, есть мобильное приложение, есть инфраструктурный репозиторий. Тулкиты SDD, ориентированные на один репозиторий, начинают «терять края»: спецификация есть, а синхронизация изменений по репам остаётся ручной. В этот момент либо вы вводите оркестрацию (скрипты, CI-процессы, правила PR), либо уходите в более агентные фреймворки, где мультирепо — гражданин первого класса.
Мой прогноз простой: победит не «самый умный агент», а самый практичный стек, который можно обновлять каждую неделю без боли. И здесь кастомный набор промптов/команд, о котором говорят практики, часто оказывается зрелее, чем сырой инструмент. Хайп заканчивается быстро; полезность остаётся там, где есть дисциплина спецификаций и чёткие правила исполнения.
Если вы хотите выбрать SDD-подход под ваш продукт и не закопаться в сыром стеке, я приглашаю обсудить контекст вашей команды и репозиториев. Напишите в Nahornyi AI Lab — консультацию проведу лично я, Vadym Nahornyi, и предложу архитектуру процесса под ваши цели, риски и сроки.