Spec-Driven Development with AI — Як AI-конституція перетворює хаос розробки на керований процес

Юрій Козуб, який консультує компанію ASK24, представив практичний підхід до AI-driven development і пояснив, як штучний інтелект уже сьогодні використовується в реальній розробці продуктів на enterprise-рівні. Йшлося не просто про генерацію коду, а про повноцінний процес, у якому AI працює в чітких межах, за правилами, з контрольними точками, артефактами, перевірками та обов’язковою участю людини як арбітра.

Ключова думка виступу проста: AI дійсно може писати код, але без рамок і правил цей код дуже швидко перетворюється на хаос. Саме тому основне завдання не в тому, щоб “дати AI задачу”, а в тому, щоб поставити його в межі, дати governance і налаштувати механізми контролю якості.

AI-програмування вже стало бізнес-реальністю

Сьогодні AI-програмування — це вже не експеримент і не футуристична концепція. Воно реально використовується великими компаніями. Питання вже не в тому, чи здатен AI генерувати код, а в тому, як поставити цей процес під контроль і як забезпечити якість на рівні великих систем.

Багато хто вже пробував генерувати невеликі програми або окремі шматки коду. Але зовсім інше питання — як це працює на enterprise-рівні, коли йдеться про:

великі проєкти;
вимоги до консистентності;
довготривале функціонування систем;
масштабування;
доєднання нових розробників;
збереження архітектури й передбачуваності розвитку продукту.

Саме тут і з’являється потреба в зрілому AI governance.

Що таке AI-SDLC

Юрій порівнює класичний SDLC і AI-SDLC. У класичній моделі бізнес-аналітик і PM формують вимоги, розробники проєктують і пишуть код, тестувальники перевіряють результат, DevOps супроводжує деплой і CI/CD.

У моделі AI-SDLC структура залишається схожою, але основну операційну роботу виконує AI. Водночас кожен крок після AI перевіряє людина.

AI:

генерує вимоги;
ставить уточнювальні запитання;
формує специфікації;
допомагає в проєктуванні;
пише код;
створює тести;
бере участь у CI/CD;
виконує перевірки;
може навіть самостійно виправляти частину збоїв.

Людина при цьому не зникає з процесу. Навпаки, її роль стає ще важливішою: вона виступає арбітром рішень AI, переглядає результати, затверджує етапи й не дає системі піти в хаос.

Чому все починається з AI-конституції

На думку Юрія, процес AI-SDLC починається не з коду, а з AI Constitution — набору правил, які не обговорюються.

AI-конституція — це рамка, в якій AI працює. У ній визначено:

що дозволено;
що заборонено;
які є нефункціональні вимоги;
які архітектурні правила є обов’язковими;
які документи AI не має права змінювати;
у яких межах він може приймати рішення;
коли повинен зупинитися й передати роботу людині.

Конституція може змінюватися, але на практиці це відбувається рідко. Її мета — створити стабільне середовище, в якому AI працює не хаотично, а в межах чітко визначеного engineering-процесу.

Юрій окремо підкреслює, що нефункціональна частина такої конституції в його підході вже втілена у вигляді готового SaaS Template. Це означає, що є наперед зібраний шаблон із закладеними best practices, на основі якого можна:

будувати продукт із нуля;
покращувати існуючий продукт;
порівнювати legacy-рішення з еталонною архітектурою;
переносити найкращі практики з темплейта в інші проєкти.

Як працюють AI-агенти в цьому процесі

Наступний рівень після конституції — це агенти.

Кожен агент має:

свою роль;
свою відповідальність;
свої правила;
набір дозволених і заборонених дій;
контрольні межі.

Фактично агенти роблять те саме, що раніше робили люди в різних ролях у процесі розробки.

Наприклад:

агент Specify створює специфікації на основі requirements;
далі формується план;
план розбивається на задачі;
імплементер виконує ці задачі;
окремий агент перевіряє відповідність результату вимогам;
тестовий агент створює й запускає тести;
додаткові агенти перевіряють, наскільки план відповідає специфікації, а специфікація — requirements.

Тобто йдеться не про одного “універсального AI”, а про набір ролей, які працюють у керованому процесі.

Чому в якості основного інструмента обрано Cursor

Юрій зазначає, що досліджував різні інструменти для AI-assisted development — Cursor, Claude Code та інші. Після ресерчу стало зрозуміло, що на даному етапі саме Cursor виявився найрозвинутішим середовищем, тому в практичному застосуванні використовується саме він.

Відповідно, частина правил і підходів у системі підлаштована саме під Cursor, хоча сам framework не обмежується лише цим інструментом.

