Сайты: цены и разработка

Вайбкодинг: что это и можно ли довести прототип до продукта

Вайбкодинг: что это и можно ли довести прототип до продукта

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

Коротко

  • Термин предложил Андрей Карпатый в феврале 2025 года. Запрос «вайбкодинг» в Яндексе вырос с 2 926 показов в месяц в сентябре 2025 года до 31 105 в сентябре 2026.
  • Если вы код прочитали, проверили и можете объяснить, это обычная разработка с ИИ. Если нет, это вайбкодинг.
  • Для себя, команды и показа идеи вайбкодинг подходит. Для чужих данных, платежей и публичного запуска нужна доработка.
  • Типичные поломки: база без правил доступа, выдуманные библиотеки, секреты в коде, данные не в России, нет тестов и никто не знает, как это чинить.
  • Доводить можно самому, если вы читаете код, или отдать на разбор разработчику до запуска, пока не случилась первая утечка.

Что такое вайбкодинг

Андрей Карпатый в феврале 2025 года описал новый способ писать программы: «полностью отдаться ощущениям и забыть, что код вообще существует» (в оригинале: fully give in to the vibes… and forget that the code even exists; формулировку приводим по Википедии и записи Фаулера, сам пост мы не открывали). Фраза разошлась по отрасли, а Collins Dictionary выбрал vibe coding словом 2025 года (CNN, 06.11.2025).

В русской выдаче «вайбкодингом» называют всё подряд, от подсказок в редакторе кода до сборки целых сервисов в браузере. Для решений полезнее узкое значение. Мартин Фаулер в записи от 21 мая 2026 года определяет вайбкодинг как создание программ подсказками для нейросети без изучения сгенерированного кода (Martin Fowler). Саймон Уиллисон проводит границу ещё прямее: если нейросеть написала код, а вы его просмотрели, тщательно проверили и можете объяснить другому человеку, как он работает, это уже обычная разработка ПО (Simon Willison, 19.03.2025).

В обычной разработке с ИИ у каждой строки есть человек, который за неё отвечает. В вайбкодинге за то, что внутри, не отвечает никто. Пока прототипом пользуетесь вы сами, это терпимо, а проблемы начинаются с первыми пользователями.

Спрос растёт быстро: по данным Яндекс Вордстата, «вайбкодинг» набирал 2 926 показов в месяц в сентябре 2025 года, 15 576 в марте 2026 и 31 105 в сентябре 2026. Запрос «вайбкодинг что это» набирает 10 445 показов в месяц. Сами разработчики оценивают подход осторожнее: в опросе Stack Overflow 2025 года вайбкодинг входит в профессиональную работу у 14,7% опрошенных, а 66% называют главной проблемой решения ИИ, которые «почти верны, но не совсем» (Stack Overflow Developer Survey 2025).

Что вайбкодингом можно собрать самому

Критерий один: кто пользуется результатом и что случится, если в нём ошибка. Фаулер советует использовать вайбкодинг для одноразового ПО, которым пользуются автор или небольшая доверенная группа, и не забывать о коде, у которого больше пользователей и серьёзнее последствия ошибок.

Типовая ситуация (пример, не кейс): менеджер сервиса по ремонту техники просит нейросеть собрать калькулятор, который по модели и поломке показывает ориентировочную цену ремонта. Калькулятором пользуются двое сотрудников, данные клиентов в нём не хранятся. Ошибка стоит поправки в таблице. Это нормальная задача для вайбкодинга. Если же тот же сервис решает принимать заявки от клиентов с телефоном и адресом и выдавать личный кабинет, задача уже другая.

Ситуация Хватит ли вайбкодинга
Калькулятор, парсер файлов, скрипт для себя или отдела Да, при условии, что в нём нет чужих персональных данных
Кликабельный прототип для интервью с клиентами и показа инвестору Да, прототип и нужен как черновик
Внутренний сервис для 5–10 сотрудников без чувствительных данных Скорее да, но один человек должен понимать, как это работает
Лендинг или сайт компании Чаще проще конструктор, подробности в статье сайт с помощью нейросети
Сервис с регистрацией, личными кабинетами и данными клиентов Только как прототип; запуск требует доработки
Приём платежей, медицинские, финансовые и юридические данные Не в одиночку: нужны разработчик и проверка безопасности

Где прототип ломается по дороге к продукту

Чаще всего подводят шесть мест.

Доступ к данным

Показательный случай связан с Lovable, сервисом, который собирает приложения по описанию. Он подключает базу Supabase, и защита данных там держится на правилах Row Level Security (RLS): без них любой, у кого есть публичный ключ из клиентского кода, может читать и менять таблицы. В документации Supabase это сказано прямо: таблица в открытой схеме без RLS доступна для чтения и записи любой роли, у которой есть на неё права (Supabase).

