Полтора года назад я вайб-кодил. Вбивал промпт в Claude Code, смотрел что получилось, двигался дальше по наитию. Сейчас у меня три скилла с human gates, параллельные субагенты и task tracking. Это уже не вайб-кодинг - это агентный инжиниринг.
Вайб-кодинг работает, но не масштабируется
Andrej Karpathy в феврале 2025 ввёл термин “vibe coding”. Говоришь модели что хочешь, получаешь код, запускаешь. Не работает - уточняешь промпт. Работает - двигаешься дальше.
AI-код генерирует в 1.7 раза больше дефектов, чем код написанный человеком (исследование CodeRabbit, декабрь 2025). Разработчики тратят 66% времени на отладку “почти правильных” решений от AI. Три месяца работы на чистом вайбе в ugaday-melodiu - и я застрял. Запросил анимацию баллов, получил код. Через час добавил интеграцию с бэкендом - анимация сломалась. Контекст уплыл.
Will Ness описал три режима отказа дефолтного Claude Code: context drift (контекст уходит в сторону), no review step (нет момента проверки), lost work (потеря сделанного). У меня были все три. Я просил Claude сделать анимацию баллов, получал что-то рабочее, через час добавлял интеграцию с бэкендом - и анимация ломалась.
Прототипы - да, продакшн - катастрофа. Это проявляется на третьем месяце работы, когда проект становится сложнее.
Мой ответ: три скилла вместо одного большого промпта
После пяти проектов я нашёл плагин superpowers для Claude Code с тремя скиллами: brainstorming, writing-plans, subagent-driven-development. Скиллы в Claude Code - это переиспользуемые инструкции в файлах SKILL.md. У них YAML frontmatter с метаданными, дальше markdown с контентом. Хранятся глобально в ~/.claude/skills/ или локально в проекте в .claude/skills/.
Три этапа вместо “один промпт на всё”.
В популярных подходах есть паттерн: задавать по одному вопросу за раз → генерация todo.md → выполнение один за одним. Ashley Ha добавляет этап валидации в конце: Research → Plan → Implement → Validate. Человек решает, из каких компонентов состоит UI. AI пишет код компонентов.
Первый проект ugaday-melodiu был хаосом. Второй (web-lk) уже получил зачатки планирования, но всё ещё неструктурированный. youtube-me я делал с PRD и TDD. excalidecks - 185 сессий с одним и тем же процессом, одинаковым результатом каждый раз.
Этап 1: Brainstorm - развернуть идею
Вместо “сделай мне UI красивый” я задаю вопросы вместе с Claude Code. Один вопрос за раз.
Популярный промпт: “Ask me one question at a time so we can develop a thorough, step-by-step spec for this idea. Each question should build on my previous answers.” Claude спрашивает, я отвечаю, он уточняет детали, я уточняю ещё. Через десять вопросов у меня детальный spec.
Когда я brainstormил анимацию баллов в ugaday-melodiu, вопросы были конкретные: какая физика движения? bounce или smooth scale? триггер - клик или автоматически после ответа? длительность - 300ms или 500ms? Мы с Claude тестировали три подхода: flip (переворот карточки), scale (увеличение числа), bounce (прыжок). Я выбрал bounce. Только после этого пошёл дальше.
Brainstorm Jira-задач в web-lk выглядел иначе. Что значит “задача готова”? Код написан - понятно. Тесты пройдены - понятно. А что с документацией? С review? С деплоем в staging? Мы с Claude прописали три подхода к DoD для двух разных задач, выбрали самый подробный. Только после этого начали планировать.
Вкладываешь полчаса в spec, экономишь три часа на фиксах.
Этап 2: Plan - организовать работу в задачи
От детального spec к чеклисту. Конкретные задачи. Независимые. Параллельные, если возможно.
Скилл writing-plans берёт spec и выдаёт структурированный план. Иногда это markdown список с чекбоксами. Иногда TaskCreate в Claude Code с зависимостями между задачами. План парсится, отслеживается, можно выполнять параллельно, если нет shared state.
После brainstorm анимации в youtube-me у меня было: PRD → TDD (test-driven design) → Design System → Brainstorm per task → Implementation. PRD дал общий spec. TDD - набор тестов, которые должны пройти. Design System собрал визуальные компоненты. Каждую задачу brainstormил отдельно.
Когда я закончил brainstorm анимации в ugaday-melodiu, у меня вышло 11 задач. Три на анимацию (bounce effect, timing, cleanup). Четыре на интеграцию с бэкендом (API calls, error handling, state sync, loading states). Две на тесты (unit, integration). Две на UI polish (responsive, accessibility). Я распределил их для параллельного выполнения субагентами - но об этом дальше.
Здесь происходит approval от человека. Human gate. Я смотрю на план и решаю: всё учёл или надо переделать? Если что-то не так - возвращаюсь на этап brainstorm, уточняю spec, генерирую план заново. Полное состояние сохраняется автоматически - можно прервать работу и вернуться к ней на любом этапе.
Этап 3: Execute - запустить работу параллельно
Скилл subagent-driven-development. Параллельное выполнение независимых задач. Четыре агента, если нет shared state и чёткие file boundaries.
У каждого субагента чёткая scope. Первый агент работает над анимацией в components/ScoreAnimation.tsx. Второй - над интеграцией API в services/scoreService.ts. Третий - над тестами в __tests__/score.test.ts. Четвёртый - над accessibility в utils/a11y.ts. Никто не мешает друг другу.
Cuong Tham экспериментировал с 4 параллельными агентами для разных частей codebase. Главное условие - нет конфликтов по файлам. Если два агента лезут в один файл - параллельность ломается, merge conflicts, потеря работы.
Контроль через commits. Каждая завершённая задача - отдельный commit. Если агент закончил анимацию - commit “Add bounce animation to score display”. Если закончил API integration - commit “Integrate score service with backend”. Если что-то пошло не так - revert конкретного commit, не всей работы.
Три субагента параллельно в ugaday-melodiu. Первый делал анимацию и UI polish. Второй - интеграцию с бэкендом и error handling. Третий - тесты и accessibility. Через 40 минут у меня было три ветки, я смёрджил их в одну, сделал финальный commit. Без параллельности это заняло бы два часа последовательной работы.
Если во время execution выяснилось, что spec был неполный - возвращаюсь на brainstorm, дополняю, переписываю план, запускаю execution заново. Human gates позволяют контролировать процесс, а не слепо доверять AI.
Скиллы работают одинаково каждый раз
Когда у тебя скиллы, gates, субагенты, task tracking - ты инженеришь агентов, а не вайбишь.
Вайб-кодинг - это “скажи AI что хочешь, надейся на лучшее”. Скиллы работают одинаково каждый раз, потому что процесс описан в SKILL.md, а не в твоей голове. Вайб зависит от настроения промпта. Процесс зависит от структуры. Воспроизводимость отличает агентный инжиниринг от вайб-кодинга.
В прошлой статье я писал про PRD как первый шаг вайб-кодинга. PRD - это brainstorm на продуктовом уровне. Какую проблему решаем? Для кого делаем? Какая ключевая фича? Без PRD нет фундамента. Но PRD - это только начало. Дальше идут три этапа: brainstorm деталей, plan выполнения, execute параллельно.
У меня 185 сессий в excalidecks. Один и тот же процесс. Предсказуемый результат каждый раз. Новая фича? Brainstorm → Plan → Execute. Рефакторинг? Brainstorm → Plan → Execute. Фикс бага? Тот же цикл. Это не вайб. Это инжиниринг.
Попробуй на одной задаче. Создай свой первый SKILL.md. Опиши в нём brainstorm step: какие вопросы задавать, какой format spec ожидаешь. Используй его в следующем проекте. Потом добавь скилл для планирования. Потом для execution. Через пять проектов ты почувствуешь разницу - ты больше не вайбишь. Ты инженеришь.