Як виглядає 7-фазний AI-SDLC Pipeline

У підході, який демонструє Юрій, використовується 7-фазний pipeline, зібраний на основі поточних best practices і реального досвіду компаній, які вже застосовують AI-SDLC.

Цей pipeline включає:

Specify
Clarify
Plan
Tasks
Analyze
Implement
Verify

На кожному етапі людина перевіряє результат, який створив AI.

Specify

На цьому етапі AI формує специфікацію на основі requirements, які задає бізнес-аналітик. Усе зберігається в Markdown-файлах прямо в проєкті.

Кожен requirement має свій номер, і специфікація також зберігає зв’язок із цими номерами. Завдяки цьому AI потім може посилатися у звітах на конкретні requirement’и та конкретні пункти специфікації.

Також на цьому етапі можуть використовуватися Mermaid-діаграми, щоб прямо в Markdown-файлах бачити схеми й структуру майбутнього рішення.

Clarify

Clarify перевіряє, наскільки специфікація відповідає вимогам. Це критично важливий етап, тому що вся якість наступних фаз залежить від того, наскільки добре сформульовані requirements і наскільки якісно AI зрозумів задачу.

Якщо в requirements є нечіткість, вона майже гарантовано виллється в проблеми на етапі специфікації, потім у плані, потім у задачах, а далі — вже в коді.

Саме тому Clarify “вичищає” все неконсистентне ще до того, як процес піде далі.

Plan і Tasks

Після якісної специфікації AI формує план дій. Потім цей план розбивається на маленькі задачі. Це важливо: задачі мають бути достатньо дрібними, щоб їх можна було контрольовано імплементувати.

Analyze і Implement

Далі AI імплементує задачі: пише код, тести, конфігурації, супровідні зміни. Але перед цим і після цього відбувається аналіз відповідності: чи все сходиться, чи не втрачено суть вимог, чи не зруйновано логіку процесу.

Verify

На фінальному етапі AI і система перевірок верифікують результат. Але навіть тут людина залишається фінальним арбітром.

Юрій підкреслює, що бувають випадки, коли з першого проходу pipeline функціонал виходить уже достатньо якісним, щоб ним користуватися. Але в більшості випадків усе одно з’являються баги, які потім ще треба фіксити, повторно проходячи частину процесу.

Артефакти як основа traceability

Кожна фаза AI-SDLC залишає після себе артефакт у Git:

специфікацію;
план;
задачі;
код;
тести;
handoff-файли;
memory-файли;
progress logs.

Саме завдяки цим артефактам зберігається повна traceability. Через пів року можна подивитися:

які були requirements;
як формувалася специфікація;
які Architectural Decision Records приймалися;
які задачі створювались;
як рухався продукт;
які правила діяли в той момент.

Це критично важливо для enterprise-середовища, тому що знання не залишаються “в голові одного девелопера” чи “десь у старому чаті”, а лежать прямо в продукті.

SaaS-конституція як нефункціональна база

Юрій окремо зупиняється на тому, що називає SaaS Constitution — нефункціональній частині конституції.

Це вже готовий SaaS-шаблон, створений із використанням best practices. У ньому закладено:

базову архітектуру;
безпеку;
типізацію;
CI/CD;
патерни модульності;
багатокористувацьку ізоляцію;
eventing;
тестову інфраструктуру;
демо-модулі;
telemetry;
правила для Cursor;
automation rules.

Цей template можна:

відкрити в Cursor;
дати команду на деплой;
відповісти на кілька уточнювальних запитань;
автоматично задеплоїти готовий SaaS-soluton із демо-сторінками;
потім видалити демо-модулі;
і далі вже запускати AI-SDLC поверх цього шаблону для створення реального функціоналу.

Архітектура: modular monolith, row-level security та eventing

Один із важливих блоків виступу — архітектурний.

Modular Monolith

Замість класичного моноліту або мікросервісної архітектури тут використовується modular monolith.

Логіка така:

код існує в єдиному back-end/front-end просторі;
але всередині логічно розбитий на модулі;
база даних одна, але розділена схемами на модулі;
модулі між собою спілкуються лише через чітко визначені механізми.

Таким чином вдається взяти сильні сторони моноліту та мікросервісів і обійти частину їхніх типових недоліків.

Outbox Pattern

Для комунікації між модулями використовується outbox-підхід: події зберігаються в тій самій транзакції, що й основні дані. Якщо запис у базі пройшов — подія теж пройшла. Якщо подія не записалась — дані теж не проходять.

Це прибирає класичну проблему, коли дані в базі збереглися, а подія в чергу не потрапила.

