У співавторстві з Євгеном Сиротенко .

Задачу на платіжний сервіс ми оцінили в місяць. Закрили за півтора тижні. Фільтри в адмінці блогу оцінили у два дні. Зробили за чотири години.

Це не магія і не черговий хайп навколо AI. Ми з дев-командою у Projector Institute просто перестали гратися з окремими асистентами й перейшли на spec-driven development.

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

Що таке вайб кодинг — і чому ми з нього пішли

Вайб кодинг (vibe coding) — це стиль розробки, де ви з моделлю фактично змагаєтесь, хто кого перенаситить контекстом. Пишете промт, дивитесь результат, пишете ще один, модель забуває, що робила раніше, і цикл починається спочатку. На маленькому скрипті за годину це працює. На реальному проєкті зі складною архітектурою все розсипається.

Spec-driven development влаштований інакше. Це інтеграція AI прямо в SDLC: кодинг за вимогами, які модель сама напише і з вами узгодить, за стандартами й підходами саме вашого проєкту. AI при цьому не став розумнішим. Змінилось те, що процес тепер структурований.

Найкраще різницю між вайб кодингом і SDD видно на прикладі. Є короткий відео-туторіал з порівнянням vibe coding і spec-driven development. Це найшвидший спосіб пояснити колезі чи менеджеру, чому «просто попросити AI написати код» і структурований SDD-процес працюють по-різному.

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

Як виглядає spec-driven development на практиці

Ви обираєте собі воркфлоу розробки. Можливо, кілька, якщо проєкти різні. Цей воркфлоу вже наповнений саб-агентами, кожен зі своєю спеціалізацією. Ми зупинились на класичному ланцюжку:

