Слово «вайбкодинг» в ИТ-среде вызывает неоднозначную реакцию: разработчики морщатся, бизнес интересуется, а остальные делают вид, что давно разобрались.
Ни лагерь хейтеров, ни лагерь евангелистов не дают полного ответа на вопрос из заголовка. Давайте разберёмся: почему разработчики так болезненно реагируют, а бизнес всё равно идёт в эту сторону — и что с этим делать.
Что такое вайбкодинг
По-простому, вайбкодинг — это когда код пишет искусственный интеллект, а человек управляет процессом через переписку с чатом. Вы описываете, что нужно сделать, ИИ генерирует реализацию. Сами строки кода вы, по сути, не пишете.
— Почему фича так долго?
— Я попросил Claude написать, он выдал 400 строк, я разбираюсь, что там.
— Подожди, ты сам это написал или ИИ?
— Ну... ИИ. Но я проверил.
— Ты проверил 400 строк?
— ...я проверил, что оно работает.
Вот и весь вайбкодинг в одной сцене.
Звучит как будущее разработки. Или как её конец — смотря с какой стороны смотреть.
По данным Stack Overflow Developer Survey 2025, 80% разработчиков уже используют ИИ-инструменты в своей работе. GitHub фиксирует, что 46% всего нового кода сегодня генерируется искусственным интеллектом. Gartner прогнозирует, что к 2028 году 75% инженеров будут использовать ИИ-ассистенты — против менее 10% в начале 2023 года.
Темная сторона: почему разработчики против
Разработчики видят проблему там, где менеджеры видят возможность. И с точки зрения инженерного ремесла их аргументы серьёзны.
Качество кода
ИИ генерирует рабочий код, но рабочий ≠ хороший. Такой код часто содержит лишние проверки, странные комментарии и неочевидную логику. Всё это превращает кодовую базу в нечто, с чем тяжело работать: плохо читается, плохо поддерживается, таит в себе скрытые дефекты.
Например, простая функция получения скидки может превратиться в головоломку: шесть уровней вложенности, дублирующие переменные, повторяющиеся условия. При этом результат правильный — но поддерживать такой код сложно.
Чистая версия той же логики выглядит проще, понятнее и безопаснее. Разница в том, насколько легко её читать, тестировать и дополнять.
Это создаёт проблему при code review. Ревьюер привык к коду, написанному человеком, с понятной структурой. ИИ-код формально корректен, но читается иначе. В итоге ревьюер либо тратит втрое больше времени, либо просто одобряет — потому что «ну работает же». Второй вариант встречается чаще. Так технический долг тихо накапливается — один PR за другим.
Деградация навыков
Когда вы перекладываете написание кода на ИИ, вы перестаёте тренировать инженерное мышление. Со временем разработчик теряет способность проектировать решения — он привыкает направлять и проверять, а не думать.
На практике это выглядит так: человек создаёт проекты с невероятной скоростью, но на собеседовании не может объяснить, что делает его собственный код. Это не катастрофа сегодня, но медленный дрейф в сторону зависимости от нейросетей.
Зависимость от внешних поставщиков
Сейчас самые мощные модели — у Anthropic и OpenAI. Локальные модели, которые можно развернуть на своих серверах, заметно слабее. Это означает, что компании, переходящие на вайбкодинг, зависят от американских провайдеров.
Такая зависимость несёт риски: утечка кодовой базы, обучение моделей на вашем коде, потенциальные юридические последствия.
Код непонятный, инженеры теряют навыки, данные утекают. С одной стороны — всё плохо.
Светлая сторона: почему бизнес всё равно переходит
Бизнес принимает решения не в вакууме, а с учётом рыночной ситуации.
На американском и китайском рынках ежегодно появляются десятки тысяч стартапов. Если вы не успели занять позицию быстро — рынок для вас закрыт. По данным LexisNexis PatentSight, в 2024 году 73% мировых патентных публикаций пришлось на Китай — против 6% у США. Только в сфере IT китайские заявки превышают объём патентов всех остальных стран вместе взятых.
Вайбкодинг позволяет разрабатывать быстрее. Значит, быстрее выйти на рынок, получить обратную связь, итерировать.
Возникает неудобный вопрос: насколько важна хорошая архитектура, если её дешевле переписать? Базовая ценность хорошего кода — в поддерживаемости. Но если переписывать с помощью ИИ быстро и дёшево, логично сначала выпустить «рабочий» продукт, заработать, а потом — при необходимости — переделать. Логика спорная, но понятная.
Есть и ещё один аргумент — самый неудобный для разработчиков. Он вообще не про код.
Рынок привыкает к тому, что всё ломается
Посмотрите на Claude Code. Его система регулярно падает — и что? Никто не уходит. Потому что ценность перевешивает неудобства.
Jira лагает при нагрузке. Telegram периодически падает в разных странах. Но пользователи остаются — потому что продукт решает их задачи.
Важная оговорка:
Это работает для B2C-продуктов и внутренних инструментов. Если ваш продукт — платёжный шлюз или медицинская система, «привыкнут к падениям» — не аргумент. Регулятор не привыкнет.
Пользователи постепенно мирятся с тем, что приложения глючат, падают, сделаны неидеально. Главное — чтобы они приносили пользу. Не факт, что из-за вайбкодинга люди перестанут использовать приложения, если те решают их задачи.
Цель вайбкодинга — не хороший код
Если люди терпят сбои ради удобства, значит, рынок уже ответил: ценность продукта важнее качества кода. Здесь важно разделить два понятия.
Хорошо написанный код — это профессиональная ценность разработчика. Это красота архитектуры, читаемость, поддерживаемость. Это то, о чём написаны сотни книг — и, кстати, то, чего даже сами разработчики не всегда достигают.
Вайбкодинг не ставит перед собой эту цель.
Цель вайбкодинга — быстро доставить до пользователя дешёвый рабочий продукт, на который есть спрос. Это другая оптимизационная функция.
Представьте рынок жилья. Эконом-класс строится быстро, из дешёвых материалов, с меньшим вниманием к деталям. Покупатели это знают. Но всё равно покупают — потому что им нужна крыша над головой. То же самое происходит в разработке: если продукт решает реальную задачу по приемлемой цене, его будут использовать — независимо от того, насколько красив код под капотом.
Тогда вайбкодинг — это хорошо?
Не совсем. Скорее — это инструмент под конкретные задачи.
Критические системы — банки, госсервисы, инфраструктура — по-прежнему будут писаться людьми. Там цена ошибки слишком высока.
Но огромный пласт прикладных продуктов — корпоративные интерфейсы, внутренние инструменты, прототипы, вспомогательные сервисы — вполне может перейти к вайбкодингу. Это как с иллюстрациями: художники не исчезнут, но большая часть задач по генерации изображений уже ушла к ИИ — и этот процесс необратим.
Пока ИИ делает быстрее, больше и дешевле, он будет выигрывать там, где это имеет значение.
Осуждать это — всё равно что осуждать людей за то, что они ездят на машинах, а не ходят пешком. Вопрос не в том, хорошо это или плохо. Вопрос в том, куда вы едете — и не забыли ли проверить тормоза.
Вайбкодинг — не угроза разработке и не её спасение. Это инструмент с другой целью: не написать красивый код, а быстро доставить рабочий продукт. Разработчики правы, что беспокоятся о качестве. Бизнес прав, что торопится. Рынок, судя по всему, будет терпеть несовершенство — если продукт решает реальную задачу.
Как попробовать без риска?
Начните с внутренних инструментов и прототипов. Замерьте скорость и количество багов через месяц. Если время до первого рабочего прототипа сократилось, а прод не горит — масштабируйте. Если баги полезли — вы нашли границу.