Вайбкодинг на автопилоте: как я выстроил процесс управления ИИ-разработкой
slug: vibe-coding-autopilot
tags: AI, разработка, процесс, Claude, автоматизация
product_ids: aihub
Блок 1 — Боль
Вайбкодинг — это кайф. Говоришь AI что сделать, он делает, ты деплоишь.
Быстро, легко, почти магия.
А потом проходит неделя.
«Где тот фикс который я делал в понедельник?» — ищешь в истории чата. «Почему
это работает именно так?» — не помнишь, решение было в прошлой сессии. «Что я
вообще менял три дня назад?» — смотришь в git log и видишь двадцать коммитов с
сообщением "fix".
AI написал код. Но контекст — где ты был, почему принял именно это решение,
что рассматривал и отверг — остался в голове. Или не остался.
Через месяц активной вайбкодинг-сессии у тебя сотни изменений, ноль
документации и ощущение что проект знаешь только ты — и то не весь.
Блок 2 — Усиление боли
Открываешь новую сессию и первые десять минут объясняешь AI кто ты и что у тебя за проект. Потом делаешь задачу. Потом закрываешь. Завтра — снова те же десять минут. Это не баг, это дизайн: AI не помнит ничего между сессиями.
Умножь на 10 сессий в неделю — и у тебя уже полтора часа в неделю только на «здравствуй, вот мой проект».
Или вот другая история. Ты три недели назад выбрал подход А вместо Б. Хорошо подумал, взвесил, решил. Сегодня в новой задаче AI предлагает Б — потому что решение осталось в голове, нигде не записано. Ты либо вспоминаешь и объясняешь, либо идёшь по Б и потом удивляешься почему что-то не так.
Или: задеплоил в пятницу, в понедельник что-то сломалось на соседнем экране. Открываешь git log — 30 коммитов за неделю, все с сообщениями «fix» и «update». Ищешь где именно сломалось. Без задач — это детектив. С задачами — открыл отчёт, прочитал за минуту.
Вайбкодинг без процесса — это когда скорость разработки растёт, а скорость понимания «что происходит» падает. В какой-то момент они расходятся настолько, что начинаешь бояться трогать работающее.
Блок 3 — Решение: воркфлоу как цепочка скиллов
Решение простое в идее и неочевидное в реализации: сделать каждый шаг работы с AI отдельным протоколом с явным артефактом на выходе.
Не «напиши мне фичу». А: сначала зарегистрируй задачу, потом разберись в ландшафте, потом найди что уже есть, потом составь план, потом выполни блок за блоком, потом задеплой и зафикси результат.
Каждый шаг — это скилл. Скилл — это инструкция для AI, которую он выполняет точно, а не импровизирует. Ты апрувнул — AI сделал — артефакт записан. Следующий шаг.
Это меняет суть взаимодействия. AI перестаёт быть непредсказуемым соавтором — он становится дисциплинированным исполнителем с памятью. Каждая задача оставляет след: что делали, зачем, какое решение выбрали, что получилось.
Через месяц у тебя не «сотни коммитов». У тебя реестр задач, отчёты по каждой, и AI который в новой сессии за 30 секунд восстанавливает контекст — потому что всё уже записано.
Блок 4 — /go-start: сессия начинается не с объяснений
Обычно сессия с AI начинается так: «Привет, я разрабатываю продукт X, вот архитектура, вот стек, вот что уже сделано...». Пять минут каждый раз.
/go-start делает это автоматически. Скилл читает пять платформенных файлов: README, WORKFLOW, DEPLOY, PLATFORM_KNOWLEDGE и список проектов. Потом ты выбираешь проект — он читает CLAUDE.md этого проекта с правилами стека и push-политикой. Всё это без твоих вопросов.
Дальше — проверка git-локов. Фоновые команды от прошлых сессий иногда зависают и держат .git/index.lock часами, блокируя репо. /go-start сканирует все 14 активных проектов, убивает зависшие процессы и чистит стейл-локи. Молча, в фоне.
Третья фаза — восстановление. Если сессия прервалась на середине задачи, вставляешь кусок терминала в чат. Скилл находит задачу в базе по slug, показывает статус каждого блока (✅ готово / 🔄 в работе / ⏳ не начато) и читает последний report.md. AI знает точно где остановился.
Вместо «объясни мне проект» — /go-start, и через 30 секунд можно работать.
📄 Артефактов не создаёт — это загрузчик контекста, не исполнитель.
Блок 5 — /go-fast + idea-first: задача начинается с регистрации
Самая частая ошибка вайбкодинга — начать делать до того как понял что делаешь.
/go-fast — точка входа любой задачи вне очереди. Пишешь команду, описываешь задачу — и первое что происходит: создаётся task.md и запись в routing.db. Задача получает номер, slug и проект. Например: vschk-platform--344-blog-platform-launch. Это не бюрократия — это то, что позволяет найти задачу через месяц за 10 секунд.
После регистрации запускается idea-first. Это короткий протокол — 5-7 вопросов за 5 минут — который определяет тип задачи до начала работы:
- Что болит, какую проблему решаем?
- Это новое или что-то уже есть?
- Кто будет пользоваться?
- Что должно получиться в конце — одной фразой?
По ответам idea-first определяет тип: новый продукт (нужен habit-loop) → новая фича (нужна декомпозиция) → фикс (нужен аудит). И автоматически маршрутизирует на следующий скилл — без твоего выбора.
Если задача оказалась однострочной правкой — idea-first это определяет и пропускает всю цепочку. Хот-фикс выполняется напрямую.
Смысл простой: пять минут на «что делаем и зачем» экономят час на «почему это не то что нужно».
📄 Создаёт: task.md — описание задачи, стек, scope; idea-first-0.1.md — тип задачи, scope, маршрут к следующему скиллу
Блок 6 — Три пути после idea-first
Когда тип задачи определён, idea-first автоматически отправляет в один из трёх скиллов. Не ты выбираешь — выбирает протокол на основе твоих ответов.
Путь 1: новый продукт → habit-first
Классика соло-разработки: построил инструмент, пользовался неделю, забросил. Это не лень — это отсутствие habit loop.
habit-first проектирует петлю привычки до того как написана первая строка кода. По методике BJ Fogg (Tiny Habits): триггер → действие → награда → повтор. Задаёт конкретные вопросы: что именно запускает тебя открыть продукт? в какой момент дня? что ты получаешь после? как встроить это в уже существующий поток жизни?
На выходе — Habit Brief: поведенческий контекст, который идёт дальше в arch-first. Технически правильный продукт который реально используется, а не технически правильный мёртвый инструмент.
📄 Создаёт: habit-first-N.R.md — habit loop brief: триггер, действие, награда, стек привычек
Путь 2: новая фича → arch-first
Для задач из 5+ блоков, которые затрагивают несколько слоёв одновременно — БД, код, скиллы, конфиги. Если просто начать писать, через три блока архитектура начнёт расползаться.
arch-first сначала декомпозирует задачу в пронумерованные блоки с явными зависимостями. Потом — research-фаза: сравнительная таблица «как сейчас vs как должно быть» по каждому слою. Каждое архитектурное решение фиксируется явно в decision-NN.md. Отчёт после каждого блока.
Реальный пример: задача cards-fk-architecture в Radar — 9 блоков, зависимости между слоями БД и скиллами обработки, 8 отчётов, один follow-up эпик. Без arch-first это бы разъехалось на третьем блоке.
📄 Создаёт: decision-NN.md — зафиксированные архитектурные решения с обоснованием; блоки задачи в task_blocks
Путь 3: баг или «что-то не так» → audit-first
Самая частая ошибка при фиксах — лечить симптом, а не причину. Вот лаг в API → патчишь конкретный эндпоинт → через неделю лаг в другом месте.
audit-first запрещает трогать код пока не составлена полная картина. Он сканирует область по 6 плоскостям: безопасность, авторизация, инъекции, целостность данных, интеграции, производительность. Результат — таблица дыр с приоритетами (HIGH / MED / LOW). Ты апрувишь таблицу — и только после этого начинается работа, по приоритетам.
Реальный пример: аудит интеграций в Ops — 8 интеграций, найдено 8 дыр, 2 критичных. Без audit-first пофиксили бы одну видимую и пропустили бы остальные семь.
📄 Создаёт: audit-doc-N.R.md — таблица дыр по 6 плоскостям с приоритетами HIGH / MED / LOW
Блок 7 — flow-first + library-first + plan-first: три шага до первой строки кода
Внутри arch-first и audit-first, перед тем как AI напишет хоть одну строку, проходит цепочка из трёх обязательных шагов. Нельзя пропустить — каждый следующий проверяет что предыдущий был выполнен.
Шаг 1: flow-first — карта ландшафта за 10 минут
Прежде чем искать готовые решения, нужно понять где именно в проекте происходит задача. AI просит назвать 2-3 зацепки: файл, таблицу, роут, сервис. Читает только их — не весь проект.
По этим зацепкам заполняется таблица 4×3: как устроено сейчас / в чём проблема / какое решение / что получится — по трём уровням: UI, БД, Интеграции. Это занимает 5-10 минут и даёт общий язык: ты видишь как AI понимает задачу, и можешь поправить до того как началась работа.
Без flow-first library-first ищет компонент для неправильного слоя.
📄 Создаёт: flow-first-N.R.md — таблица 4×3 ландшафта по уровням UI / БД / Интеграции
Шаг 2: library-first — что уже есть, что писать с нуля
После того как ландшафт ясен — AI строит таблицу переиспользования. Каждый элемент задачи: что именно делаем, откуда берём (готовая библиотека / существующий компонент / с нуля), сколько строк кода.
Принцип: максимум переиспользования, минимум нового кода. Таблица показывает это явно — ты видишь что AI собирается писать с нуля, и можешь сказать «стоп, вот же готовое».
Без апрува этой таблицы — никакого кода.
📄 Создаёт: library-first-N.R.md — таблица переиспользования: что делаем / откуда берём / сколько строк
Шаг 3: plan-first — план блоками с апрувом
Последний барьер перед исполнением. Обязателен перед любым: написанием кода, рефакторингом, миграцией БД, git-операцией. Без исключений.
AI показывает план в виде таблицы: блок — что делаем — результат — зависимости. Ты апрувишь. После этого работает блок за блоком — каждый с явным результатом, каждый с остановкой.
Ключевое: если блок пошёл не так — останавливаемся на этом блоке, не ломаем следующие. Без плана AI часто делает «ещё немного» и выходит за scope.
📄 Создаёт: plan-first-N.R.md — план блоков с зависимостями и ожидаемым результатом каждого
Блок 8 — dev-auto-first: автопилот
К этому моменту у нас есть декомпозиция на блоки от arch-first или audit-first. Дальше можно работать в двух режимах: ручном — апрувить каждый шаг лично, или автопилоте.
dev-auto-first — это автопилот.
Он берёт список блоков из базы и прогоняет каждый по цепочке: flow-first → library-first → plan-first → execute. Без остановок на «ок». Вместо того чтобы ждать твоего апрува — скилл сам читает артефакт предыдущего шага, валидирует по правилам, и если всё корректно — двигается дальше.
На практике это выглядит так: написал /go-fast добавить экспорт в CSV, arch-first декомпозировал на 4 блока, выбрал автопилот — и пошёл заниматься другим. Через 20-30 минут 4 блока выполнены, задача задеплоена, отчёт в базе.
Но у автопилота есть одно правило: при любом блокере — эскалация. Если на каком-то шаге что-то неоднозначно, зависимость не та, или артефакт не прошёл валидацию — dev-auto-first останавливается и пишет в TG dev-bot. Ждёт ответа. Не угадывает, не импровизирует.
Это принципиальное отличие от «просто скажи AI делать всё сам». Автопилот с эскалацией — это предсказуемость. Ты знаешь что без твоего ответа в Telegram он не пойдёт дальше туда где не уверен.
📄 Собственных артефактов не создаёт — оркестрирует цепочку скиллов, каждый из которых пишет свои.
Блок 9 — ship-first: задача закрывается, а не просто заканчивается
Большинство AI-задач заканчиваются так: код написан, задеплоен, чат закрыт. Через месяц этого как будто не было — ни следа, ни контекста, ни решений.
ship-first — это финальный протокол, который превращает «закончил» в «зафиксировал».
Работает в двух режимах. Per-block — после каждого выполненного блока: пишет report-N.M.md (что сделано, что было нетривиального), деплоит изменения, прогоняет smoke test на проде, помечает блок как done в базе, и сразу передаёт управление на следующий блок через flow-first.
Task-level — когда все блоки закрыты: собирает финальный user-note.md по всей задаче (человекочитаемый итог — что изменилось, почему, что решили), обновляет routing.db, записывает строку в sessions.md, обновляет STATUS.md проекта.
Почему это важно. Через три месяца ты или другой агент откроет эту задачу и увидит: что было сделано, какие решения приняты, какой коммит, прошёл ли smoke test. Не «смотри в git log» — а конкретный человекочитаемый отчёт с контекстом.
Это и есть разница между вайбкодингом и процессом: задача оставляет след.
📄 Создаёт: report-N.M.md — что сделано в блоке, что было нетривиального; user-note-N.M.md — заметка для человека; user-note.md — финальный итог всей задачи
Блок 10 — Реальные цифры: одна неделя, шесть продуктов, ноль менеджеров
Вот что произошло за семь дней — с 26 мая по 1 июня 2026:
38 задач зарегистрировано в системе. Не «написал код» — именно зарегистрировано: с номером, slug'ом, проектом и артефактами на каждом шаге.
249 блоков выполнено и закрыто. Каждый с отчётом, каждый с коммитом.
903 артефакта создано цепочкой скиллов автоматически: flow-first таблицы, library-first анализы, plan-first планы, отчёты, user-note, решения. 16 типов артефактов — всё что нужно чтобы восстановить контекст любой задачи.
6 продуктов параллельно: Ops, AIHub, Radar OS, VSCHK Platform, Sandbox, KB OS. Один человек, без менеджера задач, без стендапов.
За всё время в системе 298 задач, из них 173 закрыто полностью.
Это не абстрактный «процесс». Это конкретные числа из routing.db прямо сейчас — пока писалась эта статья, система продолжала работать.
Блок 11 — С чего начать
Всё описанное в статье доступно на aihub.vschk.online.
Скиллы можно подключить к своему Claude Code и начать с самого простого: /go-start при следующем открытии терминала. Один запуск — и сессия начинается не с объяснений, а с работы.
Дальше — по задачам. Первая задача через /go-fast: любая конкретная правка или фича. Посмотреть как регистрируется, как idea-first задаёт вопросы, как выглядит план и отчёт. Этого достаточно чтобы почувствовать разницу.
Полная цепочка появляется естественно: как только задачи начинают накапливаться, становится очевидно зачем нужна каждая следующая часть протокола.
Все скиллы из статьи собраны в одном паке — с чистой схемой routing.db и инструкцией по подключению.
Приложение — Все артефакты системы
Каждый скилл создаёт файлы-артефакты и регистрирует их в routing.db. Вот полная карта:
| Скилл | Артефакт | Что внутри |
|---|---|---|
| go-fast | task.md |
Описание задачи, проект, стек, scope |
| idea-first | idea-first-0.1.md |
Тип задачи, scope, маршрут к следующему скиллу |
| habit-first | habit-first-N.R.md |
Habit loop brief: триггер → действие → награда → стек |
| arch-first | decision-NN.md |
Архитектурное решение с обоснованием |
| audit-first | audit-doc-N.R.md |
Таблица дыр по 6 плоскостям с приоритетами |
| flow-first | flow-first-N.R.md |
Таблица 4×3: ландшафт по уровням UI / БД / Интеграции |
| library-first | library-first-N.R.md |
Что делаем / откуда берём / сколько строк кода |
| plan-first | plan-first-N.R.md |
План блоков: блок → результат → зависимости |
| ship-first | report-N.M.md |
Что сделано в блоке, коммит, smoke test |
| ship-first | user-note-N.M.md |
Человекочитаемая заметка по блоку |
| ship-first | user-note.md |
Финальный итог всей задачи |
Приложение — Схема routing.db
Три таблицы. Всё остальное — производное.
artifacts — реестр задач
id TEXT PK — vschk-platform--344-blog-launch
type TEXT — fast-track / brief / tz / epic
project TEXT — radar-os / aihub / ...
title TEXT — название задачи
status TEXT — open / done
number INTEGER — порядковый номер (344)
arch_ref TEXT — привязка к архитектурному элементу
task_blocks — блоки внутри задачи
task_id TEXT → artifacts.id
block_num TEXT — 1, 2, 7.1, 10.2 ...
title TEXT — что делаем в блоке
status TEXT — pending / open / done
commit_hash TEXT — хеш коммита при закрытии
task_artifacts — артефакты скиллов
task_id TEXT → artifacts.id
block_num TEXT — к какому блоку
artifact_type TEXT — flow-first / library-first / report / ...
file_name TEXT — flow-first-1.1.md
file_path TEXT — полный путь к файлу
Комментарии