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

Моє правило: специфікація лишається єдиним джерелом істини, тому не вносимо зміни в код в обхід неї.

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

Ще в травні я писав пост про SDD-фреймворки. Відтоді їх стало значно більше, тож проаналізував існуючі та відібрав 19 найпомітніших і розклав їх за головною функцією:

⏺Спершу вимоги, план і задачі — потім код: Spec Kit, Kiro, BMAD, GSD, MoAI-ADK, Gangsta Agents.
⏺ Оновлюють специфікацію разом зі змінами в наявному коді: OpenSpec, Spec Kitty.
⏺ Вчать агента правил роботи замість етапів: Superpowers, Matt Pocock skills, GRACE.
⏺ Перевіряють реалізацію за планом або критеріями приймання: Traycer, Memex.
⏺ Перезапускають агента, доки задача не закриється: Ralph Loop, Smart Ralph, GAAI.
⏺ Запускають кількох агентів одночасно, кожного в окремій копії репозиторію: Conductor, Frame, Zenflow.

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

21 жовтня GitHub Next і Microsoft Research показали Proof-Driven Development Kit: він формально доводить, що код агента має властивості, задані у специфікації, — але не те, що сама специфікація правильна. Поки це дослідницьке прев’ю для Rust.

У наступних постах порівняю ці групи за чотирма критеріями — час на фічу, IDE, робота з наявним кодом, перевірка.

👍 — уже користуюсь SDD-фреймворком
👀 — поки працюю без нього
🔥 — чекаю серію

#SDD #SpecDrivenDevelopment

Який процесний SDD-фреймворк обрати: Spec Kit, Kiro, BMAD, GSD Core, MoAI-ADK чи Gangsta Agents

Порівняв усі шість за 4 критеріями:

⏺ Час на фічу.
⏺ Підтримка IDE та AI-агентів.
⏺ Робота з наявним кодом.
⏺Перевірка результату.

Це пост 2 із 5 у серії про SDD-фреймворки (перший тут).

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

Spec Kit від GitHub

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

Kiro від AWS

⏺Час на фічу: агент сам пише три артефакти — вимоги, дизайн і задачі.
⏺IDE та агенти: лише власна IDE та CLI.
⏺Наявний код: будує специфікації з наявної кодової бази.
⏺Перевірка: хуки запускають тести після зміни файлів.

BMAD

⏺Час на фічу: залежить від задачі — нечітку ідею спершу уточнюють, дрібну правку одразу реалізують і перевіряють.
⏺IDE та агенти: Claude Code, Codex та інші.
⏺Наявний код: є окремий сценарій.
⏺Перевірка: рев’ю та повторні цикли вдосконалення.

GSD Core

⏺Час на фічу: найлегший процес — Plan → Execute → Verify.
⏺IDE та агенти: Claude Code, Codex, Cursor, Copilot, Windsurf та інші.
⏺Наявний код: команда /gsd-onboard.
⏺Перевірка: окремий етап Verify перед завершенням роботи.

MoAI-ADK

⏺Час на фічу: найсуворіший процес — SPEC → аудит → TDD.
⏺IDE та агенти: лише поверх Claude Code.
⏺Наявний код: спершу characterization-тести фіксують поточну поведінку, потім агент вносить зміни.
⏺Перевірка: гейт TRUST 5 на кожну зміну — лінт, типи й тести, а «тести пройшли» зараховується лише з реальним виводом.

Gangsta Agents — мій фреймворк

Чому я додав власний інструмент до порівняння?

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

Рішення: Рішення: ще до специфікації Gangsta Agents проводить фазу
Grilling — агенти шукають слабкі місця ідеї й аргументи проти неї.

Проект уже включили до незалежного каталогу awesome-ai-plugins.

⏺Час на фічу: найдовший — шість фаз, серед них Grilling, із підтвердженням людини на кожній.
⏺IDE та агенти: Claude Code, Cursor, Codex, OpenCode, Gemini CLI, Copilot.
⏺Наявний код: перша фаза — розвідка кодової бази й вимог.
⏺Перевірка: спершу червоний тест, який падає, і лише потім код, що його проходить.

