Spec-driven development: що це і як написати ТЗ, за яким збудує AI-команда

Spec-driven development з'явився, коли команди помітили: AI-агенти чудово пишуть код і жахливо вгадують, що ви мали на увазі. У spec-driven development джерелом істини є коротка версійована специфікація, а код генерують із неї AI-агенти, якими керують і яких перевіряють старші інженери. Змінюється продукт - спершу змінюється специфікація, потім перегенеровується те, чого вона торкнулася. Саме тому AI-first команда здає той самий обсяг утричі дешевше і втричі швидше за ручну розробку: суперечки відбуваються на одній сторінці до початку роботи, а не впродовж чотирьох місяців переписувань.

Ми ведемо так кожен проєкт відтоді, як перейшли на AI-пайплайн, тому нижче - те, що ми просимо від клієнтів, а не переказ README якогось інструмента.

Що таке spec-driven development (і чим він не є)

Означення, яке витримує перевірку: специфікація декларує намір, код його реалізує. Решта - питання ступеня. Спільнота розрізняє три рівні:

• Spec-first. Специфікація запускає першу генерацію, далі код розходиться з нею, а документ забувають. Дешево і майже нічого не варте вже на другому тижні.
• Spec-anchored. Специфікація і код розвиваються разом, а автоматичні тести доводять, що код досі робить те, що написано. Тут мають бути продакшен-системи, і тут перебуваємо ми.
• Spec-as-source. Люди редагують лише специфікацію і ніколи не торкаються згенерованого коду. Реально для емуляторів і портів, ще не для продуктів, які зустрічаються з клієнтами.

Це не повернення до ТЗ на 80 сторінок. Специфікація для MVP, за якою можна будувати, - це дві-п'ять сторінок у репозиторії, які редагують частіше за README. І це не інструмент. GitHub Spec Kit випустив v1.0.0 21 серпня 2026 року і того ж місяця перетнув 132 000 зірок, в AWS є Kiro, а Claude Code, Cursor і Codex мають режими планування, але інструменти лише закріплюють звичку. Thoughtworks саме тому тримає spec-driven development у кільці Assess свого Technology Radar, і ми вважаємо це правильним: переймайте дисципліну і не прив'язуйтеся до тулінгу.

Чому spec-driven development вистрілив у 2026 році

Пояснюють три цифри. JetBrains з'ясував, що 90% професійних розробників користувалися AI-агентами для коду щонайменше щотижня у травні-липні 2026 року, а 68% - щодня. McKinsey повідомив, що майже третина організацій відмовилася від купівлі щонайменше одного програмного продукту, бо змогла зібрати його всередині за допомогою агентів. А хвиля вайб-кодингу 2025 року лишила по собі покоління додатків, які гарно виглядають на демо і падають на реальних користувачах; про це ми писали в статті як довести додаток після вайб-кодингу до продакшену.

Складіть це докупи: софту генерують більше, ніж будь-коли, за промптами, які ніколи не були достатньо точними, щоб із ними звірятися. Специфікація - і є відсутній артефакт. Ранні користувачі повідомляють про в кілька разів вищу частку задач, які агент закриває з першої спроби, коли працює зі специфікації, а не з треду чату; це цифри вендорів, але вони збігаються з нашим пайплайном. Агент зі специфікацією і тестом, який треба пройти, доводить задачу до кінця. Агент з абзацом тексту вгадує або зарано оголошує перемогу.

Незручна частина в тому, що специфікація - людський документ. Клієнти не брешуть на discovery, але описують продукт, який хотіли б уже мати. У "MVP" шість інтеграцій і власний дашборд. Специфікація - це місце, де на них тиснуть, доки кілька не впадуть.

Як написати ТЗ, за яким може будувати AI-агент (або агенція)

Сім частин, саме в такому порядку. Якщо частини бракує, агент заповнить її найімовірнішою статистично відповіддю, і це рідко буде ваш бізнес.

