Vibe coding с Cursor и Claude: как собрать MVP за 3 дня без команды разработки
Что такое vibe coding и почему это работает в 2026
Karpathy придумал термин в феврале 2025, описав режим, где ты говоришь модели что хочешь, смотришь что получилось, и итерируешь. Никакого специального синтаксиса, никаких шаблонов запросов, просто разговор. Через год это уже не эксперимент энтузиастов, а стандартный рабочий режим у соло-фаундеров.
Механика простая: ты описываешь задачу естественным языком, AI генерирует код, ты проверяешь результат и говоришь что не так. Точка. Весь цикл занимает минуты вместо часов, если задача понятно сформулирована.
Почему именно сейчас, а не год назад? Потому что в начале 2026 вышли новые версии Claude, которые закрыли конкретный разрыв, тормозивший всю историю: разрыв между "игрушечным" кодом, который красиво выглядит в демо, и кодом, который можно деплоить. До этого модели генерировали что-то работающее на хэппи-пате и разваливающееся на первом граничном случае. Сейчас это значительно реже.
Цифры говорят сами. Claude Code достиг ~$2B annualized revenue к началу 2026, а около 4% всех публичных коммитов на GitHub сейчас генерируются с его участием. Это не метрика хайпа, это метрика реального использования.
Но есть один результат, который надо знать честно. METR провели оценку и показали: у опытных инженеров на сложном легаси-коде AI-ассистенты дают замедление на 19%. Не ускорение, замедление. Контекст большой, архитектурные решения запутанные, модель начинает генерировать правдоподобные но неверные вещи, и старший инженер тратит время на разбор полётов.
MVP с нуля, история обратная. Там вайб-кодинг работает именно так, как описано в любом твите на эту тему.
Правильно сформулированный промпт экономит часы ручной работы уже на старте проекта.
Cursor против Claude Code: что выбрать для трёхдневного спринта
Если у тебя три дня и один разработчик, выбор инструмента реально влияет на то, что ты успеешь.
Cursor, это форк VS Code с встроенным AI-автодополнением и чатом. Он быстрее на простых задачах, это ощущается при UI-итерациях, когда ты меняешь компоненты, гоняешь стили, правишь формы. Просто жмёшь Tab и двигаешься дальше.
Claude Code работает иначе. Это терминальный агент, он не встраивается в IDE, а разворачивается рядом с ней. Зато окно контекста в 200k+ токенов позволяет ему держать в голове несколько файлов одновременно, без того чтобы ты вручную копировал куски кода в чат. На бэкенде, при написании тестов или когда нужно разобраться в чужой кодовой базе, это ощутимо. Я видел случаи, когда Claude Code за один промпт находил баг, который разработчик искал два часа.
По ценам на апрель 2026: Cursor Pro стоит $20 в месяц, Claude Code Max от $100 до $200 в зависимости от тарифа, GitHub Copilot, $10 для контекста сравнения. Разница в стоимости в 5-10 раз между Cursor и Claude Code Max не случайна. Anthropic сейчас субсидирует цены: они строят долю рынка, не зарабатывают на ней. Через год тарифы переоценят, скорее всего вверх. Если закладываешь AI-инструменты в unit-экономику MVP, считай реальные затраты, не нынешние.
Рабочая схема для спринта выглядит так: Cursor как основная среда разработки, Claude Code в терминале для тяжёлых задач. Миграции баз данных, сложный рефакторинг, дебаг непонятного поведения, сюда. Компоненты, стили, быстрые правки, туда. Переключение между ними занимает секунды, оба работают с одним репозиторием.
Для трёхдневного спринта с упором на фронтенд хватит Cursor Pro. Если есть нетривиальный бэкенд или унаследованный код, который надо понять быстро, добавь Claude Code хотя бы на один день.
Cursor удобен для работы внутри проекта, Claude Code лучше справляется с задачами из командной строки.
День 0: подготовка, без которой три дня превратятся в три недели
Я вообще не пишу код в день 0. Это правило. Если открыть редактор раньше, чем готов PRD и инфраструктура, к вечеру первого дня обнаруживаешь себя в дебрях аутентификации с тремя нерешёнными вопросами про схему БД. Видел это десятки раз, сам попадал.
PRD умещается на двух-трёх страницах в Notion. Структура простая: проблема в одном абзаце, портрет юзера (один, не три), 3-5 сценариев в формате "юзер заходит, делает X, получает Y", и отдельный раздел "не входит в MVP". Последний раздел важнее первых четырёх. Туда я выписываю всё, что хочется сделать, но не буду: командные аккаунты, дашборд аналитики, темная тема, мобильное приложение, экспорт в PDF. Список растёт по мере работы, и каждый пункт там это сэкономленные часы.
Стек выбираю не по любви, а по тому, сколько готовых решений можно склеить за вечер. Сейчас, в мае 2026, моя связка для трёхдневного MVP выглядит так: Next.js 15 с App Router, Supabase под Postgres, Auth и Storage сразу, Vercel для деплоя, Stripe Checkout (не Payment Intents, не подписки руками), Resend для транзакционных писем. Это закрывает примерно 80% задач любого SaaS-MVP. Оставшиеся 20% это твоя бизнес-логика, ради которой всё и затевалось.
Дизайн не рисую. Беру shadcn/ui, Tailwind, иконки из Lucide. Если на этапе MVP хочется кастомный дизайн-язык, значит проект ещё не валидирован и кастом будет выкинут через месяц.
Дальше создаю файл правил для AI-ассистента. У меня это CLAUDE.md в корне репо, для Cursor дублирую в .cursorrules. Без него Claude и Cursor начинают изобретать архитектуру на каждом запросе: то Pages Router вспомнят, то useEffect вместо Server Action предложат, то zod заменят на ручную проверку. Минимальный файл выглядит так:
# CLAUDE.md
*Выбор стека до начала работы позволяет AI генерировать согласованный код с первого дня.*
## Stack
- Next.js 15 (App Router), TypeScript strict
- Supabase (Postgres + Auth + Storage)
- Tailwind + shadcn/ui
- Stripe Checkout, Resend
*Схема данных, зафиксированная в первый день, избавляет от болезненных миграций на третьей неделе.*
## Rules
- Server Components по умолчанию, 'use client' только при необходимости
- Все мутации через Server Actions
- Zod для валидации входных данных
- Никаких any, никаких console.log в коммитах
- Файлы до 300 строк, иначе разбивай
К этому я обычно добавляю секции про структуру папок (app/, components/ui/ для shadcn, components/ для своих, lib/ для утилит, lib/db/ для запросов к Supabase) и конвенции именования: компоненты PascalCase.tsx, серверные действия kebab-case.ts с экспортом export async function createInvoice(...). Чем конкретнее правила, тем меньше тебе придётся переписывать за моделью.
Последний шаг дня 0, инфраструктура. Всё поднимаю до первой строки кода:
- Репозиторий на GitHub, ветка
mainзащищена, подключён Vercel. - Проект в Supabase, скопированы
SUPABASE_URLиSUPABASE_ANON_KEYв.env.localи в Vercel. - Домен куплен и привязан к Vercel, сертификат выпустился.
- Stripe в test mode, ключи в env, вебхук на
/api/stripe/webhookсSTRIPE_WEBHOOK_SECRETчерезstripe listen. - Resend, добавлен домен, прошла DNS-верификация (это иногда занимает пару часов, поэтому делаю первым).
- Sentry или хотя бы Vercel Logs для прода.
К концу дня 0 у меня нет ни одного React-компонента, зато есть задеплоенная страница "Hello", работающий логин через Supabase Auth (буквально <Auth /> из их UI), тестовый платёж через Stripe и письмо, упавшее мне на почту через Resend. Это и есть фундамент. Дальше три дня уходят на продукт, а не на ковыряние с переменными окружения в три часа ночи.
День 1: каркас, аутентификация, базовая модель данных
Открываю Cursor и пишу первый промпт в Composer: "Прочитай CLAUDE.md в корне, создай структуру Next.js 15 проекта по этой спеке, инициализируй shadcn/ui с темой neutral, поставь ESLint flat config и Prettier с tailwind-плагином". Через минуту у меня лежит каркас, который раньше я бы собирал руками часа полтора. CLAUDE.md заранее описывает стек (Next.js App Router, Supabase, TanStack Query, Zod) и конвенции именования, поэтому Claude не лезет тащить лишнее.
Дальше переключаюсь на схему БД. Создаю файл supabase/migrations/0001_init.sql, жму Cmd+K и диктую таблицы:
// Промпт для Cursor (Cmd+K в файле schema.sql):
// 'Создай таблицы users (расширяет auth.users), projects (id, user_id, name, created_at),
// tasks (id, project_id, title, status enum: todo|doing|done, position int).
// RLS политики: пользователь видит только свои projects и tasks.
// Сгенерируй TypeScript типы в types/db.ts'
Получаю SQL с references auth.users(id) on delete cascade, корректные RLS-политики через auth.uid() = user_id, и отдельно файл types/db.ts. Прогоняю миграцию через supabase db push, проверяю в дашборде что политики применились. Один нюанс: Claude любит забывать политику на insert, проверяю её отдельно и дописываю with check (auth.uid() = user_id).
Аутентификация. Беру Supabase Auth, magic link плюс Google OAuth, потому что email/password в 2026 это лишний код и лишний саппорт. Промпт: "Сделай страницы /login и /auth/callback, middleware.ts с матчером на /dashboard/* и /app/*, который рефрешит сессию и редиректит анонимов на /login". Cursor выдаёт почти рабочий middleware на @supabase/ssr, ловлю одну опечатку в матчере и иду дальше.
Лендинг делаю минимальный. Hero, заголовок, подзаголовок, кнопка "Войти через Google". Никаких социальных пруфов, фичеров, FAQ. Это страница на 30 минут, а не на полдня, и она нужна только чтобы было куда положить домен. Дизайн копирую из shadcn-блока hero-01, перекрашиваю акцент.
К вечеру первого дня картина такая: я могу залогиниться через Google, попасть на /dashboard, увидеть пустой экран с надписью "No projects yet", нажать кнопку "New project" и в Supabase появится запись с правильным user_id. Tasks пока не трогаю, только убеждаюсь что RLS реально режет чужие строки (открываю второй браузер, логинюсь другим аккаунтом, проверяю что проектов нет). Это и есть готовый день 1. Не красиво, но скелет стоит и держит вес.
Перед деплоем стоит прогнать финальный чеклист: AI не отловит баг, который вы не попросили проверить.
День 2: основная фича, оплата, письма
К утру второго дня у меня обычно есть авторизация, пустой dashboard и ощущение, что можно начать "пилить функционал". Это ловушка. Если на день 2 я возьму три фичи и сделаю каждую на 60%, к вечеру у меня будет три сломанных потока и ноль работающих сценариев. Поэтому правило: одна главная фича, end-to-end, до состояния "юзер заплатил и получил письмо".
Для SaaS, который я делал в апреле, главным сценарием был "загрузил CSV, получил отчёт в PDF на почту". Всё остальное (история отчётов, шаринг, настройки команды) откладывается на день 3-4. Если основной поток не работает, остальное не имеет значения.
Оплата: Stripe Checkout, не Elements. Я больше не трогаю Stripe Elements в первые дни проекта. Checkout это одна ссылка, хостится у Stripe, поддерживает Apple Pay, SCA и налоги из коробки. Мне нужен только Server Action, который создаёт сессию, и webhook, который слушает checkout.session.completed и обновляет subscription_status в таблице users. Всё. На это уходит часа полтора, если промпт нормальный.
И вот тут начинается типичный затык vibe coding. AI пишет код, который запускается. Тесты (если они есть) проходят. Но логика поплыла: webhook ставит is_pro = true, а middleware проверяет subscription_status === 'active'. Поля разные, имена разные, итог: юзер заплатил, доступа нет. Лечится одним способом, явными acceptance criteria в промпте.
// Плохой промпт: 'добавь оплату через Stripe'
// Хороший промпт:
/*
Добавь Stripe Checkout для подписки $19/мес.
Acceptance criteria:
1. Кнопка 'Upgrade' на /dashboard вызывает Server Action createCheckoutSession
2. Action создаёт сессию Stripe с success_url=/dashboard?upgraded=1
3. Webhook /api/stripe/webhook обрабатывает checkout.session.completed
4. В таблице users поля stripe_customer_id и subscription_status обновляются
5. Middleware блокирует /pro роуты если subscription_status != 'active'
Используй переменные STRIPE_SECRET_KEY и STRIPE_WEBHOOK_SECRET из .env.local
*/
Разница между этими двумя промптами это разница между "вечером у меня работает оплата" и "вечером я три часа дебажу, почему юзер платит, но is_pro остаётся false". Я в промпт явно прописываю имена полей в БД, имена роутов, имена переменных окружения. AI не угадывает, AI заполняет шаблон.
Webhook тестирую через stripe listen --forward-to localhost:3000/api/stripe/webhook. На проде секрет webhook другой, это ловит человек 90% при первом деплое.
Письма: Resend + React Email. Три шаблона на день 2: welcome (после регистрации), payment success (после webhook), password reset. Больше не нужно. React Email даёт мне писать шаблоны как обычные React-компоненты, Resend отправляет одним вызовом resend.emails.send(). Домен на DNS я настраиваю заранее, на день 1, потому что верификация SPF/DKIM иногда висит часами.
Welcome письмо триггерится из того же Server Action, что создаёт юзера. Payment success из webhook, после апдейта subscription_status. Reset через Supabase Auth hook или свой роут, зависит от того, как у меня устроен auth.
Ритм коммитов. Каждые 2 часа: git commit, push, Vercel разворачивает preview. Я открываю preview-ссылку с телефона и прохожу основной сценарий как юзер. Не как разработчик с открытым DevTools, а как человек, который первый раз увидел продукт. Это ловит примерно 80% UX-косяков, которые на localhost не видны: кнопка под кейбордом на iOS, шрифт 12px на мобиле, форма, которая не скроллится при открытой клавиатуре.
К концу дня 2 у меня должно быть: юзер регистрируется, получает welcome, нажимает Upgrade, платит, получает payment success письмо, видит pro-функции в dashboard. Если что-то из этой цепочки не работает, день 3 я начинаю с починки, а не с новых фич. Никогда наоборот.
Когда контекст раздувается до нескольких тысяч токенов, модель начинает забывать решения из начала диалога.
День 3: полировка, аналитика, продакшен
Утром третьего дня я открываю браузер и прохожу весь продукт руками. Не смотрю в код, не проверяю консоль. Просто пользуюсь, как пользователь, который видит это впервые. Каждое место, где я споткнулся, где что-то не очевидно, где форма ведёт себя странно, идёт в TODO.md. Обычно набирается 15-25 пунктов. Затем я скармливаю этот файл Claude Code одним промптом: «Вот список багов. Исправь по порядку, не трогай то, что не упомянуто». Часа за два список обнуляется.
Дальше аналитика. Я подключаю PostHog и Sentry. Оба бесплатные на старте, оба встают за 10 минут каждый.
PostHog: регистрируешься, получаешь API-ключ, вставляешь их SDK в layout.tsx, расставляешь posthog.capture('event_name') в нужных местах. Минимальный набор событий: регистрация, первый ключевой action пользователя (то, ради чего он пришёл), оплата. Всё остальное потом.
Sentry ставится через их Next.js wizard (npx @sentry/wizard@latest -i nextjs), он сам правит конфиги. После этого необработанные исключения и серверные ошибки полетят к тебе на почту. Это важнее красивого UI. Ты узнаешь о падении раньше, чем пользователь успеет написать жалобу.
SEO я делаю по минимуму, но правильно. В Next.js 14+ метатеги отдаются через generateMetadata в page.tsx: title, description, og:image, og:url. Картинку для Open Graph генерирую через @vercel/og, она рендерится на лету и нормально выглядит при шаринге в Telegram и X. Туда же sitemap.xml через встроенный sitemap.ts и robots.txt с разрешением для всех краулеров. Это не гарантирует трафик из Google, но без этого органики точно не будет.
Production checklist перед деплоем выглядит у меня так. Rate limiting на API-роуты через Upstash Redis: две строки кода с их библиотекой @upstash/ratelimit, защищает от дурацких скриптов и случайных петель. CSP-заголовки в next.config.js, хотя бы базовые. Все секреты (ключи Stripe, OpenAI, базы) проверены в Vercel Dashboard в разделе Environment Variables, ни один не захардкожен. Кастомный домен подключён через Vercel и уже резолвится.
Последний пункт люди недооценивают. Запуск.
Продажи начинаются с трафика, а не с кода. Готовый продукт без аудитории не существует. Я записываю короткое демо-видео (Loom, без монтажа). Пишу тред в X: первый твит с болью, которую решает продукт, следующие три-четыре с демо и конкретными цифрами, последний с ссылкой. Параллельно постю в 2-3 Telegram-каналах, где живёт целевая аудитория. Не в общих «стартап-чатах», а там, где люди реально обсуждают проблему, которую я решаю.
Product Hunt запускаю в тот же день или на следующий, в полночь по тихоокеанскому времени. Страница готовится заранее: скриншоты, tagline, первый комментарий от основателя с историей. Это не серебряная пуля, но даёт 200-500 уникальных посетителей в первый день, а это достаточно, чтобы понять, работает ли месседж.
Три дня прошли. Продукт стоит в продакшене, собирает данные, виден поисковикам и получил первый трафик. Дальше начинается другая работа.
Список фич нужно резать до MVP жёстко: AI ускоряет сборку, но не отменяет ограничения времени.
Где vibe coding ломается и как чинить на лету
Первые 200 строк идут гладко. Потом начинается.
Один чат на весь проект, главная ловушка для тех, кто только пришёл в vibe coding. К третьему дню в этом чате живёт история про переделанную схему базы, три варианта авторизации и куча отменённых решений. Контекст забит, и модель начинает противоречить тому, что сама написала два часа назад. Рецепт простой: новый чат на каждую логическую задачу. "Реализовать загрузку файлов", отдельный чат. "Починить пагинацию", отдельный чат. Звучит неудобно, но это единственное, что держит модель в связном состоянии.
Галлюцинации API, проблема специфическая и неочевидная. Claude (и не только он) выдумывает методы с убедительной уверенностью. Я видел, как модель генерировала supabase.auth.getUserMetadata(), метода нет ни в одной версии SDK. Или несуществующий параметр в Stripe PaymentIntent. Код выглядит разумно, приложение падает на рантайме, и ты полчаса ищешь свою ошибку, которой нет. Лечение: в промпт явно кидать ссылку на актуальную документацию или конкретный блок из неё. Не "используй Supabase Auth", а "вот текущий раздел доки по signInWithOTP, работай строго по этому интерфейсу". Разница огромная.
Отдельная история, vibe debugging. Модель видит симптом и чинит симптом. Падает с undefined is not a function, добавляет опциональную цепочку. Ошибка уходит, баг остаётся. После второй итерации без результата я перестаю просить AI "разберись сам" и начинаю читать код руками. Формулирую гипотезу: "я думаю, проблема в том, что X происходит до Y". С гипотезой уже можно нормально работать, попросить проверить именно её, а не гадать. Третья итерация "попробуй ещё раз", сигнал остановиться и думать самому.
После примерно 2000 строк проекты начинают выглядеть как один большой файл с функциями, которые знают друг о друге слишком много. Архитектурная каша, это не баг AI, это следствие того, что vibe coding не думает о модульных границах по умолчанию. Профилактика работает только с первого дня: явно прописывать, какой модуль что экспортирует и с чем не должен пересекаться. Я называю это contracts, не в смысле TypeScript-типов (хотя и это тоже), а в смысле договора: "auth не знает про billing, billing смотрит только в user ID". Если нарушение этого контракта обнаружилось на 1500 строках, рефакторить больно, но можно. На 5000, уже почти нет.
И последнее, самое серьёзное. AI охотно пишет небезопасный код. Не из злого умысла, просто оптимизирует на "работает", а не на "безопасно". Row Level Security в Supabase? Будет включён, но политика может разрешать всем читать всё. Валидация входящих данных? Модель иногда доверяет req.body напрямую. SQL-инъекции в raw-запросах случаются, если не уточнить явно. Перед любым запуском с реальными пользователями я прохожусь руками по трём вещам: логика авторизации и проверки токенов, все RLS-политики в базе, валидация и санитизация входов на сервере. Это не опционально. AI может написать 90% кода, но эти 10% нельзя делегировать.
Реалистичные ожидания: что получится за 3 дня, а что нет
За три дня получается конкретная вещь: рабочий SaaS с регистрацией через email или Google, одной core-фичей, которую пользователь реально использует, подключённой оплатой через Stripe и базовой страницей админки. Этого хватает, чтобы получить первых 10-50 платящих клиентов и понять, есть ли спрос вообще.
Что не получится: мобильное приложение в App Store или Google Play (только review занимает несколько дней), сложный realtime типа Google Docs с совместным редактированием, любые ML-фичи со своими моделями, мультиязычность с нормальным i18n, и всё enterprise-ное: SSO, audit log, role-based permissions на уровне строк в базе. Это не за три дня, и врать себе тут не надо.
Деньги. Cursor: $20 в месяц. Claude: при интенсивной работе над проектом с нуля выходит около $100 на Pro-плане плюс немного API. Vercel и Supabase на старте: $0, бесплатных квот хватает до нескольких тысяч пользователей. Домен: $12 на Namecheap. Итого порядка $132 на весь MVP. Не $15 000 агентству.
Время. По опыту, спринт от нуля до задеплоенного продукта занимает около 30 часов при нормальной подготовке. Для сравнения: команда аутсорса на аналогичный проект с авторизац