Коли Андрей Карпаті на початку 2025 популяризував термін "vibe coding" - вільне промптування AI без чіткого плану, з прийняттям усього, що "виглядає правильно" - він точно описав, як більшість розробників тоді користувались AI-агентами. Це чудово працює для одноразового прототипу. І доволі жахливо працює для всього, що доведеться підтримувати місяцями чи роками.
Spec-Driven Development (SDD) - дисциплінована відповідь на цю проблему, яка за 2025-2026 рік перетворилась з нішевої ідеї на стандарт де-факто. До неї у своїй версії доклались GitHub (Spec Kit), AWS (Kiro), а також OpenSpec, BMAD, Tessl і Google Antigravity.
Проблема, яку вирішує SDD
Суть проста: AI-агенти вже добре пишуть код, але погано вгадують, що ти насправді мав на увазі. Без явного скоупу агент починає робити припущення - і швидко йде не туди. Без чітких критеріїв прийняття неможливо перевірити, чи результат "правильний". Код-рев'ю перетворюється на нескінченний процес, бо немає єдиного джерела правди, з яким можна звірити результат.
Цифри тут доволі красномовні: дослідження показують, що LLM генерують вразливий код у 9,8-42,1% випадків залежно від бенчмарку, а кількість зафіксованих проблем, спричинених AI-згенерованим кодом у продакшн-репозиторіях, перевищила 110 000 випадків до лютого 2026 року.
Ключова ідея: специфікація - джерело правди, а не код
Формулювання, яке зустрічається чи не в кожній статті про SDD за 2025-2026 рік: "специфікація - це промпт". Це методологія, де детальна, версійована специфікація - а не код - є єдиним джерелом правди. Команда (чи AI-агент) спочатку пише специфікацію того, що система має робити, потім із неї виводить план реалізації, розбиває його на атомарні задачі, і тільки тоді генерує код. Специфікація лишається "живою": коли вимоги змінюються, редагуєш специфікацію і перегенеровуєш відповідний код.
Це не означає, що код перестає бути важливим - радше йдеться про архітектурний зсув: людські зусилля зміщуються з написання рядків коду на точне визначення поведінки системи.
Чотириетапний робочий процес
Практично всі сучасні SDD-інструменти сходяться на одному циклі: Specify → Plan → Tasks → Implement.
На прикладі GitHub Spec Kit це виглядає як послідовність слеш-команд у твоєму AI-агенті (Claude Code, Copilot, Cursor - Spec Kit агностичний до конкретного агента):
/speckit.constitution # принципи й правила проєкту, пишуться один раз
/speckit.specify # що будувати - фокус на "що" і "чому", без технічних деталей
/speckit.plan # технічний план - стек, архітектура, залежності
/speckit.tasks # розбиття плану на конкретні, виконувані задачі
/speckit.implement # власне генерація коду за задачами
Є ще проміжна команда для перевірки узгодженості - вона ловить розбіжності між специфікацією, планом і задачами (наприклад, невідповідність директорій чи пропущені вимоги) ще до того, як агент почне писати код.
EARS-нотація: як писати вимоги, які неможливо неправильно зрозуміти
Найпрактичніша частина всієї методології - те, як саме писати критерії прийняття. EARS (Easy Approach to Requirements Syntax) - формальна нотація для написання однозначних, тестованих вимог. Кожна вимога слідує строгому шаблону з ключовими словами у верхньому регістрі. Слово SHALL - обов'язкове, ніколи не "should", "must" чи "may".
П'ять основних патернів:
Ubiquitous (завжди активна, без тригера):
THE System SHALL encrypt all passwords using bcrypt
Event-driven (тригер-подія):
WHEN a user submits the login form THE System SHALL validate credentials
State-driven (поки триває умова):
WHILE the user is authenticated THE System SHALL display the dashboard
Optional feature (опційна фіча):
WHERE two-factor authentication is enabled THE System SHALL require a verification code
Unwanted behavior (обробка помилок):
IF the password is incorrect THEN THE System SHALL display an error message
Ці патерни можна комбінувати для складніших вимог:
WHILE the cart is not empty
WHEN the user clicks checkout
THE System SHALL navigate to payment
Робочий приклад: скидання пароля з обмеженням частоти запитів
Візьмемо конкретну фічу - скидання пароля з rate limiting, щоб побачити весь цикл на практиці.
Крок 1 - Specify (що і чому, без технічних деталей):
Build a password reset flow. Users who forget their password should be
able to request a reset link via email. To prevent abuse, limit how
often a single account or IP address can request a reset.
Крок 2 - агент ставить уточнюючі питання (це і є головна цінність цього кроку - запобігання недоспецифікованості, головної причини, чому агенти "йдуть не туди"): Скільки максимум запитів дозволено за який період? Що показати користувачу, якщо ліміт вичерпано? Чи термін дії посилання на скидання обмежений у часі?
Крок 3 - критерії прийняття в EARS, після уточнень:
THE System SHALL allow a maximum of 3 password reset requests per email
address within a 15-minute window
WHEN a user requests a password reset THE System SHALL send an email
containing a reset link valid for 30 minutes
IF a user exceeds the reset request limit THEN THE System SHALL display
a message indicating when they can try again
WHILE a reset link has already been used THE System SHALL reject any
further attempts to use that same link
IF the reset link has expired THEN THE System SHALL display an error
and offer to request a new link
Крок 4 - Plan: тут вказуєш технічний контекст - "використовуємо наш існуючий стек і патерни, консультуємось із constitution і специфікацією, тримаємо залежності мінімальними". Агент виводить конкретну архітектуру: яка таблиця в БД, яка черга для email, який механізм rate limiting (Redis-лічильник, database throttle).
Крок 5 - Tasks: план розбивається на виконувані шматки - міграція БД, throttle-мідлвар, email-шаблон, ендпоінт скидання, тести на кожен EARS-критерій.
Крок 6 - Implement: агент виконує задачі одну за одною (або весь набір одразу, якщо довіряєш більше), і кожен написаний тест напряму мапиться на конкретний EARS-рядок вище - тобто в тебе є пряма трасованість від вимоги до коду, який її перевіряє.
Suprepowers: методологія поруч зі специфікаціями
Окрім самого SDD-циклу, варто знати про obra/superpowers - плагін для Claude Code (і кількох інших агентів - Codex, Cursor, Gemini CLI), який описує себе як "агентний фреймворк навичок і методологія розробки, яка реально працює". Це не заміна Spec Kit, а радше сусідній шар: бібліотека з 20+ перевірених навичок, що охоплює мозковий штурм, написання планів, TDD, систематичний дебаг, git-воркфлоу і код-рев'ю.
Робочий цикл тут коротший і менш формальний, ніж повний SDD:
/superpowers:brainstorm # інтерактивне уточнення дизайну
/superpowers:write-plan # створення плану реалізації
/superpowers:execute-plan # виконання плану пакетами
Ключова відмінність від Spec Kit - Superpowers менше про формальну специфікацію-як-контракт і більше про перевірені патерни командної роботи з агентом: коли створювати git worktree, коли ділегувати задачу субагенту, як проводити систематичний дебаг замість навмання. Навички активуються автоматично, коли Claude Code розпізнає відповідний контекст - не потрібно пам'ятати команди напам'ять.
Реальні результати і чому це не завжди виправдано
GitHub повідомляє, що команди, які використовують Spec Kit на внутрішніх проєктах, відправляють фічі приблизно з на порядок меншою кількістю циклів "перегенерувати з нуля" порівняно зі спонтанним промптуванням. AWS Kiro документує реальні кейси клієнтів, де фічі на 40 годин роботи були доставлені менш ніж за 8 годин людського часу, коли їх спочатку оформили як специфікацію.
Але тут варто зберігати тверезість. Thoughtworks у своєму огляді методології прямо застерігають: досвідчені програмісти можуть виявити, що надмірно формалізовані специфікації створюють зайві проблеми і сповільнюють цикли змін і зворотного зв'язку - так само, як це було на ранніх етапах waterfall-розробки. SDD залишається практикою, що активно розвивається, і індустрія ще не до кінця визначилась, чи саме специфікація, чи все ж код є кінцевим артефактом розробки.
Практичне правило, яке зустрічається в кількох джерелах: vibe-код для прототипів, одноразових скриптів і дослідження, де швидкість важливіша за все. Spec-Driven Development - для продакшн-коду, командних проєктів і довгоживучих систем, де "дрейф" від початкового наміру коштує дорого.
Чому я скептично ставлюсь до платних курсів по SDD
Останнім часом мені в стрічці постійно трапляються платні курси й марафони по Spec-Driven Development - і, чесно кажучи, я до них доволі скептично налаштований. Не тому, що тема не варта уваги - варта, я щойно присвятив їй цілу статтю. А тому, що більшість таких курсів по суті переказує те саме, що є у відкритій документації Spec Kit чи Kiro, просто загорнуте в "мій особистий фреймворк" і "ексклюзивний метод, який я відточив за роки роботи".
Сама методологія - це кілька слеш-команд, EARS-нотація на пів сторінки і загальна дисципліна "спочатку опиши, потім плануй, потім виконуй". Це можна прочитати в README репозиторію за 20 хвилин. Платний курс зазвичай додає до цього анекдоти з особистого досвіду автора і трохи мотиваційної риторики про те, як SDD "змінить твою кар'єру" - що само по собі непогано, але коштує це зазвичай непропорційно дорого відносно того, скільки нової інформації там реально є понад офіційні джерела.
Якщо тобі цікаво розібратись у SDD - я б порадив спочатку прочитати документацію Spec Kit і кілька практичних розборів на кшталт цього, спробувати цикл specify → plan → tasks → implement на реальній маленькій фічі, і тільки якщо після цього залишаться конкретні прогалини в розумінні - шукати платний курс під конкретну проблему, а не як загальний вступ у тему.
Як я це використовую
Коли я заходжу в новий, незнайомий код без жодної документації, я фактично будую полегшену версію цього ж підходу, ще до того, як прочитав про SDD як формальну методологію. Замість того, щоб просити агента "розберись у коді" одним широким запитом, я скопую модуль за модулем: спочатку деterministичні shell-інструменти (cloc, git log, find) для фактів без жодного LLM, потім скоуп кожного проходу на один обмежений каталог, і кожен прохід дистилюю у вкладений CLAUDE.md файл - по суті, "жива специфікація" того, що модуль робить і на що не можна наступати.
Це напряму перегукується з філософією Superpowers - субагент-орієнтована розробка, де кожному субагенту дається вузький, чітко обмежений скоуп замість того, щоб один агент тримав у контексті весь проєкт одразу. Я роблю окремих субагентів саме за цим принципом: кожен перевіряє конкретну, вузьку річ і дописує знахідки в постійний файл, а не тримає все в оперативній пам'яті розмови.
Для нових фіч у власних проєктах я тепер свідомо пишу коротку специфікацію в EARS-стилі перед тим, як просити агента щось реалізувати - навіть без повного Spec Kit циклу. Просто три-п'ять рядків "WHEN / THE SYSTEM SHALL" перед тим, як писати промпт, забирають хвилину часу і рятують від того, що агент придумає власну версію того, що я "мав на увазі".