Вайб-кодинг перестал быть шуткой про ленивых разработчиков: по данным Georgia Tech, за три месяца 2026 года исследователи нашли 74 уязвимости, которые удалось связать с AI-сгенерированным кодом. Как пишет Engadget, термин быстро оброс репутацией хаотичной разработки «на ощущениях», хотя изначально речь была не о халтуре, а о новом способе взаимодействия с LLM. Для русскоязычных команд это уже не философия из X, а практический вопрос: кто отвечает за код, если значимую его часть написал не человек, а модель?
Термин vibe coding в феврале 2025 года предложил Андрей Карпати, AI-исследователь и бывший руководитель направления Autopilot Vision в Tesla. Он описал подход, при котором разработчик почти полностью доверяется языковой модели: формулирует намерение, принимает результат, правит на ходу и не застревает в деталях реализации. В его примере фигурировали Cursor Composer и Claude Sonnet, которые уже тогда достаточно уверенно генерировали рабочие фрагменты кода.
С тех пор модели стали лучше, IDE — навязчивее, а грань между «помощником» и «соавтором» размылась. Вайб-кодинг начали хвалить за демократизацию разработки: человек без классического бэкграунда может собрать небольшой инструмент под свою задачу. В источнике приведён бытовой, но показательный пример: бывшая веттехник сделала приложение для отслеживания инъекций инсулина пожилому коту. Это не единорог на миллиард, зато реальная автоматизация боли, которую раньше никто бы не поставил в спринт.
Критики смотрят на ту же картину с другой стороны. Если человек не понимает созданный код, он не может нормально оценить архитектуру, безопасность и ремонтопригодность. Пока приложение живёт на личном ноутбуке, риск ограничен. Но когда такой подход просачивается в рабочие репозитории, у компании появляется код, который вроде бы проходит тесты, но плохо объясним, слабо сопровождаем и может тащить типовые ошибки из обучающих данных модели.
Самый жёсткий аргумент — безопасность. Исследователи School of Cybersecurity and Privacy при Georgia Tech изучили 43 тыс. security advisories за трёхмесячный период в начале 2026 года и нашли 74 уязвимости, которые смогли напрямую связать с AI-сгенерированным кодом. Из них 14 они отнесли к критическим. Команда отдельно подчеркнула: реальная цифра может быть в 5-10 раз выше, потому что отследить удалось только случаи, где происхождение кода от LLM было корректно раскрыто.
При этом списать всё на любителей уже не получается. В опросе 1 100 профессиональных программистов, которые пробовали AI-инструменты, 72% заявили, что используют их ежедневно. В среднем 42% их кодовой базы уже были AI-generated или AI-assisted. Та же группа ожидает, что к следующему году доля такого кода превысит половину. Даже если выборка не описывает всю индустрию, направление движения довольно прозрачно: AI-код больше не живёт только в пет-проектах.
Здесь важно не смешивать разные практики в одну кучу. AI-assisted code — это автодополнение, ревью, поиск ошибки, объяснение API, рефакторинг скучного участка. AI-generated code — это когда модель пишет значимый кусок логики по описанию, а человек принимает его как черновик или почти готовое решение. По данным Stack Overflow Developer Survey 2025, 47,1% респондентов пользовались AI-инструментами ежедневно, но 72% говорили, что вайб-кодинг не является частью их рабочего процесса, ещё 5% подчеркнули это особенно резко. Парадокс только на первый взгляд: разработчики охотно берут AI как инструмент, но не хотят отдавать ему авторство без контроля.
Для бизнеса спор упирается не в терминологию, а в процесс. Если команда использует LLM для ускорения, ей нужны правила: где AI-код допустим, кто его ревьюит, какие проверки обязательны, как фиксируется происхождение критичных фрагментов. Без этого вайб-кодинг превращается в скрытую техническую задолженность: сегодня фича выходит быстрее, завтра никто не понимает, почему модуль ломается при простом изменении входных данных.
Есть и кадровой слой, менее удобный для обсуждения. Многие задачи, которые senior-разработчики теперь отдают AI, раньше доставались junior-инженерам: простые багфиксы, шаблонный код, разбор устаревших участков, подготовка тестов. Если компании будут меньше нанимать новичков, потому что «модель справляется», рынок получит странную воронку: много инструментов для ускорения опытных специалистов и всё меньше мест, где можно стать опытным специалистом.
Вайб-кодинг вряд ли исчезнет: слишком велик выигрыш в скорости и слишком соблазнительна идея собрать работающий прототип без долгого входа в стек. Вопрос теперь не в том, можно ли писать код с LLM, а в том, где проходит граница между ускорением разработки и потерей инженерной ответственности. Команды, которые проведут эту границу явно, получат инструмент. Остальные получат репозиторий, который выглядит продуктивно ровно до первого серьёзного инцидента.