О вайб-кодинге пишут в двух тональностях: восторженной и презрительной. Обе бесполезны. Ниже — семь рисков, которые подтверждены замерами или проявляются у всех, кто дошёл до второго месяца, и то, что с каждым реально делать. Это не аргумент против метода: начинать стоит, просто зная, где тонко.
Короткий ответ
Главная проблема не в том, что нейросеть пишет плохой код. Синтаксических ошибок в нём как раз мало — по замерам их стало меньше на 76%, логических багов на 60%. Проблема в том, что код выглядит правильным и при этом небезопасен, а человек, который его не читал, не может этого заметить.
Веракод прогнал больше сотни моделей через 80 задач с требованиями к безопасности: 45% сгенерированных фрагментов вносят уязвимости из списка OWASP Top 10. Показатель не улучшился за несколько циклов замеров с 2025 по начало 2026 года, несмотря на заявления вендоров.
1. Уязвимости, которых не видно
Цифры по классам уязвимостей выглядят хуже общей: 86% образцов не выдержали проверку на межсайтовый скриптинг, 88% оказались уязвимы к внедрению в логи. Худший язык — Java с 72% провалов, Python и JavaScript держатся в диапазоне 38–45%.
Отдельное исследование Университета Карнеги — Меллона даёт ту же картину с другой стороны: 61% сгенерированного кода работает правильно, но только 10,5% проходит проверку безопасности. То есть «работает» и «безопасно» здесь почти не связаны между собой.
Почему это опаснее обычных багов: обычный баг заметен — что-то не работает. Уязвимость не мешает ничему до того дня, когда её находят.
Что делать. Отделять «работает у меня» от «можно пускать людей». Всё, где есть чужие данные, вход по паролю или деньги, проверяется отдельно — либо инструментом, либо человеком. Прямо спросить агента «найди в этом коде уязвимости и объясни каждую» — не панацея, но ловит очевидное. Общие принципы — защита данных и агенты.
2. Пакеты, которых не существует
Около 20% сгенерированных фрагментов ссылаются на библиотеки, которых нет. Это обычная галлюцинация модели, и сама по себе она безобидна: установка падает с ошибкой.
Опасность в том, что имена галлюцинаций предсказуемы и повторяются. Появился отдельный приём атаки — slopsquatting: злоумышленник заранее регистрирует придуманное моделью имя пакета и кладёт туда вредоносный код. Дальше разработчик копирует команду установки из ответа агента и ставит его сам.
Что делать. Перед установкой незнакомого пакета — тридцать секунд на проверку: существует ли он давно, сколько загрузок, есть ли репозиторий и живые коммиты. Пакет, появившийся неделю назад с одной версией, — повод остановиться.
ОсторожноЭто единственный риск из списка, где вред наступает мгновенно и на вашей машине, а не когда-нибудь потом на проде.
3. Код, который придётся поддерживать
Через месяц любой код становится чужим — включая тот, что вы написали сами. Код, который вы никогда не читали, становится чужим сразу.
Проявляется это не на старте, а когда нужна вторая версия. Просьба «добавь ещё вот такую возможность» на разросшемся проекте начинает ломать то, что работало, а понять почему — нечем.
Что делать.
- Держать проекты маленькими и разделёнными. Три отдельные утилиты поддерживать проще, чем один комбайн.
- Просить агента объяснять устройство: «опиши в двух абзацах, как это устроено и где что лежит». Читать объяснение, даже не читая код.
- Хранить историю версий, чтобы можно было откатиться к рабочему состоянию.
- Записывать правила проекта в файл, который агент читает при каждом заходе — CLAUDE.md или AGENTS.md. Это радикально уменьшает «а почему он опять сделал по-своему».
4. Ложная уверенность
Самый недооценённый пункт, и он же объясняет остальные. Синтаксических ошибок стало меньше на три четверти, логических — на две трети. Код запускается с первого раза, выглядит аккуратно, снабжён комментариями.
Ощущение надёжности при этом растёт быстрее, чем сама надёжность. Разработчики в опросах сообщают, что чувствуют себя продуктивнее и увереннее — и это правда про скорость и неправда про качество.
Что делать. Ввести себе правило: уверенность в результате берётся из проверки, а не из внешнего вида кода. Если проверить нечем — значит, задача не для вайб-кодинга.
5. Счёт за токены
Расход растёт не линейно. Первые задачи стоят копейки, а потом выясняется, что агент на каждом шаге перечитывает проект целиком, и месяц активной работы обходится ощутимо.
Отдельная статья — циклы «не помогло, попробуй ещё раз»: каждый круг оплачивается, а результат не гарантирован.
Что делать. Посчитать заранее — калькулятор расхода на модель даёт порядок цифр. Работать в подписке, а не по API, пока объём не стал предсказуемым: что выгоднее и когда. Не держать в проекте лишнего — чем больше файлов, тем дороже каждый запрос.
6. Навык не растёт, а иногда падает
Спорный пункт, поэтому аккуратно. Для человека без опыта в коде вайб-кодинг — чистое приобретение: он может сделать то, чего не мог. Здесь минуса нет.
Минус появляется у тех, кто программировать умеет и перестаёт. Способность быстро читать чужой код и держать в голове устройство системы поддерживается практикой; без неё она уходит. А именно она нужна в тот момент, когда агент застрял и надо разобраться самому.
Что делать. Читать диффы хотя бы выборочно. Раз в неделю делать небольшую задачу руками. Это не про ностальгию, а про сохранение способности проверять.
7. Юридическая и организационная сторона
Три вопроса, которые всплывают в компаниях и не всплывают у частников:
- Лицензии зависимостей. Агент подтягивает библиотеки, не спрашивая про условия использования. В коммерческом продукте это может оказаться проблемой.
- Куда уходит код. Работая с облачной моделью, вы отправляете ей содержимое проекта. Для внутренней разработки компании это отдельное согласование, а иногда прямой запрет — тогда остаётся локальная модель.
- Кто отвечает за результат. Никто ещё не выиграл спор аргументом «так написала нейросеть». Ответственность остаётся на том, кто выпустил.
Где вайб-кодинг работает без оговорок
Чтобы список выше не читался как «не связывайтесь». Есть зона, где риски малы, а выигрыш огромный:
- внутренние инструменты — калькуляторы, обработка выгрузок, отчёты для себя;
- прототипы — проверить идею за вечер вместо недели;
- разовые задачи — переименовать тысячу файлов, вытащить данные из документов;
- сайты-визитки без личных кабинетов — пошагово;
- автоматизация своей рутины — то, что раньше не делали, потому что дорого заказывать.
Общее у всех пяти: нет чужих данных, нет денег, результат проверяется глазами. Пока задача укладывается в эти рамки, всё перечисленное выше — не про вас.
Коротко о главном
- 45% сгенерированного кода вносит уязвимости из OWASP Top 10; по межсайтовому скриптингу — 86% провалов. Замер стабилен с 2025 года.
- Работает ≠ безопасно: 61% кода функционален, 10,5% проходит проверку безопасности.
- Каждый пятый фрагмент ссылается на несуществующий пакет — проверяйте имена перед установкой.
- Синтаксис стал чище, а уверенность выросла сильнее качества. Проверка важнее ощущения.
- Границу проводить по данным и деньгам: свои задачи — смело, чужие данные и платежи — только с проверкой.
Дальше: с чего начать правильно, чем это делают, что происходит с профессией.
Источники замеров
- Veracode, GenAI Code Security Report — 100+ моделей, 80 задач: 45% с уязвимостями OWASP Top 10, Java 72%, XSS 86%, внедрение в логи 88%.
- Cloud Security Alliance, исследовательская записка о росте CVE в сгенерированном коде: ~20% ссылок на несуществующие пакеты, slopsquatting; синтаксические ошибки −76%, логические −60%.
- Университет Карнеги — Меллона: 61% кода работает верно, 10,5% проходит проверку безопасности.
- CSET Джорджтаунского университета: 86% провалов по защите от XSS.