Слово «вайбкодинг» в ИТ-среде вызывает неоднозначную реакцию: разработчики морщатся, бизнес интересуется, а все остальные делают вид, что давно разобрались.

Всем привет, это команда продукта SimpleOne SDLC. Давайте честно — ни лагеря хейтеров, ни лагеря евангелистов не дают полного ответа на вопрос из заголовка. Поэтому разберёмся: почему разработчики так болезненно реагируют, а бизнес всё равно идёт в эту сторону, и что со всем этим делать.

Отдельную благодарность за помощь в написании статьи выражаем Панфиловой Яне.

Сначала — что такое вайбкодинг

По-простому, вайбкодинг — это когда код пишет искусственный интеллект, а человек управляет процессом через переписку с чатом. Вы описываете, что нужно сделать, ИИ генерирует реализацию. Сами строки кода вы, по сути, не пишете.

— Почему фича так долго?

— Я попросил Claude написать, он выдал 400 строк, я разбираюсь что там.

— Подожди, ты сам это написал или ИИ?

— Ну... ИИ. Но я проверил.

— Ты проверил 400 строк?

— ...я проверил что оно работает.

Вот и весь вайбкодинг в одной сцене.

Звучит как будущее разработки. Или как ее конец. Смотря с какой стороны смотреть…

По данным Stack Overflow Developer Survey 2025, 80% разработчиков уже используют ИИ-инструменты в своей работе. GitHub фиксирует, что 46% всего нового кода сегодня генерируется искусственным интеллектом. Gartner прогнозирует, что к 2028 году 75% инженеров будут использовать ИИ-ассистенты в работе — против менее 10% в начале 2023-го.

Темная сторона: почему разработчики против

Разработчики видят проблему там, где менеджеры видят возможность. И с точки зрения инженерного ремесла — аргументы у них серьезные.

Во-первых, качество кода

ИИ генерирует рабочий код, но рабочий ≠ хороший. «Рабочий» код, как правило, содержит в себе лишние проверки, комментарии в неожиданных местах, логику, которая решает задачу, но делает это странно. Все это превращает кодовую базу в нечто, с чем потом тяжело работать: плохо читается, плохо поддерживается, таит в себе дефекты, которые проявятся в самый неудобный момент.

Вот пример — простая функция получения скидки для пользователя. Задача тривиальная, но вайбкодинг делает из неё головоломку:

# Function to get discount for user

def get_user_discount(user, product):

    # Check if user is not None

    if user is not None:

        # Check if user exists

        if user:

            # Get the user role

            user_role = user.get('role')

            # Check if role is not None

            if user_role is not None:

                # Check if the role equals admin

                if user_role == 'admin':

                    # Admin gets 20% discount

                    discount = 20

                    return discount

                else:

                    # Check if role equals premium

                    if user_role == 'premium':

                        # Premium user discount

                        discount_value = 10

                        return discount_value

                    else:

                        # For all other roles

                        if user_role == 'basic':

                            return 5

                        else:

                            # Default case - no discount

                            discount = 0

                            return discount

            else:

                # If role is None, return 0

                return 0

        else:

            return 0

    else:

        # User is None

        return 0

Код работает. Но попробуйте вернуться к нему через месяц — или передать новому разработчику. Шесть уровней вложенности ради четырёх значений. Комментарии, которые пересказывают код дословно. Две разные переменные для одного и того же (discount и discount_value). Проверка if user is not None сразу за if user — это одно и то же условие дважды.

Чистая версия той же логики:

DISCOUNTS = {'admin': 20, 'premium': 10, 'basic': 5}

def get_user_discount(user):

    if not user:

        return 0

    return DISCOUNTS.get(user.get('role'), 0)

Результат идентичный. Разница в том, насколько легко это читать, тестировать и дополнять.

И здесь возникает проблема с code review. Ревьюер привык читать код написанный человеком — с понятной логикой, предсказуемой структурой. ИИ-код формально корректный, но читается иначе. Ревьюер либо тратит втрое больше времени, либо просто одобряет — потому что «ну работает же». Второй вариант встречается чаще. И именно так техдолг тихо копится в кодовой базе — один одобренный PR за раз.

Во-вторых, деградация навыков

