Controlled vibe coding и small diff

1. Скорость под контролем бьёт одну большую генерацию

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

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

Дальше я пишу SPEC.md (если в вашем MVP-репозитории живёт MVP_SPEC.md — это тот же frozen spec) и EVIDENCE_LOG.md (если файл называется EVIDENCE.md, не заводите второй — это тот же журнал).

Полезно смотреть на разницу не как на спор «плохо/хорошо», а как на два разных режима мышления:

Здесь важно одно психологическое переключение. В обычной жизни скорость — это реже останавливаться. Перед демо — наоборот: пауза перед правкой или коммитом экономит часы отладки. Не философия — математика усталого разработчика.

2. Sprint вырастает из controlled loop

Этот цикл вам уже знаком: план → маленькое изменение → проверка → 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 в его нормальном, приземлённом виде. Не магия и не автопилот — спокойный темп, где скорость идёт не из хаоса, а из того, что проект всё время можно показать без стыда и без «сейчас, только ещё одну мелочь быстро поправлю».