Вайбкодинг обещает скорость там, где классическая разработка требует недель. Крупные компании смотрят на него с интересом, но в продакшн, как правило, не пускают. Владислав Степанов, архитектор Nord Clan, объясняет, где вайбкодинг реально ускоряет работу, где создаёт технический долг и почему через год эксплуатации счёт почти всегда оказывается не в пользу ИИ-агентов.
Где вайбкодинг работает — и почему именно там
Вайбкодинг даёт реальный выигрыш на задачах с чёткими границами и изолированным контекстом: прототипы, внутренние инструменты, автоматизация рутины, интеграционные скрипты. Общий признак таких задач — весь контекст помещается в запрос или в структурированную документацию. ИИ-агент работает в замкнутом пространстве, где у него есть всё необходимое для точного результата.
Как только задача выходит за эти рамки — требует погружения в логику легаси-системы, согласования с несколькими командами или соблюдения регуляторных требований — актуальность вайбкодинга падает.ИИ-агент угадывает там, где нужна точность, и часть таких решений потом требует ручной проверки и исправления. В таких случаях вайбкодинг не ускоряет процесс, а замедляет его.
Что происходит через год эксплуатации
Разница между вайбкодингом и классической разработкой становится наглядной не в момент сдачи задачи, а в процессе эксплуатации. Если документация не обновляется после каждой итерации, агент начинает дрейфовать: создаёт функции с той же сигнатурой, но другой логикой, использует устаревшие абстракции, пропускает побочные эффекты.
Поначалу расхождения незначительны. Через несколько месяцев они накапливаются до состояния, когда систему проще переписать, чем отлаживать. Выход из этой ситуации существует, но он меняет саму природу процесса: постоянное обновление документации и валидация на каждом этапе дают предсказуемый результат — только такой подход уже выходит за рамки вайбкодинга в его исходном понимании. Скорость остаётся, но исчезает главное свойство — возможность работать без строгой дисциплины.
Важно учитывать и еще одну особенность. ИИ хорошо справляется с генерацией нового кода, но гораздо хуже — с безопасным рефакторингом существующего. Для enterprise это критично: по мере развития системы большую часть времени команда тратит не на создание новых функций, а на упрощение архитектуры, устранение технического долга и сокращение сложности. Если после внедрения ИИ объем кода постоянно растет, а существующий не становится проще, это скорее повод насторожиться, чем считать такой подход успешным.
Тут нужно что-то про экономику добавить типа На этапе написания кода вайбкодинг действительно сокращает время разработки. Но стоимость программного продукта складывается не только из первой версии. Основные расходы появляются позже — при сопровождении, развитии функциональности, исправлении ошибок и подключении новых команд. Если качество архитектуры и документации снижается, выигрыш первых недель постепенно превращается в дополнительные месяцы поддержки. Поэтому в крупных компаниях оценивают не скорость написания первой версии, а совокупную стоимость владения системой.
Три класса уязвимостей, которые агент вносит незаметно
Безопасность кода, написанного ИИ-агентом, — отдельная проблема. В enterprise ИИ не заменяет инженерные практики безопасности — он сам становится объектом контроля. Есть три класса уязвимостей, которые появляются в вайбкод-проектах чаще всего.
Первый — угадывание безопасных практик. Агент, не имея контекста существующей политики безопасности, может сгенерировать код с SQL-инъекцией, некорректной валидацией входных данных или утечкой чувствительной информации в логи. В продакшне такой код становится точкой входа для атаки.
Второй — дрейф абстракций. Когда агент создаёт новую функцию вместо использования существующей, он может обойти авторизационные или аудитовые слои, встроенные в старую абстракцию. При код-ревью это не очевидно, если ревьюер не знает всего ландшафта системы. Итог — операции выполняются, но без обязательной проверки прав доступа или фиксации в журнале аудита.
Третий — внедрение зависимостей. Агенты склонны подключать пакеты для решения локальной задачи без аудита их безопасности, лицензий и истории уязвимостей. Одна непроверенная зависимость может открыть доступ к данным или нарушить лицензионные обязательства компании.
Проверить всё это до попадания кода в продакшн позволяет обязательный статический анализ безопасности в CI/CD, валидация каждого плана на соответствие политике безопасности и человеческий аудит изменений, касающихся аутентификации, авторизации и обработки данных.
Вайбкодинг и легаси: надстройка поверх проблем
В промышленных компаниях разработка часто завязана на системы, которым по
Проблема усугубляется тем, что языковые модели хорошо покрывают мейнстримовые стеки, но для старых систем это покрытие резко падает. Агент не знает неявных контрактов
Как корпоративная скорость и дисциплина сосуществуют
Enterprise-разработка — это процессы, согласования, архитектурные комитеты. Вайбкодинг по природе своей про скорость и эксперимент. На первый взгляд эти два мира несовместимы.
Совместить их можно, но не за счёт упрощения процессов. Агентная скорость встраивается в существующие этапы разработки: план проверяется до реализации, задача валидируется перед коммитом, результат проходит финальную проверку до того, как его видит человек. Вайбкодинг в таком процессе ускоряет отдельные этапы — но не заменяет инженерную культуру.
Граница между вайбкодингом и классической разработкой проходит по типу задачи. Первый даёт выигрыш там, где контекст замкнут и требования чёткие. Вторая нужна там, где важны архитектурная целостность и предсказуемость результата на горизонте года. Решение о том, какой подход применять к конкретной задаче, требует архитектурного мышления — и это всегда решение человека, а не инструмента.
Источник: Владислав Степанов, архитектор Nord Clan
