Вайб-кодинг без хаоса: как я поставил проект на рельсы

Полтора месяца назад я начал создавать платформу для онлайн-школы импровизации - часть проекта Improv Mir - почти не притрагиваясь к коду руками, в диалоге с ИИ. По-английски это называют vibe coding (вайб-кодинг - программирование, где ты описываешь намерение словами, а код пишет модель). Первые недели это похоже на полёт: за вечер выходит то, на что раньше ушла бы неделя. А потом полёт превращается в туман.

Эта статья - про управление вайб-кодинг-проектом: как я выбрался из тумана. Без теории, сразу четыре слоя - я докручивал их по очереди, когда очередная боль становилась невыносимой. Все они живут в обычных текстовых файлах. Ни одного нового сервиса, ни одной подписки. И почти без лишних трат на токены (расход модели за запрос).

Каждую неделю я разбираю, как в одиночку собираю целую платформу через вайб-кодинг: что сработало, где обжёгся, какие инструменты прикрутил. Если это ваша тема - подпишитесь на блог, чтобы не пропустить разборы.

Почему через месяц вайб-кодинга я перестал понимать, куда идёт проект?

Сначала всё прекрасно. Ты говоришь «сделай вход по magic link» (вход по одноразовой ссылке из письма) - и через десять минут он есть. Говоришь «добавь личный кабинет ученика» - есть и кабинет. Дни идут, кода всё больше, демки работают.

Проблема в том, что ИИ не помнит предыдущий разговор. Каждое новое окно (сессия диалога) - чистый лист. Я закрывал ноутбук с мыслью «завтра доделаю оплату», открывал на следующий день, и первые двадцать минут уходили на пересказ самому себе и ассистенту: что вообще происходит, что готово, что висит. Один из участников нашего мастермайнда сформулировал это точнее меня:

Помножьте это на скорость. Когда ты делаешь одну фичу в неделю, держать всё в голове легко. Когда ИИ выдаёт пять фич за вечер, голова не успевает. Через месяц я поймал себя на ощущении: педаль в пол - а куда еду, непонятно. Скорость на максимуме, а конечной точки маршрута нет.

Что значит «ИИ срезает углы» и почему это незаметно?

Вот конкретный случай. Я попросил ассистента разобрать пачку скриншотов и разложить по плану. Он бодро отчитался: прочитал, разложил, готово. Я открыл результат и написал ему ровно так:

Он не соврал. Он действительно «разложил». Просто пробежал пачкой, проставил галочки и выдал видимость работы вместо разбора. Каждый скриншот нёс продуктовый смысл, который надо вытаскивать по одному, а не штамповать.

Это и есть «срезанный угол»: технически задача закрыта, по сути - нет. И самое коварное - угол не виден в отчёте. Отчёт всегда зелёный. ИИ уверенно рапортует успех, а где он упростил, где не спросил, где сделал «на отвали» - ты узнаёшь через неделю, когда на этом фундаменте уже стоят три этажа кода.

Когда таких незаметных углов накапливается достаточно, наступает то самое чувство тумана из первого раздела. Мне стало ясно: проблема не в том, что ИИ плохой. Проблема в том, что у меня нет рельсов, по которым его пускать, и нет приборов, которые показывают, где он схитрил.

Рельсы: зачем расписывать проект по фазам (нотация BPMN)?

Где-то на пятой неделе я сел и нарисовал карту. Не «todo на сегодня», а схему всего пути платформы от пустого репозитория до боевого запуска. Нарисовал в нотации BPMN (Business Process Model and Notation - открытый стандарт для описания процессов: прямоугольники-шаги, ромбы-развилки, стрелки).

Получилось семь фаз, и порядок их неслучаен:

Ключевое тут - ромбы-ворота между фазами. Каждый ромб с веткой «нет» возвращает назад. Мимо обязательного узла не проедешь: пока не сверили понимание - не лезем в требования; пока не собрано ядро (та самая изоляция данных, деньги, безопасность) - не лезем в красивую начинку. Именно те углы, которые ИИ так любит срезать, тут стоят воротами на критическом пути.

