Вайбкодинг без боли — 10 правил, которые отделяют рабочий MVP от трёхчасовой ругани с AI

Вайбкодинг без боли — 10 правил, которые отделяют рабочий MVP от трёхчасовой ругани с AI

Первые 20 минут вайбкодинга — чистый кайф. Ты описываешь идею, AI генерирует код, приложение появляется на глазах. А потом начинается: кнопка стала зелёной вместо синей, фича ломает три других, и ты уже третий час объясняешь модели, почему onClick не должен удалять базу данных.

На Reddit это называют "ловушкой трёх часов" — момент, когда ты из "10x разработчика" превращаешься в менеджера, который не знает, как работает его фабрика. А на Stack Overflow 66% разработчиков признают, что AI-код — "almost right", и на доводку уходит больше времени, чем на написание с нуля.

TL;DR: 10 правил, которые превращают хаотичный вайбкодинг в предсказуемый процесс. Конкретные промпты, рабочие workflow и ловушки, о которых не пишут в туториалах. Главное правило: не давай AI кодить, пока не утвердишь план.

Правило 1: Сначала спека, потом код

Самая частая ошибка — кинуть AI фразу "сделай мне таск-трекер" и ждать чуда. Без чёткого ТЗ модель будет угадывать — и угадает неправильно.

Что делать: перед первым промптом написать мини-PRD. Не на 20 страниц — достаточно описать, что строишь, для кого, и какие фичи нужны в первой версии.

Промпт для старта:

Я строю [описание приложения]. Целевая аудитория — [кто].
Ключевые фичи первой версии:
- [фича 1]
- [фича 2]
- [фича 3]

Стек: [Next.js / Supabase / Tailwind / etc.]

Перед написанием кода составь архитектуру: схему базы данных,
структуру страниц и ключевые API-роуты. Я хочу сначала
проверить архитектуру.

Этот подход Peter Yang называет "vibe PMing" — ты управляешь продуктом, а не пишешь код. После 50+ часов вайбкодинга он пришёл к выводу: README с требованиями, стеком и 3-5 milestone'ами — минимальный набор, без которого проект обречён на "ловушку трёх часов".

Правило 2: Запрети AI кодить

Парадокс: лучший способ получить хороший код от AI — запретить ему кодить. Сначала.

Расскажи план, что собираешься делать. Не пиши код.

По опыту Peter Yang, в 90% случаев AI предложит избыточно сложное решение. Когда видишь план — можно попросить упростить:

Дай несколько вариантов, начиная с самого простого. Не пиши код.

Ещё один мощный промпт:

Думай сколько нужно. Если чего-то не понимаешь — задай мне вопросы.

Это заставляет модель остановиться и подумать, вместо того чтобы генерировать 500 строк в неизвестном направлении.

Правило 3: Один промпт — одна задача

Большой промпт = большие проблемы. Модель пытается сделать всё сразу, запутывается и ломает то, что уже работало. На Reddit это называют "One Last Fix" Trap — каждый следующий фикс рождает два новых бага.

Рабочий подход — vertical slices: одна фича от базы данных до UI за один заход.

Вместо:

Сделай систему авторизации с OAuth, dashboard с графиками,
управление пользователями и настройки профиля.

Делай по шагу:

Шаг 1: Настрой авторизацию — email + Google OAuth через Supabase.
Больше ничего не трогай.

Потом:

Шаг 2: Создай страницу dashboard. Пока пустую, с layout и навигацией.

Каждый шаг тестируешь, коммитишь, и только потом идёшь дальше.

Правило 4: Тестируй после каждого изменения

Не "после каждой фичи". После каждого изменения. Открыл localhost, проверил, работает — двигаешься дальше. Сломалось — откатываешь сразу, пока помнишь, что поменялось.

Что проверять:

• Браузерная консоль — Cmd+Option+J на Mac, Ctrl+Shift+J на Windows
• Работают ли старые фичи (регрессия — главный убийца вайбкодинг-проектов)
• Правильно ли подключены данные (по данным Softr, AI часто хардкодит данные во фронтенд вместо реального подключения к базе)

Промпт для проверки:

Найди в проекте дублирующийся код и захардкоженные данные.
Выведи список, не исправляй.

Правило 5: Git — твоя страховка, а не опция

Checkpoint'ы в Cursor — это хорошо, но git — это страховка на случай, когда AI ломает всё. Коммить после каждого рабочего milestone'а.

git add -A && git commit -m "feat: auth with Google OAuth working"

А когда всё полетело:

git log --oneline -10        # Найти последний рабочий коммит
git stash                    # Сохранить текущие изменения на всякий случай
git checkout <commit-hash>   # Вернуться к рабочему состоянию

Правило трёх попыток: если AI не может починить баг за 3 итерации — откатывайся на рабочий коммит и пробуй другой подход. Долбиться в стену дольше — это и есть "ловушка трёх часов".

Правило 6: Давай AI контекст, а не надежды

AI не видит твой экран, не помнит предыдущие сессии и не знает, что ты имел в виду. Чем больше контекста — тем точнее результат.

Что работает:

• Скриншоты — покажи, как выглядит баг или желаемый дизайн. Один скриншот заменяет 200 слов промпта
• @-упоминания файлов в Cursor — @src/pages/settings.tsx вместо "тот файл с настройками"
• Полные ошибки — копируй весь stack trace, не пересказывай своими словами

Промпт для дебага:

