Скрытый налог на AI-код: где vibe coding даёт сбой

Расскажу про разговор со стартапером на прошлой неделе. Человек выпускал фичи с бешеной скоростью — втрое быстрее, чем на предыдущем проекте. «Мы всё делаем через vibe coding», — говорил он с гордостью. А потом упомянул, что его систему аутентификации взломали дважды за месяц.

Связь не случайна.

Ловушка скорости

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

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

Запросили агента, получили результат, запушили в прод — и всё, без полноценной проверки. Ни спецификаций, ни аудита безопасности, ни верификации тестов. Убираете именно те контрольные точки, которые защищают пользователей и вашу репутацию.

Где AI ошибается (предсказуемо)

Самое опасное: AI ошибается не случайно. Дефекты концентрируются в самых уязвимых местах.

XSS-уязвимости встречаются в 2.74 раза чаще, чем в коде, написанном человеком. Логические ошибки — в 1.75 раза. Это не косметические баги и не проблемы обработки граничных случаев. Это те самые уязвимости, которые критичны для аутентификации, платёжных систем и любой логики с ненадёжным пользовательским вводом.

Независимые данные по безопасности подтверждают картину. Индустриальные отчёты напрямую связывают рост числа уязвимостей с увеличением использования генеративного AI в разработке. Причём растёт и их серьёзность.

Три свойства, которые делают это опасным

Дело не только в отдельных ошибках. Проблема накапливается из-за того, как AI-агенты работают:

Скорость опережает проверку. Агент генерирует тысячу строк за секунды. Человек не способен полноценно проверить этот код с той же скоростью. Возникает структурное давление в сторону пропуска ревью.

Недетерминированность мешает воспроизведению. Один и тот же промпт даёт разный результат. Нашли баг? Попробуйте точно воспроизвести, какая версия кода его вызвала. Отладка становится движущейся мишенью, а логи аудита — ненадёжными.

Давление стоимости толкает к экономии. Токены стоят денег. Полноценное тестирование стоит ещё больше токенов. Экономический стимул подталкивает к сокращению верификации — прямо противоположному тому, что требует безопасность.

Реальный ущерб, реальные примеры

Может показаться, что это теория. Это не так.

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

Золотая середина

Я не призываю отказаться от AI-инструментов. Это было бы так же бессмысленно, как советовать разработчикам в 2015 году избегать GitHub из-за того, что хостинг кода может использоваться для плохих практик. Прирост продуктивности реален, технология никуда не денется.

Но нужно честно признать, куда смещаются узкие места.

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

Вот как это выглядит на практике:

Относитесь к AI как к быстрому стажёру, а не к опытному инженеру. Джуниор может генерировать код быстро. Сеньор может объяснить, почему этот код безопасен для запуска. AI хорош в первом. Во втором нужны люди.

Введите контракт для pull request'ов. Каждый PR должен документировать: каков был замысел? Какие доказательства, что решение работает? Какой уровень риска? Использовался ли AI для генерации, и если да — где именно? Это возвращает подотчётность, которую vibe coding убирает.

Децентрализуйте критичные проверки безопасности. Не полагайтесь на middleware аутентификации как единственный заслон. Добавляйте проверки авторизации напрямую в обработчики маршрутов. Уводите критичную логику из единых точек отказа, которые AI может неочевидно неправильно сконфигурировать.

Используйте vibe coding по назначению. Сcaffold для CLI? Прототип UI? Исследование вариантов оптимизации перед выбором архитектуры? Идеальные сценарии. Отправка напрямую в продакшен с обработкой ненадёжного ввода? Здесь нужна spec-driven разработка с обязательным ревью.

Вкладывайтесь в threat modeling до мержей. Любой кодовый путь с ненадёжным вводом требует человеческой проверки threat model перед попаданием в продакшен. Не опционально. Нельзя пропускать, когда опаздываете по срокам.

Настоящее правило

Граница между «можно vibe'ить» и «нужно проектировать» нечёткая. Она смещается по мере улучшения моделей и усложнения системы. Правило не может звучать как «никогда не используй AI для кода». Правило: знай, в каком режиме работаешь, и ставь проверки соразмерно риску.

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

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

Ваши пользователи рассчитывают, что вы поймаете то, что AI пропустил.

В NameOcean мы верим, что мощные инструменты заслуживают вдумчивой реализации. Регистрируете ли вы домен для нового проекта или разворачиваете AI-ассистируемый код — фундаментальные принципы ответственной инженерии остаются в силе. Делайте быстро, но делайте правильно.