7 опасностей вайбкодинга в проде: разбор инцидентов Replit, Lovable и Moltbook в 2026

В июле 2025 года основатель сообщества SaaStr Джейсон Лемкин (Jason Lemkin) тестировал AI-агента в Replit. Дело было в code freeze — режиме, когда никаких изменений в продакшен не вносят. Лемкин дал агенту прямую инструкцию: ничего не трогать в живой базе данных. Через несколько часов агент удалил из неё 1206 руководителей и 1196 компаний, проигнорировав запрет, а потом соврал, что восстановить данные нельзя.

Это самая громкая история про вайбкодинг в продакшене за 2025 год, но далеко не единственная. Параллельно случились утечки 1,5 млн API-ключей через Supabase, массовая уязвимость 170 приложений на Lovable (CVE-2025-48757), статистика от Wiz и Veracode о том, что 40–62 % AI-сгенерированного кода содержит уязвимости.

В этой статье собрали семь главных опасностей вайбкодинга в проде на живых кейсах 2025–2026 годов, разобрали технический долг и утрату навыков ревью, показали чек-лист безопасной работы с AI и объяснили, какие защиты встраивают сами Anthropic, OpenAI и Replit.

Если вы ещё не знаете, что такое вайбкодинг, начните с обзорной статьи «Вайбкодинг: что это, как работает и с чего начать». Там разобрали базу, инструменты и первые шаги. А общее представление о том, что вообще такое нейросети, можно получить в материале «Что такое нейросети, рассказываем простыми словами».

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

Если после статьи захочется системно научиться работать с нейросетями и понимать, где AI помогает, а где его опасно пускать в прод — загляните в нашу подборку курсов по нейросетям и искусственному интеллекту. Там 316 программ от коротких интенсивов до годовых направлений.

Что такое вайбкодинг и почему опасности именно у негоСкопировано

Вайбкодинг (vibe coding) — это способ писать программы, при котором человек объясняет нейросети на человеческом языке, что нужно сделать, а AI генерирует код. Термин ввёл Андрей Карпатый (Andrej Karpathy) в феврале 2025 года. Главная идея вайбкодинга: разработчик не вычитывает каждую строчку, он запускает результат, смотрит, что получилось, и даёт следующую инструкцию.

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

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

Дальше разберём конкретные истории и статистику по каждой опасности.

Опасность 1 — AI-агент удаляет данные в живом продеСкопировано

Самый громкий кейс 2025 года — инцидент Replit и SaaStr. Джейсон Лемкин, основатель крупнейшего сообщества SaaS-предпринимателей, тестировал агентский режим Replit на продакшен-окружении. Перед началом он дал агенту явную письменную инструкцию: идёт code freeze, никаких изменений в базе, любые операции — только после ручного одобрения.

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

CEO Replit Амжад Масад (Amjad Masad) публично извинился и запустил три защиты: автоматическое разделение dev- и prod-баз (раньше агент мог их путать), улучшенный rollback и новый «planning-only» режим, в котором AI обсуждает план, но ничего не выполняет.

Главный урок: текстовая инструкция «ничего не трогай» не работает как защита. Защиту должен обеспечивать сам инструмент — разные базы для dev и prod, обязательное human approval перед deploy, отдельный аккаунт для AI с ограниченными правами. Если этого нет, AI на любую неожиданность может среагировать командой DROP TABLE.

Опасность 2 — утечки API-ключей и секретов через публичные репозиторииСкопировано

В 2025 году компания Wiz исследовала Moltbook — приложение, которое автор публично собрал на Lovable без единой строчки кода. Через три дня после запуска оказалось, что база Supabase настроена с открытыми правами на чтение. Из неё утекли 1,5 млн API-ключей и 35 тысяч email-адресов пользователей. Все они были доступны любому, кто знал URL базы.

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

• хардкод API-ключей к OpenAI, Anthropic, Stripe, Supabase
• токены доступа к продакшен-базе
• пароли от сторонних сервисов
• JWT-секреты для подписи токенов авторизации

Сканеры GitHub находят такие ключи за минуты после публикации. Дальше идёт автоматический майнинг или, если ключи дают доступ к платным API, перепродажа доступа на чёрном рынке. Пользователь Reddit рассказывал, как за ночь его OpenAI-ключ сгенерил счёт на 1800 $ через утечку из демо-проекта.

AI этого не замечает, потому что для модели «положить ключ в `.env`» и «положить ключ в `config.js` и закоммитить» — одинаково валидный код. Защита здесь только техническая: secret scanning в GitHub, файл `.gitignore` с запретом коммитить `.env`, отдельные ключи для разработки и продакшена, ротация ключей по расписанию.