При этом рельсы - не смирительная рубашка. Карта говорит, чего пропустить нельзя. Она не запрещает добавить то, чего на ней нет: нужен конкретному клиенту особый модуль - прицепляешь вагон по необходимости. Обязательный каркас держит от съезда в кювет, а «мясо» наращиваешь сколько надо.

Технически карта - это просто текстовый файл со схемой плюс файл со статусом каждого узла по конкретному проекту (spinup-manifest.json). На сегодня по моей онлайн-школе из примерно 49 узлов закрыто около 39. Когда я открываю новое окно, скрипт на входе печатает: вот что закрыто, вот ближайший незакрытый узел, вот какие ворота тебя держат. ИИ физически видит, где мы на рельсах, и не может сделать вид, что фундамент уже готов.

Отдел из шести ролей: как один человек дирижирует и экономит на токенах?

Вторая боль была про деньги и качество разом. Я гонял вообще всё через самую мощную модель - и архитектурные решения, и тупую правку опечаток. Это дорого и, как ни странно, хуже по качеству: мощная модель на рутине частит, а на сложном без отдельного критика пропускает дыры.

Однажды я обжёгся на этом буквально. Упёрся в недельный лимит токенов и больше суток просидел без вайб-кодинга - просто не мог продолжать, пока лимит не обновится. Сутки вынужденного простоя на ровном месте: дорогая модель сжигала токены там, где спокойно хватило бы дешёвой. После этого я и сел переразложить работу.

Решение подсмотрено в том, как устроены настоящие команды разработчиков. Я расписал «отдел» - набор ролей, у каждой своя модель и своя зона:

Принцип ровно один, и он экономит и деньги, и нервы: дешёвые роли на простые задачи, дорогое суждение - на сложные. Разведка по коду или прогон тестов не требуют гениальности - туда младшую модель. Архитектура и проверка безопасности требуют - туда старшую.

Я при этом не пишу код в главном окне. Моя роль - дирижёр: разложить задачу на куски, раздать ролям, дождаться, собрать. Звучит как лишний формализм, но именно это вернуло мне ощущение контроля: я снова вижу проект сверху, а не залипаю в одной функции.

И ещё одно правило, выстраданное на граблях: один репозиторий - одно активное пишущее окно. Параллелить можно ролями внутри одной сессии, но не пятью окнами в один и тот же код - иначе они затирают друг друга и врут в отчётах.

Дашборд почти даром: состояние в JSON, перерисовка без токенов

Карта и отдел дали порядок, но мне всё ещё хотелось видеть проект глазами, на одной странице. Соблазн был - просить ИИ каждый раз рисовать отчёт. Это ловушка: каждый такой отчёт жжёт токены и устаревает через час.

Я сделал иначе. Всё состояние - кто чем занят, какой процент готовности, какие ворота открыты - лежит в простом текстовом файле state.json. Вот как кодируется одна роль:

{
  "id": "orchestrator",
  "label": "Оркестратор",
  "mood": "ok",
  "task": "окно 28: 3 фичи на проде; MVP перешёл в валидацию",
  "load": 0.4
}

А рисует страницу отдельный маленький скрипт build-dashboard.mjs. Раз в час он читает JSON, считает зоны светофора и выдаёт готовый HTML. К модели он не обращается вообще. В подвале панели у меня так и подписано: источник - git и JSON-файл, а перерисовка идёт «ежечасно (0 токенов)».

Разделение простое и важное: ИИ трогает JSON только когда я дал ему задачу и он закрыл узел. А визуализация - чистая арифметика, её гоняет скрипт бесплатно сколько угодно раз. Состояние - источник правды, картинка - производная от него.

Критическая цепь: как понять, отстаём мы или нет (CCPM)?

К концу второго месяца, когда школа уже стояла на проде, я видел, кто чем занят. Но не видел главного: успеваем ли мы к сроку и где узкое место. Тут пригодилась теория ограничений и её метод управления проектами - CCPM (Critical Chain Project Management, управление по критической цепи), описанный Элияху Голдраттом.

