Spec-driven development: від ідеї до архітектури продукту з ШІ

Коротко (TL;DR)

Зібрати прототип з ШІ за вечір і довести великий продукт до пуття — два різні завдання. Перше пробачає хаос, друге на ньому розвалюється. Цей матеріал — про друге: зв’язний метод, що веде від сирої ідеї через ресерч і межі MVP до дисциплінованої архітектури, з конкретними механізмами Claude Code на кожному кроці, а не абстрактним «зробіть специфікацію».

Що важливо зрозуміти одразу:

• «Вайб-кодинг» великого проєкту в одну сесію не масштабується. Що довше завдання і що більше файлів, то сильніше агент втрачає намір і накопичує технічний борг. Дисципліна тут — не бюрократія, а спосіб не переписувати все за місяць.
• Метод — це п’ять етапів: brainstorm → ресерч ринку → межі MVP → вибір стека → специфікація й архітектура. Перші два робляться у звичайному чаті, кодового агента відкриваємо пізніше.
• У Claude Code вже вбудовані інструменти під цей метод: режим планування (Plan Mode), аліас opusplan (потужна модель на план, швидка — на реалізацію), субагенти з ізольованим контекстом і файл проєкту CLAUDE.md.
• Ризики реальні та вимірні: ШІ-код без плану й перевірок статистично частіше містить вразливості. Метод знижує конкретні ризики на конкретних кроках — про це наприкінці.

Що знадобиться: доступ до Claude Code (підписка або API), звичайний вебчат з моделлю для перших етапів і готовність працювати методично, а не однією сесією. Рівень — просунутий. Терміни на кшталт «специфікація» та «Plan Mode» розбираємо по ходу, але передбачається, що ви вже пробували писати код зі ШІ.

Чому «просто вайб-кодити» ламається на масштабі

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

BINANCEДосі дивишся збоку?Ринок працює без вихідних. Рахунок на Binance відкривається за 2 хвилини.Почати зараз

Є й дані. Академічне дослідження ризиків вайб-кодингу (arXiv 2509.12491, вересень 2025) за самозвітами практиків фіксує один і той самий набір проблем: технічний борг, непідтримуваний код, приховані баги й небезпечні місця, що спливають саме тоді, коли проєкт виростає за межі прототипу. Окрема робота з безпеки згенерованого коду (arXiv 2506.23034) показує, що в більшості протестованих у ній моделей частка вразливого коду — від 9,8% до 42,1% (конкретна цифра залежить від моделі, бенчмарка й типу вразливості), а в інших дослідженнях трапляються й вищі значення. Висновок не «ШІ пише поганий код», а «ШІ-код без плану й перевірки не можна вважати готовим за замовчуванням».

Монтаж відео кодом: пайплайн із Deepgram, FFmpeg і Remotion

Supabase і Stripe за вечір з Claude Code — і три речі, які агент зробить не так

Деплой на Vercel через GitHub: як викласти проект покроково

AWS Continuum прийде в Claude Code і Codex: пошук дірок просто в редакторі

OpenClaw на Claude скасував чуже бронювання, щоб підняти власника з 4-го на 3-тє

Звідси й увесь метод: на кожному кроці ми свідомо додаємо те, що вайб-кодинг прибирає заради швидкості, — зафіксований намір, межі й перевірку.

Етап 1 — Brainstorm: розганяємо ідею до відкриття кодового агента

Перша помилка — одразу відкрити Claude Code і почати «робити застосунок». На етапі ідеї технічний агент шкідливий: він тягне вас у деталі реалізації, коли ще не вирішено, що взагалі будуємо.

Практика, яку радять російськомовні практики (наприклад, розбори на bitrix24) і яка працює: мозковий штурм ведемо у звичайному чаті з моделлю, а не в кодовому агенті. Завдання етапу — не код, а ясність. Добре працює роль «ШІ-скептик»: просите модель не погоджуватися, а шукати діри — кому це потрібно, чим уже розв’язують цю проблему, де ви себе обманюєте.

Ще корисніше — не діалог, а структуроване інтерв’ю. Попросіть ШІ провести вас по питаннях продакта: яку проблему розв’язуємо, для кого, який сценарій використання головний, як зрозуміємо, що продукт потрібен. Claude Code вміє вести таке інтерв’ю через уточнювальні питання, але на цьому етапі достатньо вебчату. Підсумок етапу — короткий документ-концепція у Markdown, а не рядок коду.