Опасность 3 — уязвимости в самом кодеСкопировано

Исследование Wiz 2025 года — по 1645 приложениям на Lovable — показало: 170 из них (один из десяти) утекали пользовательские данные через одну и ту же уязвимость. AI-генератор инвертировал логику доступа: вместо «можно только своему пользователю» — «можно всем, кроме своего». Получился CVE-2025-48757. Корень проблемы: пропущенные политики Row Level Security в Supabase.

Veracode и другие лаборатории безопасности проверили AI-сгенерированный код на стандартный набор уязвимостей. Цифры неприятные:

• 40–62 % AI-сгенерированного кода содержит хотя бы одну уязвимость по OWASP Top 10
• AI-код имеет уязвимости в 2,74 раза чаще, чем код, написанный людьми
• 20 % вайбкоднутых приложений в продакшене Wiz классифицирует как «серьёзно небезопасные»

Самые частые проблемы:

• SQL-инъекции — AI собирает запрос строкой, в которую можно подсунуть кусок чужого SQL через поле ввода
• Cross-Site Scripting (XSS) — AI вставляет пользовательский ввод напрямую в HTML без экранирования
• Сломанная авторизация — как в истории Lovable, доступ открыт там, где не должен
• Remote Code Execution (RCE) — пользователь может выполнить команды на сервере через специально подобранный ввод
• Открытые CORS — любой сайт в интернете может дёргать ваше API от имени пользователя

AI знает, что такие уязвимости существуют. Но знание абстрактное, а при генерации конкретного кода под конкретную задачу модель думает в первую очередь о том, чтобы код работал. Безопасность для неё — второстепенная цель, если её не ставить явно.

Опасность 4 — технический долг от MVP, который потом нельзя поддерживатьСкопировано

Технический долг (technical debt) — это разница между тем, как код написан, и тем, как он должен быть написан, чтобы его легко было дорабатывать. Чем больше долг, тем дороже каждое следующее изменение.

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

• дублируется логика, которая уже есть в другом месте проекта
• появляются костыли вокруг кода, написанного час назад тем же AI
• имена переменных и функций несовместимы со стилем проекта
• обработка ошибок построена через `try/catch`, который проглатывает всё подряд
• тесты не покрывают логику, а симулируют ожидаемый ответ

На этапе MVP это незаметно. Проблема включается через 3–6 месяцев, когда нужно добавить новую фичу или поправить баг. Опытный разработчик открывает кодбейс и понимает, что для исправления небольшого бага надо переписать половину модуля — потому что AI растащил одну и ту же логику по пяти файлам.

Здесь не помогают советы вроде «пишите промпт лучше» или «выбирайте модель умнее». Помогает только дисциплина: ревью каждого крупного куска кода человеком, рефакторинг по ходу, документация в файле `CLAUDE.md` или аналогичном — чтобы AI понимал контекст проекта, а не генерил каждый раз заново. Подробнее про CLAUDE.md мы разбирали в статье «CLAUDE.md примеры: 15 шаблонов под популярные фреймворки».

Опасность 5 — баги, которые AI не видит без понимания всей системыСкопировано

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

Конкретные примеры:

• Race conditions — два запроса приходят одновременно, оба читают баланс пользователя, оба пишут «баланс минус 100», в итоге списали один раз вместо двух
• Утечки памяти — каждый запрос оставляет за собой объект в памяти, через сутки сервер падает
• N+1 запросы к базе — на десяти заказах работает, на десяти тысячах база встаёт
• Конфликты схем — один сервис ждёт поле `userId`, другой шлёт `user_id`, тесты проходят, потому что в тестах все поля захардкожены
• Аномалии в edge case — что происходит, если у пользователя нет email, дата рождения в 1900 году, имя из 500 символов

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

Опасность 6 — зависимость от вендора и чёрный ящикСкопировано

Когда вы пишете приложение с помощью Cursor или Replit, у вас формируется зависимость от трёх слоёв сразу: интерфейса (Cursor), модели (Claude или GPT), инфраструктуры (Replit Cloud, Vercel). Если любой из них меняет правила или цены, вместе с ним меняется ваш бизнес.

Конкретные риски:

• Изменение цен — у Cursor в 2025 году переходили на токен-метрики дважды, у многих счёт вырос в 3–5 раз за полгода
• Депрекейт моделей — Claude 3.5 Sonnet (на котором работал ваш агент год назад) был заменён на Claude Sonnet 4.6, поведение и цены поменялись
• Региональные блокировки — Cursor и Anthropic не работают напрямую из России, нужно искать обходные оплаты
• Закрытие сервиса — мелкие AI-стартапы регулярно закрываются, забирая с собой ваш кодбейс
• Чёрный ящик — когда что-то ломается, вы не понимаете, что именно произошло внутри AI, и не можете воспроизвести проблему

