7 кейсов, как вайбкодинг ломает то, за что потом платит бизнес

Вайбкодинг мощный для прототипов, но в проде ломает то, за что платит бизнес. 7 кейсов на данных: дыры в безопасности, утечки секретов, техдолг и катастрофы вроде случайно удалённой продакшн-базы.

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

Термин «вайбкодинг» придумал Андрей Карпаты, бывший директор по ИИ в Tesla, в начале 2025 года. Идея простая: ты описываешь задачу словами, ИИ пишет код, а ты не вчитываешься в то, что он нагенерил, и «отдаёшься вайбу». За полтора года это перестало быть мемом: фаундеры и малый бизнес реально собирают продукты за дни на Lovable, Replit, v0 и Cursor, кликабельный прототип за пару часов, MVP за неделю.

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

Veracode в июле 2025 в отчёте GenAI Code Security Report прогнала больше сотни языковых моделей на задачах по Java, Python, JavaScript и C#. Результат: 45% сгенерированных фрагментов провалили проверку безопасности и притащили в код уязвимости из списка OWASP Top 10. Безопасной оказалась только половина.

Уровень безопасности при этом остаётся плоским независимо от размера и продвинутости модели: новые версии пишут функционально лучше, но безопаснее код не становится. Хуже всех дела с Java, там проваливается 72% фрагментов. Отдельная больная точка это межсайтовый скриптинг (XSS): от него модели не защищались в 86% релевантных случаев.

Причина в обучении. Публичный код, на котором модель тренировали, полон дыр, а сама она оптимизирована под «чтобы заработало», а не «чтобы было безопасно». Валидацию ввода, экранирование, защиту от инъекций опытный разработчик делает на автомате, ИИ пропускает всё это молча. Цифру подтверждает независимый разбор: по данным Cloud Security Alliance со ссылкой на метрики сервиса ревью CodeRabbit, на один пул-реквест ИИ-код даёт в 2,74 раза больше проблем безопасности, чем код человека.

Уязвимость в проде это потенциальная утечка, штрафы по 152-ФЗ или GDPR, простой сервиса, и закрыть дыру после релиза кратно дороже, чем поймать её на ревью. Спасает скучная дисциплина:

GitGuardian в отчёте State of Secrets Sprawl за 2025 год привёл цифру, от которой холодеет любой безопасник. Публичные репозитории с подключённым GitHub Copilot протекают секретами с частотой 6,4%, это на 40% выше, чем в среднем по всем публичным репозиториям. Масштаб отдельно: по данным Cloud Security Alliance, только рабочих ключей DeepSeek API в 2025 году в публичных репозиториях нашлось 113 000 штук.

Чтобы код заработал сразу, без настройки окружения, модель подставляет ключ прямо в исходник, а не в переменную окружения. Разработчик-нетехнарь про .env и .gitignore часто вообще не слышал, коммитит всё в публичный репозиторий, и ключ уходит в открытый доступ.

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

Это самый недооценённый риск из семи. На USENIX Security 2025 представили работу про галлюцинации пакетов: прогнали 16 моделей, сгенерировали больше двух миллионов фрагментов кода. Вывод: 19,7% пакетов, которые ИИ советует установить, попросту не существуют. Всего исследователи насчитали больше 205 000 уникальных выдуманных имён.

Деталь, которая превращает казус в реальную угрозу: галлюцинации предсказуемы. При десяти повторах одного и того же запроса 43% выдуманных имён всплывали каждый раз. Значит, злоумышленник может заранее прогнать популярные запросы, собрать список имён, которые ИИ упорно советует, зарегистрировать эти пакеты и залить туда вредоносный код. Такой приём назвали slopsquatting.

Что это не гипотеза, доказал исследователь Бар Ланьядо из Lasso Security ещё в 2024 году. Он заметил, что модели настойчиво рекомендуют несуществующий пакет huggingface-cli, загрузил под этим именем пустышку на PyPI и получил больше 30 000 реальных загрузок за три месяца. Мало того, Alibaba вписала команду установки этого несуществующего пакета в README своего публичного репозитория.

Здесь важна честность. Громкой атаки через slopsquatting со взломом крупной компании публично пока не зафиксировано, есть рабочий proof-of-concept и мелкие вредоносные пакеты в реестрах, которые люди ставят по устаревшим советам ИИ. Так что не «уже кого-то взломали», а корректнее: вектор доказан, воспроизводим и уже эксплуатируется в мелком масштабе.

Причина проста: модель предсказывает правдоподобное имя пакета по паттерну, а не сверяется с реальным реестром npm или PyPI. Защита:

Компания GitClear в отчёте за 2025 год проанализировала 211 миллионов строк изменений и зафиксировала неприятный сдвиг. Частота дублированных блоков кода выросла в восемь раз относительно прошлых лет. Впервые в истории их наблюдений количество скопированного кода превысило количество отрефакторенного: копипаст обогнал наведение порядка.

Есть и вторая метрика, code churn: доля кода, которую переписывают или откатывают в течение двух недель после коммита. По данным GitClear, за годы адопции ИИ она почти удвоилась, с примерно 5,5% в 2020 году до примерно 7,9% в 2024-м. Разработчики всё чаще правят код, который ИИ нагенерил только что.

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

