Вайбкодинг, или vibe coding, — это разработка через диалог с AI: человек описывает желаемый результат, запускает сгенерированный код, показывает модели ошибки и уточняет направление. Выражение вошло в широкий оборот после поста Андрея Карпати от 2 февраля 2025 года, где он описал нарочито свободный режим работы с Cursor и Claude: почти не читать код, принимать изменения и судить по тому, что получилось на экране. Такой подход отлично ускоряет прототип. Рабочий продукт начинается на следующем круге: нужно сузить задачу, проверить сценарии, закрыть безопасность, подготовить запуск для другого человека, оформить предложение и найти первых пользователей. Иначе быстрый результат действительно останется папкой с эффектным названием.
Не начинайте с «сделай мне приложение»
Модель охотно построит CRM «для любого бизнеса», социальную сеть или универсальный планировщик. Чем шире идея, тем убедительнее выглядит первый экран и тем труднее понять, кому он нужен.
Начните не с набора функций, а с одного неприятного момента. Кто сталкивается с ним? Что человек делает сейчас? Где теряет время или ошибается? Какой наблюдаемый результат должен получить?
Вместо «сделай сервис записи» задача может звучать так: частный мастер создаёт свободные окна, отправляет клиенту ссылку, а занятое время нельзя выбрать повторно. Здесь уже видны роли, данные, конфликт и критерий готовности. Уведомления, аналитика и программа лояльности могут подождать.
До первого промпта запишите четыре вещи:
Один тип пользователя.
Один основной сценарий.
Данные, без которых сценарий не работает.
Условия, при которых вы признаете результат рабочим.
Это не техническое задание на сорок страниц. Это граница, которая не даёт агенту каждый вечер строить новый продукт.
Когда сама идея уже понятна, остаётся выбрать точку старта. В отдельном разборе «Как создать приложение с помощью ИИ» сравниваются три варианта: пустой репозиторий, UI-кит и готовый исходник.
Промпт должен быть рабочим контрактом
Хороший стартовый промпт описывает не только внешний вид. Дайте модели контекст, ограничения и способ проверки:
Пользователь: частный мастер.
Основной сценарий: создать окна и принять одну запись на каждое.
Стек: используй существующий стек репозитория.
Ограничения: мобильный интерфейс, часовой пояс пользователя,
никаких секретов в клиентском коде.
Готово, когда: запись сохраняется, конфликт блокируется,
ошибка понятна пользователю, сценарий покрыт тестом.
Сначала изучи проект и задай вопросы. Затем предложи маленький план.Просите делать изменения небольшими шагами и объяснять, как проверить каждый. Если агент предлагает новую библиотеку, выясните, зачем она нужна и кто будет её обновлять. Если меняет схему данных, потребуйте миграцию и путь отката. Самый длинный промпт не заменит обратную связь от запущенного приложения.
Вайбкодинг ускоряет производство кода, но не снимает с человека выбор задачи, проверку результата и ответственность за то, что произойдёт после кнопки «Опубликовать».
Соберите один рабочий контур
Первый контур должен пройти от ввода до результата: пользователь совершает действие, сервер его проверяет, данные сохраняются, интерфейс показывает новое состояние. Красивый макет без этой цепочки остаётся демонстрацией.
Пройдите основной сценарий сами, затем намеренно сломайте его. Отправьте пустое поле, повторите запрос, обновите страницу, войдите под другим пользователем, отключите внешний API. Проверьте, что второй аккаунт не видит чужие данные, а повторное нажатие не создаёт две оплаты или две записи.
После каждого устойчивого шага делайте коммит. Добавьте автоматические тесты хотя бы на правила, от которых зависит смысл продукта, и отдельный smoke-тест запуска. AI хорошо продолжает правдоподобный код, включая правдоподобные ошибки. Зелёный экран и отсутствие красного текста в консоли ещё не являются проверкой.
Безопасность начинается до первых пользователей
Секреты должны жить в переменных окружения или менеджере секретов, а в репозитории нужен только .env.example без значений. Не отправляйте модели production-токены, выгрузки клиентов и реальные платёжные данные. Выдавайте каждому ключу минимальные права и заранее понимайте, как его отозвать.
Разделяйте аутентификацию и авторизацию. Факт входа не означает право читать чужой заказ или менять роль. Валидируйте данные на сервере, ограничивайте загрузки, экранируйте вывод, обновляйте зависимости и проверяйте лицензии пакетов и сгенерированных материалов.
Продумайте резервную копию, восстановление, логи без паролей и откат релиза. Для продукта с платежами, медицинскими, финансовыми или персональными данными нужен профильный специалист и отдельный аудит. Вайбкодинг может ускорить работу эксперта, но не превращает рискованную систему в безопасную по умолчанию.
Упаковка превращает репозиторий в продукт
Человек, который не видел ваши промпты, должен понять продукт без экскурсии по переписке. Минимальный комплект обычно включает:
README.mdилиstart_here.mdс командами от чистой установки до первого экрана;.env.exampleс описанием каждой переменной;lock-файл и точные версии среды;
миграции, тестовые данные и способ проверить запуск;
лицензию, ограничения и список известных проблем;
понятное демо, скриншоты и честное описание того, что входит.
Удалите из архива .env, ключи, пользовательские данные, локальные базы, кеши и случайные дампы. Проверьте чистый checkout или распаковку ZIP на другой машине.
Если агенту продукта нужны внешние сервисы, документируйте endpoint, разрешения и способ отзыва токена. Для такого сценария пригодится разбор что такое MCP-сервер и как его подключить. Само слово MCP в описании не заменяет инструкцию и модель угроз.
Дайте продукт другому человеку
Автор знает, куда нажать, какую переменную «и так понятно» заполнить и какую ошибку проигнорировать. Поэтому собственный успешный запуск почти всегда слишком мягкая проверка.
Дайте сборку человеку из целевой аудитории и не ведите его за руку. Наблюдайте, где он останавливается, какие слова понимает иначе и в какой момент просит объяснение. Потом исправляйте не пользователя, а интерфейс, документацию или сам сценарий.
Повторите тест с новым аккаунтом и чистым окружением. Продукт можно считать готовым к ограниченному выпуску, когда основной результат воспроизводится, опасные ошибки закрыты, установка описана, секретов в поставке нет, а известные ограничения названы прямо. Это не означает, что багов больше не будет. Это означает, что следующий человек получает не загадку.
Как дойти до публикации и первых продаж
В первой статье о Vibedepot такой софт назван третьим жанром: не заказная разработка и не бизнес, продаваемый целиком, а готовое решение, которое можно передать копией или давать по подписке.
На странице «Продать продукт» автор выбирает разовую покупку, подписку или оба варианта. Для карточки нужны название, категория, короткое и полное описание, хотя бы одно фото, стек, состав и цена. Для разовой продажи загружается ZIP с проектом; демо необязательно, но помогает показать реальное состояние. Карточка появляется в каталоге только после модерации.
Подробный чек-лист поставки, лицензий, цены и обновлений собран в материале «Пет-проект: как превратить сделанное для себя в товар».
Публикация не создаёт спрос автоматически. Сформулируйте предложение через задачу покупателя, а не через список библиотек. Покажите основной сценарий, назовите требования к запуску, границы поддержки и известные ограничения. Цена должна учитывать не количество строк, а ценность альтернативы, готовность комплекта и будущие затраты на помощь.
Ищите первых покупателей в контексте самой проблемы: в профессиональном сообществе, среди текущей аудитории, знакомых пользователей или тех, кто уже решает задачу вручную. Не обещайте экономию и продажи, которых не измеряли. Собирайте реальные вопросы к карточке: они точнее любого придуманного рекламного текста.
После публикации работа меняется
Теперь важны не новые экраны, а повторяемость. Заведите одно место для обращений, список известных проблем и журнал версий. Отделяйте дефект от индивидуальной доработки: просьба одного покупателя не обязана становиться функцией для всех.
Следите за ошибками, сроком действия ключей, резервными копиями и уязвимостями зависимостей. При обновлении меняйте не только код, но и инструкцию, .env.example, демо и архив поставки. Если возможность больше не поддерживается, уберите обещание из карточки раньше, чем его обнаружит покупатель.
Папка становится продуктом не в момент первого промпта и не в момент публикации. Это происходит, когда другой человек может понять ценность, безопасно запустить решение, получить заявленный результат и обратиться за понятной поддержкой.
Короткие ответы
Что такое вайбкодинг простыми словами?
Это способ собирать программу через разговор с AI, проверяя результат запусками и уточняющими командами вместо ручного написания каждой строки.
Можно ли заниматься вайбкодингом без знания программирования?
Можно собрать прототип. Для публичного продукта всё равно придётся разобраться в данных, доступах, развертывании, тестах и рисках либо привлечь специалиста.
Чем вайбкодинг отличается от обычной разработки с AI?
В исходном смысле человек почти не читает код и ведёт модель по наблюдаемому результату. В инженерной работе AI тоже пишет код, но изменения проходят ревью, тесты и контроль архитектуры.
Когда проект готов к продаже?
Когда посторонний человек может запустить его по инструкции, основной сценарий работает, ограничения описаны, а в архиве нет секретов и чужих данных.
Можно ли продавать сгенерированный AI код?
Сам способ создания не отменяет лицензии зависимостей, права на данные и материалы, условия AI-сервисов и ответственность автора. Всё это нужно проверить до публикации.
Как правильно писать: вайбкодинг или вайб кодинг?
Встречаются оба варианта. В этом тексте используется слитное «вайбкодинг», а английское название пишется vibe coding.