Протилежність вайб-кодингу: SDD як спосіб імплементовувати бізнес-вимоги з AI

💡 Усі статті, обговорення, новини про AI — в одному місці. Приєднуйтесь до AI спільноти!

Краще зроблю сам

«Краще зроблю сам» — типова думка сеньйора, коли йому доводиться наставляти джуна. Але поганий той сеньйор, що дійсно починає робити сам, замість того щоб навчити починаючого розробника.

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

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

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

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

Хто кращий розробник?

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

Нечіткі промпти (привіт, «vibe coding») призводять до нечіткого коду, що акумулює технічний борг.

Наприклад, якщо ви просите AI «впровадити дозволи користувача» без детальної специфікації, агент може згенерувати ідеальний, на вигляд, код RBAC (Role-Based Access Control), але він може не врахувати специфічні бізнес-потреби, такі як гранульовані дозволи чи тимчасовий доступ.

Що таке SDD?

Саме тут на сцену приходить Specification-Driven Development (SDD).

Самому терміну і концепції вже є добрих два десятки років — вперше згадується в публікації від 2004 року, як інтегрований підхід, що поєднує найкращі риси Test-Driven Development (TDD) та Design-by-Contract (DbC). В SDD і тести, і контракти є специфікаціями, які є взаємодоповнюючими для створення високоякісного ПЗ.

Але виглядає так, що свого часу вона чекала аж до 2025, коли її почали застосовувати до агентів для генерації коду. Ще не минуло й трьох місяців як Amazon Kiro та GitHub Speс Kit відродили це поняття і влучно застосували до керування AI-агентами для написання коду.

Фактично це методологія з достатньо революційними ідеями, ось її трактування від GitHub, можете ознайомитися детально.

Основні принципи SDD:

• Специфікація як Lingua Franca: Специфікація — первинний артефакт.
• Виконувані специфікації: Специфікації достатньо точні для генерації робочих систем.
• Безперервне вдосконалення: Постійна перевірка специфікацій на неоднозначність, суперечності та прогалини.
• Контекст, керований дослідженнями: Агенти збирають критичний контекст під час процесу формування специфікацій.
• Двонаправлений зворотний зв’язок: Досвід з продакшину впливає на еволюцію специфікації.
• Розгалуження для дослідження: Генерація різних імплементацій з однієї специфікації.

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

SDD допомагає нам бути кращими «сеньйорами» для наших «AI-джунів», даючи їм чітку структуру та контекст, якого вони потребують для масштабування роботи.

Специфікація як єдине джерело істини (Single Source of Truth)

Ключова відмінність SDD від традиційних методів полягає в тому, що специфікація стає центральним артефактом — єдиним джерелом істини (SSOT), яке керує автоматичним генеруванням коду, валідацією та підтримкою.

Специфікації для AI-інструментів — це не просто довільний текст. Вони є очищеним контекстом, який забезпечує LLM-моделям необхідну структуру та напрямок. Завдяки значно більшим контекстним вікнам сучасних LLM (200K+ токенів), AI може ефективно обробляти цю комплексну, структуровану інформацію.

SDD пропонує поетапний робочий процес (який взагалі напряму не згадує про AI):

1. Specify (Специфікація): На цьому етапі ви надаєте високорівневий опис того, що і навіщо ви створюєте, фокусуючись на користувацькому досвіді та бізнес-цінності. Агент генерує детальний документ, що містить історії користувачів та критерії успіху.
2. Plan (Планування): Ви переходите до технічних деталей. Визначається, як буде будуватися рішення: технологічний стек, архітектура, обмеження, стандарти безпеки та продуктивності. Це допомагає AI вбудувати ваші корпоративні архітектурні патерни безпосередньо в план.
3. Tasks (Завдання): Агент розбиває специфікацію та план на малі, ізольовані та тестовані завдання. Завдяки цьому AI працює сфокусовано, подібно до циклу TDD.
4. Implement (Впровадження): Кодувальний агент виконує ці завдання (послідовно або паралельно). Розробник тепер переглядає не величезні «дампи коду», а сфокусовані, конкретні зміни.

Критерії прийняття — ви тепер в іншій ролі

У цьому процесі ваша роль перетворюється з «кодера» на «архітектора» та «валідатора». Ви повинні перевіряти на кожному етапі, чи відповідає специфікація вашому наміру, чи враховані всі реальні обмеження та граничні випадки (edge cases).

Особливо критичним моментом є чітке визначення критеріїв прийняття (Acceptance Criteria). Це та частина специфікації, яка прямо говорить AI-агенту, що означає успішне завершення роботи і коли слід зупинитися. Якщо ви даєте AI обмеження, наприклад, «не використовуй жорстко закодовані кольори» або «не використовуй застарілі конструкції», агент буде змушений мислити глибше і не використовувати «хакерських рішень» (hacky solutions), які він міг би використати за відсутності обмежень, щоб просто виконати завдання.

Чіткість специфікації приносить величезні переваги, які є критично важливими для бізнесу:

• Менше галюцинацій: Обмеження області роботи AI забезпечує більш прямий шлях до успіху, модель має менше про щось здогадуватися, а просто слідувати чітким інструкціям.
• Системна якість: Якість рішення стає ключовою складовою рішень, оскільки AI постійно валідує свою роботу відповідно до специфікації та критеріїв прийняття, які визначаються заздалегідь.
• Спрощена підтримка: Документація вбудовується в процес розробки автоматично, а оскільки специфікації зберігаються (наприклад, як Markdown-файли у Git), передача (handoff) функціоналу наступному розробнику стає значно простішою, ніж розшифровка чужого коду.
• Прискорення складних завдань: Хоча початкове написання детальної специфікації вимагає часу, це окупається завдяки тому, що AI генерує реалізацію в рази швидше, ніж ручне кодування.

Нова мова програмування

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

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

Це дозволяє нам як розробникам масштабуватися і використовувати швидкість AI для створення production-ready коду, а не просто швидких, але сирих прототипів.

Кому тема цікава — запрошую в мій телеграмчик, останнім часом багато з SDD працюю і сеньйором для цього бути зовсім не обов’язково, навіть можливо не факт що треба вміти писати код взагалі, достатньо знання «людської мови» — за словами Дженсена Хуанга, CEO nVidia, «нової мови програмування» :)