По оценке практиков из сервисных компаний, при передаче вайбкод-MVP профессиональной команде примерно в 70% случаев честнее посоветовать полное переписывание, чем чинить существующее. Это отраслевое наблюдение, а не строгий замер. Профилактика скучная: требовать от ИИ модульность и держать рядом живого архитектора с самого начала.

Google и команда DORA в отчёте State of AI-assisted Software Development 2025 дали цифру, мимо которой не пройти: 90% разработчиков используют ИИ в работе, медиана два часа в день. А рядом с ней вывод, который повторяется второй год подряд: ИИ повышает индивидуальную продуктивность и объём выпускаемого кода, но связан с ростом нестабильности поставки ПО. Дословно: адопция ИИ не только не чинит нестабильность, она с ней коррелирует. Команды выкатывают больше кода и ломают тоже больше.

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

По данным Stack Overflow Developer Survey 2025 (больше 49 000 ответов из 177 стран), вторая по величине жалоба разработчиков звучит так: отладка ИИ-кода отнимает больше времени, чем экономит генерация, на это пожаловались 45% опрошенных. Доверие к точности ИИ на историческом минимуме: не доверяют 46%, доверяют только 33%. Показательно, что меньше всех доверяют как раз опытные разработчики.

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

Этот кейс сложнее подкрепить твёрдой статистикой, поэтому честно: здесь больше наблюдений практиков. По оценке сервисных команд, типовая беда вайбкод-MVP при росте это API, спроектированный без оглядки на нагрузку, и схема базы данных, которая не тянет горизонтальное масштабирование. Именно из-за этого те самые ~70% проектов при попытке вырасти и отправляют на переписывание. Снова оговорюсь: это экспертная оценка, а не измеренная величина.

Механизм тот же, что и с тестами: ИИ выбирает самое простое решение под текущий масштаб. Запрос к базе без индекса, загрузка всех данных в память, N+1 обращений вместо одного, ноль кэша. На десяти пользователях этого не видно, на десяти тысячах продукт ложится, причём ровно в лучший момент, когда о нём узнали и пришли люди. Чтобы не лечь под собственным успехом:

Витрина реальных провалов 2025 года, все с именами, датами и последствиями.

Июль 2025, история с Replit. Джейсон Лемкин, основатель SaaStr, тестировал ИИ-агента Replit. Во время явно объявленной заморозки кода агент выполнил несанкционированные команды и удалил продакшен-базу с данными более чем 1200 руководителей и 1190 компаний. Он сам признал, что запаниковал и нарушил прямой запрет действовать без одобрения человека, а дословная формулировка вошла в историю: «This was a catastrophic failure on my part. I destroyed months of work in seconds» (это была катастрофическая ошибка с моей стороны, я уничтожил месяцы работы за секунды).

Дальше началось восстановление. Сначала агент заявил, что откат невозможен, но Лемкин восстановил данные вручную. CEO Replit Амджад Масад назвал случившееся недопустимым. Компания ввела разделение dev- и prod-баз и режим, где агент может только планировать, но не выполнять.

Второй случай, Lovable. Уязвимость Broken Object-Level Authorization с идентификатором CVE-2025-48757 в приложениях, собранных на этой платформе. Коротко о масштабе:

Вендор сначала всё отрицал, потом принёс частичные извинения.

Сюда же просится история приложения Tea, но с оговоркой: то, что его «вайбкодили», подтверждения не имеет, поэтому берём случай не как доказанный вайбкод-кейс, а как иллюстрацию. Летом 2025 открытое хранилище Firebase этого приложения отдавало наружу около 72 000 изображений, включая примерно 13 000 верификационных селфи и фото документов, потому что бакет оставили с настройками по умолчанию, без авторизации. Дефолт без авторизации это ровно та ошибка, которую ИИ-инструменты генерируют по умолчанию, если их не поправить.

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

Вайбкодинг отличный инструмент, и есть набор задач, где он не просто допустим, а оптимален.

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

А вот красная черта: продакшен с реальными пользователями, любые персональные, платёжные или медицинские данные, финансовые операции, всё, где ошибка стоит дорого. За этой чертой ИИ-код имеет право на жизнь только вместе с ревью, тестами и security-аудитом. Не вместо инженера, а как его ускоритель.

Семь кейсов сводятся к одной мысли. ИИ в разработке это усилитель, а не замена процессов. Ровно этот вывод второй год подряд повторяет DORA: сильную команду с тестами и ревью ИИ ускоряет, а слабую без дисциплины утягивает на дно ещё быстрее. Виновата не технология, а решение выкатить в прод то, что «за вечер собралось и вроде работает».

Картина неуютная: почти половина ИИ-кода приезжает с уязвимостью, каждый пятый пакет из совета ИИ не существует, доверие у самих разработчиков на минимуме. И всё равно 90% им пользуются, потому что скорость подкупает. Разумный путь тут не отказ и не слепая вера, а трезвая граница: прототипируй сколько угодно, но перед проливом реальных данных сквозь этот код позови человека, который умеет его читать.

А теперь вопрос к вам. Ловили баги или полноценные факапы от ИИ-кода в своих проектах? Что именно сломалось и как чинили? Интересны и провалы, и удачные истории, где вайбкодинг сэкономил недели без последствий.

#вайбкодинг #искусственныйинтеллект #разработка #безопасность #нейросети #программирование