Сценарий «AI-инструмент сделал что-то странное, потом обновился и ведёт себя по-другому» встречается постоянно. Если ваш продукт построен на вайбкодинге целиком, контроль над ним у вас только частичный. Подробнее про альтернативы и запасные варианты, в том числе про локальные модели, разобрали в статье «Бесплатные альтернативы Claude Code: китайские модели, локальные LLM и российские нейросети».

Опасность 7 — слепое доверие AI и потеря навыков ревьюСкопировано

Самая коварная опасность не техническая, а человеческая. Когда AI пишет код за вас полгода подряд, у вас постепенно атрофируется привычка читать чужой код. Сначала перестаёте проверять мелкие куски, потом средние, потом крупные. В какой-то момент вы уже не понимаете, что именно делает приложение в каждой конкретной точке.

Признаки, что вы подошли к этой границе:

• код-ревью занимает 30 секунд — «выглядит ок, мерджу»
• при появлении бага первый порыв — переспросить AI, а не залезть в логи
• при отладке вы копируете весь стектрейс в промпт, не читая его
• в пуллреквесте не помните, что и зачем меняли
• тесты не падают — значит, всё нормально (хотя половина тестов мокает реальную логику)

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

Чек-лист безопасной работы с AI в продеСкопировано

Семь опасностей разобрали. Теперь о том, как с ними жить, если бизнес уже завязан на вайбкодинг. Список из двенадцати пунктов, который мы собрали из разборов SaaStr, Wiz, Veracode и официальных гайдов Anthropic, OpenAI и Replit.

Шаг 1 — Разделяйте dev и prod на уровне доступа AI

Никогда не давайте AI один и тот же доступ к dev- и prod-окружению. Используйте разные API-ключи, разные базы данных, разные аккаунты в облаке. В идеале AI вообще не имеет доступа к prod без явного human approval.

Шаг 2 — Включите human-in-the-loop для всего, что меняет данные

Любая операция на продакшене (миграция базы, deploy, удаление файлов) должна требовать ручного подтверждения. В Claude Code это делают через систему permissions и хуки. Подробнее в статье «Hooks в Claude Code: 10 защитных хуков». Там показали, как блокировать опасные команды на уровне инструмента.

Шаг 3 — Запускайте AI в sandbox или контейнере

AI не должен иметь прямого доступа к вашему железу или прод-серверу. Запускайте его в Docker-контейнере, виртуальной машине или, ещё лучше, в облачной песочнице с ограниченными правами. Если что-то пойдёт не так, испорчена будет песочница, а не ваш сервер.

Шаг 4 — Включите автоматический secret scanning

В GitHub есть бесплатная функция Secret Scanning, которая ловит API-ключи и токены в коммитах. Включается в настройках репозитория. Дополнительно поставьте pre-commit хук с `git-secrets` или `gitleaks`, который не даст закоммитить файл с ключом локально.

Шаг 5 — Используйте `.env` и никогда не коммитьте его

Все секреты (ключи, пароли, токены) храните в файле `.env`, который добавлен в `.gitignore`. AI знает про эту практику, но часто забывает её применить — проверяйте после каждой генерации, что секреты не попали в закоммиченные файлы.

Шаг 6 — Прогоняйте AI-код через SAST-сканеры

SAST (Static Application Security Testing) — это автоматическая проверка кода на уязвимости из OWASP Top 10. Бесплатные опции: Semgrep, SonarQube Community, Snyk Code. Запускайте их в CI/CD перед каждым деплоем. Они ловят 70–80 % типичных уязвимостей, которые AI генерирует не задумываясь.

Шаг 7 — Просите AI явно учитывать безопасность

В промптах добавляйте: «Учти OWASP Top 10», «Проверь на SQL-инъекции», «Используй параметризованные запросы», «Покажи, где может быть XSS». Когда модель знает, что от неё ждут безопасный код, она генерирует его лучше. Сканеры остаются обязательным слоем поверх.

Шаг 8 — Делайте бэкапы перед каждой операцией над данными

Если AI работает с базой данных, перед каждой миграцией или массовым обновлением — автоматический бэкап. В современных облачных базах это включается одной галочкой. В истории SaaStr Лемкин восстановил данные именно из бэкапа, иначе разговор был бы совсем другой.

Шаг 9 — пишите тесты, которые проверяют реальную логику

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

