Вайбкодинг: какие ошибки и риски поджидают предпринимателя без разработчика

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

Похожая история повторяется у десятков компаний, когда предприниматель без инженерного бэкграунда доверяет AI-агенту доступ к боевой инфраструктуре и не видит границы между черновиком и продакшном. Claude Code сняло с бизнеса необходимость нанимать программиста для простых задач — но риски, которые раньше ловил инженер на автомате, никуда не делись. Разбираем, что конкретно идёт не так у предпринимателей, которые вайбкодят сами, и что реально снижает риск, не отказываясь от инструмента.

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

Что вообще может сломаться, когда бизнес делает вайбкодинг без программиста

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

Из-за этого рискованная комбинация складывается почти незаметно: автономный агент получает доступ к продакшн-данным, работает без ревью человека и без проверенного пути отката. Каждый элемент по отдельности выглядит безобидно — быстрее протестировать на реальных данных, зачем отдельное окружение для маленькой задачи, AI же справился с похожим раньше. Вместе они и создают тот самый сценарий, который случился с Replit — и он далеко не единственный: обзоры 2026 года описывают уже целый класс похожих утечек в приложениях, собранных через вайбкодинг, вплоть до полутора миллионов потерянных API-ключей за три дня наблюдений.

Технические риски: код выглядит готовым, а безопасность — нет

Отчёт Veracode за 2025 год протестировал больше сотни языковых моделей на задачах на Java, JavaScript, Python и C#. В 45% тестов сгенерированный код содержал уязвимости — и качество не улучшалось даже у более новых и крупных моделей. Хуже всего дела обстояли с Java: там код проваливал проверку безопасности в 72% случаев. Защита от XSS не срабатывала в 86% релевантных сценариев, защита от log injection — в 88%.

Именно разрыв между тем, что видит предприниматель, и тем, что происходит внутри, объясняет большинство таких историй. Интерфейс работает, кнопки нажимаются, данные сохраняются — и по этим признакам продукт кажется готовым. При этом права доступа могут быть открыты шире необходимого, а секретные ключи — лежать там, где их не должно быть. Сервис Lovable столкнулся именно с этим: часть проектов не включала Row-Level Security в Supabase, из-за чего данные пользователей становились доступны кому угодно, кто знал, куда смотреть. По оценкам обзоров 2026 года, примерно каждое десятое приложение на Lovable оставалось открытым для подобных атак, хотя создатели вовсе не были небрежны — просто настройка прав доступа никак не отражается на экране во время работы с AI-агентом, и заметить её отсутствие неоткуда.

Почему это не видно, пока не становится слишком поздно

Готовый интерфейс и защищённый продукт — разные вещи, но со стороны выглядят одинаково. Фронтенд можно собрать за вечер, и он будет работать именно так, как задумано: форма отправляется, данные появляются в базе, страница обновляется. Всё это никак не говорит о том, кто ещё, кроме владельца, может достучаться до этой базы напрямую.

Программист привык проверять эту границу рефлекторно, потому что несколько раз в карьере уже обжёгся на её отсутствии. У предпринимателя, который занимается вайбкодингом впервые, такого рефлекса нет — и взяться ему неоткуда, если никто заранее не показал, где именно проходит эта граница между «работает у меня на экране» и «безопасно для чужих данных».

Управленческие риски: доверие без проверки

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

CEO Replit Амджад Масад отреагировал публично и назвал случившееся недопустимым. После инцидента компания развела dev и prod-окружения по умолчанию и добавила режим, в котором агент может только планировать изменения, а не исполнять их напрямую, пока человек не подтвердит каждый шаг. Показательно уже то, что даже производитель инструмента признал: без таких ограничений автономный агент опасен сам по себе, независимо от того, насколько он в целом хорош.

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

Как снизить риск, не отказываясь от вайбкодинга

Разобранные случаи складываются в один практический вывод: процесс стоит выстроить так, будто за спиной агента всё же стоит осторожный инженер, который перепроверяет за ним каждый шаг. Разработку имеет смысл физически развести на dev, staging и продакшн, с разными правами доступа — тогда у агента просто не будет технической возможности задеть боевые данные по умолчанию. Отдельно агенту стоит запретить любые необратимые действия без явного подтверждения человека — массовое удаление, перезапись данных или смену прав доступа потом не всегда получается откатить, и именно этой страховки не хватило в истории с Replit.

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

Отдельная привычка, которая окупается почти всегда — работать первые итерации в песочнице или одноразовом окружении, подальше от живой инфраструктуры. Тогда цена ошибки — отменённый черновик, а не потерянная база клиентов. И последнее: если AI-агент говорит, что что-то невозможно исправить или откатить, стоит переспросить и проверить это самому, прежде чем поддаваться панике. В истории с Replit именно эта уверенность агента чуть не стоила компании данных, которые на самом деле восстановить было можно.

FAQ

Значит ли это, что вайбкодинг не подходит для бизнеса? 

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

Нужно ли нанимать программиста, чтобы проверить AI-код перед запуском? 

Не обязательно на постоянной основе — разовая консультация или ревью критичных мест (доступы, платежи, персональные данные) снимает большую часть риска. Для внутренних некритичных инструментов эта необходимость ниже.

Как понять, что конкретный AI-инструмент безопаснее других? 

Ориентироваться стоит на три вещи: разделяет ли инструмент dev и prod по умолчанию, спрашивает ли подтверждение перед необратимыми действиями и как он работает с секретами и правами доступа. Маркетинговые обещания эти вопросы не заменяют.

Какие задачи вообще безопасно доверять вайбкодингу без дополнительных проверок? 

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

С чего начать, если уже вайбкодил без всех этих предосторожностей? 

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

Кто отвечает, если AI-агент случайно удалит данные клиентов? 

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

Заключение

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

Разбираем такие практические ситуации на встречах AI Practiq Club — с реальными кейсами участников, что сработало и что пришлось чинить.

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