Row-Level Security

Для multi-tenancy використовується row-level security. Це означає, що навіть на рівні запису в таблиці стоїть захист від витоку даних одного юзера або workspace в інший.

Навіть якщо AI випадково забуде додати workspace ID або десь помилиться, дані одного користувача не потраплять іншому, тому що це закладено на рівні інфраструктури.

Чому саме TypeScript

Окремий великий блок стосувався стеку технологій.

Після додаткового ресерчу й аналізу того, як працюють компанії у США, Юрій дійшов висновку, що для AI-розробки найбільш логічним стеком на найближчі 3–6 місяців стає TypeScript і для back-end, і для front-end.

Причина в тому, що AI значно простіше працювати, коли:

і фронтенд, і бекенд використовують одну мову;
є типи;
менше розривів між шарами;
менше різних файлів для синхронізації;
менше місць для помилок і “галюцинацій”;
один runtime і один контекст.

Саме тому як рекомендований дефолтний стек на 2026 рік Юрій називає TypeScript-зв’язку на кшталт:

Drizzle,
Zod,
Hono,
та інші сумісні інструменти.

При цьому важлива не просто популярність стеку, а те, що він оптимально підходить саме для AI-агентів і LLM-driven development.

CI/CD, Zero Bug Policy і self-healing CI

Ще один важливий блок — повністю автоматизований CI/CD, реалізований через Terraform.

Будь-які зміни в CI/CD можна описати прямо в чаті Cursor. AI генерує зміни в Terraform, а Terraform далі деплоїть усе, куди потрібно, наприклад у Google Cloud.

7 перевірок у pipeline

У pipeline проходять перевірки:

Build
TypeCheck
Lint
Test
Security
Visual regression
інші обов’язкові фази

Якщо хоча б одна обов’язкова фаза не проходить, pull request не створюється або блокується.

ToDoSecurity та блокування merge

Якщо після проходження pipeline залишаються security-зауваження, наприклад ToDoSecurity, merge не відбудеться. Ці проблеми мають бути виправлені в рамках AI-SDLC.

Visual Regression

Для візуальної регресії використовується AI-хроматік або подібний механізм, який піксель за пікселем порівнює стан інтерфейсу до змін і після них. Якщо знаходяться небажані зміни, AI їх фіксує.

AI Code Review

AI проводить review кожного pull request:

аналізує зміни;
виставляє рівень критичності;
залишає коментарі;
ранжує зауваження як Critical, High, Medium, Low.

Людина далі вже приймає фінальне рішення.

Self-Healing CI

Self-healing CI означає, що AI може:

прочитати логи;
знайти першу причину помилки;
виправити код;
запустити перевірки;
створити Draft PR для людини.

Якщо помилка дуже проста — наприклад, друкарська або технічна дрібниця — AI теоретично може сам її пофіксити й навіть задеплоїти, якщо така автономія дозволена. Але на практиці зараз рекомендується залишати фінальне рішення за людиною майже в усіх сценаріях.

Антигалюцинації: межі, governance gate і anti-drift rules

Юрій кілька разів повертається до теми галюцинацій.

Основний меседж тут такий: AI галюцинує, це факт. Але галюцинації не є катастрофою, якщо є:

чіткі межі;
добрий context engineering;
governance gate;
anti-drift rules;
заборона на вигадування;
нотатки Need Clarification;
блокування роботи до рішення людини.

Якщо AI чогось не розуміє, він не має права “домислювати”. Він повинен залишити позначку Need Clarification і чекати рішення людини. Саме це захищає систему від дрейфу не в той бік.

Пам’ять, progress logs і handoff files

Оскільки кожна AI-сесія починається з нуля і контекст може втрачатися, в системі використовуються спеціальні артефакти пам’яті:

memory;
progress log;
handoff file.

Memory — це Markdown-файл, у який AI записує, що він зрозумів і вивчив у процесі роботи.

Progress log — лог реалізації, де фіксується, що саме зроблено й з посиланнями на requirement’и та специфікації.

Handoff file — файл передачі роботи. Якщо один агент зламався, інший починає саме з читання handoff-файлу. Завдяки цьому контекст переходить між сесіями й агентами.

Також у процесі кожен новий етап починається в новому чаті. Попередній чат закривається, а потрібний контекст передається через handoff і артефакти. Це ще один спосіб контролювати контекстне вікно й не тягнути зайвий шум із попередніх обговорень.

Як підхід працює з legacy-проєктами

На запитання про те, чи підходить AI-SDLC лише для нових продуктів, Юрій відповідає однозначно: підходить і для legacy, причому дуже добре.

