Команда AI for Devs подготовила перевод статьи о феномене vibe coding и agentic coding. ИИ позволяет любому — от маркетолога до дизайнера — выпускать рабочие приложения за считанные часы. Но скорость имеет оборотную сторону: код без ревью и тестов становится уязвимостью, а компании сталкиваются с новым классом рисков безопасности.
Vibe coding — новая блестящая игрушка в мире разработки. Возможно, вы уже сталкивались с этим на практике:
Продавец делает собственный инструмент с помощью ИИ.
Дизайнер заливает изменения в интерфейсе прямо в GitHub.
Маркетинговая команда пишет софт для кампании вместо того, чтобы продлевать контракт с подрядчиком.
Как сказал Стив Йегги в подкасте The Pragmatic Engineer, ИИ «снес все двери». Код теперь пишут не только разработчики. Любой, у кого есть промпт, может выпустить приложение. Большинство людей, которые этим занимаются, даже не знают, что это называется vibe coding. Они просто описывают на английском, что хотят, и получают готовый код от ИИ.
Этот сдвиг изменил не только то, кто пишет софт, но и скорость, с которой он появляется. Такая скорость впечатляет, но вместе с ней приходит и серьёзная проблема: большая часть этого кода работает «вслепую» — без ревью, без тестов и без какой-либо безопасности.
Когда происходит минус вайб
Есть немало примеров, когда vibe coding оборачивался проблемами:
Инцидент с Replit. Джейсон Лемкин из SaaStr доверил AI-агенту Replit разработку приложения продакшн-уровня. Сначала всё было захватывающе: прототипы за часы, проверки QA, быстрый прогресс. Но потом всё пошло наперекосяк. ИИ начал врать про unit-тесты, игнорировал code freeze и в итоге удалил всю продакшн-базу SaaStr. Месяцы собранных вручную записей руководителей исчезли за одну ночь. Как сказал Лемкин в интервью ZDNet: «Перетерать продакшн-базу нельзя. Никогда. Ни при каких обстоятельствах».
Приложение Tea. Админские руты оказались незащищёнными, и данные пользователей были доступны любому, кто случайно наткнётся на нужный эндпоинт. То, что выглядело как безобидный эксперимент, мгновенно превратилось в угрозу приватности.
Значительная часть приложений, созданных энтузиастами, содержит серьёзные уязвимости ещё до запуска. Если взять десять таких проектов, как минимум одно из них наверняка окажется взламываемым.
Эти провалы важны, потому что уязвимости в vibe-коде — это не просто мелкие баги. Они часто затрагивают базовые механизмы защиты: аутентификацию, доступ к данным, управление секретами. Если приложение работает с платежами или персональными данными, последствия выходят далеко за пределы технических: это уже про деньги, законы и репутацию.
Маккензи Джексон, деврел в Aikido Security, выразился предельно ясно:
ИИ по умолчанию не пишет безопасный код. Он просто выдаёт то, что работает. А под капотом этот код оставляет дверь настежь открытой для атак.
Почему vibe coding распространяется так быстро
Главное отличие vibe coding в том, что им занимаются все подряд. Дизайнеры, продакт-менеджеры, продавцы, маркетинговые команды — все выкатывают код. Атакующим всё равно, пет-проект это или корпоративное ПО. Их волнует только одно: открыта ли дверь.
Скорость — это преимущество, но одновременно и проблема. То, что раньше занимало недели, теперь можно собрать за один день. Это значит, что любая команда может наклепать прототипы и инструменты, не дожидаясь инженеров. Подвох в том, что новые «разработчики» совсем не думают о контроле доступа, фильтрации входных данных или обновлениях зависимостей.
Виллем Делбар, основатель и CTO Aikido, описал этот сдвиг в интервью ZDNet как «идеальный шторм»:
Vibe coding делает разработку доступнее, но вместе с тем создаёт "идеальный шторм" рисков безопасности, с которыми не справляются даже опытные разработчики. SQL-инъекции, path traversal, хардкод секретов.
Маккензи Джексон предупреждает, что ситуация будет только ухудшаться. В разговоре с TechMonitor он отметил:
Всё больше людей без серьёзного опыта в инженерии и безопасности используют эти инструменты для написания софта… а это значит, что нас ждёт ещё больше AI-кода, который никто толком не проверял.
Так vibe coding превращается в то, что Маккензи называет «уязвимость как сервис». Чем быстрее неподготовленные люди штампуют приложения с помощью ИИ, тем быстрее дыры множатся по всему интернету.
Безопасный вайб
Мы уже публиковали чеклист по безопасности для vibe кодеров. Там собраны основы: аутентификация, фильтрация входных данных, сканирование и управление секретами. Но главная мысль здесь — осознанность. Если вы экспериментируете с AI-кодингом, или это делает ваша команда, важно понимать: блестящий прототип, который вы выкатываете за один вечер, может оказаться чёрным ходом для атакующих.
Что могут сделать команды?
Относиться к коду от ИИ так, будто его написал джун: проверять, тестировать, закрывать дыры.
Использовать готовые сервисы для аутентификации вместо самописных решений.
Держать секреты подальше от фронтенда и репозиториев.
Не ограничиваться сканами уязвимостей — продумывать и логические ошибки.
Звучит очевидно, но большинство vibe кодеров этого не делают. Поэтому безопасность должна быть частью обсуждения — даже для тех ролей, которые находятся вне инженерии.
Что такое Agentic Coding?
Agentic coding — это следующий шаг после vibe coding. Вместо того чтобы просить у ИИ сниппеты и вставлять их вручную, ИИ-агенты берут процесс под полный контроль: сами пишут, запускают и модифицируют код. Они могут устанавливать зависимости, гонять тесты, рефакторить файлы и даже обновлять инфраструктуру.
Этим подходом чаще пользуются разработчики и техкоманды, а не случайные пользователи, поэтому он кажется более надёжным. Но это ложное чувство. Agentic coding создаёт более чистый и «профессиональный» код, однако за этим фасадом скрываются риски.
Agentic Coding на полную катушку
Если vibe coding часто рождает грязный, хрупкий код, то agentic coding выдаёт результат, который выглядит безупречно. Именно в этом и кроется опасность. Одно неверное решение может прокатиться по всей системе и незаметно распространиться через зависимости и окружения.
ИИ-инструменты штампуют такой код быстрее, чем когда-либо, и по умолчанию он никак не защищён. Чистый код проще внедрить и переиспользовать, а значит, уязвимости распространяются тихо и стремительно.
Единственный способ контролировать риск — ловить ошибки до того, как они попадут в продакшн. Для этого нужно подключаться напрямую к CI/CD-пайплайнам, сканировать каждую зависимость и проверять ключевые допущения с мгновенной обратной связью.
О чём CISO стоит задуматься
Для руководителей в области безопасности vibe coding — это не просто тренд среди разработчиков. Он меняет сам процесс создания софта в компании. Роль CISO сдвигается от «сторожа у ворот» к архитектору защитных барьеров, которые позволяют экспериментировать, не обрушивая продакшн.
Вот несколько ключевых идей:
MTTG (Mean Time to Guidance).
Классические метрики MTTD и MTTR измеряют последствия уже случившихся проблем. MTTG показывает, насколько быстро vibe кодеры получают практические рекомендации до того, как их код превратится в уязвимость. Чем ниже MTTG, тем меньше инцидентов возникает в принципе.
PromptBOM.
Аналог SBOM, но для AI-кода. Простой список с указанием модели, промпта и параметров, которые породили сниппет. Если что-то ломается, можно понять, откуда это взялось и почему. Прозрачность означает ответственность.
Уровни доверия к vibe coding (VCAL 0–5).
По аналогии с уровнями автономного вождения, но для кодинга с ИИ. VCAL-1 — ИИ просто подсказывает. VCAL-3 добавляет защитные рамки и фиксацию происхождения. VCAL-5 — полностью автономные мёрджи для низкорисковых изменений с непрерывной аттестацией. Такой фреймворк помогает CISO управлять ожиданиями, а не действовать вслепую.
Русскоязычное сообщество про AI в разработке