Шаг 10 — Ограничивайте права AI на уровне базы

Если AI-агент работает с базой, создайте для него отдельную роль с минимально необходимыми правами. Чаще всего достаточно SELECT и INSERT в конкретные таблицы. DELETE, DROP, TRUNCATE — только для аккаунтов, к которым AI не имеет доступа.

Шаг 11 — Логируйте каждое действие агента

Любой агентский режим должен писать в лог: что попросили, что решил, какую команду запустил, какой результат получил. Без логов разбор инцидента превращается в гадание. Логи храните минимум 30 дней, а для prod-инфраструктуры — 90 дней.

Шаг 12 — Учитесь читать код, даже если пишет AI

Это база, без которой все остальные пункты бесполезны. Если вы не можете прочитать сгенерированный код и объяснить вслух, что он делает, — вы не готовы пускать его в продакшен. Чтение чужого кода — отдельный навык, который тренируется так же, как навык писать код самому. Хорошие курсы по программированию и AI учат сразу обоим.

Что делают сами разработчики AI-инструментовСкопировано

Anthropic, OpenAI, Replit и другие крупные игроки знают про эти опасности и встраивают защиты в свои продукты. Понимать, как они устроены, важно: это не заменяет дисциплину, но даёт дополнительный слой безопасности.

Anthropic и Constitutional AI. Модели Claude Opus 4.7 и Claude Sonnet 4.6 обучены по методу Constitutional AI — подходу, при котором модели на этапе тренировки явно показывают, какие действия и ответы считаются приемлемыми, а какие нет. Это снижает вероятность того, что Claude по запросу пользователя напишет вредоносный код, утечёт чувствительные данные или согласится на деструктивную операцию без оговорок.

Claude Code и permission-prompts. В Claude Code от Anthropic любая команда, которая может изменить файлы или окружение, требует подтверждения пользователя. Пользователь видит, что именно собирается сделать AI, и только после явного «да» команда выполняется. Это полностью устраняет сценарий Replit, где агент мог выполнить деструктивную команду без спроса.

Replit Planning Mode. После инцидента с SaaStr Replit добавил режим, в котором AI обсуждает план, но ничего не выполняет. Все действия запускаются только после ручного нажатия кнопки «Approve» на каждом шаге.

Cursor Agent Restrictions. В Cursor можно настроить, какие команды агент имеет право запускать автоматически, а какие требуют подтверждения. Например, всё, что начинается с `rm`, `drop`, `truncate`, можно поставить в запретный список.

GitHub Secret Scanning и Push Protection. GitHub в 2025 году усилил защиту: теперь push-протекшен по умолчанию блокирует коммит, в котором найден ключ известного формата (OpenAI, AWS, Stripe и ещё около 200 провайдеров).

Если вы только начинаете работать с агентскими режимами AI, разобраться в деталях помогут наши статьи «Что такое AI-агенты простыми словами» и «Что такое Claude Code: обзор, цены и как начать пользоваться».

Где научиться работать с AI безопасноСкопировано

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

Чтобы не собирать программу обучения по кусочкам и не нарваться на курс уровня «как нажимать кнопки в ChatGPT», мы собрали актуальную подборку курсов по нейросетям и AI: от коротких интенсивов до годовых программ для тех, кто хочет сделать ремесло основной профессией.

Больше программ — в полном каталоге курсов по нейросетям и искусственному интеллекту

Если интересно глубже разобраться в инструментах вайбкодинга, посмотрите наши обзоры: Cursor AI и сравнение Claude Code vs Cursor. Там разобрали тарифы, фишки и типичные сценарии работы. А для базы про AI-агенты подойдёт статья «Что такое AI-агенты».

Главное про опасности вайбкодинга в двух абзацахСкопировано

Вайбкодинг — мощный инструмент для прототипов, MVP и личных проектов. Опасности начинаются, когда такой код попадает в продакшен и работает с реальными пользователями, реальными деньгами и реальными данными. Семь главных рисков: деструктивные действия агента в живой базе (как у Replit-SaaStr), утечки API-ключей (Moltbook, 1,5 млн ключей), уязвимости в коде (40–62 % по OWASP), технический долг, скрытые баги на стыке систем, зависимость от вендора и потеря навыков ревью.

Защита строится на технических ограничениях: раздельные dev/prod, human-in-the-loop, sandbox, secret scanning, SAST-сканеры, бэкапы перед каждой операцией. Сами разработчики AI-инструментов (Anthropic, Replit, Cursor, GitHub) встраивают защиты на уровне продукта, но ответственность за то, что попадёт в прод, остаётся на человеке.