Що обрати?

• GSD Core — якщо потрібен компактний процес із плануванням, виконанням і перевіркою.
• BMAD — якщо процес має адаптуватися до масштабу задачі.
• MoAI-ADK — якщо важливі TDD і формалізовані вимоги до якості.
• Kiro — якщо команда працює в екосистемі AWS.
• Spec Kit — якщо потрібен структурований процес для різних AI-агентів.
• Gangsta Agents — якщо важливо перевіряти не лише код, а й саму ідею до того, як вона стане специфікацією.
Перевірка ідеї теж коштує часу: агенти сперечаються ще до початку реалізації. Але іноді це дешевше, ніж швидко побудувати не те, що потрібно.

🔥 — уже користуюся SDD-фреймворком
👀 — ще обираю
😁 — пишу специфікацію просто в чаті й поки вистачає

#SDD #SpecDrivenDevelopment

Living specification: як OpenSpec і Spec Kitty тримають специфікацію узгодженою з кодом

Це пост 3 із 5 у серії про
SDD-фреймворки

Критерії ті самі, що й для всієї серії:

⏺ Час на фічу.
⏺ Підтримка IDE та AI-агентів.
⏺ Робота з наявним кодом.
⏺ Перевірка результату.

GitHub, запускаючи Spec Kit, пообіцяв living documents, «що розвиваються разом із кодом». У Thoughtworks перевірили, як це працює насправді, і розділили SDD на три рівні:

⏺ spec-first — специфікацію пишуть перед задачею і використовують лише для неї;
⏺ spec-anchored — специфікацію зберігають після задачі й через неї розвивають і підтримують фічу;
⏺ spec-as-source — людина редагує тільки специфікацію, а код генерується з неї.

Їхній висновок: Kiro і Spec Kit на практиці працюють як spec-first, а spec-as-source є лише в закритій беті.

За цією шкалою OpenSpec і Spec Kitty — другий рівень: специфікація лишається в репозиторії після задачі, а кожна зміна оновлює її. Відрізняються вони масштабом: перший — легкий цикл для однієї людини, другий — конвеєр для кількох агентів одночасно.

OpenSpec

⏺ Час на фічу: три команди — /opsx:propose, /opsx:apply, /opsx:archive. Якщо задача ще не ясна, спершу /opsx:explore: агент читає код і пропонує варіанти.
⏺ IDE та агенти: понад 30 інструментів, зокрема Claude Code, Cursor, Copilot і Codex.
⏺ Наявний код: автори прямо пишуть, що будували його для наявних проектів, а не лише для нових. Зміна описується як різниця до поточної специфікації: що додано, що змінено. Для фіч на кілька репозиторіїв є Stores — поки в беті.
⏺ Перевірка: план затверджуєте ви до першого рядка коду; у розширеному профілі є /opsx:verify. Тестових гейтів немає.

Spec Kitty

⏺ Час на фічу: найдовший цикл — spec → plan → tasks → next → review → accept → merge. Автори самі пишуть, що для дрібних правок це зайве.
⏺ IDE та агенти: Claude Code, Codex, Cursor, Gemini, Copilot, Windsurf, OpenCode та інші.
⏺ Наявний код: додається в наявний репозиторій однією командою; кожен пакет робіт іде в окремому git worktree, тож кілька агентів працюють паралельно й не заважають одне одному.
⏺ Перевірка: пакети проходять статуси planned → for_review → approved → done, а перед злиттям — review і accept. Після кожної місії — автоматична ретроспектива.

Що обрати?

⏺ OpenSpec — якщо ви працюєте з наявним проектом і хочете, щоб специфікація не відставала від коду.
⏺ Spec Kitty — якщо кілька агентів чи розробників ведуть одну фічу паралельно й потрібні гейти перед злиттям.

👍 — специфікація в репозиторії, поруч із кодом
👀 — поки в окремому доці
😁 — поки в голові

#SDD