Что такое vibe coding: как собрать прототип без хаоса
Vibe coding называют разработку через разговор с моделью: человек описывает, что должно получиться, а помощник предлагает код, экраны и следующие действия. Термин звучит так, будто достаточно поймать настроение и дать ИИ свободу. На практике устойчивый результат появляется от обратного: от очень конкретных границ. Это хороший способ проверить гипотезу, собрать внутренний инструмент или разобраться в незнакомом участке проекта. Это плохой способ молча выпускать в продакшен то, чего никто не прочитал.
Главная польза подхода — не в том, чтобы обойти разработку, а в том, чтобы быстрее увидеть работающий сценарий и задать правильные вопросы. Ниже — маршрут для первого прототипа, который можно показать коллеге, проверить и без боли передать в обычную разработку.
Выберите один сценарий, а не «продукт»
Плохой старт: «сделай CRM для отдела продаж». Хороший: «менеджер вставляет текст обращения, выбирает статус и получает черновик ответа; ничего не отправляется клиенту автоматически». Во втором случае понятно, кто пользуется экраном, какое действие делает и где заканчивается эксперимент.
Запишите сценарий одной строкой и добавьте три условия: что вводит человек, какой результат видит и что система точно не должна делать. Например: не хранить реальное имя клиента, не отправлять письма, не менять данные в CRM. Это одновременно помогает модели и защищает от лишней «инициативы» агента.
Если задача связана с интерфейсом, сначала нарисуйте последовательность экранов на бумаге или в заметке: вход → действие → результат → ошибка. Для кода в существующем проекте полезнее начать с гайда как писать код с нейросетью: там другой фокус — дифф, тесты и совместимость с репозиторием.
Соберите короткий бриф для модели
Vibe coding ломается, когда в одном сообщении смешивают идею, дизайн, базу данных, оплату и надежду «сделать красиво». Разделите работу на запросы. В первом попросите модель только пересказать задачу и назвать неясности. Во втором — описать структуру экрана. В третьем — подготовить минимальный вариант без подключений к реальным сервисам.
Удобный бриф выглядит так:
Нужен прототип для [роли]. Пользователь делает [действие] и видит [результат]. В первом варианте используем тестовые данные. Не добавляй авторизацию, оплату, отправку сообщений и внешние API. Сначала опиши три экрана и состояния ошибки. Код пока не пиши.
Такой запрос оставляет вам возможность спорить с логикой до того, как появятся десятки файлов. Когда структура согласована, попросите реализовать один экран и показать список созданных файлов. В редакторах с агентным режимом, например в Windsurf, особенно важно не пропускать этот остановочный пункт: скорость правок не заменяет решения о том, что именно строить.
Работайте от видимого к настоящему
Первый вариант прототипа может быть честной имитацией. Кнопка «сформировать сводку» берёт подготовленный тестовый текст; таблица показывает несколько заранее заданных строк; ошибка возникает по понятному условию. Это не обман, если вы прямо помечаете прототип и не выдаёте его за подключённый сервис. Зато так можно оценить, понятен ли путь человеку, до затрат на интеграции.
После каждого экрана проверьте пять вещей: виден ли главный призыв к действию, ясно ли что вводить, есть ли пустое состояние, что происходит при ошибке и можно ли вернуться назад. Откройте страницу на узком экране, пройдите её с клавиатуры и прочитайте все сообщения вслух. Модель часто делает эффектный первый экран, но забывает о загрузке, отмене и ситуации «ничего не найдено».
Когда прототип убедителен, заменяйте заглушки по одной. Сначала источник данных, затем валидация, затем сохранение. После каждого шага повторяйте исходный сценарий. Не подменяйте сразу все тестовые данные рабочими: при сбое будет непонятно, где именно возникла ошибка.
Не отдавайте агенту право решать за вас
Агент может читать файлы, предлагать команды и даже менять несколько компонентов одновременно. Но решение о миграции базы, установке пакета, изменении прав доступа или публикации должно требовать человека. Просите сперва план и список побочных эффектов, затем дифф. Не соглашайтесь на фразу «я всё исправил», пока не ясно, какие файлы и почему изменились.
Данные для прототипа должны быть синтетическими. Вставленный в чат экспорт клиентов, токен доступа или рабочая конфигурация превращают удобство в риск. О ключах и разделении окружений можно свериться в материале как не потерять API-ключ. Даже если модель не использует эти данные дальше, они не нужны для проверки расположения кнопки или текста ошибки.
Проведите «холодный» тест
Не проверяйте прототип только самому. Дайте его человеку, который не участвовал в сборке, и попросите выполнить одну задачу без подсказок. Наблюдайте, а не объясняйте. Где он остановился? Что ожидал после нажатия? Какие слова в интерфейсе прочёл иначе?
Запишите наблюдения отдельно от предложений модели. Если три человека не находят нужное действие, проблема почти наверняка в сценарии, а не в формулировке следующего промпта. Сначала исправьте путь пользователя, затем уже обсуждайте цвет, анимацию или новую функцию.
Проверьте и границу результата: что будет, если модель вернула пустой ответ, сервис недоступен или данные слишком длинные? Для прототипа допустимо показать честное сообщение «демо-режим, результат не сохранён». Недопустимо создать впечатление, что заявка отправлена, когда она осталась только на экране.
Решите, что делать после удачного демо
У прототипа есть три здоровых финала. Первый: отказаться, потому что сценарий никому не нужен — это тоже экономия. Второй: оставить как внутренний черновик без реальных данных. Третий: передать в разработку с понятным описанием. В последнем случае приложите путь пользователя, скриншоты состояний, список заглушек, известных ограничений и критерии готовности.
Не переносите автоматически сгенерированный код в основную систему. Разработчик должен оценить архитектуру, лицензии, зависимости, безопасность и тесты. Для этой части пригодится отдельная практика проверки кода, созданного ИИ. Внутри каталога можно сравнить способы работы редакторов: карточки Cursor и GitHub Copilot полезны не как обещание одинакового результата, а как ориентир по режимам и ограничениям инструментов.
Короткий чек-лист
- описан один пользовательский сценарий, а не весь будущий сервис;
- до кода согласованы экраны, пустое состояние и ошибка;
- первый вариант использует только тестовые данные и явно помечен как демо;
- агент показывает план и дифф, но не получает право на рискованные команды;
- прототип прошёл человек, который не участвовал в его сборке;
- известно, какие части являются заглушками и что требуется для настоящего запуска.
Передача прототипа разработчику
Соберите в один пакет не только исходники, но и маршрут проверки: какую задачу выполнял тестовый пользователь, какие данные были заглушками, где возникают ошибки и что считается готовым результатом. Приложите список зависимостей и команды запуска, но удалите локальные ключи и личные файлы. Так разработчик получает воспроизводимый прототип, а не набор случайных фрагментов.
Попросите провести независимый просмотр интерфейса и кода. Один человек проходит сценарий с чистого состояния, другой читает места, где модель принимала архитектурные решения. Все замечания разделите на блокирующие, важные и косметические. До интеграции в основную систему исправьте блокирующие: утечки данных, неверные права, отсутствие обработки ошибок и ложное сообщение об успешном действии.
Vibe coding хорош там, где нужно быстро сделать мысль проверяемой. Чем честнее границы демо и внимательнее проверка живого сценария, тем ценнее результат — даже если в конце вы решите ничего не выпускать.