Друзья! Эту статью перевела команда ТГК «AI for Devs» — канала, где мы рассказываем про AI-ассистентов, плагины для IDE, делимся практическими кейсами и свежими новостями из мира ИИ. Подписывайтесь, чтобы быть в курсе и ничего не упустить!
Главный вывод
Не пытайтесь научить каждого сотрудника «заниматься безопасностью». Вместо этого сделайте так, чтобы безопасность была встроенной, невидимой и масштабируемой — в том виде, в котором люди реально работают с ИИ.
Комментарии (2)
Shaman_RSHU
04.09.2025 08:22И как PromptBOM поможет на практике? Ну узнаю я, что это наго***дил Grok, а не Cursor. И что дальше делать? Запретить его использовать?
David_Osipov
Это что даст? Модели по своей природе будут писать разный код для одного и того же промпта, это если условиться, что компании не будут модели обновлять.
Имхо, я сейчас создаю такую либу и могу только сказать, что нужно критически проверять сам код несколькими моделями несколько раз, потом обложить его юнит, интеграционными, фазз тестами, потом ещё провести оценку угроз по Страйду и попросить ИИ сыграть в red teaming с написанием PoC, а сами PoC кидать в adversarial tests папочку и гонять со всеми тестами.
Помимо этого всего, надо ещё обложится всякими SAST и прочими тулзами, потому что ИИ мелочи не видит - они как раз и помогут находить.