Приклад стартового промпту:

Ти — скептичний співзасновник. Я хочу зробити <ідея>.
Не піддакуй. Постав мені по одному питанню за раз про:
проблему, аудиторію, конкурентів, монетизацію і головний сценарій.
Наприкінці збери з моїх відповідей концепцію на одну сторінку в Markdown.

Етап 2 — Ресерч ринку і конкурентів зі ШІ

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

BINANCE SIMPLE EARNЗмусь крипту працюватиВідсотки на USDT і BTC без блокування — гроші лишаються під рукою.Розмістити

Сам вендор фактично підтверджує цю рамку. Anthropic випустила «founder’s playbook» — опис життєвого циклу AI-native стартапу: Idea → MVP → Launch → Scale, де засновник працює «оркестратором» ШІ-інструментів. Це рівно той шлях, який ми розбираємо, лише сформульований з боку творця моделі.

Підсумок етапу — не «ШІ сказав, що ринок хороший», а список перевірених фактів: 2–3 прямі конкуренти з їхніми слабкими місцями, ваша гіпотеза відмінності й один-два способи монетизації.

На цьому ж матеріалі зручно зібрати PRD (product requirements document) — короткий документ вимог до продукту для людей. Згодуйте моделі концепцію й результати ресерчу і попросіть оформити їх у структуру «проблема — аудиторія — сценарії — функції першої версії — метрики успіху». Важливо не плутати PRD зі специфікацією: PRD відповідає на питання «що і навіщо будуємо» для людини, а специфікація (п’ятий етап) — «як саме агент це робить» для машини. PRD пишеться один раз, специфікація живе й змінюється.

Етап 3 — MVP: окреслюємо межі й не ловимо scope creep

MVP — це не «маленька версія всього», а «мінімум, що перевіряє головну гіпотезу». Дві типові помилки, які фіксують практики: scope creep (у MVP заповзають функції «на майбутнє») і брак зворотного зв’язку (будуємо пів року, не показавши нікому).

Дисципліна проста: випишіть одну головну функцію, заради якої продукт існує, а все інше відправте до списку «потім». ШІ тут зручний як безжальний редактор скоупу — дайте йому концепцію і попросіть викреслити все, що не обслуговує головну гіпотезу, з обґрунтуванням по кожному пункту.

Важливо: саме на межах MVP визначається, чи буде наступний етап (архітектура) осмисленим. Розмите MVP → розмита специфікація → агент будує не те.

Етап 4 — Вибір стека для великого, а не одноразового проєкту

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

Практичний критерій: обирайте технології, яких багато в навчальних даних моделі (популярні, зрілі, з великою документацією) — на них агент помиляється рідше й краще виправляється. Екзотичний стек красивий, але кожну нестандартну бібліотеку агент «додумуватиме». Заразом на цьому кроці вирішується, де хостити, де база й платежі — якщо продукт комерційний, базу даних і приймання оплати теж проєктують заздалегідь, а не прикручують наприкінці.

Етап 5 — Від ідеї до архітектури: специфікація замість здогадок

Тут метод переходить із продуктової площини в інженерну. Ключова ідея — spec-driven development (SDD): спершу пишемо специфікацію (що і як має працювати), а агент за нею генерує план і код, звіряючи результат із критеріями. Специфікація стає контрактом, від якого агент не відхиляється без явної зміни контракту.

Чим специфікація відрізняється від PRD, який ви могли скласти на етапі 2. PRD — документ для людей, його пишуть раз і рідко чіпають. SDD-специфікація — живий документ для агента й CI, вона оновлюється по ходу. Докладний промпт — це ще не специфікація: промпт разовий, специфікація — те, проти чого звіряється кожен крок.

З чого складається хороша agent-специфікація. За аналізом тисяч реальних конфігурацій агентів на GitHub (дослідження по 2500+ репозиторіях) корисна специфікація покриває шість областей: команди (як зібрати/запустити/протестувати), тестування, структуру проєкту, стиль коду, роботу з git і межі — що агентові можна, що ні. Інструменти формалізують це по-різному: GitHub Spec Kit проводить через чотири гейтовані фази (Specify → Plan → Tasks → Implement), а роль носія специфікації в Claude Code грає файл CLAUDE.md.

