Андрей Карпати, сооснователь OpenAI, 2 февраля 2025 года написал пост, в котором придумал термин «vibe coding»: я разрабатываю проект или веб-приложение, но это не совсем программирование — я просто вижу что-то, говорю что-то, запускаю что-то и копирую/вставляю код, и в основном это работает.

На практике это выглядит как ремонт квартиры по дизайн-проекту, без сметы, без прораба: вы формулируете запрос на своем языке, получаете результат и отправляете его в прод. Collins Dictionary даже сделал «vibe coding» словом 2025 года. Но старый принцип машинного обучения и информатики GIGO (англ. garbage in, garbage out «мусор на входе — мусор на выходе») никуда не делся и сейчас он подтверждается в массовом масштабе.

Vibe coding: семиотический мусор на входе, технический долг на выходе

Семиотический мусор

В семиотике знак состоит из двух компонентов: означающее и означаемое. Код содержит синтаксис и семантику. Синтаксис определяет форму выражения, а семантика его значение и поведение при выполнении. LLM (большая языковая модель в ИИ) генерирует правдоподобный текст, имитируя наличие смысла, например, пишет функцию, которая по запросу «сортирует массив», а по факту она иногда сортирует, иногда удаляет дубликаты, а иногда просто возвращает пустой список. Или объявляет переменную user_count, но кладёт туда не число, а строку «пять». Компилятор промолчит, так как синтаксис не нарушен. Автор, который «вайбкодит», тоже не заметит. Зато через три месяца разработчик будет читать этот код и пытаться понять, почему счетчик пользователей иногда превращается в слово «пять» и всё падает. Это и есть семиотический мусор: внешне похоже на код, но внутри несоответствие.

Технический долг

Классический техдолг по сути осознанный компромисс: быстро сейчас, перепишем потом. В vibe coding долг не осознается и накапливается пассивно. Каждый сгенерированный фрагмент может содержать скрытые допущения, неявные зависимости, избыточность. Через месяц таких фрагментов становится столько, что переписать всё дешевле, чем понять, что там происходит. Это не долг, а коллапс для разработки.

Практика вайбкодинга далека от идеала

Опрос 18 технических директоров и руководителей инженерных подразделений, проведенный Final Round AI, выявил, что 16 из них столкнулись с критическими инцидентами в продакшене, вызванными «вайб-кодом». Типичный пример: авторизация с «перевернутой» логикой, когда заблокированные пользователи получают доступ, а авторизованные не могут войти в приложение, или запросы к базе данных, работающие в тестовой среде, но кладущие прод под реальной нагрузкой.

Исследование компании CodeRabbit показало, что в коде, созданном большими языковыми моделями, содержится в 1,7 раза больше ошибок, чем в написанном человеком, а ошибок, связанных с безопасностью в среднем больше в 1,5 раза. К таким ошибкам они отнесли: неправильную обработка паролей, небезопасные ссылки на объекты и уязвимости XSS.

Вот ещё один пример от исследователей из METR: разработчики, использующие ИИ-инструменты, в среднем тратили на выполнение задач на 19% больше времени, чем их коллеги без нейросетей. При этом их субъективная оценка показывала обратное — ожидаемое ускорение в 24%. Вайбкодинг кажется простым, но занимает больше времени на решение задачи: расхождение ощущений с реальностью на 43%.

В том же ключе и выводы исследования Anthropic: разработчики, полагавшиеся на ИИ при написании кода, показали в тестах на понимание и компетенции результаты на 17% хуже по сравнению с теми, кто писал всё руками. Самый сильный разрыв зафиксирован в области отладки. Однако те, кто использовал ИИ как инструмент и формулировал концептуальные запросы, задавал уточняющие и направляющие вопросы, а также просил объяснить логику решений показали результаты не хуже разработчиков, программирующих руками. Разница в подходе и структуре запросов.

Проблемы вайбкодинга в реальных проектах

Веб-разработчик с пятнадцатилетним стажем использовала GitHub Copilot для своего стартапа, относясь к нейросети, как к сотруднику. Через некоторое время вместе с сооснователем они обнаружили, что код пронизан критическими проблемами, включая серьезные уязвимости в безопасности. Работу над проектом пришлось остановить, а готовый код удалить. Всё переписывали с нуля.

Другой случай — стокгольмский стартап, существовавший пять лет. За несколько дней команда «навайбкодила» новый проект и быстро набрала сотни регистраций. В ходе проверки выяснилось, что админ-интерфейс был полностью открыт: любой желающий мог зайти и скачать базу пользователей. Компания получила риск GDPR-иска, способного уничтожить бизнес. Экстренная доработка системы авторизации превратилась в ад, им пришлось латать дыры в никем не спроектированном коде.

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

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

Почему «вайб» не заменяет модель

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

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

Как делать не больно и без программистов: Low-code/No-code вместо вайбкодинга

Вайбкодинг это быстрое програмированние без архитектуры, без автора и обычно без какого-либо описания кода.

Low-code/No-code другой подход. В нем структура решения закладывается сразу. Система строится из готовых структурно подготовленных компонентов в конструкторах для работы с данными, интерфейсами, процессами и процедурами.

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

В Appliner также используется ИИ-агент, который действует в рамках системы. Он не генерирует случайный код, а опирается на проверенные блоки с предсказуемым поведением, что обеспечивает стабильную работу системы и исключает неожиданные сбои. У кода компонентов Appliner есть автор, компоненты задокументированы (https://wiki.appliner.io/ ) . API-спецификация генерируется автоматически при создании новых элементов приложения (процессов, процедур, таблиц и т.д.).

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

Выводы

В вайбкодинге ИИ делает то, что сказали и как сказали, без лишних вопросов. Если на входе отсутствует структура и представление о том, для кого и зачем это делается, получится приложение, которое окажется непонятным и невостребованным. Мусор на входе остаётся мусором, независимо от того, как «просто» и «вайбово» было его производить. Модель не станет умнее от того, что вы ей доверяете. Код без автора и без логической определённости рано или поздно потребует автора с очень дорогой почасовой ставкой, а вероятнее даже команду программистов-криминалистов, которые будут разбирать «вайбы» прошлого.