Когда вы перекладываете написание кода на ИИ, вы перестаете тренировать инженерное мышление. Со временем разработчик теряет способность самостоятельно проектировать решения — он привыкает направлять и проверять, а не думать. На Хабре уже разбирали, как именно это происходит: человек создаёт проекты с невероятной скоростью, а потом приходит на собеседование и не может объяснить, что делает его собственный код. Это может и не станет катастрофой прямо сейчас, но это медленный дрейф в сторону зависимости от нейронок.

В-третьих, зависимость от внешних агрегаторов

Сейчас самые мощные модели — у Anthropic и OpenAI. Локальные модели, которые можно развернуть на собственных серверах, заметно слабее. Это означает, что компании, которые переходят на вайбкодинг, начинают зависеть от американских поставщиков — с рисками утечки кодовой базы, обучения моделей на вашем же коде и потенциальными юридическими последствиями.

Итого

Код непонятный, инженеры тупеют, данные утекают. С одной стороны — все плохо.

Светлая сторона: почему бизнес все равно переходит

Бизнес не принимает технические решения в вакууме (если вы вдруг так подумали) — он принимает решения, опираясь на ситуацию на рынке.

На американском и китайском рынках ежегодно появляются десятки тысяч технологических стартапов. Если вы не успели занять позицию быстро — рынок для вас закрылся. По данным LexisNexis PatentSight, в 2024 году 73% всех мировых патентных публикаций пришлось на Китай — против 6% у США. Только в сфере IT китайские патентные заявки превышают совокупный годовой объём патентов всех остальных стран вместе взятых.

Вайбкодинг позволяет разрабатывать быстрее — это факт. Значит, быстрее попадаешь на рынок, быстрее получаешь обратную связь, быстрее итерируешь.

И здесь возникает неудобный вопрос, который задают не часто: насколько вообще важна изначально хорошая архитектура, если ее дешевле переписать из «рабочей»? Базовая ценность хорошего кода — в том, что его легко поддерживать. Но если скорость переписки с ИИ достаточно высокая, дешевле нагенерировать «не идеальный» код, быстро выпустить, получить деньги, а потом — при необходимости — быстро переделать. Логика не бесспорная, но она не лишена смысла.

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

Рынок привыкнет к тому, что все ломается

Здесь, пожалуй, самое интересное наблюдение — и самое дискуссионное.

Посмотрите на Claude Code. На его странице статусов регулярно появляются инциденты, хотя это важная система, на которой работают сотни компаний, и она регулярно падает. И что? Никто не уходит. Все продолжают пользоваться — потому что ценность, которую она создает, перевешивает неудобство от периодических сбоев.

Jira лагает при большом количестве одновременных пользователей. Telegram периодически падал в разных странах. Все это не мешало людям оставаться на этих продуктах — потому что они закрывают важную потребность.

Важная оговорка:

Это работает для B2C-продуктов и внутренних инструментов. Если ваш продукт — платёжный шлюз или медицинская система, «привыкнут к тому, что падает» — не аргумент. Регулятор не привыкнет.

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

Цель вайбкодинга — не хороший код

И если люди мирятся с глючными приложениями ради удобства — значит, рынок уже негласно ответил на вопрос: что важнее, качество кода или ценность продукта? Здесь важно разделить понятия, которые мы по привычке смешиваем.

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

Вайбкодинг не ставит перед собой эту цель.

Цель вайбкодинга — быстро доставить до пользователя дешевый рабочий продукт, на который есть спрос. Это другая оптимизационная функция.

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

Тогда вайбкодинг — это хорошо?

Не совсем. Скорее — это инструмент под конкретные задачи.

Критические системы — банки, государственные сервисы, инфраструктура — по-прежнему будут писаться людьми с высокими требованиями к надежности, потому что там цена падения слишком высока.

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

Пока ИИ делает быстрее, больше и дешевле, он будет выигрывать там, где это имеет значение.

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

Резюме

Вайбкодинг — не угроза разработке и не её спасение. Это инструмент с другой целью: не написать красивый код, а быстро доставить рабочий продукт. Разработчики правы, что беспокоятся о качестве. Бизнес прав, что торопится. Рынок, судя по всему, будет терпеть несовершенство — если продукт решает реальную задачу.

Как попробовать без риска?

Начните с внутренних инструментов и прототипов. Замерьте скорость и количество багов через месяц. Если время до первого рабочего прототипа сократилось, а прод не горит — масштабируйте. Если баги полезли — вы нашли границу.

***

Используете ли вы ИИ при написании кода — и если да, то как с этим уживается ваша команда?