В 2025 году запись CVE-2025-48757 описала недостаточные политики RLS в Lovable, которые позволяли неаутентифицированному атакующему читать и писать в таблицы сгенерированных сайтов. Оценка критичности 9,3 из 10, запись опубликована 30 мая 2025 года (Tenable). Lovable с записью не согласна и считает, что за защиту данных приложения отвечает его владелец. Для вас этот спор вторичен: нейросеть собрала рабочее приложение, а правила доступа никто не проверил, потому что в интерфейсе их не видно.

Зависимости, секреты и уязвимости в самом коде

Нейросеть иногда придумывает названия библиотек. В исследовании USENIX Security 2025 на 576 000 образцов кода коммерческие модели выдумывали несуществующие пакеты минимум в 5,2% случаев, открытые модели в 21,7%. Исследователи нашли 205 474 уникальных выдуманных имени (arXiv). Опасность в том, что злоумышленник может зарегистрировать пакет с таким именем и ждать, пока кто-нибудь установит его по подсказке нейросети.

С уязвимостями в целом картина похожая. Veracode в отчёте от 30 июля 2025 года проверила код более чем ста моделей на 80 заданиях: уязвимость появлялась в 45% случаев, причём защита от XSS отсутствовала в 86% случаев. Это исследование разработчика средств безопасности на синтетических заданиях, и к вашему проекту его цифры применять нельзя. Тенденцию оно при этом показывает: безопасность не растёт вместе с тем, как нейросеть лучше пишет рабочий код (Veracode).

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

Агент с доступом к рабочей базе

В июле 2025 года основатель SaaStr Джейсон Лемкин в 12-дневном эксперименте с агентом Replit обнаружил, что на девятый день агент удалил рабочую базу с записями о 1 206 руководителях и 1 196 компаниях, хотя ему запретили менять данные без согласия. Глава Replit Амджад Масад назвал случай недопустимым и сообщил о новых мерах: разделение тестовой и рабочей баз, режим «только планирование» и восстановление из бэкапа в один клик (eWeek, 22.07.2025). У агента не должно быть прав на рабочую базу, а бэкап считается рабочим, только когда его хотя бы раз восстановили.

Персональные данные граждан России

Если прототип собирает имена, телефоны или почту россиян, срабатывает 152-ФЗ. По новой редакции ч. 5 ст. 18 нельзя записывать, хранить и извлекать персональные данные граждан РФ с помощью баз за пределами России, кроме случаев, которые прямо предусмотрены законом (ComNews). Поэтому смотрите, где физически лежит база. У Lovable Cloud в документации три региона хранения: Americas, Europe и Asia Pacific (Lovable), России в списке нет. Проверьте условия вашего сервиса на дату запуска и обсудите схему с юристом, потому что исключения в законе есть, а шаблонного ответа нет. Это не юридическая консультация.

Есть и деловой риск: сервис может стать недоступен российским пользователям целиком. Wix с 12 сентября 2024 года заблокировал аккаунты резидентов России и отключил сайты (Коммерсантъ). Если ваш продукт целиком живёт внутри чужой платформы, этот сценарий стоит учесть заранее и держать копию кода в своём репозитории.

Поисковый индекс

Многие вайбкодинг-сервисы собирают страницы в браузере на JavaScript. Яндекс называет индексирование таких страниц бета-функцией и пишет, что по умолчанию робот сам решает, выполнять ли скрипты (Яндекс Вебмастер). Если страницы сервиса должны приводить клиентов из поиска, проверьте, что робот видит текст, а не пустую оболочку. Подробнее о проверке мы писали в статье про сайт с помощью нейросети.

Поддержка

Прототип, который никто не читал, нельзя быстро поправить. Каждая правка через нейросеть может сломать то, что работало. Опрос Stack Overflow фиксирует ту же боль у профессионалов: решения «почти верные, но не совсем» названы главной проблемой у 66% опрошенных. Разработчик замечает, где именно «почти», а тот, кто код не читает, узнаёт об этом от клиента.

От прототипа к продукту: что добавить

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

Что добавить Зачем Признак готовности
Правила доступа к данным (RLS или права на уровне сервера) Пользователь видит только свои данные, анонимный запрос ничего не читает Запрос без входа и запрос под чужим аккаунтом возвращают отказ, это проверено руками
Авторизация и роли Отделить клиента, сотрудника и администратора Есть список ролей и что каждая может, проверен сброс пароля
Секреты и конфигурация Ключи не должны лежать в коде и в браузере Ключи в переменных окружения сервера, старые ключи перевыпущены
Свой репозиторий и история изменений Код не зависит от сервиса, где его собрали Код в git у вас, любой разработчик может его склонировать
Миграции базы и бэкапы Изменение структуры не должно терять данные Бэкап восстановлен хотя бы раз на тестовой базе
Тесты на главные сценарии Правка не должна ломать регистрацию и оплату Прогон тестов перед каждой выкладкой
Тестовое и рабочее окружения Агент и разработчик не трогают рабочие данные Разные базы и разные ключи
Логи и оповещения об ошибках Узнавать о поломке раньше клиента Ошибка в рабочей среде приходит в мессенджер или почту
Хранение данных в России, политика обработки ПДн, согласия 152-ФЗ Известно, где лежит база; документы подготовлены с юристом
Проверка зависимостей Выдуманные и уязвимые пакеты Список зависимостей просмотрен, неизвестные пакеты проверены вручную

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

