Controlled vibe coding і small diff

1. Швидкість під контролем перемагає одну велику генерацію

Коли проєкт наближається до демо, майже у кожного зʼявляється небезпечна спокуса схитрувати: «Попрошу Claude Code зібрати все разом, а потім швиденько поправлю». Бадьорість тримається до diff на 700 рядків із зайвою логікою, випадковим рефакторингом і однією милою дрібницею, що ламає головний сценарій показу. Слово «швиденько» першим залишає чат.

Тут важливо розуміти: під controlled vibe coding ми розуміємо не відмову від швидкості, а інше її джерело. Я прискорюю кожен крок знайомого циклу: задача, маленький зріз, план, правка, перевірка, коміт, запис у EVIDENCE_LOG.md. Каркас не відкидається — він стає настільки ритмічним, що пришвидшує роботу замість хаосу.

Далі я пишу SPEC.md (якщо у вашому MVP-репозиторії живе MVP_SPEC.md — це той самий заморожений spec) і EVIDENCE_LOG.md (якщо файл називається EVIDENCE.md, не заводьте другий — це той самий журнал).

Корисно дивитися на різницю не як на суперечку «погано/добре», а як на два різні режими мислення:

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

2. Sprint виростає з керованого циклу

Цей цикл вам уже знайомий: план → маленька зміна → перевірка → diff → рішення → commit. Sprint не вигадує новий workflow — він робить той самий цикл суворішим, а кроки коротшими: ціна помилки перед демо вища, тому крок стискається сильніше.

У sprint-режимі змінюються не самі цеглинки, а їхній розмір і дисципліна: задачі дрібніші, plan-first обовʼязковий, evidence пишеться у процесі, core flow весь час робочий. Ви й далі будуєте дім — просто тепер у вас дедлайн, і складати цеглини посеред дверей уже не можна.

Ось зручна схема цього режиму:

