Вайбкодинг – это когда приложение собирает нейросеть по описанию обычными словами. Прототип и внутренний инструмент он ускоряет на недели, а платежи, персональные данные и поддержку до выпуска проверяет разработчик.
Главное
- Что это. Вайбкодинг – способ разработки, при котором вы описываете задачу словами, нейросеть пишет код, а вы смотрите на результат и почти не читаете код. Термин ввел Андрей Карпаты 2 февраля 2025 года (Wikipedia).
- Наш замер. У профессиональной команды AppCraft AI пишет около 96% кода: на выборке из 11 разработчиков коммитов стало в 4,1 раза больше, а закрытых задач на 100 часов – на 10-34% (наш замер). Ускорилось написание кода, а не выпуск.
- Наша проверка кода. 8 ноября 2026 года мы просмотрели 63 публичных репозитория, собранных в Lovable, v0 и Bolt. В 40% закоммичен файл .env, у 43% нет ни одного теста, а у 6 из 21 проектов с описанной базой есть таблица без защиты строк.
- Это совпадает с чужими сканами. В 2025 году у 170 из 1 645 сайтов из витрины Lovable данные были открыты из-за пропущенной защиты строк (Matt Palmer).
- Рекомендация. Собирайте сами прототип, демо и внутренний инструмент на несколько человек. Платежи, персональные данные, интеграции и все, что должно жить год, до выпуска покажите разработчику.
Содержание
- Что такое вайбкодинг простыми словами и чем он отличается от разработки с AI
- Где вайбкодинг помогает бизнесу, а где создает долг
- Наш замер: как AI работает у профессиональной команды
- Что мы нашли в коде 63 публичных вайб-кодных проектов
- Что проверить перед выпуском собранного продукта
- Что спросить у подрядчика, которому вы принесли прототип
- Что сделать собственнику
- Частые вопросы
Что такое вайбкодинг простыми словами и чем он отличается от разработки с AI
Вайбкодинг – это разработка, в которой код пишет нейросеть, а человек описывает желаемое и принимает результат по тому, как оно выглядит и работает. Карпаты в записи на X 2 февраля 2025 года сформулировал это так: «fully give in to the vibes, embrace exponentials, and forget that the code even exists» (Wikipedia). В переводе: полностью довериться ощущениям и забыть, что код вообще существует. Это ключевое слово: код не читают.
Профессиональная разработка с AI-агентами устроена иначе. Агент пишет код, но человек ставит задачу, читает изменения, запускает тесты и отвечает за выпуск. Я руковожу этим направлением в AppCraft, и разница между двумя подходами для меня одна: кто и чем проверяет результат.
Инструменты бывают двух видов. Lovable, Bolt и v0 собирают приложение или его интерфейс прямо из описания, а Lovable и Bolt еще и публикуют результат. Cursor и Claude Code работают внутри репозитория разработчика. Первые доступны собственнику без программиста, вторые требуют, чтобы кто-то читал код. Обе группы можно использовать в обоих режимах, но риск у них разный.
Где вайбкодинг помогает бизнесу, а где создает долг
Вайбкодинг убрал барьер «написать код». Барьер «выпустить продукт» остался: выпуск включает безопасность, данные, нагрузку, интеграции и поддержку. Первое видно на демо, второе не видно.
Таблица ниже – мое решение по типовым задачам.
| Задача | Собрать самому | Нужен разработчик | Почему |
|---|---|---|---|
| Прототип для проверки спроса | да | нет | Ошибка стоит дней, а не денег; прототип не хранит чужих данных |
| Демо для инвестора или партнера | да | нет | Нужен вид и сценарий, а не надежность |
| Внутренний инструмент на несколько человек, без чужих данных | да, с проверкой доступа | перед расширением круга | Мало пользователей и понятный владелец |
| Приложение с приемом оплаты | нет | да | Деньги, возвраты и платежные ключи требуют безопасного серверного кода |
| Хранение персональных данных клиентов | нет | да | Нужны права доступа, журнал и юридическая проверка: по 152-ФЗ при сборе данных граждан РФ базы должны быть на территории РФ (Гарант) |
| Интеграция с 1С, CRM, банком | только пробная | да | Чужие системы ломаются иначе, чем ваше приложение; нужны логи и повтор запросов |
| Сервис с нагрузкой в тысячи пользователей | нет | да | Нагрузку на демо не видно, а падение видно клиентам |
| Продукт, который должен жить год и дольше | нет | да | Через год зависимости устарели, а автор не помнит, как все работает |
Юридических выводов из таблицы делать нельзя: что именно требует закон для вашей базы, решает юрист.
Наш замер: как AI работает у профессиональной команды
Цифры из итогового отчета за шесть месяцев перехода AppCraft на AI-агентов: выборка из 11 разработчиков на клиентских и внутренних проектах, данные из Git и трекера задач, отчет внутри компании от 03.11.2026. Подробный разбор лежит в статье наш замер AI в разработке.
AI-агенты стали основным способом работы у всех 11 разработчиков выборки, доля кода от AI – около 96%. Коммитов в месяц стало в 4,1 раза больше, слитых изменений – в 5,9 раза. Закрытых задач на 100 часов стало на 10% больше по клиентским проектам и на 34% вместе с внутренними (полный разбор).
Вывод я сформулировал в отчете так: узким местом стали постановка задач, ревью и тестирование, а не написание кода. У команды это не страшно, потому что ревью, тесты и три контура – разработка, тестирование, продакшн – уже есть. Вайбкодинг без них получает те же кратные ускорения кода, но не получает ничего, что ловит ошибки. Поэтому риск уезжает из «не успели написать» в «не заметили, что написали».
Что мы нашли в коде 63 публичных вайб-кодных проектов
Чтобы не гадать, мы посмотрели код. 8 ноября 2026 года мы нашли через GitHub публичные репозитории с признаками Lovable, v0 и Bolt (README со ссылкой на инструмент или пакет lovable-tagger), случайно выбрали 100, склонировали 99 и оставили 63 настоящих приложения: 44 из Lovable, 15 из v0 и 4 из Bolt. Проверки только статические: мы читали файлы и не открывали работающие приложения, базы и ключи. Найденные секреты не проверяли и нигде не записывали. Имен и адресов в статье нет.
Наша проверка 08.11.2026, 63 публичных репозитория (44 Lovable, 15 v0, 4 Bolt): .env закоммичен у 40%, нет тестов у 43%, нет CI у 60%; у 6 из 21 проектов с описанными таблицами есть таблица без RLS. Для сравнения: у Lovable в 2025 году недостаточная защита строк была у 10,3% сайтов витрины.
Что в этих цифрах.
Файл .env. В 25 из 63 репозиториев (40%) лежит файл .env, и все 25 – Lovable. В 24 из них только адрес Supabase, публичный ключ и номер проекта: они предназначены для браузера и секретом не считаются. Но в одном репозитории (2%) в .env лежат переменные с именами платежного и почтового ключей, и значения у них не пустые. Всего секрет-подобное нашлось у 3 из 63 (5%): шаблон ключа в коде, JWT с ролью service_role или секретная переменная в .env. В 28 репозиториях (44%) файл .gitignore не исключает .env, то есть следующий неосторожный коммит выложит любой ключ. Ключи API во фронтенде хранить нельзя, об этом пишет и документация Lovable.
Защита строк в базе. Supabase используют 37 проектов, таблицы описаны в миграциях у 21. У 6 из этих 21 (29%) есть хотя бы одна таблица без включенной защиты строк (RLS), всего 54 таблицы из 1 261. Без RLS таблица в публичной схеме читается и пишется любой ролью, у которой есть права (Supabase). Оговорка: RLS могли включить в панели без миграции, поэтому это оценка по коду, а не доказанная утечка. У 16 из 21 есть политика записи с условием true, что бывает намеренным, например для формы заявки, но требует ручной проверки. У 7 из 63 (11%) в конфигурации отключена проверка входа для хотя бы одной серверной функции.
Тесты и обвязка. Ни одного теста нет у 27 из 63 (43%): у v0 – у 13 из 15, у Lovable – у 13 из 44. Нет автоматической проверки (CI) у 38 (60%). Ни тестов, ни CI – у 16 (25%). Тесты и ревью – именно то, что в нашем замере держит качество у команды. Lock-файла нет у 4 (6%), в 16 (25%) остался шаблонный README инструмента, то есть ни одной строки о том, как проект запускать и кто за него отвечает.
Как читать. Выборка мала, и это репозитории, которые владельцы оставили публичными. Многие после генерации правили люди, поэтому цифры описывают состояние репозитория, а не первую выдачу нейросети. Это не доля уязвимых работающих приложений.
Крупные исследования показывают ту же картину на других данных. Matt Palmer просканировал главные страницы 1 645 сайтов из витрины Lovable: у 170, около 10,3%, защита строк оказалась недостаточной в 303 запросах (Matt Palmer). Escape.tech в октябре 2025 года проверил более 5 600 публичных приложений (около 4 000 из них Lovable) и нашел более 2 000 уязвимостей, более 400 раскрытых секретов и 175 случаев персональных данных; авторы называют результат нижней границей (Escape). Wiz в сентябре 2025 года описал четыре повторяющиеся проблемы: проверка пароля в браузере, ключи в клиентском коде, таблицы без защиты и внутренние инструменты без входа (Wiz). Нейросеть без проверки склонна и к небезопасному коду: в тестах Veracode на 80 заданиях более 100 моделей внесли уязвимость в 45% случаев (Veracode).
Lovable сам пишет в документации, что за безопасность приложения отвечает его автор, а для чувствительных данных рекомендует проверку специалистом (Lovable). Я с этим согласен.
Что проверить перед выпуском собранного продукта
Я сформулировал вопросы, ответ на которые не требует читать код. Если на любой из них вы отвечаете «не знаю», это уже ответ.
- Платежи. Приложение принимает оплату? Если да, нужен разработчик.
- Персональные данные. Хранит ли оно данные клиентов или сотрудников? Если да, нужны права доступа, журнал и проверка юриста.
- Доступ. Вошли ли вы под чужой учетной записью и убедились, что видите только ее данные?
- Ключи. Лежат ли ключи API и базы только на сервере? Ключи во фронтенде хранить нельзя (Lovable).
- Копии. Есть ли резервная копия базы и проверяли ли вы восстановление из нее?
- Логи. Узнаете ли вы об ошибке раньше клиента?
- Обновления. Кто обновляет библиотеки через полгода?
- Интеграции. Подключено ли приложение к 1С, CRM, банку?
- Владелец. Кто поддерживает продукт через год и есть ли у него документ, как все запустить?
Калькулятор ниже сводит ответы к одному из трех вердиктов. Это мои правила, а не аудит.
Что спросить у подрядчика, которому вы принесли прототип
Прототип из Lovable или Bolt – хорошая постановка задачи: подрядчик видит экраны и сценарии. Но решение «доработать или переписать» зависит от кода, и честный ответ дается после просмотра репозитория, а не по скриншотам.
Вот вопросы, которые стоит задать:
- Вы посмотрите код и дадите заключение: доработка или переписывание, с причинами? Что именно вы проверите: доступ к данным, ключи, зависимости, тесты?
- Какие части вы оставите (экраны, тексты, сценарии), а какие перепишете (база, права, платежи)?
- Как вы оцените работу: фиксированная цена за аудит и отдельная смета на доработку?
- Какие тесты и проверки будут у кода после доработки и кто будет их запускать?
- Кто владеет репозиторием и аккаунтом инструмента, из которого собран прототип?
Общую рамку бюджета дает статья сколько стоит разработка приложения. Чтобы принести подрядчику не картинки, а задачу, пригодится чек-лист для составления ТЗ. Как мы выстраиваем проверки кода от агента, описано на странице про AI-разработку AppCraft.
Что сделать собственнику
| Шаг | Кто отвечает | Что получится |
|---|---|---|
| Составить список того, что уже собрано сотрудниками в Lovable, Bolt, Cursor | директор по ИТ или продукту | видно, какие инструменты и данные уже вне контроля |
| Пройти девять вопросов выше по каждому продукту | владелец продукта | вердикт: прототип, ограниченный запуск или доработка |
| Закрыть ключи и доступ у всего, что видит интернет | исполнитель с подрядчиком | нет ключей в коде и таблиц без защиты |
| Назначить владельца и дату проверки через три месяца | директор по продукту | у продукта есть человек, который его поддерживает |
| Показать репозиторий разработчику перед платежами и персональными данными | собственник | заключение «доработать или переписать» до выпуска |
Код теперь почти ничего не стоит. Дорого стоит проверка, и ее по-прежнему делает человек.
Частые вопросы
Это способ создавать приложения, описывая задачу нейросети обычным текстом и принимая результат, не читая код. Термин предложил Андрей Карпаты 2 февраля 2025 года (Wikipedia). Для прототипа и демо это работает, для продукта с оплатой и данными клиентов нужна проверка разработчика.
Можно сделать прототип, демо и внутренний инструмент для нескольких человек. Платежи, персональные данные, интеграции с 1С и нагрузку без разработчика выпускать не стоит: в нашей проверке 63 публичных проектов у 43% не было ни одного теста, а Wiz описывает ту же картину: ключи в клиентском коде и таблицы без защиты.
В нашем замере у профессиональной команды AI пишет около 96% кода, но закрытых задач стало больше на 10-34%, а не в разы, потому что остались постановка, ревью и тестирование (наш замер). Работа сместилась от набора кода к проверке.
Опасно, если не проверены права доступа. В 2025 году у 170 из 1 645 проверенных сайтов из витрины Lovable данные были доступны из-за пропущенной защиты строк (Matt Palmer). Включите защиту, проверьте доступ под чужой учеткой и покажите разработчику.
Не запрещайте, а проведите через девять вопросов. Если сервис не принимает оплату и не хранит чужие данные, оставьте его внутренним. Иначе передайте репозиторий разработчику для заключения.
Источники
- en.wikipedia.org — Wikipedia
- mattpalmer.io — Matt Palmer
- garant.ru — Гарант
- docs.lovable.dev — документация Lovable
- supabase.com — Supabase
- escape.tech — Escape
- wiz.io — Wiz
- veracode.com — Veracode
