Spec-Driven Development: як AI перестає вгадувати вимоги
AI рідко пише «не той» код навмисно. Частіше він пише цілком логічний код для нечітко поставленої задачі.Саме цю проблему намагається вирішити SDD — Spec-Driven Development. Підхід, у якому розробка починається не з промпту «зроби фічу», а з узгодженої специфікації.
Промпт — це ще не специфікація
Уявімо задачу: «Додай відновлення пароля».Для AI цього достатньо, щоб створити endpoint, форму й відправлення email. Але що має відбутися, якщо користувача не існує? Скільки живе посилання? Чи можна використати його двічі? Що робити з попередніми токенами? Чи потрібне обмеження кількості запитів?Якщо цього немає у вимогах, модель заповнить прогалини сама. І її припущення можуть виглядати переконливо навіть тоді, коли суперечать правилам продукту або безпеки.У SDD та сама задача спочатку перетворюється на конкретний контракт: відповідь не розкриває, чи існує email; посилання діє 15 хвилин і лише один раз; новий запит анулює попередній токен; діє ліміт у п'ять запитів на годину; подія потрапляє в аудит-лог без самого токена.Тепер AI не вгадує поведінку — він реалізує її.
Як виглядає процес
GitHub Spec Kit описує простий ланцюжок: Spec → Plan → Tasks → Implement.Спочатку команда формулює, що й навіщо будує: користувацькі сценарії, обмеження та критерії приймання. Потім AI пропонує технічний план: компоненти, моделі даних, API-контракти й тести. План розбивається на невеликі перевірювані задачі, і тільки після рев'ю починається генерація коду.Кожен етап залишає Markdown-файл у репозиторії. Тому важливі рішення не губляться в історії чату, а наступна сесія або інший AI-агент отримує той самий контекст. GitHub Spec Kit уже підтримує понад 30 інтеграцій з coding agents, тож підхід не прив'язаний до однієї моделі чи IDE.
Де тут реальна економія
SDD додає час перед написанням першого рядка. Але саме тоді зміни найдешевші.Знайти пропущений сценарій у spec.md — це виправити кілька речень. Знайти його після реалізації — це змінити API, схему бази, UI, тести й, можливо, вже відкритий pull request.Тому головна метрика тут не кількість коду, який згенерував AI. Важливіше, скільки неоднозначностей команда прибрала до генерації та скільки вимог можна перевірити тестами.
Специфікація не замінює інженера
Погана специфікація лише допоможе швидше створити неправильну систему. Хтось усе одно має поставити незручні запитання, перевірити архітектурні рішення та прийняти компроміси.SDD змінює роль AI: замість імпровізатора він стає виконавцем чітко описаного задуму. І для production-коду це значно цінніше за ефектну генерацію з одного речення.