Идея против интуиции. Обычно мы закладываем запас в каждую задачу - и этот запас тихо проедается на каждом шаге (работа занимает всё отведённое время). CCPM убирает запасы из задач и собирает их в один буфер на весь проект. Дальше следишь за одним числом: сколько общего буфера ты уже потратил относительно того, сколько работы пройдено.

Второй элемент - ресурс-ограничение. В моём проекте кодер по сути один (это AI-ускоренный, но один поток сборки). Значит, дорожка кодера и есть критическая цепь - всё упирается в неё. Ревьюер, тестер, безопасник работают параллельно и на цепи не лежат, кроме хвоста самых чувствительных участков работы.

Что я с этого вижу на одном экране:

• остаток критической цепи в «кодеро-днях» (сколько дней работы кодера ещё впереди);
• скорость по факту (у меня вышло около 5 кодеро-дней работы за один календарный день - вот вам реальная цена AI-ускорения);
• прогноз трёх сроков завершения: оптимист, реалист, пессимист, и крайний срок по договору;
• сколько буфера проедено.

На сегодня по школе пройдено 82% трудоёмкости, буфер не проеден, а наоборот в плюсе - заложил с запасом. Это и есть ответ на «отстаём или нет», который раньше я давал на глаз.

Два светофора на один проект: чем панель отличается от плана?

Это сбивает с толку: на двух экранах один и тот же проект, оба с диагональным светофором, а точки стоят в разных зонах. На панели - жёлтая, на плане - голубая. Как так?

Так и задумано. Это две разные системы координат одного вопроса «успеем ли»:

Поэтому зоны и не совпадают. По календарю я в жёлтой зоне - времени прошло чуть больше, чем хотелось бы на этом этапе, надо приглядывать. А по запасу работ я в голубой - заложил буфер с избытком, темп держу, рабочих дней впереди хватает. Оба верны одновременно, просто отвечают на разное: по календарю стоит чуть поднажать, а сил и рабочих дней впереди с запасом.

Пунктир на графике - это моя реальная история за последние дни. Каждая точка - один замер, примерно раз в день. Сначала я был в жёлтой зоне: пора присматриваться, проект подползал к опасной красной. Потом и правда свалился в красную - у меня была презентация проекта, и пару дней я не кодил вообще. Следом добавил в план несколько новых фич - и точка ушла в чёрную, самую тревожную зону. А затем включился в работу всерьёз, по несколько кодеро-дней за сутки, быстро нагнал отставание - и точка спустилась в спокойную голубую. Один график, и на нём виден весь этот сюжет.

Когда я это для себя развёл, ушла паника от «светофор жёлтый». Жёлтый по времени - не пожар, если по работе ты в плюсе.

Когда ИИ тормозит меня, а когда я торможу ИИ?

Самое интересное началось, когда система заработала в обе стороны.

Иногда торможу я. Был случай: всё прошло автоматические ворота - проверку типов, тесты, сборку, даже ревью. Зелёным-зелено. А отдельный проход безопасника нашёл дыру: роли по ошибке выдали лишние права, и через неё открывался прямой доступ к десяткам действий с заказами и оплатами. В рабочем журнале я отметил это коротко: безопасник поймал то, что пропустили все зелёные ворота и даже ревью.

Мораль: для всего, что трогает вход, роли и деньги, отдельный безопасник обязателен. Зелёные ворота его не заменяют: они проверяют, что код работает. Безопасен ли он - вопрос отдельный.

А иногда тормозит ИИ - и бывает прав, а бывает нет. В одном окне ассистент честно отговаривал меня писать блок про удаление аккаунта: мол, это «фича впрок», давай лучше займёмся проверкой гипотез. Я возразил:

И тут любопытно, откуда у ассистента взялось это «не делай лишнего впрок». Несколькими днями раньше я сам зашил ему в инструкцию принцип Андрея Карпаты о дисциплине работы с ИИ: «минимум кода, ничего на запас». Правило хорошее - и ассистент честно его применил. Только применил не туда: удаление аккаунта это не запас на будущее, а юридический минимум по закону. Он не глупил - он перестраховывался не в ту сторону. Без явного указания на карте (вот тут юридический минимум, его не пропускаем) такие споры превращаются в лотерею. С рельсами это короткий разговор по схеме: открываем карту фаз, видим обязательный узел - и спорить не о чем.