Окремо про межі — найбільш недооцінений розділ. Замість плаского списку заборон працює трирівнева система: що агентові дозволено завжди, що — лише з підтвердженням, і що — ніколи. Найчастіше правило у вибірці — «ніколи не комітити секрети». Така градація читається агентом краще за суцільний список «не можна».

Важливе застереження: SDD виправданий не завжди. Для дрібної фічі або дослідницького прототипу, який ви збираєтеся викинути після перевірки гіпотези, важка формальна специфікація — надлишок. Правило: завдання цілком поміщається в контекст агента й одноразове — специфікація зайва; продукт живе й росте — специфікація окупається.

Механіка Claude Code для великого проєкту

Тепер — конкретні інструменти, що перетворюють метод із теорії на робочий процес.

Офіційний робочий цикл: Explore → Plan → Implement → Commit. Спершу агент досліджує код у режимі лише-читання, потім будує план (Plan Mode — агент не чіпає файли, поки ви не затвердили план), далі реалізує й комітить. Планування до коду — це той самий принцип SDD, вбудований в інструмент.

Розділення моделей за етапами — аліас opusplan. Claude Code вміє ставити потужну модель (Opus) на планування, а на реалізацію автоматично перемикатися на швидшу (Claude Sonnet 5). Це готова технічна реалізація саме тієї ідеї, яку метод радить робити вручну: думати дорого й ретельно, виконувати швидко й дешево. Конкретні імена моделей змінюються часто — звіряйте актуальну лінійку в офіційній документації з конфігурації моделей на момент роботи.

CLAUDE.md — пам’ять проєкту. Цей файл завантажується на початку кожної сесії й тримає контекст: як зібрати проєкт, які домовленості, які межі. Правило — тримати його коротким і по суті: роздутий CLAUDE.md сам з’їдає контекст.

Субагенти — ізольований контекст під підзавдання. У субагента власне вікно контексту, власний системний промпт і власний набір інструментів. Це дає змогу винести важке підзавдання (ресерч, рев’ю, міграцію) в окремий «чистий» контекст і повернути в основний лише результат — так основна сесія не захаращується. Якщо хочеться побачити агентний патерн у готовому продукті, показовий розбір особистого ШІ-агента та його реальної собівартості.

Керування контекстним вікном. Anthropic називає ефект прямо — context rot: що більше токенів у контексті, то гірше модель їх утримує й то нижча точність. Звідси практика: не вести один нескінченний чат на весь проєкт, а працювати фазами зі свіжим контекстом, передаючи між ними короткий handoff-файл. Споріднений ефект — «curse of instructions»: що більше правил в одному промпті, то гірше агент дотримується кожного, тому специфікацію декомпозують на модулі й фази.

Адверсаріальне рев’ю: генератор проти критика

Один агент, який і пише, і перевіряє власний код, — це конфлікт інтересів: у нього мета «здати». Працює розділення ролей. Anthropic у best practices радить запускати окремого субагента в чистому контексті, який перевіряє diff проти плану. Незалежна інженерна практика (наприклад, в Augment Code) формалізує це як зв’язку Coordinator / Implementor / Verifier — з протилежними цілями «реалізувати» й «знайти брак».

Для одного розробника це адаптується просто: після того як основний агент реалізував фазу, відкрийте свіжий контекст (або субагента) із завданням «ти рев’юер, твоя мета — знайти, де реалізація розходиться з планом і де діри в безпеці». Різні цілі ловлять те, що один прохід пропускає.

Вайб-кодинг за вечір проти дисциплінованого процесу

Метод не скасовує швидкий вайб-кодинг — у них різні завдання. Орієнтир, коли що:

Правило вибору: що довше жити коду і що вища ціна помилки, то правіше ви маєте бути в цій таблиці.

Ризики і як метод їх знижує

Дисципліна — не самоціль, а відповідь на конкретні ризики. Розбираємо по кожному:

• Вразливий код. ШІ-код статистично частіше містить вразливості (arXiv 2506.23034; конкретні частки залежать від моделі й методу заміру — не універсальна «середня цифра»). Знижують: специфікація з явними межами безпеки й адверсаріальне рев’ю diff’а.
• Технічний борг і непідтримуваність. Головна скарга практиків (arXiv 2509.12491). Знижують: вибір зрілого стека, короткий CLAUDE.md, декомпозиція на фази.
• Втрата наміру на довгій дистанції. Context rot і «curse of instructions». Знижують: робота фазами зі свіжим контекстом, специфікація як зовнішня пам’ять замість перевантаженого вікна.
• «Lethal trifecta» (формулювання Саймона Віллісона, атрибутована думка): швидкість + недетермінізм ШІ + економія на верифікації разом дають небезпечну комбінацію. Знижує: не зрізати перевірку заради швидкості на комерційному продукті.
• Регуляторика. Для деяких класів систем з’являються зобов’язання (наприклад, положення EU AI Act поетапно набувають чинності; звіряйте актуальні терміни й застосовність до вашого випадку на першоджерелі). Знижує: заздалегідь закласти вимоги в специфікацію.

YMYL-висновок: ШІ радикально прискорює шлях від ідеї до продукту, але «згенеровано» не дорівнює «готово». Метод із цієї статті — спосіб отримати швидкість ШІ, не заплативши за неї якістю й безпекою.

Як виглядає один прохід методу цілком

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

1. Brainstorm (вебчат). Роль «скептик»: «кому це потрібно, якщо є готові нотатники?» Відповідь на заперечення дає формулювання відмінності — «фокус на видобуванні завдань, а не на зберіганні тексту». Підсумок — концепція на сторінку.
2. Ресерч. ШІ збирає 3 конкурентів, ви звіряєте їхні фічі й ціни вручну. Знахідка: у всіх слабка обробка довгих записів. Це ваша гіпотеза відмінності. Оформлюєте PRD.
3. MVP. Головна гіпотеза — «користувач готовий платити за точне видобування завдань». Усе, що не обслуговує її (теги, шеринг, мобільний застосунок), іде в «потім». У MVP лишається: завантаження запису → транскрипт → список завдань.
4. Стек. Зрілий і популярний: щоб агент упевнено писав код і менше «додумував». Хостинг, база й оплата намічені заздалегідь.
5. Специфікація й архітектура. Пишете специфікацію з шістьма областями (команди, тести, структура, стиль, git, межі) і трирівневими межами. Відкриваєте Claude Code, Plan Mode будує план за специфікацією, ви його затверджуєте.
6. Реалізація з розділенням моделей. opusplan: Opus планує, Sonnet пише код по фазах. Після кожної фази — свіжий контекст.
7. Рев’ю. Окремий агент-критик перевіряє diff проти плану й шукає діри в безпеці (тут — як зберігається й передається аудіо користувача).

На виході — не «прототип, який шкода розвивати», а продукт із зафіксованим наміром, керованим техборгом і зрозумілою архітектурою. Саме це відрізняє розробку MVP з Claude Code за методом від вайб-кодингу великого проєкту навмання.

FAQ

З чого почати, якщо ідея поки сира? Зі звичайного чату, не з Claude Code. Проведіть мозковий штурм у ролі «скептик», зберіть концепцію на одну сторінку, і лише потім переходьте до ресерчу й коду. Кодовий агент на етапі ідеї заважає — тягне в деталі реалізації.

Чим специфікація відрізняється від докладного промпту? Промпт — разова інструкція. Специфікація — живий документ, проти якого агент звіряє кожен крок плану і за яким потім перевіряється результат. Докладний промпт специфікацію не замінює.

Чи обов’язково писати специфікацію для кожного проєкту? Ні. Для одноразового прототипу або дрібної фічі формальна специфікація — надлишок. Вона окупається, коли продукт живе й росте. Критерій — чи поміщається завдання цілком у контекст агента і чи викинете ви його після перевірки.

Що дає opusplan і навіщо розділяти моделі? Планування виграє від найсильнішої моделі, а рутинна реалізація — ні. opusplan ставить Opus на план і перемикається на Sonnet для коду: якість задуму за меншої ціни виконання. Актуальні імена моделей звіряйте в документації — вони часто змінюються.

Як не дати агентові накопичити технічний борг на великому проєкті? Три речі: зрілий популярний стек, робота короткими фазами зі свіжим контекстом (проти context rot) і окремий агент-рев’юер, що перевіряє кожну фазу проти плану. Один агент, який пише й перевіряє сам себе, — поганий контроль якості.

Чи можна довірити ШІ всю архітектуру? ШІ добре пропонує варіанти й пише специфікацію під вашим керівництвом, але фінальні рішення щодо меж, безпеки й стека лишаються за вами. Роль людини тут — оркестратор, а не спостерігач.