«У четвер це була ідея з розмови. У неділю — продукт на проді. Жодного рядка його коду я так і не прочитав»
У четвер ми домовились «обговорити ідею в понеділок»
У четвер, під час розмови зі своїм SEO партнером про велику кількість WordPress-сайтів та те, як складно їх менеджити одночасно, мені прийшла цікава ідея, бо сайтів там реально багато, відверто – тисячі!
А тепер уявіть операційку навколо такого господарства. У кожного сайту — свої користувачі, свої логіни, свої паролі. Редактори, адміни, підрядники. І все це живе в Google-таблицях: посилання на сайт, логін, пароль, кому дали, кому наче дали. Хтось звільнився пів року тому — а рядок у таблиці лишився. І доступ, власне, теж. До речі, ця проблема спостерігається і в звичайних клієнтів з невеликою кількістю сайтів, або зовсім з одним, але це вже історія для іншого лонгриду…
Доступи губляться. Їх нема в тих, у кого вони мають бути. Зате вони є в тих, у кого їх не має бути вже давно. А кожен із тисяч сайтів ще й світить в інтернет відкритим wp-login.php — улюбленими дверима для підбору паролів.
Я запропонував рішення: єдина “цифрова прохідна” для всього флоту сайтів, одна надзахищена адмінка, через яку заходять усі — а вона вже вирішує, кого й куди пускати. Партнеру ідея сподобалась, і ми домовились про дзвінок у понеділок — обговорити деталі, скоуп та терміни.
І ось тут я вирішив зробити інакше. Не готувати презентацію, не малювати естімейти. А прийти на понеділковий дзвінок із готовим продуктом на проді. Так, реальна CRM-ка за такий короткий термін!
Між четвергом та понеділком — рівно чотири дні, а проєкт уже на проді. Як — коротка відповідь: спочатку план, потім код, і агенти, які цей план виконують. Довга відповідь — це і є ця стаття. І в ній доведеться розібрати методологію з хайповою назвою Spec-Driven Development.
Цифрова прохідна для кількох тисяч сайтів
Назву проєкту я видумав на ходу: WP Guard. Це вебдодаток, який працює як прохідна величезного заводу з різними рівнями допусків та необхідністю їх час від часу продовжувати: людина логіниться не у WordPress, а у WP Guard з захистом від Cloudflare Turnstile, звісно ж паролем, та двофакторкою (2FA) у вигляді смс, гугл аутентифікатора, passkey (тач айді або фейс айді). Далі все просто: обрати сайт, клікнути на вхід — і ти миттєво опиняєшся в вордпрес адмінці потрібного сайту. Без пароля WordPress, без проміжного wp-login.php, а через захищений SSO-канал, з роллю, яку тобі призначили саме на цьому сайті.
Сам wp-login.php на підключених сайтах вимикається взагалі. Точка входу одна – WpGuard.
Механіка дуже проста: на кожен сайт ставиться плагін-конектор, який створює захищений канал, heartbeat, синхронізація користувачів і ролей. Ролі тут — атрибут звʼязки «людина ↔ конкретний сайт»: та сама людина може бути Адміністратором на одному сайті й Редактором на іншому. А в єдиному журналі видно все: хто зайшов, коли, звідки, скільки було невдалих спроб і на якому сайті.
Рівень захисту я свідомо закладав не «як у блога», а як у систем, де ціна помилки реальна: обовʼязкові passkeys для адмінів, повторна верифікація на критичні дії, автоблокування за серію невдалих авторизацій, гео-обмеження, алерти на аномалії — нова країна, новий пристрій, тощо. І kill-switch: одна дія — і всі сесії відкликано, всі канали до сайтів зірвано. Модель загроз я збирав із ресерчу та власного досвіду захищених WordPress-проєктів — про один такий кейс я вже писав у розборі зламу, що вартий тисячі порад. Плюс дивився, як влаштований захист там, де він справді працює: в українському банкінгу та «Дії».
Масштаб — чесно: на старті партнер підключить кілька сотень сайтів. Сподобається — підключить решту. Система до цього вже повністю готова.
Умова експерименту: Node.js, у якому я поки студент =3
Тепер найцікавіше. Понад 18 років мій профіль — PHP та WordPress: від кастомізації ядра до цілих платформ. JavaScript зі мною теж давно — але виключно в контексті фронтенду. Бекенд на Node.js я ніколи раніше не використовував.
І саме тому WP Guard написаний на Node.js.
Причин дві. Перша — прагматична: мені був потрібен легковісний рушій і живий канал звʼязку з сайтами в реальному часі. Вебсокети в Node працюють з коробки; на PHP це окремий квест. Друга причина — справжня: мені було цікаво зайти саме туди, де в мене пробіл. Пробіли в знаннях це нормально, як колись хтось сказав: “Вік живи – Вік учись!“.
Тож умови експерименту вийшли жорсткі: маловідома технологія, реальний продукт із банківськими вимогами до безпеки, дедлайн у чотири дні, соло. Інструмент один — Claude Code. І головне питання: що саме дозволяє в таких умовах не потонути?
Спойлер: не швидкість генерації коду.
Що таке Spec-Driven Development?
Вайб-кодинг — це коли ти описуєш агенту бажане своїми словами, тиснеш Enter і дивишся, що вийде. Для прототипу за вечір — чудово. Але на реальному продукті вайб-кодинг має стелю, і бʼєшся об неї тільки ти:
- Ти не проговорюєш очевидне. Те, що роками сидить у твоїй голові, здається очевидним для всіх — а агент цього не знає і додумує за тебе. Іноді красиво, але частіше — ні.
- Немає критерію готовності. Агент не знає, коли задача завершена, бо ніхто не сформулював, що таке «готово».
- Рішення живуть у чаті. Чому обрали цю архітектуру? Чому саме так? Через тиждень цього не памʼятаєш ні ти, ні тим більше нова сесія агента.
- Контекст протухає. У моделей є контекстне вікно «на папері» і вікно, яким реально можна користуватись, — і це дуже різні числа. Що довша сесія, то гірше агент памʼятає, з чого все починалось: в Anthropic цей ефект описують як context rot. Симптоми ви бачили: агент, який пів години тому був генієм, раптом починає «покращувати» те, чого ніхто не просив.
Spec-Driven Development розвертає процес. Спочатку — специфікація: окремий документ, у якому зафіксовано, що будуємо, для кого, що вважається результатом і чого робити не треба. Потім — план: як саме, якими кроками. Потім — задачі. І лише потім — код, який агент пише вже не з розмови, а зі спеки: короткої, щільної та без зайвої води. Кожен етап — окремий файл у репозиторії, який вичитує людина. Код стає похідною від спеки, а не навпаки.
Індустрія цю ідею вже підхопила на повний зріст: Spec Kit від GitHub — набір команд, що проводить агента через увесь ланцюжок specify → plan → tasks → implement — зібрав близько 90 тисяч зірок. Поруч виросли цілі альтернативні фреймворки і вбудовані спек-режими в AI-редакторах. До речі, якщо ви хоч раз користувались план-модом у Claude Code — вітаю: ви вже торкалися SDD у зародковій формі. Різниця лише в тому, що план живе всередині чату і вмирає разом із сесією, а спека — це файл, «висічений у камені» поруч із кодом.
Гарний україномовний розбір із живим демо Spec Kit — у цьому відео:
Мій кустарний SDD: git усе памʼятає
А тепер чесно. Класичний SDD-тулінг у цьому проєкті я не використовував. Ні Spec Kit, ні альтернатив — деталі методології я взагалі розібрав уже post factum, коли сів готувати цю статтю.
Але потім я відкрив git log власного репозиторію. Перший коміт — клікабельний прототип. Другий — «розділено документацію: README, ROADMAP, SECURITY». Третій — «зафіксовано фінальний стек». Код застосунку починається після.
Тобто дивіться, що вийшло насправді:
- README з проблемою і рішенням — написаний до продукту. У SDD це називають intent: навіщо ми взагалі це будуємо.
- ROADMAP на чотири фази з чеклістами — план, по якому агент і йшов: ядро → плагін і SSO-міст → безпека промислового рівня → масштаб.
- SECURITY з моделлю загроз — вимоги: сценарії атак і відповіді на кожен.
- Клікабельний прототип — спека інтерфейсу. Іронія: прототип я зробив на PHP — рідною мовою, — а продукт агент писав на Node. Зате агенту не треба було вгадувати, як має виглядати кожен екран: структура і поведінка, бо це все вже існувало.
- STATUS.md — вахтовий журнал. Мій головний трюк. Щоразу, коли контекстне вікно сесії добігало кінця, я казав агенту: «запиши в STATUS.md, на чому ми зупинились і що робити далі». Нова сесія починається не зі здогадок і не з переказу — агент читає журнал і продовжує з того самого місця. Прохідна — для людей, вахтовий журнал — для агентів. Все як на справжньому заводі.
Фішка в тому, що я не одразу усвідомив, що мій підхід і був фактично Spec-Driven Developmentʼом, я просто не знав, що в цього процесу вже є назва, фреймворки і 90 тисяч зірок на GitHub. Це, до речі, найкращий доказ, що методологія не висмоктана з пальця: якщо різні люди незалежно доходять до одного й того ж — значить, воно варте для таких широких обговорень, як десятки відео на ютубі і навіть ось ця стаття.
Цифри експерименту
Люблю, коли підсумки можна помацати:
- 4 дні — від розмови в четвер до продукту на проді в неділю;
- 140+ комітів — на момент написання цієї статті;
- 0 рядків коду написано і прочитано мною. Взагалі. У цьому й був експеримент: я перевіряв поведінку продукту і вичитував документацію, а не диффи чи баги;
- 5 npm-залежностей — увесь бекенд. Passkeys працюють без жодної сторонньої бібліотеки, на вбудованому
node:crypto; - 3 фази роадмапу з чотирьох — уже на проді: від 2FA і passkeys до kill-switch і алертів на аномалії;
- 1 підписка Claude Code Max за $200 баксів на місяць — і за чотири дні я жодного разу не вперся ні в пʼятигодинні, ні в тижневі ліміти. Свіжий Opus 5, Opus 4.8 у швидкому режимі та іноді Fable 5 + паралельні агенти в режимі ультракоду — лімітів вистачило на все!
Це не перший мій швидкий продукт — SaaS з AI я колись збирав за 37 днів. Але тоді між ідеєю і результатом стояли тижні. Тепер — дні. І змінилась не модель. Змінився процес.
Чесно про обмеження
Тепер ложка дьогтю — куди ж без неї.
«Не читав код» — це експеримент, а не рекомендація. Я свідомо перевіряв межу: чи можна довіритись процесу повністю. Замість читання коду в мене були інші запобіжники: перевірка поведінки руками на кожному чекпоінті, вичитка документації, агентні ревʼю — зокрема адверсаріальні, коли окремі агенти прицільно шукають дірки в безпеці. Але якщо ваш проєкт — не експеримент, читайте хоча б критичні місця. Відповідальність за прод усе одно ваша, а не агента.
SDD — не для всього. На дрібній правці в пару файлів спека — це бюрократія заради бюрократії. Методологія окуповується там, де задача не влазить в одну сесію агента. Чим гірше влазить — тим більше окуповується.
Спеки застарівають. Тримати актуальною варто лише ту, з якою працюєш зараз; решта — в архів. Спека тримісячної давнини має викликати посмішку, а не бути джерелом істини.
Є ризик перегратися в бюрократію. Якщо виписувати всі задачі наперед до останньої коми — вийде старий добрий waterfall, тільки з агентами. Рятують короткі ітерації: фаза за фазою, з живим продуктом наприкінці кожної.
І ще одне, зовсім чесне: я після цих чотирьох днів не став Node.js-сеньйором і не вдаю його. Але експеримент довів інше — вузьке місце розробки тепер не в синтаксисі. Воно в ясності задуму.
Наступний проєкт: уже за правилами
WP Guard я будував кустарним SDD — на інтуїції та вахтовому журналі. Наступний проєкт я вже веду за методологією повністю: спека до першого рядка коду, явні non-goals, окремі сесії для плану і виконання, канонічний тулінг.
Що це за проєкт — поки не скажу. Хай буде інтрига: про нього буде окрема стаття, і, здається, вона вийде ще цікавішою за цю.
Підсумок
Агент і торік писав код швидше за мене. Але продукт за чотири дні зʼявився не тому, що моделі стали швидшими. А тому, що я перестав розповідати агенту, що робити, — і почав давати йому план, за яким він працює сам. Спека — це не бюрократія. Це спосіб один раз подумати так, щоб далі можна було не смикатись.
Завтра понеділок. У мене дзвінок із партнером — він чекає на обговорення ідеї, естімейти і терміни. А я просто відкрию шеринг екрана, покажу готовий проєкт і дам йому креденшели для використання.
А якщо у вашому бізнесі є процес, який щотижня зʼїдає години рутини — таблиці, доступи, ручні звіти, копіпаст між системами, — найімовірніше, його можна автоматизувати швидше, ніж ви звикли думати. Подивіться на мої послуги або просто напишіть мені: розберемо вашу операційку і подивимось, як її можна оптимізувати за допомогою сучасних AI-технологій.