При нажатии кнопки "Сохранить" на странице настроек вижу ошибку:

[полный stack trace]

Ожидаемое поведение: клик по "Сохранить" обновляет профиль
в таблице users и показывает toast "Сохранено".

Текущее поведение: страница крашится с ошибкой выше.

Файлы: src/pages/settings.tsx, src/lib/supabase.ts

Правило 7: Rules-файлы — инструкция для AI на весь проект

В Cursor это .cursor/rules/, в Claude Code — CLAUDE.md. Rules-файл — это набор правил, которые AI читает перед каждым ответом.

Что туда писать (по рекомендациям из структурированного workflow):

• Стек проекта и версии библиотек
• Conventions по именованию и структуре файлов
• Конкретные запреты: "не добавляй новые зависимости без спроса", "не меняй файлы, которые я не упоминал"
• Паттерны обработки ошибок

Минимальный набор правил:

1. Объясни, что собираешься делать, прежде чем кодить.
2. Делай простое решение первым.
3. Меняй только то, что я попросил.
4. Не пиши дублирующийся код.
5. Не добавляй зависимости без моего одобрения.

По опыту автора workflow на DEV.to, правильно настроенные rules-файлы позволяют генерировать до 98% кода через AI — потому что модель точно знает контекст и ограничения проекта.

Правило 8: Простой стек = меньше поломок

Чем проще стек, тем меньше мест, где AI может ошибиться. Серверы, базы данных и сложный тулинг — это точки отказа, где модель особенно часто галлюцинирует.

Рабочие комбинации для вайбкодинга:

• Быстрый MVP — Next.js + Supabase + Tailwind + Vercel
• Full-stack с batteries — Wasp (React + Node.js + Prisma из коробки)
• Без серверов — чистый JavaScript + localStorage, если данные не нужно шарить

Промпт для выбора стека:

Какие библиотеки и версии ты знаешь лучше всего для [задача]?
Предложи самый простой стек, который решит задачу.

Зачем спрашивать про версии: AI может знать React 18, но не React 19. Если навязать незнакомую версию — начнутся галлюцинации в API вызовах.

Правило 9: Не принимай всё на веру

66% разработчиков, по данным Stack Overflow, сталкиваются с кодом, который "almost right" — выглядит рабочим, но ломается в проде.

Что проверять в AI-коде:

• Безопасность — AI по умолчанию не добавляет валидацию, параметризованные запросы и role-based доступ. Промпт: "Используй параметризованные запросы и валидируй весь ввод"
• Реальные данные — убедись, что данные приходят из базы, а не захардкожены во фронтенде
• Зависимости — AI может подключить пакет, который не существует. Атакующие регистрируют малварь под именами, которые модели часто "галлюцинируют"

Промпт для security-ревью:

Проверь этот код на:
- SQL injection, XSS, обходы авторизации
- Захардкоженные секреты или токены
- Пакеты, которые я не утверждал
- Отсутствие обработки ошибок для API-вызовов

Правило 10: 80/20 — вайбкодь рутину, пиши руками критичное

Вайбкодинг блестит на рутине: CRUD-эндпоинты, формы, трансформация данных, базовая вёрстка. Но авторизация, платежи и кастомные алгоритмы — это зона, где "almost right" означает утечку данных или потерю денег.

Правило простое: если баг в этом коде стоит дороже, чем 30 минут ручной работы — пиши руками и ревьюй каждую строку.

Подводные камни

• "Стена трёх месяцев" — по наблюдениям Red Hat, вайбкодинг-проекты ломаются примерно через три месяца, когда кодовая база вырастает за пределы понимания. Интент решений теряется, и каждый фикс рождает каскад новых багов. Лечение: документируй решения по ходу, веди docs/decisions.md
• Functionality flickering — если ты не указал, что кнопка должна быть синей, завтра она может стать зелёной. AI не помнит стилевые решения между сессиями. Лечение: rules-файл с дизайн-токенами
• Фантомные пакеты — AI уверенно импортирует npm install super-auth-helper, которого не существует в npm. Под такими именами регистрируют малварь. Лечение: проверяй каждый import на существование пакета перед установкой
• Хардкод вместо данных — AI показывает красивый dashboard с данными, но данные зашиты в JSX. Выглядит как рабочее приложение, а это demo-заглушка. Лечение: промпт "покажи, откуда берутся данные на каждом экране"

Вердикт

Из десяти правил три дают 80% результата: спека перед кодом (правило 1), запрет кодить до плана (правило 2) и git после каждого milestone (правило 5). Без них вайбкодинг — это лотерея. С ними — рабочий процесс, который по оценкам практиков ускоряет разработку MVP в 20-50 раз по сравнению с классическим подходом.

Вайбкодинг — не замена программированию. Это мультипликатор. Опытный разработчик + вайбкодинг = суперсила. Новичок + вайбкодинг без правил = проект, который умирает на второй неделе.

Как попробовать

1. Установи Cursor или Claude Code — оба поддерживают rules-файлы и контекст проекта
2. Создай rules-файл (.cursor/rules/ или CLAUDE.md) с пятью правилами из правила 7
3. Начни новый проект с промпта из правила 1 — опиши продукт, аудиторию, фичи и стек
4. Попробуй промпт "расскажи план, не пиши код" перед каждой новой фичей
5. Документация по structured workflow: vibecoding.app/blog/vibe-coding-workflow-examples, Peter Yang's 12 Rules