brainstorm (research) → plan writer (пропонує, як він вирішив би задачу) → plan reviewer (перевіряє план і узгоджує з вами) → developer (кодить) → reviewer (код-рев'ю) → commit → PR.

Проєкт створюється як окремий репозиторій на GitHub: під капотом Claude Code, обраний воркфлоу і дефолтні скіли, які хтось уже відточив і заклав. Таких воркфлоу на GitHub маса. Можна взяти перевірений часом і адаптувати під свої процеси. Коли ми пізніше подивились на десятки інших команд, які пройшли той самий шлях, картина повторювалась: усі основні воркфлоу сходяться до одного архітектурного патерну. Це Research, Plan, Execute, Review, Ship. Це не випадковість. Підхід уже перевірений багатьма командами, не лише нашою інтуїцією.

Ще одне, про що майже не пишуть: готовий фреймворк ми не поставили як є. За основу взяли Superpowers, але одразу побачили, що для нашого воркфлоу він роздутий. Додає кроки типу TDD, які нам не потрібні, і виносить брейншторм окремо там, де він радше заважає. Тут допомогла стаття з порівнянням 15 найпопулярніших SDD-фреймворків, яка мапить їх на трирівневу таксономію суворості. За десять хвилин читання розумієте, який фреймворк підходить саме вашому проєкту і чому інші не підходять. Беріть готове як референс, а не як інструкцію. Розбирайте, скільки там агентів, команд і скілів, і лишайте тільки те, що відповідає розміру й контексту вашої команди. Інакше замість пришвидшення отримаєте зайву витрату токенів і часу.

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

Як ми виміряли прискорення — і чесні цифри

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

Схема така. Розробник оцінює задачу так, ніби робив би її по-старому, вручну. У ворклогах фіксуємо реальний час з усіма доступними інструментами: Claude Code, CodeRabbit і так далі. Різниця між оцінкою і фактом і є метрикою прискорення.

Рефактор платіжного сервісу — задача, яку команда оцінила на місяць. Ми закрили її приблизно за півтора тижні чистого часу.

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

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

Методика поки груба, ми цього не приховуємо. Вона не враховує якість рішення, не рахує час на виправлення багів від самої AI-генерації, а оцінка «як я думав, що зробив би це вручну» суб'єктивна. Але груба метрика, яку рахуєте послідовно, краща за точну, яку так і не почали рахувати. Головне — почати міряти системно. Не покладатися на відчуття «здається, стало швидше».

Де AI реально прискорює, а де заважає

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

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

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

На великих задачах без розбиття на фази все ламається. AI починає гальмувати, контекст розмазується, модель забуває деталі, про які ви явно казали, навіть якщо в plan review усе виглядало ідеально. Чим більший скоуп, тим на дрібніші фази його треба ділити. Краще завести один загальний план з чекбоксами і рухатись точково, ніж кидати AI одну величезну задачу і сподіватись на диво.

Ще один вимір ми виявили емпірично. AI чудово працює з відомими UI-фреймворками: MUI, Radix і подібними. Він сприймає їх не як візуалку, а як текст, бо є документація і усталені патерни. З кастомним дизайном справи набагато гірші, навіть якщо дати детальний контекст: скріншоти, опис стилів, посилання на дизайн-систему. Результат усе одно часто розчаровує.

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

Розробник стає диригентом

Найсильніше враження за квартал: стало набагато швидше накидати перше рішення. Раніше дизайн і реалізація займали багато часу навіть із промтами. Коли ви самі берете задачу, агрегуєте її, розбиваєте на частини й реалізуєте окремі шматки, усе це стало помітно швидшим. Але з'явилось важливе «але». Тепер набагато більше уваги треба приділяти початковому аналізу.

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

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

Цінність зміщується від рук до голови.

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

Є й простий індикатор здоров'я процесу. Якщо команда просто «проганяє» задачі через AI без ретельного обдумування, процес деградує назад у вайб кодинг, тільки з гарною обгорткою. Здоровий SDD — це коли команда витрачає видимий, усвідомлений час саме на постановку задачі й рев'ю плану.

AI вміє переконливо помилятися

Був кейс, який навчив нас обережності. AI запропонував архітектурне рішення для асинхронної обробки, умовно «fire and forget». Обґрунтував дуже переконливо: пояснив можливу проблему з асинхронщиною, показав логіку. Ми прислухались і погодились, виглядало розумно. А потім з'ясувалось, що аналогічний механізм уже був реалізований в іншому пакеті нашої ж екосистеми, і запропоноване рішення було зайвим.

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

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

Правило в нас просте: дивитись diff. Завжди. Якщо щось незрозуміле, питати прямо: навіщо ти це зробив? Можна запросити summary українською, якщо не хочеться читати технічний текст англійською. Це не забирає багато часу і різко знижує ризик пропустити щось важливе.

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

Одна модель — точка відмови

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

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

Тому тримаємо паралельно два інструменти: Claude Code і Codex з новими моделями типу GPT-5.5 на високому режимі міркування. Коли один починає гальмувати, перемикаємось на інший. Технічно це виявилось простіше, ніж очікувалось. Є вбудовані механізми міграції всього SDD-сетапу (агентів, скілів, правил) з одного інструменту в інший. Синхронізація конфігурацій — окрема морока, яку треба тримати в голові. Але не блокер.

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

Manual QA отримує друге дихання

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

У нас було кілька кейсів, де загальна логіка рішення виглядала абсолютно правильною: AI зробив те, що просили, усе узгоджено. А поруч він «довиправляв» ще щось:

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

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

І ось найнеприємніше визнання. На великих задачах цей процес неможливо уявити без викатки на стейдж і повного мануального проходження руками. Деякі проблеми просто непомітні на етапі код-рев'ю чи запуску автотестів. Найбільший час зараз іде вже не на написання коду. Його AI генерує швидко. Час іде на мануальне рев'ю і мануальне тестування. Автотести теж не панацея, особливо для візуальних і поведінкових речей, які складно покрити тестом наперед: ви навіть не знали, що саме варто перевірити.

Тому «Manual QA отримує друге дихання» — фраза, яка почалась як жарт, а стала серйозним організаційним висновком. Окремих QA у нас поки немає, доки технічна команда здатна сама перевіряти, що накодили. Але при значному масштабуванні без них не обійтися. Якщо плануєте переходити з асистентів у spec-driven development, одразу закладайте презумпцію винуватості й окремий, усвідомлений фокус на мануальне тестування кросс-сервісних і корнер-кейсів.

Швидкість коду більше не наше вузьке місце. Наступне вузьке місце — швидкість генерації якісних гіпотез і аналітики: розуміння, що взагалі варто будувати. Якщо маленька команда отримує таке прискорення, залишається відкрите питання: що станеться при сотні розробників. AI зняв один бар'єр і одразу оголив наступний.