Доводить самому, нанять разработчика или переписать с нуля

Выбор зависит от двух вещей: читаете ли вы код и что в прототипе лежит.

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

Если решили разрабатывать с нейросетью сами, заранее продумайте процесс вокруг неё. Мы ведём разработку в оркестраторе: так мы называем систему, в которой ИИ-агенты работают по ролям, как небольшая команда. Один агент составляет план и делит задачу на части так, чтобы у каждой были свои файлы; большой план утверждает человек. Остальные пишут код, а проверяющие гоняют тесты и сборку, делают ревью и отдельной проверкой пытаются доказать, что задача не готова. Опасные команды, секреты и выкладка на рабочий сервер для агентов закрыты, а необратимые шаги они делают только после нашего «да». Так мы разрабатываем сайт veyro.ru и собственные сервисы.

Мы можем внедрить оркестратор у вас и настроить его под ваш проект и команду; стоимость назовём после разбора. Читать код и принимать решения всё равно будет человек. Хранение данных и документы по 152-ФЗ оркестратор не решает, а для разовой формы или калькулятора он слишком громоздкий.

Нанять разработчика на разбор стоит, если прототип подтвердил идею, у него появились первые пользователи, а код вы не читаете. Разработчик смотрит доступ к данным, секреты, зависимости, структуру базы и говорит, что оставить. Минус: придётся заплатить за разбор, даже если выяснится, что переписывать нужно много.

Переписать с нуля разумно, если прототип нужен был как продуманный макет. Его экраны и сценарии пригодятся как ТЗ, код нет. Вайбкодинг свою задачу выполнил: показал идею за выходные. Минус: переписывание стоит денег, и если часть кода была нормальной, вы платите за уже сделанное.

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

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

  1. Запрос к базе без входа в систему ничего не возвращает. Проверено вручную, слова нейросети не в счёт.
  2. Пользователь А не видит данные пользователя Б.
  3. В репозитории и в клиентском коде нет паролей и ключей, старые ключи перевыпущены.
  4. Список зависимостей просмотрен, все пакеты существуют и нужны.
  5. У агента и у сервиса разработки нет прав на рабочую базу.
  6. Есть бэкап рабочей базы, и вы хотя бы раз восстановили его на тестовой.
  7. Код лежит в вашем репозитории, а не только в сервисе, где его собрали.
  8. Известно, в какой стране лежат данные граждан РФ; политика обработки ПДн и согласия подготовлены.
  9. Ошибки в рабочей среде приходят вам на почту или в мессенджер.
  10. Есть человек, который понимает код и отвечает за правки.

Если не пройдены пункты 1–3 или 5, запускать продукт для клиентов рано.

Если не хотите разбираться сами

Расскажите на бесплатном 30-минутном разборе, что у вас уже собрано, и мы скажем, хватит ли прототипа для первых клиентов или доводить его до продукта надо с разработчиком.

  • SaaS и веб-сервисы: прототип на рабочем коде с одной ролью пользователя и одним сценарием от 100 000 ₽, срок около 2 недель. MVP от 450 000 ₽ за 2–3 месяца, личный кабинет от 400 000 ₽. Это нижняя граница: итог зависит от задачи, смета строится построчно после брифа и фиксируется в договоре. Минус: дороже, чем дорабатывать прототип самому.
  • Оркестратор ИИ-агентов для вашей команды: подойдёт, если вы разрабатываете с нейросетями сами и хотите, чтобы большие планы утверждал человек, а код проходил проверки до выкладки. Стоимость назовём после разбора.

Вопросы и ответы

Это способ делать программы, когда вы описываете задачу обычным языком, нейросеть пишет код, а вы пробуете результат и просите поправить, не читая сам код. Термин в феврале 2025 года предложил Андрей Карпатый. Если вы код читаете, проверяете и можете объяснить, как он работает, это уже обычная разработка с помощью ИИ.

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

Сам по себе нет. В исследовании Veracode 2025 года код, сгенерированный более чем сотней моделей, содержал уязвимость в 45% случаев на синтетических заданиях. Поэтому код нужно проверять так же, как чужой: правила доступа к базе, секреты, зависимости, ввод пользователя.

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

Если цель одноразовые инструменты для себя, курс почти не нужен: хватит практики и документации сервиса. Если вы хотите выпускать продукт для клиентов, полезнее учить основы: как устроены база, авторизация, git и развёртывание. Без них вы не заметите, что нейросеть сделала не так.

Следующая статья02 / 18

Нейропродакшн и ИИ-видео

Лучшие нейросети для видео в 2026: Seedance, Kling, Veo и что стало с Sora

14 мин чтения

Листайте дальше — статья откроется самаЧитать