За последний год в новостной ленте сложился устойчивый жанр коротких историй с почти одинаковой структурой. Сначала кто-то рассказывает, как за выходные собрал приложение, ни разу не открыв учебник и просто объясняя нейросети словами, чего он хочет. Через пару недель в той же ленте появляется заметка о том, что из этого приложения утекли данные пользователей или что сервис лег и никто не понимает почему, потому что код никто из живых людей не читал. Обе истории подаются с одинаковым азартом, только во второй он приобретает злорадный оттенок.

Термин «вайбкодинг» предложил Андрей Карпаты в начале 2025 года, описав манеру программировать, при которой разработчик говорит модели, чего хочет, принимает все правки не глядя и вставляет сообщения об ошибках обратно в чат, пока оно как-нибудь не заработает. К концу того же года словарь Collins выбрал это слово словом года, и за несколько месяцев термин проделал путь от шутки в соцсети до строчки в описаниях вакансий, где его пишут уже совершенно серьезно. Экономика здесь понятна без графиков: раньше маленькая программа вроде бота для домового чата или странички для записи к мастеру маникюра стоила либо денег фрилансеру, либо пары недель вечеров с учебником, а теперь обходится в полчаса переписки и подписку по цене пары обедов в столовой. Строчка кода подешевела до стоимости электричества, которое на нее потратил дата-центр, и рынок отреагировал так же, как на любой подешевевший товар, то есть кода стало очень много.

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

Самая наглядная история из этой серии случилась летом 2025 года, когда Джейсон Лемкин, основатель сообщества SaaStr, несколько дней подряд с большим удовольствием собирал приложение на платформе Replit и вел об этом публичный дневник в соцсети. В какой-то момент ИИ-агент, которому прямым текстом запретили что-либо менять, удалил рабочую базу с записями о тысяче с лишним компаний и их руководителей, а потом еще и уверенно сообщил, что откатить изменения нельзя, хотя откатить их в итоге получилось. Глава Replit потом публично извинялся, компания быстро разделила тестовую и рабочую базы и добавила режим, в котором агент только планирует и ничего не трогает. Формально история закончилась неплохо, но вся бухгалтерия в ней видна как на ладони: само приложение обошлось в несколько вечеров и какие-то сотни долларов за использование, зато чтобы этому приложению можно было доверять, понадобились те самые скучные вещи, которые программисты десятилетиями строили вокруг кода, включая отдельные окружения, права доступа, резервные копии и человека, который понимает, что именно сделает команда удаления, еще до того как она выполнится. Есть и история потише, без удаленных баз, которая кажется даже показательнее, потому что там ничего не сломалось. Летом того же года исследователи из METR попросили опытных разработчиков открытых проектов поработать над их собственным кодом, часть задач с ИИ-помощниками, часть без, и выяснилось, что с помощниками люди справлялись примерно на пятую часть медленнее, хотя сами были уверены, что ускорились где-то на столько же. Исследование потом много обсуждали и находили в нем слабые места, выборка была небольшой, инструменты с тех пор успели поменяться, но сам разрыв между ощущением и секундомером запомнился многим: код появляется на экране мгновенно, и это ощущается как скорость, а время, которое потом уходит на то, чтобы его прочитать, понять, поправить и уговорить модель не трогать соседний файлик, размазано по всему дню и в голове как работа почему-то не засчитывается.

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

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

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