Шість тижнів тому я поставив @fission-ai/openspec на brownfield TypeScript-кодову базу, яку троє інженерів правили два роки. Учора відвантажив зміну на чотирнадцять файлів за дев’яносто хвилин зі двохсотрядкової специфікації. Без мерж-конфліктів. Без ескалацій рев’ю. PR-опис складався з proposal і шестидесятирядкової spec-дельти; код-діфф був її наслідком. Сеньйор, який рев’ював, не читав код — він прочитав spec-дельту і апрувнув.
Ця фраза два роки тому звучала б як маркетинг. У травні 2026 це третій тиждень поспіль, коли я відвантажую щось таким способом, і я почав думати, що магія не в OpenSpec. Магія в тому, що у методології нарешті з’явився інструмент, що ставиться до її власних заяв всерйоз.
Це четвертий пост у дузі, яку я веду. Контекст-інжиніринг був рантайм-дисципліною. Spec-driven development був design-time-філософією. Evals був шаром верифікації. Кожен із цих постів вказував уперед на питання, на яке я не відповідав: але як ти насправді ганяєш це у реальній кодовій базі, з реальними людьми, у вівторок? OpenSpec — перший інструмент, який відповідає на це питання чесно.
Теза жорсткіша, ніж людям зручно. OpenSpec — перший spec-driven фреймворк, що ставиться до специфікацій так, як Git ставиться до коду: filesystem-state-machine з гілками, ізоляцією й атомарними мержами. Це не фіча. Це вся причина, з якої він працює.
Що таке OpenSpec, якщо по суті
OpenSpec — це open-source CLI від Fission-AI, заснований Tabish Bidiwale, запущений через Y Combinator на початку цього року, що сидить на п’ятдесяти тисячах GitHub-зірок приблизно за шість місяців після релізу. NPM-пакет — @fission-ai/openspec. TypeScript, потребує Node 20.19+, остання стабільна — v1.3.1 (21 квітня 2026 — близько місяця тому на момент написання).
Фреймінг засновника варто цитувати, бо він проривається крізь три роки LLM-хайпу одним реченням:
Генерація коду тепер дешева. Коректність — все ще дорога.
Це весь діагноз. Пляшкове горло відвантаження AI-фіч у 2026 — не можливості моделі. Opus 4.7 і Codex 5.5 можуть виробити робочу реалізацію майже з будь-якої добре сформованої специфікації. Пляшкове горло — дістатися до добре сформованої специфікації, тримати її стабільною між сесіями, ізолювати паралельні зміни і мержити їх назад у джерело істини без забруднення. Це системна задача, не задача про промптинг.
OpenSpec вирішує її так, як вирішував би backend-інженер — файловою системою, без БД, markdown’ом скрізь, і воркфлоу, що мапиться майже один-в-один на Git Flow. Канонічний layout:
project_root/
└── openspec/
├── AGENTS.md # поведінкові правила для будь-якого AI-інструменту
├── project.md # глобальний контекст — стек, конвенції, обмеження
├── specs/ # Джерело істини — поточна поведінка системи
│ ├── auth-login/spec.md
│ ├── payment-checkout/spec.md
│ └── ...
└── changes/ # ізольована робоча зона для in-flight пропозицій
├── add-oauth-login/
│ ├── proposal.md # "чому" і "що"
│ ├── design.md # технічний підхід
│ ├── tasks.md # чек-лист реалізації
│ └── specs/ # spec-дельти: ADDED / MODIFIED / REMOVED
└── archive/
└── 2026-04-12-add-rate-limiting/
└── ...Дві директорії несуть усю модель. specs/ — поточний стан світу, джерело істини системи, організоване за capability. changes/ — in-flight робоча зона; кожна пропозиція — своя папка, повністю ізольована, зі своєю дельтою проти поточних специфікацій. Коли зміна схвалена і застосована, її дельти мержаться назад у specs/, а папка proposal переїжджає у changes/archive/[date]-[name]/. Архів незмінний. Все. Це весь контракт файлової системи.
Усе решта — CLI, slash-команди, інтеграції з AI-інструментами — це інтерфейс над цим контрактом. Можна видалити кожен JavaScript-файл у node_modules і в тебе все одно буде когерентна SDD-кодова база, бо методологія живе у структурі директорій, не в інструменті.
Машина станів із чотирьох фаз
CLI експонує невеликий набір slash-команд, що переміщують зміну через чотири фази. Усередині AI-інструменту на кшталт Claude Code чи Cursor ти набираєш команду, AI робить роботу; ти рев’юєш.
| Фаза | Команда | Файли створені / змінені | Що відбувається downstream |
|---|---|---|---|
| 1. Propose | /opsx:propose <feature> | openspec/changes/<feature>/ з proposal.md, design.md, tasks.md, дельтами specs/ | Існує нова ізольована робоча зона; у джерелі істини нічого не змінилося |
| 2. Define | openspec validate | Нових файлів немає; репортить помилки синтаксису специфікацій / сценаріїв | Статичний аналіз spec-дельти до того, як написаний хоч якийсь код |
| 3. Implement | /opsx:apply | Зміни вихідного коду, чекбокси задач відщовкнуті | AI виконує tasks.md строго проти узгодженої специфікації; ти рев’юєш код-діфи і spec-дельти разом |
| 4. Archive | /opsx:archive | specs/ оновлено мержем дельт; proposal переїхав у changes/archive/[date]-<feature>/ | Джерело істини відображає новий стан системи; архівований proposal — постійна історія |
Конкретний end-to-end:
Ти: /opsx:propose add-dark-mode
AI: Створено openspec/changes/add-dark-mode/
✓ proposal.md (обґрунтування, критерії успіху)
✓ design.md (theme-контекст, CSS-змінні, персистенс)
✓ tasks.md (8 задач на 3 компоненти)
✓ specs/theme/spec.md (ADDED: 4 сценарії)
Ти: openspec validate
✓ Усі сценарії коректно сформовані
✓ Конфліктів з існуючими специфікаціями немає
Ти: /opsx:apply
AI: ✓ 1.1 Додати theme context provider
✓ 1.2 Створити toggle-компонент
✓ 2.1 Додати CSS-змінні для темної палітри
...
Ти: /opsx:archive add-dark-mode
✓ Специфікації змержені в openspec/specs/theme/
✓ Proposal заархівований у openspec/changes/archive/2026-05-21-add-dark-mode/Увесь цикл, від «я хочу темну тему» до «темна тема в main зі специфікацією» — одна термінальна сесія. Специфікація — довговічний артефакт; код — її наслідок. Архів — історія.
Чому filesystem-as-state-machine — правильний вибір
Хитрість тут не в CLI. Хитрість у тому, що хтось нарешті сів і запитав: як виглядав би Git, якби Git версіонував поведінку, а не код? І потім реалізував це без БД, без сервісу, без централізованого сервера — просто файлами в директорії і машиною станів із чотирьох команд.
Маппінг один-в-один з інтуїціями, які в кожного backend-інженера вже є.
| Поняття Git | Еквівалент OpenSpec | Нотатки |
|---|---|---|
Гілка main | openspec/specs/ | Джерело істини; поточний стан світу |
| Feature-гілка | openspec/changes/<feature>/ | Ізольована робоча зона; не забруднює main, поки не змержена |
| Дифф | Spec-дельта (ADDED / MODIFIED / REMOVED сценарії) | Рев’юється як текст, історія за рядками |
| Мерж | /opsx:archive | Атомарний; дельти застосовані, proposal переїхав у історію |
git log | openspec/changes/archive/ | Append-only історія кожної зміни зі збереженим обґрунтуванням |
| Pre-commit hook | openspec validate у CI | Ловить криво сформовані специфікації до того, як вони потраплять у рев’ю |
Щойно бачиш маппінг, будь-який інший SDD-інструмент виглядає недо-спроектованим. GitHub Spec Kit важкий і жорсткий; він нав’язує фазові гейти й інлайн-править source-of-truth специфікації по ходу, що означає: конкурентні пропозиції від двох інженерів зіткнуться на одному файлі. AWS Kiro прив’язує до Kiro IDE та зокрема до моделей Claude — норм, якщо ти вже AWS-shop, фатально інакше. Tessl — пуристська позиція («код реконструюється зі специфікації»), філософськи чиста й операційно болісна — у більшості реальних кодових баз є код, написаний руками, який має співіснувати з генерованим. BMAD, Antigravity від Google, та жменя інших SDD-фреймворків, що відвантажуються у 2026, роблять різні ставки, але майже всі припускають greenfield — новий проєкт, порожнє репо, чистий аркуш.
Brownfield — це де робота насправді. Кожна команда, яку я поважаю, відвантажує в кодову базу, яку правили роками, люди, що пішли з компанії, з конвенціями, які не збігаються з README, у директоріях, названих за продуктами, що перейменовували двічі. Уся архітектура OpenSpec побудована під цю реальність. Директорію specs/ можна ретрофітнути на існуючий проєкт — є навіть документований режим retrofitting, де ти просиш AI зворотно-інженерити специфікації з існуючого коду, виробляючи базову документацію для систем, що її ніколи не мали. Це справжнє розкриття. Не «spec-driven з першого дня» — spec-driven з третього року.
Backend-архітектор, який це читає, має помітити, що OpenSpec насправді відвантажує workflow-engine поверх content-addressed store, і адресує файлова система. Усе це вміщується на USB-флешці. Немає сервісу, який треба експлуатувати, немає consensus-протоколу для дебагу, немає API для версіонування. Це найлегша можлива реалізація справжньої ідеї, і тому він уже виграє SDD-екосистему.
Форма PR змінюється downstream від цього. У старому світі рев’юер відкриває PR, бачить 600-рядковий діфф, скролить, сподівається, що в середині нічого важливого не ховається, і апрувить. У OpenSpec-формі PR тіло складається з proposal.md + design.md + spec-дельта. Рев’юер читає шістдесят рядків специфікації, ставить одне питання за неоднозначним сценарієм і апрувить. 600-рядковий код-діфф проглядається як sanity-check — це наслідок узгодженої зміни, не сама зміна. Це і є зміна воркфлоу, на яку Spec-Driven Development вказував; OpenSpec — перший інструмент, який реально доставляє це на brownfield-команді.
Як це б’є по дизайну компонентів
OpenSpec описують і демонструють переважно backend-leaning інженери, що заслонило дещо, варте сказати: це негучно-чудовий frontend-інструмент.
Причина в layout’і файлів. Кожна поведінкова capability отримує свою папку під openspec/specs/. Для component-heavy frontend це мапиться в:
openspec/specs/
├── ui-button/spec.md
├── ui-form-field/spec.md
├── auth-login-form/spec.md
├── checkout-cart/spec.md
├── nav-language-switcher/spec.md
└── ...Кожен spec.md містить сценарії у форматі GIVEN / WHEN / THEN — наприклад, для форми логіну:
СЦЕНАРІЙ: Користувач із увімкненим 2FA надсилає валідні дані
GIVEN у користувача увімкнено 2FA
AND користувач надіслав валідний email і пароль
WHEN форму надіслано
THEN сервер повертає OTP-виклик
AND форма переходить у стан вводу OTP
AND поля email/пароль задизейблені
СЦЕНАРІЙ: Надсилання форми з невалідним форматом email
GIVEN поле email містить "not-an-email"
WHEN користувач блюрить поле
THEN поле показує inline-валідаційну помилку
AND кнопка submit залишається задизейбленоюЦе не новий формат. Це та сама форма даних, яку твої Playwright-тести вже використовують. Та сама форма даних, яку play-функції Storybook вже використовують. Та сама форма даних, у якій твоя QA-команда вже пише user stories. Причина, з якої більшість frontend-команд не пишуть специфікацій, — не в тому, що формат незнайомий — у тому, що у формату не було канонічного дому. OpenSpec дає йому дім.
Що це розкриває для frontend:
- A11y, i18n, design tokens і responsive-обмеження стають first-class spec-контентом замість розкиданих коментарів. «Кнопка має досягати мінімум touch-target 44×44 на мобілі» перестає бути повідомленням у Slack і стає сценарієм, рев’юваним, коли рев’юється специфікація.
- Дизайнер може відвантажити UX-пропозицію як spec-дельту, поки інженер відвантажує data-layer-пропозицію як окрему spec-дельту. Ці дві ніколи не торкаються одного файлу. Вони мержаться незалежно у
specs/. Мерж-конфлікту немає, бо немає shared mutable state — кожна пропозиція ізольована by design. - Рефактори компонентів перестають бути «я переписав форму» і стають «я MODIFIED два сценарії й ADDED один». Рев’юери бачать, яка поведінка змінилася. Якщо сценарій не змінився — поведінка не змінилася, і рев’юер може довіряти реалізації.
Де це напружується — і я продавав би тобі щось, якби не сказав — це на сильно візуальній роботі. Тайминг анімації, layout-as-art, мікро-інтеракції, що залежать від руху і кольорових рішень: ці не вписуються чисто в GIVEN / WHEN / THEN. Як і раніше потрібні visual-regression evals, screenshot-діфи, design-system stories. OpenSpec не замінює це. Але він означає, що поведінковий шар — що цей компонент робить, коли, кому, з яким наслідком — має канонічний дім, і отже, перестає битися за простір з візуальним шаром.
Tell frontend-архітектора тут — що
GIVEN / WHEN / THENбайт-у-байт та сама форма даних, яку твій Playwright-спек уже використовує. Ти не вчиш новий формат. Ти вчиш куди покласти той, що в тебе є, щоб він перестав бути осиротілим у папці, яку ніхто не читає.
Це також те місце, де дисципліна evals зустрічається з OpenSpec природно. Кожен сценарій у специфікації — механічно — це eval-вхід. Пайплайн, що читає openspec/specs/**/spec.md, видобуває сценарії і ганяє їх як Playwright-тести проти розгорнутого превью — проєкт на вихідні. Щойно він існує, специфікація перестає бути aspirational — вона верифікується на кожному PR, і будь-яке розходження між специфікацією і реалізацією — це CI-падіння, не ескалація рев’ю.
Контекст-інжиніринг під іншим іменем
Першого разу, коли я читав доки OpenSpec, у мене було конкретне відчуття впізнавання старої ідеї у нових одежах.
Доки прямо кажуть: «Коли використання контексту перевищує 40%, перформанс AI значно деградує, і минулі вимоги забуваються». Це не відкриття OpenSpec; це відома властивість long-context LLM у 2026, і це вся причина, чому контекст-інжиніринг — дисципліна, що важлива. Цікаво, що OpenSpec з цим робить.
Воркфлоу OpenSpec, у рантаймі, — це load-on-demand стратегія контексту. Коли AI починає сесію, він читає три файли: openspec/project.md (глобальний стек, конвенції, ~200 рядків), openspec/changes/<active>/tasks.md (поточний фокус, ~50 рядків) і конкретні openspec/specs/<capability>/spec.md файли, на які посилається задача (~100 рядків кожен). Це приблизно 500–1,000 токенів курованого, щільного контексту — не 50,000 токенів «ось усе репо, розбирайся».
Кожна проблема, яку ідентифікує контекст-інжиніринг — розрідження контекстного вікна, hot/warm/cold тіринг, економіка токенів, стратегія евікції, planning context vs execution context — тут вирішується layout’ом директорій. Hot-тір — це tasks.md. Warm-тір — це згадані spec.md-файли. Cold-тір — це решта specs/ і весь archive/, доступний для завантаження на вимогу, але не оплачуваний за дефолтом. Ти не конфігуруєш контекстний пайплайн. Ти використовуєш інструмент, у якого правильний пайплайн вбудований у його файлову структуру.
Є також історія про пам’ять. Plan mode зникає, коли модель перезапущена; історія розмови випаровується між сесіями; навіть найкраща long-context модель не пам’ятає, що ти вирішив у вівторок минулого тижня. Специфікації вирішують це без церемоній: це файли, версіоновані, довговічні, тривіально завантажувані. «Пам’ять» OpenSpec-проєкту — це директорія specs/. «Мислення» OpenSpec-проєкту — це директорія changes/. Кожна обмежена, інспектована, переживає рестарти. Це те, що будь-який agent-фреймворк, який я використовував, намагався побудувати з векторних сховищ і KV-кешів, а OpenSpec відвантажує це як .md-файли у папці.
Тут є більш тонка властивість, яку я кілька тижнів учився цінувати. Оскільки OpenSpec-специфікації написані в GIVEN / WHEN / THEN, кожен сценарій природно eval-shaped. Можна зробити scrape усього дерева specs/, вважати кожен сценарій тест-кейсом і годувати їх eval-харнес як канонічні критерії коректності. Ти не пишеш evals окремо — вони і є специфікація, у достатньо структурованій формі, щоб бути машинно видобуваними. Це уніфікація, за яку я виступав у кінці eval-посту, і OpenSpec — перший інструмент, який добирається туди побічно, а не через церемонію.
AI-архітектор уже знає, що тут відбувається: це load-on-demand context engineering, що надів CLI-шапку. Цікава річ у тому, що це навчає дисципліні інженерів, які не знають, що вона їм потрібна. Через пів року інженер, що щодня використовує OpenSpec і ніколи не читав статті про контекст-інжиніринг, буде контекст-інженером, за звичкою, ніколи не почувши терміна.
Практична нотатка про моделі. OpenSpec працює з двадцятьма п’ятьма+ AI-інструментами, але не працює однаково добре з усіма. Специфікації — це markdown, що потребує міркування для якісного виробництва — назва capability, декомпозиція задач, написання сценаріїв, що покривають крайові випадки — і дешеві моделі виробляють поверхневі специфікації. Консенсус спільноти, що збігається з тим, що я бачив у двох продакшен-кодових базах: Opus 4.7 або Codex 5.5 для propose і apply. Менші моделі справляються з archive і validate. Якщо підключиш Haiku-tier модель до /opsx:propose, отримаєш специфікації, які виглядають правдоподібно й пропускають третій крайовий випадок, щоразу. Плати за міркування там, де міркування важливе.
П’ять правил, які я заробив, відвантажуючи з OpenSpec
Пронумеровані, бо зароблені в двох продакшен-кодових базах за шість тижнів, не виведені зі сторінки доків.
1. openspec validate блокує CI з першого дня, не «потім». Валідація — це spec-еквівалент type-check. Без неї криво сформовані сценарії прослизають у specs/, і через тиждень у тебе «специфікація», що насправді не парситься, а твій spec-to-eval пайплайн мовчки пропускає половину. Додай openspec validate як обов’язковий крок у pre-commit hook і як блокуючу CI-перевірку у перший день, коли впроваджуєш інструмент. Не у другий. У перший.
2. project.md короткий і конкретний, не довгий і aspirational. Це глобальний контекст, який кожен агент читає першим, на кожній сесії. Кеп — 200 рядків. Назви стек («Next.js 16, Tailwind 5, Postgres, Drizzle ORM»). Назви конвенції («ми використовуємо Result-типи, не throw»). Назви заперечення («не використовувати any у TypeScript; не eval; не прямий DB-доступ із хендлерів»). Пропусти маркетинг. Пропусти team mission statement. Агент — не твій інвестор.
3. Архів незмінний. Ніколи не редагуй openspec/changes/archive/*. Стався до нього як до Git-історії. Якщо минуле рішення треба переглянути — пишеш новий proposal, що його перекриває; новий proposal посилається на старий, і архів росте. День, коли хтось відредагує архівований proposal «просто помилку поправити», — це день, коли історія стає ненадійною, а через кілька місяців ти дебажиш регресію і архів тобі бреше. Не треба.
4. Рев’ю spec-дельту, не код-діфф. Це зміна воркфлоу з найвищим важелем, яку я зробив у 2026, і мені знадобилося три тижні її інтерналізувати. Тіло PR має бути proposal’ом, design-summary і spec-дельтою — це те, що читають люди. Код-діфф — це у кращому разі sanity-check. Якщо spec-дельта правильна і код проходить validator і evals, код правильний; якщо spec-дельта неправильна, код теж неправильний, але код був неправильним, бо специфікація була неправильною, і виправлення коду без виправлення специфікації лише відкладає баг. Рев’юери, які читають spec-дельту першою, відвантажують код краще, ніж рев’юери, що читають код першим.
5. Не використовуй OpenSpec для дослідницької роботи. Це та сама обмовка, що в Spec-Driven Development, з подвійною силою. Не можна заспецифікувати те, чого ще не розумієш. Якщо ти в research-фазі — з’ясовуєш, чи спрацює підхід, накидаєш форми API, вчишся модам відмови — пиши код руками, читай вивід, потім видобувай специфікацію з того, що спрацювало. Spec-after, не spec-first. Помилка, яку роблять нові adopter’и, — хапатися за OpenSpec на першому дні research-spike. Так і виходять п’ятдесятирядкові специфікації на штуку, що через два дні виявиться трьома різними штуками. Використовуй його для відомої роботи, не для невідомої.
Де це все-таки ламається
Чесний облік. Я продавав би тобі інструмент, не методологію, якби зупинився на правилах.
- Сильно візуальна / animation-heavy робота не вписується в
GIVEN / WHEN / THENчисто. Зберігай visual-regression-сьют. OpenSpec — для поведінкового шару, не естетичного. - Research-фаза коду як і раніше краще пишеться руками зі spec-after-extraction. Не борися з цим.
- Дешеві setup’и моделей дають поверхневі специфікації. Якщо твій AI-бюджет — haiku-tier по всьому фронту, тобі самому доведеться писати сценарії, що ловлять крайові випадки, і інструмент перетворюється на гальмо замість мультиплікатора. Плати за high-reasoning модель там, де це важливо — propose, apply, validate. Економ на archive, якщо треба.
- Фрагментація екосистеми реальна. SpecKit, Kiro, BMAD, Antigravity, Tessl і OpenSpec усі хочуть бути SDD-фреймворком, який ти впровадиш, і вони не інтероперують чисто. Обери один. Закомить команду на нього. Switching costs вищі, ніж доки визнають; ти не просто вчиш CLI, ти кодуєш усю change-дисципліну команди у форму інструмента.
- Телеметрія — opt-out, не off-by-default. OpenSpec збирає анонімізовані імена команд і версії, якщо не виставити
OPENSPEC_TELEMETRY=0абоDO_NOT_TRACK=1. Більшості команд це норм. Командам у регульованих середовищах або з жорсткими data-handling політиками — це однорядковий конфіг у shell-профіль і CI, але про це треба знати. - Brownfield retrofitting працює, але не безкоштовно. Рекламований воркфлоу «попроси AI зворотно-інженерити специфікації з твого коду» працює — я використовував його на кодовій базі у шість тисяч файлів — але перший прохід дає descriptive-специфікації, не prescriptive. Вони кажуть, що код робить, не що має робити. Потім потрібен другий прохід із людиною в петлі, щоб конвертувати descriptive-специфікації в кодуючі реальний намір. Плануй це. Не відвантажуй специфікації першого проходу як джерело істини.
Чесна рамка: OpenSpec — правильний інструмент для дев’яноста відсотків роботи у зрілій 2026-кодовій базі, і ті десять відсотків, що лишаються, важать. Сеньйорний інженер — той, хто вміє розрізняти.
Кар’єрний кут
«Покажи свій eval-сьют» — це питання, яке я почав ставити на AI-інженерних співбесідах цього року. «Покажи свій OpenSpec-воркфлоу» — або SpecKit, або Kiro, але якусь SDD-операційну модель з реальною формою — це питання, що до нього приєдналося в останні два місяці. Якість відповіді каже про кандидата більше, ніж будь-який інший одиничний сигнал.
Ринок ще не запрайсив це. Інженери, здатні артикулювати когерентну spec-driven операційну модель — що живе у project.md, а що ні, де межі змін, як зсувається PR-рев’ю, як інтегруються evals — все ще single-digit відсоток кандидатського пулу, який я бачу. Премія компресуватиметься в міру становлення дисципліни стандартною практикою, тим самим шляхом, що юніт-тестування стандартизувалося між 2005 і 2015. Моя оцінка — вісімнадцять місяців до того, як fluency у якомусь flavor SDD стане table stakes для сеньйорних AI-інженерних ролей.
80/20, якщо не читати більше нічого: візьми продакшен AI-фічу, якою володієш. Впровади OpenSpec на ній цього тижня. Ретрофітни специфікації для існуючої поведінки в два проходи — спочатку descriptive, потім human-edited prescriptive. Прожени один повний proposal-to-archive цикл на реальній зміні. За тиждень виявиш, що у твоєму старому воркфлоу було три місця, де ти гадав — про намір, про скоуп, про те, хто має що верифікувати — і OpenSpec перетворив усі три на файли, на які можна тицьнути пальцем. Це відкриття — увесь навик.
Глибша думка
Урок не в тому, щоб «використовувати OpenSpec». Урок у тому, що коли в методології з’являється такий хороший інструмент, люди, які вже розуміли методологію, компаундять свій важіль удесятеро, а ті, хто не розумів, отримують можливість вивчити методологію, використовуючи інструмент. Ця асиметрія — кар’єрна історія інженерії 2026.
Spec-driven development був філософією три роки тому. Став практикою у 2025. У 2026 стає операційною системою, і OpenSpec — найлегша відвантажена на сьогодні реалізація цієї системи. Цікаве питання більше не «чи варто займатися spec-driven development?». Це «яку SDD-операційну модель я комічу своїй команді, і наскільки швидко можу ретрофітнути кодову базу, яку вже маю?»
Якщо хочеш глибше, курси нижче покривають частини дисципліни, які я викладаю найчастіше: Claude Code Mastery: Agentic Coding for Engineers — щоденний slash-command воркфлоу всередині інструмента, що найкраще париться з OpenSpec, Building Agents with the Claude Agent SDK — побудова агентів, що споживають специфікації як first-class входи й виробляють як виходи, Building MCP Servers & AI Tool Integrations — розширення OpenSpec-воркфлоу через MCP-обслуговувані capability, і Building LLM-Powered Apps: RAG & Agents — проводка GIVEN / WHEN / THEN сценаріїв з твоїх специфікацій у робочий evals-харнес на продакшен-трафіку.
