Вайбкодинг: что это и как подготовить сайт к запуску

Вайбкодинг - это способ создавать программы, объясняя искусственному интеллекту нужный результат обычными словами. Вы просите сделать сайт, форму записи или личный кабинет, инструмент пишет код, а вы смотрите, что получилось, и просите изменения. Так удобно проверять идеи. Прежде чем доверять такому сайту клиентов, деньги и персональные данные, нужно отдельно проверить работу за пределами красивого экрана.

Если вы уже собрали сайт в Lovable, Bolt или с помощью Cursor и застряли, начните с конкретной проблемы. Не приходят заявки? Покупатель заплатил, а заказ остался неоплаченным? Исправление одной страницы ломает другую? У каждой такой задачи есть результат, который можно проверить. Само происхождение кода ещё не означает, что проект придётся выбросить.

Вайбкодинг: что это и откуда взялось название

Термин vibe coding предложил исследователь искусственного интеллекта Andrej Karpathy в 2025 году. В исходном смысле человек почти не вникает в код: описывает идею, запускает полученное и ориентируется на ощущение, насколько результат похож на задуманный. Теперь этим словом нередко называют вообще создание программ через разговор с ИИ.

Для бизнеса различие существенное. Разработчик тоже может генерировать код, а затем читать изменения, проверять права и запускать тесты. Тесты проверяют ожидаемое поведение программы. Надпись «сделано с ИИ» не объясняет, проходил ли проект эти этапы. Владельцу нужны ответы на другие вопросы: кто видит данные, где сохраняется обращение, как вернуть рабочую версию после ошибки.

Lovable и Bolt позволяют создавать сайты и приложения по описанию в чате. Cursor представляет собой редактор кода с помощником, который может менять файлы проекта. У них разные возможности и ограничения, поэтому судить обо всех по одному инструменту неправильно. Вайбкодинг используют предприниматели, дизайнеры, сотрудники компаний и разработчики. Он помогает быстро превратить замысел в вещь, которую можно открыть и попробовать.

Где сайт, созданный с помощью ИИ, приносит пользу

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

Внутренний инструмент тоже может быть удачным началом: список задач, подготовка черновика отчёта, простой калькулятор. Для первых проверок используйте вымышленные или обезличенные записи. Если приложение открывается из интернета, слово «внутреннее» само по себе не защищает информацию. Но ограниченный рабочий процесс проще описать, проверить и передать на сопровождение.

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

Что проверять перед запуском для клиентов

Ниже не список недостатков каждого сайта с ИИ. Это места, где внешний вид не доказывает правильную работу. Часть проверок доступна владельцу, для остальных нужен специалист, который читает код и настройки.

Вход, роли и чужие записи

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

Создайте два тестовых аккаунта и убедитесь, что каждый видит только свои заказы. Отдельно проверьте выход, открытие сохранённой ссылки на кабинет после выхода и восстановление пароля. Не используйте чужие данные для экспериментов. Проверку обхода прав поручите разработчику на тестовой копии.

База данных хранит записи сайта. В решениях с Supabase правила RLS ограничивают доступ к отдельным строкам таблиц. Если таблица доступна через публичный интерфейс без подходящих ограничений, посторонний может прочитать больше, чем показывает страница. Просто включить RLS недостаточно: правила должны учитывать владельца каждой записи и разрешённые действия.

Секретные ключи и персональные данные

API называют способ обращения одной программы к другой. Секретный API-ключ может разрешать отправку писем, расходование баланса или управление сервисом. Код, загруженный в браузер посетителя, доступен для чтения. Поэтому секретные ключи хранят вне него. Есть и специальные публичные ключи: их присутствие в браузере само по себе не является утечкой.

Проверьте, какие сведения собирает форма, зачем они нужны и кому передаются. Не добавляйте лишние поля «на будущее». Политика конфиденциальности должна описывать реальную обработку данных. Если вашей аудитории и используемым файлам cookie, небольшим записям в браузере, требуется согласие, баннер должен управлять их включением. Просто закрыть уведомление недостаточно. Требования зависят от рынка и данных, их нельзя определить по случайному шаблону.