flowchart TD
    A["Заморожений spec
SPEC.md"] --> B["Обрати один маленький зріз"]
    B --> C["Спочатку план"]
    C --> D["Правка лише в потрібному scope"]
    D --> E["Прочитати diff"]
    E --> F["Запустити smoke / tests"]
    F --> G["Commit одного логічного кроку"]
    G --> H["Короткий запис у EVIDENCE_LOG.md"]

А ось практична різниця між звичайним режимом і sprint:

Це означає, що sprint — не режим без гальм. Це режим, де гальма перевіряють частіше. І, як не дивно, саме так ви їдете швидше.

3. Scope freeze: швидкість починається зі слова «ні»

Scope freeze звучить майже сумно, але саме він перетворює sprint із нескінченного discovery на доставку результату. Поки ви обговорюєте, що б іще додати, ви не прискорюєте проєкт — ви швидко відʼїжджаєте від обраного slice. Core flow обраний і не розширюється без дуже серйозної причини. Нові ідеї йдуть у parking lot — LATER.md, секція LATER у spec або блок у нотатках. Важлива не назва файла, а ритуал: ідея не зникає, але й не вміщується в зріз без запиту.

На прикладі Landing Optimizer це особливо видно. Нехай SPEC.md говорить: користувач вставляє URL лендинга, обирає аудиторію, отримує короткий аналіз і список гіпотез. Ідея «а давайте підʼєднаємо справжню інтеграцію з рекламним кабінетом» — не покращення, а класичне переселення дедлайну в сусідню область галактики.

Фрагмент замороженого spec може виглядати так:

## Основний потік
Користувач вставляє URL лендинга, вказує аудиторію
і отримує 5 пріоритизованих гіпотез покращення.

## Нецілі
Немає авторизації.
Немає інтеграції з Google Ads.
Немає збереження історії в хмарі.

Зверніть увагу: добрий spec фіксує не лише що робимо, а й чого не робимо. Він захищає не від поганих ідей, а від хороших, що прийшли занадто пізно, — саме вони й ламають sprint. «Я тільки швиденько додам ще одну корисну кнопку» наприкінці проєкту — відкритий портал у світ зайвих багів.

Після freeze головна робота вже не в нових ідеях, а в тому, щоб розкласти обовʼязковий шматок на маленькі зрозумілі зрізи. До цього і переходимо нижче.

4. Plan-first: спочатку думаємо, потім правимо

На попередніх етапах курсу у вас уже зʼявилася звичка не кидати Claude Code одразу в складні зони. У sprint вона стає ще жорсткішою: необдуманий multi-file захід може знести demo path, а часу на героїчне рятування тепер помітно менше.

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

Попросити Claude Code працювати в цьому режимі можна дуже прямо. Точні назви команд і режимів залежать від версії, тому спирайтеся на актуальний /help, а сенс запиту такий:

Спочатку склади план, без правок.
Потрібно реалізувати лише крок 1 з release slice:
ввід URL і базову кнопку "Аналізувати".

Обмеження:
- не переходити до кроку 2;
- не чіпати експорт звіту;
- змінювати лише повʼязані файли форми;
- після плану перелічити файли, яких це торкнеться, і ризики.

Такий запит добрий одразу з кількох причин: він задає межі, не дає Claude «допомогти» надто широко і змушує вас перевірити, чи розумієте ви самі, чого хочете. Дуже часто план потрібен не стільки ШІ, скільки вам самим.

Корисно ще тримати в голові маленьку таблицю:

У sprint план — це не довгий документ. Це короткий спосіб не втратити пів дня на виправлення власного «ну тут усе очевидно».

5. Small diff: одиниця швидкості, читабельна очима

Одна з найкорисніших навичок на фінальному відрізку проєкту — перестати міряти прогрес розміром задачі й почати міряти його розміром diff. Не читається за хвилину-півтори — шматок надто великий, і проєкт ризикує доїхати не до захисту, а до філософської кризи.

Small diff — це не обовʼязково «мало рядків»: 15 рядків бувають небезпечними, а 50 — безпечним вертикальним зрізом. Сенс в іншому: зміна має вміщуватися в голову — ви швидко відповідаєте собі на три запитання: що змінилося, навіщо, як я це перевірив.

На прикладі Landing Optimizer великий шматок «зробити аналіз лендинга» звучить як одна задача, але для sprint це занадто розпливчасто. Набагато здоровіше розрізати так:

1. форма введення URL і аудиторії;
2. локальна валідація порожнього URL;
3. заглушка результату;
4. справжній виклик аналізу;
5. відмальовування пʼяти гіпотез;
6. окрема дрібна правка тексту і вигляду карток.

Це не бюрократія, а спосіб не відкрити одного дня git diff і не виявити, що в одному коміті змішалися форма, сервіс, картки і «до речі, я заодно поліпшив структуру папок».

Мінімальний технічний ритуал тут дуже земний:

git diff --stat                          # швидко дивимося розмір змін
npm run smoke                            # перевіряємо основний сценарій
git add app/page.tsx lib/analyze.ts      # додаємо тільки потрібні файли
git commit -m "Додав базове введення URL" # один логічний крок

Якщо ви ловите себе на думці «ну я ж усе розумію, просто поки не комічу», це якраз той момент, коли варто насторожитися. На свою памʼять у sprint сподіваються так само регулярно, як на «зараз швидко закінчу». Маленький diff і маленький commit — не обмеження, а зовнішня памʼять проєкту.

6. Demo path завжди зелений

Це, мабуть, головний нерв цієї лекції. У sprint не має бути стану «головний сценарій зламаний, але я ще допиляю і потім полагоджу». Щойно core flow червоний, ви перестаєте будувати demo-ready проєкт і починаєте жити в борг у власного дедлайну. Зазвичай із дуже неприємними відсотками.

Demo path — це найкоротший шлях, яким зовнішня людина розуміє цінність продукту. Для Landing Optimizer: вставити URL, обрати аудиторію, натиснути «Аналізувати», побачити пʼять гіпотез. Усе. Десять фільтрів, експорт у CSV і розумна інтеграція не потрібні, поки основний шлях працює стабільно.

Коли якась додаткова ідея не готова, її краще сховати, вимкнути, відкласти або чесно позначити як limitation. Недороблена другорядна фіча не така страшна, як зламаний core flow. Це просте правило, яке багато хто розуміє лише після першої невдалої репетиції демо.

Корисне щоденне запитання до себе: якби захист перенесли на сьогоднішній вечір, чи зміг би я показати основний сценарій без виправдань? Відповідь «майже» — demo path уже не зелений. Утримує його навіть простий smoke-check: відкрити локальну версію, вставити тестовий URL, переконатися, що аналіз спрацьовує. Не красиво, зате чесно. А чесні перевірки майже завжди красивіші за красиві обіцянки.

7. EVIDENCE_LOG.md ведеться у процесі, а не по памʼяті

Одна з найчастіших помилок наприкінці проєкту — вірити, що evidence спокійно відновите потім. Формально — так. Практично це перетворюється на археологію: відкриваєте коміти зі дивними повідомленнями, згадуєте, де допоміг Claude Code, і бачите, що половина «очевидної» три дні тому логіки тепер виглядає як давній напис на стіні.

Тому EVIDENCE_LOG.md краще вести як робочий щоденник маленькими порціями. Не трактат, а один короткий запис після кожного закритого зрізу: що зробили, як перевірили, де брав участь Claude Code, що залишили за людиною.

Запис може виглядати так:

## 2026-05-24 — Зріз 03
Зробив: форму URL і базову кнопку "Аналізувати".
Перевірив: ручний smoke check + лінтер.
Claude допоміг: запропонував валідацію порожнього URL і текст помилки.
Рішення людини: залишив один обовʼязковий input, без дод. налаштувань.

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

8. Один робочий день на прикладі Landing Optimizer

Щоб усе це не залишилося красивою теорією, давайте пройдемо один звичайний sprint-день на конкретному прикладі. SPEC.md заморожено: користувач вставляє URL лендинга й отримує список гіпотез. Мета на сьогодні — перший тонкий вертикальний зріз: введення URL, вибір аудиторії, кнопка запуску.

Зранку ви не відкриваєте IDE з думкою «зараз щось швидко накодуємо». Спочатку перечитуєте spec, щоб не відʼїхати вбік. Даєте Claude Code крихітну задачу: спланувати перший крок, не чіпаючи результат аналізу та експорт. Далі — знайомий цикл: план, зріз, diff, smoke-check, один коміт, запис у EVIDENCE_LOG.md. День не втрачено, навіть якщо більше нічого не встигли: core flow ближче до демо, історія чиста, проєкт не перетворився на звалище добрих намірів.

Якщо перенести це в маленький робочий шаблон, вийде приблизно так:

Ранок:
- перечитав frozen spec;
- обрав один зріз;
- запросив plan-first.

День:
- зробив лише цей зріз;
- прочитав diff;
- прогнав smoke check.

Вечір:
- один commit;
- один запис у EVIDENCE_LOG.md;
- demo path усе ще працює.

Це і є controlled vibe coding у його нормальному, приземленому вигляді. Не магія і не автопілот — спокійний темп, де швидкість іде не з хаосу, а з того, що проєкт увесь час можна показати без сорому і без «зараз, лише ще одну дрібницю швидко підправлю».