Вот ради этого всё и затевалось - ради общего языка и общей схемы, на которой видно, кто куда тянет. Управлять вайб-кодинг-проектом - это и есть держать такую схему между собой и моделью.

Минимальный набор, чтобы собрать такую систему у себя

Если хотите попробовать, вот скелет без лишнего:

1. Карта фаз. Один файл со списком обязательных этапов вашего проекта и воротами между ними. Не идеальная схема, а ваш реальный порядок: что нельзя пропустить. Это первый слой, с него и начните (как выглядит узел такой карты - в сворачиваемом блоке в разделе про рельсы выше).
2. Файл состояния. Простой JSON: что сделано, что в работе, какой процент. Его обновляет ИИ, когда закрывает кусок.
3. Скрипт-визуализатор. Маленький скрипт, который читает состояние и рисует HTML. Гоняется по расписанию, к модели не обращается - значит, бесплатно (функция расчёта зоны - в блоке про дашборд выше, она вся такая).
4. Правила для ИИ. В постоянной инструкции агента пропишите дисциплину дирижёра.

Вот реальный кусок такой инструкции - можно дословно положить в файл своему ассистенту:

Ты - оркестратор, а не кодер. Не пиши код в главном окне.
Любую задачу: (1) сверь с картой фаз - какой узел закрываем и какие ворота держат;
(2) раздели на куски и делегируй ролям (дорогое суждение - старшей модели, рутину - младшей);
(3) для всего, что трогает вход/роли/деньги - отдельный проход безопасника;
(4) перед "готово" - прогони ворота (проверка типов + тесты), не рапортуй успех на сломанном.
Закрыл узел - обнови файл состояния.

Светофор по критической цепи я бы добавлял последним, когда первые три слоя уже прижились. Он самый методически тяжёлый и без привычки к буферам выглядит абстрактно.

Что это дало и где границы метода

Что изменилось по факту. Я перестал терять контекст между окнами - карта и файл состояния держат его за меня. Срезанные углы стали видны: ворота и отдельный безопасник ловят то, что раньше всплывало через неделю. И я наконец знаю, успеваю ли: буфер показывает это числом, без гадания на глаз.

Честная оговорка, без неё нельзя. Всё описанное заточено под мой случай: один человек, который дирижирует ИИ. Критическая цепь у меня сходится в одну дорожку именно потому, что поток сборки один. Как только у вас живая команда из нескольких разработчиков, ресурсов-ограничений становится больше, и буфер считается сложнее - база та же, арифметика другая. И сами рельсы - не догма: это моя карта моих платформ, у вас фазы будут свои.

А что дальше: куда меня это привело

Когда один проект наконец под контролем, руки сами тянутся к следующей идее, потом к третьей. И тут меня накрыло то, чего я раньше за собой не замечал: начинаешь вести несколько проектов одновременно, распыляешься, и становится сложно управлять приоритетами и собственным временем. Та же логика критической цепи показала, где теперь узкое место. Уже не ИИ - токены докупаются, модель параллелится. Узкое место - я сам, мои рабочие часы. Это единственное, чего не докупишь.

Два честных ограничителя на каждую идею - деньги и срок, заданные заранее: чтобы идея либо подтвердилась в этих рамках, либо была спокойно закрыта, а не висела годами недоделанной. Так я и перешёл от управления одним проектом к управлению собственным временем между проектами.

Из этого выросла моя следующая затея - фабрика MVP «Воплоти». Но это уже другая история: про портфель идей, где ограничитель не кодер, а ты сам. Про неё расскажу в следующий раз.

Кстати, та самая онлайн-школа, на которой я всё это обкатываю, - часть Improv Mir, площадки про импровизацию в России. Если любопытно посмотреть, что в итоге собирается вживую, а не на схемах: Мир Импро.