Оплата и состояние заказа

Страница «Спасибо за оплату» не подтверждает поступление денег. Платёжный сервис передаёт подтверждение серверу, а сайт проверяет его. Такое сообщение часто называют webhook. Заказ должен получить правильные сумму, валюту и состояние. Повторное сообщение не должно приводить к повторной выдаче товара.

На тестовых платежах проверяют успешную оплату, отказ и закрытие вкладки сразу после платежа. Ещё один вопрос: что увидит менеджер, если подтверждение задержалось? Нельзя сообщать покупателю о выполненном заказе, пока система этого не подтвердила. Готовое подключение помогает подключить сервис, но весь путь покупки всё равно проверяют отдельно.

Письма и уведомления

Форма может показать успех, хотя менеджер ничего не получил. Отправьте тестовое обращение, найдите сохранённую запись и проверьте конечный почтовый ящик. Для доставки важны настройки отправителя, отказ почтового сервиса и попадание в спам. Если письмо потерялось, обращение должно остаться в системе, чтобы его можно было обработать.

Отдельно проверьте восстановление пароля и уведомление покупателя. Одна исправная форма не доказывает работу всех писем. После изменения отправителя или почтового тарифа пройдите эти действия снова. Заранее договоритесь, где смотреть ошибки доставки и кто реагирует на них.

Google, превью ссылок и скорость на телефоне

Клиентский рендеринг означает, что страницу собирает JavaScript, код в браузере. Google умеет его выполнять, но ошибка загрузки или закрытый доступ могут оставить поиску пустую оболочку. Робот мессенджера, который делает превью ссылки, не обязательно выполняет этот код. Поэтому проверяют доступный текст, заголовок, описание и картинку предпросмотра.

Утверждение «Google не видит все сайты Lovable» уже неверно как общее правило. В документации платформа описывает серверный рендеринг новых приложений и предварительное формирование страниц для проверенных роботов у более старых. После экспорта на другой хостинг это поведение проверяют заново. В Google Search Console полезна проверка конкретного адреса, а не только наличие главной страницы в выдаче.

Откройте сайт на телефоне через мобильный интернет. Дойдите до формы, заполните её и дождитесь результата. Тяжёлые картинки, лишний код и медленные запросы способны испортить удобный на большом экране сайт. Начальные технические проблемы поможет заметить бесплатная проверка существующего сайта. Она не заменяет проверки прав и платежей.

Хостинг, домен и восстановление

Хостингом называют среду, где работает опубликованный сайт. Доменом называют его адрес. Они остаются на аккаунте владельца. Убедитесь, что именно вы получаете уведомления об оплате и продлении, можете войти и восстановить доступ. Работа бизнеса не должна зависеть от личного аккаунта случайного исполнителя.

У Lovable и Bolt есть интеграция с GitHub, сервисом хранения кода и истории изменений. Репозиторий, хранилище файлов проекта, полезно контролировать владельцу. Но копия кода не включает автоматически базу данных, загруженные документы и настройки сторонних сервисов. Выясните, что резервируется, за какой период и как восстанавливается. Архив, который никто не пробовал восстановить, ещё не подтверждает готовность к сбою.

Расходы и бесконечный круг исправлений

Кредиты и токены измеряют использование инструмента, а не число готовых функций. Lovable использует кредиты, Bolt описывает расход токенов. Проверяйте действующие условия собственного тарифа. Учитывайте также работу опубликованного приложения, почту, хранение файлов, платёжные комиссии и другие подключённые услуги.

Если просьба «исправь всё» убирает нужную форму, вернитесь к последнему рабочему состоянию и опишите один сбой. Запишите шаги, ожидаемый результат и полученный. После исправления повторите соседние сценарии. История версий помогает вернуть код, но её действие на данные нужно выяснить отдельно. Не соглашайтесь на непонятную очистку базы ради исчезновения ошибки.

Кто заметит проблему после передачи сайта

