Вайбкодинг: как на волне хайпа не доплыть до абсурда

Майя Батырбекова, Phd, MIT Digital Transformation AI Professional
Еще недавно, чтобы проверить идею по автоматизации, компании требовалась команда, которая описывала требования, оценивала работу и согласовывала бюджет. Сегодня сотрудник может описать задачу ИИ-инструменту и через несколько часов получить внешне рабочее приложение. Для бизнеса это выглядит почти как чудо: вместо месяцев — несколько дней, вместо команды — один человек, вместо серьезного бюджета — подписка за $200.

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

Я руковожу командой, которая за три месяца с помощью ИИ переписала монолитную систему, охватывавшую более 10 процессных областей. ИИ помогал с рутиной и ускорял переход от идеи к решению, но значительную часть времени мы тратили на восстановление контекста, проверку связей между процессами и поиск изменений за пределами исходной задачи. Этот опыт показал границы технологии. В рамках программы MIT Digital Transformation я также анализировала международную практику внедрения ИИ. Она показывает, что устойчивый эффект появляется там, где уже выстроены процессы, обеспечено качество данных и определена ответственность за результат.

Подписка за $200 — не подорожник, который можно приложить ко всем болезням компании. Когда внутри бизнеса беспорядок, технология не устраняет его, а помогает быстрее превратить этот беспорядок в код. Именно здесь, на мой взгляд, начинается главная проблема нынешнего увлечения вайбкодингом.

Кода стало больше, но разработка проще не стала
Приложение, собранное за выходные, воспринимается как успех, а команда, выпустившая вдвое больше функций, кажется вдвое эффективнее. Отсюда возникает идея сократить опытных инженеров и передать больше задач молодым специалистам. В моей практике CEO одной компании заморозил вакансии для опытных инженеров, потому что считал, что джун с подпиской становится мидлом. Но уровень инженера определяется не объемом кода, а способностью понять последствия своих решений и заметить риск до запуска. ИИ поможет джуну быстрее написать функцию, но не передаст ему несколько лет опыта вместе с подпиской.

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

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

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

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

Работает, но это еще не значит надежно
У кода, созданного с помощью ИИ, есть особенность, которая одновременно делает такие инструменты удобными и опасными. Он умеет выглядеть убедительно, поэтому плохое решение не обязательно будет выглядеть плохо, ведь ИИ код может быть аккуратно оформлен, снабжен комментариями и успешно пройти основной сценарий. Особенно опасны не те продукты, которые сразу падают, потому что такой сбой обычно быстро замечают, а те, которые продолжают работать, но понемногу искажают цифры, теряют часть данных или дают пользователям лишние права. Компания может долго не видеть проблему, поскольку внешне процесс будет выглядеть исправным. ИИ не несет ответственности за результат и может уверенно объяснить решение, которое сам же предложил неправильно, причем просьба проверить собственный код не гарантирует независимой оценки, потому что модель способна повторно не заметить ту же ошибку.

Готовы ли вы отдать этому свой бизнес
Представим, что собственник нанял человека для создания внутренней системы, а тот за короткий срок собрал ее с помощью ИИ. Кнопки работают, данные выводятся правильно, но сам исполнитель не может объяснить, почему модель выбрала эту архитектуру и как система поведет себя в нештатной ситуации. По сути, бизнес получил продукт, устройства которого не понимает ни собственник, ни нанятый исполнитель. Готов ли владелец доверить такой системе платежи, клиентские данные, складские остатки или расчет зарплаты? Если система ошибется, отвечать будет компания, а не модель. Сам по себе сгенерированный код не означает, что инженер его не понимает. Граница проходит между пониманием и слепым доверием. Если сотрудник может объяснить решение, назвать его ограничения, безопасно изменить и восстановить после сбоя, ИИ остается инструментом. Если он может только вводить новые запросы и надеяться на очередное исправление, бизнес получает систему без настоящего владельца.

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

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

Так внедрять или нет
Одно дело раздать сотрудникам подписки, и совсем другое выстроить процессы компании, в которой ИИ действительно встроен в работу. На международных кейсах цифровой трансформации, которые мы разбирали в MIT, было хорошо видно, что
AI-native компания не возникает после покупки лицензий. Для этого нужны подготовленные люди, качественные данные, понятные процессы и ответственность за результат. Чем больше решений компания передает ИИ, тем важнее становится контроль, а не наоборот. Все это стоит денег. Помимо подписок, бизнес будет платить за обучение, перестройку процессов, безопасность, интеграции, ревью и поддержку. Поэтому ожидание, что ИИ позволит быстро сократить штат и сразу уменьшить расходы - ошибочно. Экономия может появиться позже, но сначала компании придется вложиться в основу, без которой инструменты останутся набором разрозненных экспериментов.

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

1. Что потеряет компания, если система ошибется?
2. К каким данным и сервисам она получит доступ?
3. Есть ли человек, который понимает, как она работает?
4. Кто восстановит процесс после сбоя?
5. Можно ли безопасно отключить систему и вернуться к прежней работе?

Если хотя бы на один из этих вопросов нет ответа, ИИ еще не готов отвечать за критическую часть бизнеса.

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

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