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, і запропоную архітектуру процесу під ваші цілі, ризики та терміни.