Обсудите обычный рабочий день после запуска. Кто просматривает новые обращения? Где владелец увидит отказ почтового сервиса или окончание оплаченного ресурса? Сохранится ли обращение, если уведомление не пришло? Такие вопросы полезнее обещания «всё будет автоматически». Сегодня сайт может работать, а позже потерять подключение к внешнему сервису без единого изменения в коде.

Оставьте ответственному короткое описание главного сценария и места, где виден результат. Например, для тестового обращения зафиксируйте страницу отправки, запись в списке обращений и полученное письмо. Это пример проверки, а не история клиентского проекта. После обновления повторяют тот же путь. Если результата нет, сначала сохраняют имеющиеся данные и выясняют состояние операции, затем повторяют её без дублей. Владельцу не нужно читать весь код, чтобы требовать понятного подтверждения и знать, кому передать сбой. Храните эти проверки вместе с договорённостью о сопровождении, а не только в истории разговора с инструментом.

Чеклист владельца перед запуском

Проходите его на опубликованной тестовой версии с вымышленными записями. Рядом с неподтверждённым пунктом оставляйте вопрос и ответственного. «Работает» означает, что вы увидели конечный результат, а не прочитали обещание в чате.

Если у сайта нет платежей или кабинета, соответствующие пункты можно пропустить. Если видны чужие записи или не подтверждаются платежи, остановите эти функции до исправления. Цвет кнопок подождёт.

Оставить текущую версию, доработать или переделать?

Когда достаточно того, что уже есть

Если сайт решает небольшую задачу, проверки пройдены, расходы понятны и восстановление возможно, переписывать его только из-за ИИ незачем. Для раннего прототипа честно обозначьте границы: демонстрационные записи, отсутствие реальных оплат, ограниченный круг пользователей. Публичная посадочная страница тоже может работать на этой основе после проверки формы, скорости и доступности для поиска.

Когда пора пригласить разработчика

Когда вы не можете объяснить, где сохраняются заявки, кто имеет права администратора или что подтверждает оплату. Другой сигнал: после каждой правки приходится заново исправлять старую ошибку. Попросите сначала воспроизвести проблему и определить границы исправления, затем проверить результат в конечной точке. Для письма это почтовый ящик, для платежа это запись заказа.

Когда переделка может обойтись дешевле

Сравнивайте две оценки одного результата: исправление текущего кода и создание нужной части заново. Переделка оправдана, если основа противоречит рабочему процессу, каждое изменение затрагивает всё или существующую версию невозможно воспроизвести. В стоимость включают перенос данных, сохранение адресов страниц, проверки и запуск. Решение «перепишем всё» без осмотра столь же необоснованно, как надежда, что чат самостоятельно всё починит.

Как получить помощь с сайтом после вайбкодинга

Artbrain разрабатывает и поддерживает сайты и бизнес-системы, принимает сайты других исполнителей. Начинаем с бесплатного разбора сайта и задачи, затем согласуем оценку. Разовые исправления и доработки стоят $25 в час, ежемесячное обслуживание начинается от $100 в месяц с согласованным составом работ. Регулярные задачи подробнее разобраны в статье о стоимости обслуживания сайта.

Для проекта после вайбкодинга сначала выясним, доступен ли код и можем ли мы взять его в работу. Закрытые конструкторы не берём на обычное обслуживание. Экспортированное приложение оцениваем по технологиям, зависимостям и нужным изменениям, а не только по названию инструмента, который его создал.

Пришлите ссылку и кратко опишите проблему или желаемую доработку. Полезны шаги до ошибки и ожидаемый результат. Для проверки кода подойдёт экспорт проекта или согласованный доступ к репозиторию. Пароли в первом сообщении не нужны. Домен и хостинг остаются на вашем аккаунте.

Обратитесь за бесплатным разбором сайта и оценкой доработок. Даже если у вас пока только рабочий прототип, начать можно с одного вопроса: какой путь клиента нужно довести до подтверждённого результата?

CEO и ведущий разработчик Artbrain

Anton Kunashenko

Основатель Artbrain с 2018 года. Разрабатывает цифровые продукты для бизнеса: от лендингов до enterprise-систем.