1. Одна робота. Одне речення: хто що робить і що для нього змінюється. Якщо потрібне "і", це два продукти.
2. Користувачі та ролі. Кожна роль і для кожної - що вона бачить і що може змінювати. Цей розділ запобігає найдорожчому класу багів, коли один користувач читає дані іншого. У Pulzio правило зафіксували до того, як з'явилася схема: анонімність живе в моделі даних, а не в текстах інтерфейсу, тож відповіді від першого дня зберігали без зв'язку з працівником, бо таку гарантію неможливо додати заднім числом.
3. Основний сценарій, а потім його збої. Опишіть щасливий шлях пронумерованими кроками. Далі для кожного кроку - що буде, коли він зламається: банк відхилив платіж, вебхук прийшов двічі, файл важить 400 МБ. Вайб-кодинг пропускає цей розділ, і продакшен знаходить його замість вас.
4. Модель даних простими словами. Сутності, як вони пов'язані, які поля ніколи не можуть бути порожніми. SQL не потрібен. У Sanction Finder ключовою була одна вимога: зіставлення імен не може бути ні точним збігом рядків, ні настільки вільним, щоб завалити клієнта хибними спрацюваннями; це речення визначило весь шар пошуку.
5. Критерії приймання, які агент може перевірити. Використовуйте форму події: КОЛИ користувач бронює слот, який щойно зайняли, СИСТЕМА МАЄ відхилити бронювання і показати три наступні вільні слоти. Кожен критерій стає тестом, який агент зобов'язаний пройти, перш ніж задача вважається виконаною.
6. Що не робимо. Те, що свідомо не входить у цю версію, записане, щоб ніхто, ні людина, ні агент, не збудував це "з добрих намірів".
7. Означення "готово". Тести зелені, старший інженер переглянув зміну, викочено на staging, є моніторинг. Агент доповість про успіх на коді, який не запускається; так ви перестаєте вірити йому на слово.

Специфікація з цих семи частин вміщається на кількох сторінках, а засновник і старший інженер пишуть її за три-п'ять днів, здебільшого над частинами 2, 3 і 6.

Spec-driven development проти вайб-кодингу і класичного ТЗ

Через середню колонку багато засновників здригаються від слова "специфікація". Права колонка - інша річ: вона ближча до добре написаного тікета, ніж до договору.

Що написана специфікація змінює у вартості та строках

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

Повні діапазони за рівнями є в нашому розборі вартості розробки MVP. Тут головний - останній рядок: коли специфікація лежить у репозиторії, зміна - це правка на сторінку і перегенерація, а не нові переговори.

Як ми працюємо за spec-driven development у DForce

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

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

Поширені запитання

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

Це просто waterfall з AI? Ні. Специфікація у waterfall - документ, який написали один раз, підписали і забули, поки код від нього віддалявся. У spec-driven development специфікація коротка, лежить у репозиторії поруч із кодом і редагується щоразу, коли змінюється продукт, тому не встигає застаріти. Помилятися теж значно дешевше: неправильна специфікація коштує день і одну перегенерацію, а не квартал написаного вручну коду. Thoughtworks досі тримає SDD у кільці Assess, а не Adopt, і це чесно: дисципліна важливіша за інструменти.

Чи треба писати ТЗ до того, як наймати команду розробки? Треба знати відповіді, а не писати документ. Хороша команда пише специфікацію разом із вами на discovery і вважає її першим результатом роботи: хто користувачі, яка одна робота продукту, що відбувається, коли щось ламається, і що свідомо не входить у цю версію. Прийти зі списком фіч - нормально. Прийти з підписаним списком фіч, який ніхто не перевірив на міцність, - так проєкти втрачають місяць на четвертому тижні.

Скільки триває і коштує специфікація? З AI-first командою discovery і написана специфікація займають 3-5 днів і коштують $500-1,500, які зараховуються у вартість розробки. Сама розробка далі йде приблизно втричі дешевше і втричі швидше, ніж традиційна ручна, бо AI-пайплайн генерує код за специфікацією, про яку інженери вже посперечалися, і на переробки йде набагато менше годин. Простий MVP за специфікацією коштує $2,000-5,000 і займає 1-2 тижні.

Якщо у вас є ідея продукту і список фіч, який, підозрюєте, насправді список бажань, запишіться на discovery-дзвінок, і ми за тиждень перетворимо його на специфікацію із семи частин з фіксованою ціною і датою.