У меня на разборах почти каждую неделю одна и та же история: человек открыл чат в браузере, попросил «сделай сайт», вставил куски в проект — через день всё разъехалось. Потом вердикт: «вайбкодинг не работает».
Работает другое: правка реального репозитория в редакторе с ИИ. Вы держите цель и критерий «готово», модель предлагает патч, вы читаете diff и принимаете или откатываете. Не замена программирования — ускорение рутины при вашей проверке.
Ниже — определение без маркетинга, когда Cursor уместен, типичные провалы и первый безопасный сценарий на один вечер. Серебряной пули нет: без чтения diff это генерация текста, не разработка.
Шаг 1. Чем вайбкодинг не равен «промптам в ChatGPT»
Вайбкодинг (vibe coding) — цикл: формулируете задачу — ИИ предлагает изменения в файлах — читаете diff — принимаете, правите запрос или откатываете. «Вайб» здесь про поток итераций, не про «пиши код настроение».
Три условия, без которых термин превращается в рекламу:
1. Редактор с контекстом — открыта папка проекта (Open Folder), не один файл в блокноте.
2. Режим с действием — в Cursor это Agent (правит файлы), а не только болтовня.
3. Ваша проверка — запуск, тест, взгляд в браузер, git diff. Без этого — генерация текста.
Типичная путаница: скопировали ответ из браузерного чата — в проекте нет связи с файлами — «не запускается». Лечится не новым промптом, а открытием папки и работой внутри репозитория.
- Архитектуру и границы — кто с чем связан, где данные. Модель предложит «логичную» структуру; ваши бизнес-ограничения знает только текст, который вы дали.
- Ключи и доступы — ключи API, пароли, персональные данные не должны уезжать в промпты и логи. .env и ротация токенов — ваша зона.
- Ответственность за прод — деплой, бэкап, откат. Кнопку «в прод» жмёт человек.
- Согласование с заказчиком — сроки и объём код не ускоряет.
Честный минимум грамотности: файл, функция, ошибка в консоли, git commit. Без этого вы зависите от каждого ответа модели. Нормальный старт для новичка: «объясни эту ошибку и предложи один фикс».
«ИИ сам всё поймёт» — Нужен контекст: файлы, rules, примеры
«Git не нужен» — Git или копия — страховка от плохого diff
«Сразу большой проект» — Сначала модуль или одна фича
«Без проверки» — Хотя бы ручной чеклист за 5 минут
Классика: алгоритм — набор — запуск — фикс.
Вайбкодинг: намерение — патч от модели — оценка патча — уточнение. Ручной набор не исчезает: правите строки, когда diff «почти верный», или когда быстрее самому.
- фокус с синтаксиса на спецификацию поведения («при пустом email — подсказка, форму не слать»);
- больше мелких итераций за час;
- чтение diff становится таким же навыком, как писать цикл;
- промпт = тикет: плохой тикет — не то.
Пример с формой. Классика: находите handler, пишете if (!email), проверяете в браузере. Вайбкодинг: в Ask — «где сейчас валидация», в Agent — «добавь проверку email и сообщение под полем, не меняй стили», смотрите diff, поднимаете dev-сервер.
Риск по умолчанию: модель любит переписать лишнее («заодно улучшил»). В промпте режьте явно: «только файл X», «не трогай CSS», «без новых зависимостей». Помогают Rules / короткий AGENTS.md в корне.
Совпадают несколько условий:
1. Задача локальна — один репозиторий, лендинг, скрипт, плагин. Не «десять сервисов с нуля за вечер».
2. Есть или будет папка на диске (лучше с git).
3. Вы можете проверить результат: страница, npm run dev, traceback.
4. Итерации короткие — фича на 20–60 минут, не «перепиши всё приложение».
5. Есть эталон — «как на странице Y», скрин, кусок кода, дока.
Слабые сценарии для старта: прод без staging/бэкапа; legacy без тестов и без человека, который помнит «почему так»; «сделай как у конкурента» без ТЗ и без доступа к коду; персональные данные без политики обработки.
Чеклист «готов ли я вайбкодить эту задачу»:
• Результат в одном предложении
• Есть откат (git или копия)
• Понимаю, что не должно измениться
Пять галочек — хороший кандидат. Две — сначала сузьте задачу. Agent включайте, когда план ясен; если не знаете, где живёт логика — сначала Ask и поиск по файлам.
Ускоряются и хорошие, и плохие правки.
- Раздувание diff — переименования, формат соседних файлов, «улучшения». Через неделю — конфликт или регрессия.
- Несуществующие API — уверенный вызов функции, которой нет в вашей версии package.json.
- Ключи в коде — токен из примера уехал в репозиторий. В diff ищите api_key, password, token.
- Отказ от git — каждый эксперимент лотерея. Минимум: коммит «до Agent», коммит «после проверки».
- Оракул-промпт — «сделай CRM» одним махом. Режьте: модель данных — одна форма — список — фильтр.
Большой diff — Лимит файлов в промпте, Rules
Галлюцинации API — Дока + версия в package.json
Утечка ключей/токенов — `.env`, ручной diff, pre-commit
Слепое принятие — Понимать каждую принятую правку
Выгорание — Малые победы, не «до 3 ночи»
Полезно вести лог на две недели: что просили — что изменилось — что проверили. Паттерн ошибок почти всегда один: слишком большой запрос и нет критерия готовности.
Не начинайте с «нового SaaS». Провал должен быть дешёвым.
Задача: в существующем статическом HTML или React-странице добавить блок «Контакты» (email + ссылка), стили в том же файле/модуле, без новых библиотек.
Почему безопасно: 1–2 файла, видно в браузере, легко откатить.
1. Копия папки или git checkout -b vibe-first.
2. Open Folder в Cursor, глянуть README / package.json.
3. Ask: «Где рендерится главная? Перечисли файлы, код не меняй.»
4. Agent: «В файле … добавь секцию Contact с … Другие секции не трогай.»
5. Dev-сервер, проверка в браузере.
6. git diff, коммит с понятным сообщением.
Альтернатива не-фронту: Python-скрипт — читает CSV, считает сумму по столбцу. Один файл, проверка на тестовом CSV.
Ограничения вслух: не подключать оплату/авторизацию/внешние API; не трогать прод; не «оптимизировать весь проект».
После успеха — форма с валидацией; потом Rules под стиль кода. Лестница вверх, не прыжок в сложность.
Оценка не «сколько промптов», а «от запроса до работающей фичи».
1. Intent — одно предложение для пользователя: «Под email — ошибка, если формат неверный». Не «сделай красиво».
2. Scope — какие файлы трогаем и что не трогаем: «только ContactForm.tsx, стили из существующего module.css».
3. Patch — Agent правит, вы читаете diff. Diff больше трети файла без причины — стоп, уточнение.
4. Verify — happy path, пустое поле, кривой формат, соседняя кнопка не отвалилась.
На мелкой задаче цикл укладывается в 30–45 минут. Время обычно жрёт неясный intent и принятие лишнего diff.
Признак, что цикл удался: можете объяснить коллеге, что изменилось, без открытия чата; есть коммит или копия до/после; следующий шаг маленький, а не «теперь всё приложение».
Одна строка после сессии: «Сегодня я …, проверил …, следующий шаг …». Это отделяет вайбкодинг от бесконечного чата.
«ИИ написал, но не запускается» — Код из браузерного чата без связи с проектом → Open Folder
«Всё сломалось после одного запроса» — Приняли большой diff без чтения → git / Local History
«Не понимаю, что он менял» — Сразу Agent без карты → сначала Ask
«Хочу без кода вообще» — Нет критерия готовности → мини-задача с проверкой за 5 минут
Diff на полрепозитория — Промпт широкий → один файл + «не трогай …»
Падает на API библиотеки — Сверить с докой и версией в package.json
Ключ в репозитории — Diff на token/password; вынести в `.env`
• Описать одну задачу одним предложением + критерий «готово»
• Открыть папку проекта в Cursor (не один файл)
• Сделать ветку или копию «до экспериментов»
• Ask: где живёт нужная логика — без правок
• Agent: один файл, явные «не трогай», без новых зависимостей
• Прочитать diff глазами; при сомнении — откат
• Проверка за 5 минут (браузер / скрипт / traceback)
• Коммит «после проверки» + одна строка лога сессии
У кого какой первый сценарий реально зашёл — HTML-блок, форма или скрипт на CSV? Напишите в комменты, что сломалось на diff.
