Вайбкодинг — способ делать программы, когда вы описываете задачу обычными словами, нейросеть пишет код, а вы пробуете результат и просите поправить, не вникая в сам код. Довести такой прототип до продукта можно, но одними промптами не обойтись: нужны правила доступа к данным, хранение персональных данных в России, тесты, развёртывание и человек, который понимает код.
Коротко
- Термин предложил Андрей Карпатый в феврале 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–3 или 5, запускать продукт для клиентов рано.
Если не хотите разбираться сами
Расскажите на бесплатном 30-минутном разборе, что у вас уже собрано, и мы скажем, хватит ли прототипа для первых клиентов или доводить его до продукта надо с разработчиком.
- SaaS и веб-сервисы: прототип на рабочем коде с одной ролью пользователя и одним сценарием от 100 000 ₽, срок около 2 недель. MVP от 450 000 ₽ за 2–3 месяца, личный кабинет от 400 000 ₽. Это нижняя граница: итог зависит от задачи, смета строится построчно после брифа и фиксируется в договоре. Минус: дороже, чем дорабатывать прототип самому.
- Оркестратор ИИ-агентов для вашей команды: подойдёт, если вы разрабатываете с нейросетями сами и хотите, чтобы большие планы утверждал человек, а код проходил проверки до выкладки. Стоимость назовём после разбора.
Вопросы и ответы
Это способ делать программы, когда вы описываете задачу обычным языком, нейросеть пишет код, а вы пробуете результат и просите поправить, не читая сам код. Термин в феврале 2025 года предложил Андрей Карпатый. Если вы код читаете, проверяете и можете объяснить, как он работает, это уже обычная разработка с помощью ИИ.
Прототип можно: форму, калькулятор, кликабельный макет сервиса для показа первым клиентам. Для продукта с чужими данными, оплатой и личными кабинетами одного описания словами недостаточно: нужны правила доступа к данным, хранение в России, тесты и развёртывание. Это работа разработчика или человека, который умеет читать код.
Сам по себе нет. В исследовании Veracode 2025 года код, сгенерированный более чем сотней моделей, содержал уязвимость в 45% случаев на синтетических заданиях. Поэтому код нужно проверять так же, как чужой: правила доступа к базе, секреты, зависимости, ввод пользователя.
Не всегда. Если прототип нужен только для проверки идеи, его можно выбросить. Если интерфейс и логика подтвердились, разработчик обычно оставляет экран и модель данных, а доступ, хранение, тесты и развёртывание делает заново. Решает разбор кода: сколько в нём можно оставить без переделки.
Если цель одноразовые инструменты для себя, курс почти не нужен: хватит практики и документации сервиса. Если вы хотите выпускать продукт для клиентов, полезнее учить основы: как устроены база, авторизация, git и развёртывание. Без них вы не заметите, что нейросеть сделала не так.