Практичний підхід такий:

Береться еталон — SaaS-конституція.
Дається AI разом із legacy-продуктом.
У Cursor ставиться завдання порівняти конституцію з поточним продуктом.
AI видає великий список відмінностей і рекомендацій.
Далі можна звузити фокус до конкретних задач і проблем.

AI оцінює:

що легко застосувати;
що принесе найбільшу користь;
що краще не чіпати;
що краще винести в окремий модуль;
де варто щось змінити, а де — залишити як є.

Таким чином AI-SDLC не замінює legacy-розробку “в лоб”, а працює як інтелектуальна рамка, через яку legacy-продукт можна поступово покращувати.

AI-SDLC як пам’ять організації

Окремий сильний аргумент на користь цього підходу — organizational memory.

У звичайних командах часто буває, що:

архітектурні рішення пам’ятає одна людина;
якийсь важливий контекст залишився в старому чаті;
документація розкидана;
новому девелоперу потрібно довго все збирати по шматках.

У підході AI-SDLC:

knowledge;
memory;
handoff files;
requirements;
ADR;
специфікації;
плани;
правила

— усе лежить прямо в продукті, у Git, у вигляді артефактів. Тому новий розробник може прийти і самостійно розібратися, що відбувається.

Які бізнес-переваги дає такий підхід

Юрій окремо підкреслює, що на практиці AI дуже добре працює саме з ідеями, покращеннями та швидким аналізом. Він може підтягувати best practices з інших компаній, із домену, з ринку, і це дає значний виграш у часі.

Серед прямих переваг для бізнесу:

швидше виправлення продакшен-проблем;
self-healing на нічних CI-фейлах;
зменшення backlog;
швидший onboarding розробників;
швидке формування summary і порядку дій при інцидентах;
повна traceability;
контрольована автономія;
якість “за замовчуванням”;
готовність до enterprise-рівня.

Також він бачить великий потенціал у створенні SaaS-продуктів під конкретного клієнта. Замість того щоб змушувати клієнта користуватися великим загальним SaaS із десятками зайвих функцій, AI-SDLC дозволяє:

взяти документацію;
дати доступ до референсів;
сформувати requirements;
зібрати тільки той функціонал, який потрібен конкретному клієнту;
навіть комбінувати фічі з різних продуктів в один новий продукт.

Роль розробника і QA в AI-SDLC

Юрій окремо наголошує: роль девелопера й QA не зникає.

Девелопер тепер:

не просто пише код;
а review-ить роботу AI;
переглядає файли, які генерує AI;
дає нові rules;
переносить свій досвід у продукт через специфікації, правила, обмеження, governance.

QA теж не зникає. Він:

перевіряє, як AI тестує;
перевіряє, як AI пише тести;
додає свої знання в продукт;
формує правила для edge cases, happy path, error path;
спрямовує AI в тестовому мисленні.

Таким чином знання окремих спеціалістів не зникають, а поступово вбудовуються в продукт і лишаються там навіть тоді, коли конкретна людина йде у відпустку або залишає команду.

Що буде актуальним у найближчі 3–6 місяців

Юрій вважає, що вже в дуже короткій перспективі — буквально 3–6 місяців — стануть нормою:

кілька агентів у людини чи в команді;
їхня взаємодія між собою;
background-агенти;
eval pipelines;
cost budgets;
hallucination detection;
rules as code;
governance як обов’язкова частина AI-driven development.

Йдеться вже не просто про “AI допомагає писати код”, а про нову модель організації розробки, у якій агенти стають частиною системи, але тільки за умови, що вони працюють у правильно налаштованих межах.

Висновок

Підхід, який представив Юрій, показує, що майбутнє AI у розробці — не в хаотичній генерації коду, а в контрольованій автономії. AI може писати код, генерувати специфікації, будувати плани, створювати тести, проводити code review, працювати в CI/CD і навіть виправляти частину помилок автоматично. Але все це працює лише тоді, коли в системі є governance, конституція, правила, артефакти й людина як фінальний арбітр.

AI-SDLC у цьому контексті — це не просто набір команд для Cursor і не красивий шаблон. Це новий операційний підхід до software development, де:

кожна фаза контрольована;
кожен результат залишає слід;
кожен агент працює в межах ролі;
кожна галюцинація має бути зупинена правилами;
кожна зміна має проходити через перевірки.

Саме тому питання вже не в тому, чи потрібен AI у розробці. Питання в іншому: з яким governance його впроваджувати. І саме на це, за логікою Юрія, сьогодні має відповідати сучасна інженерна команда.