В феврале 2025 года Андрей Карпати написал пост, который выглядел скорее как признание программиста, немного обленившегося из-за хороших языковых моделей. Он разговаривал с Cursor Composer через распознавание речи, почти всегда нажимал Accept All, перестал читать изменения и просто отправлял модели сообщения об ошибках. Если баг не исчезал, просил попробовать что-нибудь ещё. Карпати назвал такой режим vibe coding.
За год выражение успело стать словом 2025 года по версии Collins, попасть в словари и превратиться в название целого класса инструментов. Но смысл размылся. Сейчас вайбкодингом часто называют вообще любое программирование с ИИ. Я бы так термин не растягивал. Если разработчик поручает модели написать функцию, а затем читает код, проверяет архитектуру, тестирует и отвечает за результат, перед нами обычная разработка с ИИ. Вайбкодинг начинается там, где человек контролирует главным образом видимый результат, а реализацию перестаёт понимать.
Карпати придумал не технологию, а очень точное название режиму работы
До появления самого слова уже существовали GitHub Copilot, ChatGPT, Cursor и другие инструменты генерации кода. Модель могла закончить функцию, написать тест, объяснить исключение или предложить рефакторинг. Следующий скачок произошёл, когда ИИ получил доступ сразу к репозиторию, терминалу и инструментам разработки. Теперь модель могла не только предложить кусок текста, но и найти нужные файлы, изменить несколько модулей, установить зависимость, запустить тесты и попытаться починить результат.
Карпати просто описал предельный вариант такого взаимодействия. В глоссарии SecurityLab вайбкодинг определяется как стиль разработки с активным использованием ИИ, импровизацией и доверием к подсказкам модели. Первоначальная формулировка Карпати была даже радикальнее. Главной мыслью служило «забыть, что код вообще существует».
В оригинальном сценарии разработчик говорил модели что-то вроде «уменьши отступ в боковой панели вдвое», принимал изменения целиком, копировал обратно ошибки и продолжал цикл. Сам Карпати сразу оговорился, что такой подход неплохо подходит для одноразовых проектов выходного дня. Никакой новой дисциплиной промышленной разработки он вайбкодинг не объявлял.
Именно ограничение быстро потерялось. Collins позже описал термин шире как применение ИИ, которому на естественном языке поручают писать программный код. Merriam-Webster тоже закрепил более широкое значение. В результате под одним словом оказались два довольно разных процесса.
| Режим | Что делает ИИ | Что остаётся за человеком |
|---|---|---|
| Автодополнение | Продолжает текущий код | Проектирование, реализация и проверка |
| ИИ-ассистированная разработка | Пишет функции, тесты, запросы, объясняет ошибки | Архитектура, ревью, интеграция и ответственность |
| Агентная разработка | Исследует репозиторий, меняет файлы, запускает команды и тесты | Спецификация, ограничения, контроль и приёмка |
| Вайбкодинг в исходном смысле | Самостоятельно строит большую часть приложения | Человек в основном смотрит, заработало ли |
Поэтому считать процент сгенерированных строк хорошей мерой вайбкодинга нельзя. Проект может состоять из машинного кода на 95%, но оставаться нормальной инженерной разработкой, если специалисты понимают архитектуру и тщательно проверяют изменения. И наоборот, маленький скрипт из двухсот строк может быть чистым вайбкодингом, если автор понятия не имеет, почему программа работает.
Как понять, что автодополнение уже превратилось в вайбкодинг
Возьмём обычную задачу. Нужно добавить авторизацию по одноразовой ссылке. Разработчик с ИИ может поставить агенту довольно крупное задание.
Добавь вход по одноразовой ссылке.
Используй существующую таблицу users.
Токен действует 15 минут и применяется только один раз.
Не меняй публичный API.
Добавь тесты на повторное использование и просроченный токен.
После изменений запусти тестовый набор.Модель вполне может написать почти всю реализацию. Но если разработчик затем проверит схему токенов, хранение сессии, обработку повторного запроса, тесты и изменения зависимостей, вайбкодингом такой процесс я бы не называл.
Другой вариант выглядит знакомее.
Сделай вход по почте.
Не работает, исправь.
Теперь ошибка 500.
Почини.
Вроде заработало. Добавь страницу профиля.Между этими двумя сценариями проходит более полезная граница, чем между «код написал человек» и «код написал ИИ». В первом случае модель выполняет работу внутри заданной инженерной системы. Во втором сама модель постепенно придумывает систему, а пользователь проверяет только симптомы.
Есть простой тест. Если после завершения задачи я не могу объяснить, где хранятся данные, как устроены права, какие новые зависимости появились и почему решение безопасно при ошибочном вводе, значит я уже слишком далеко ушёл в сторону вайбкодинга.
Агентность сама по себе ситуацию не меняет. Современный агент может самостоятельно выполнить десятки действий, а инженер всё равно сохраняет контроль через спецификацию, тесты, ограничения прав, просмотр diff и независимое ревью. Автономность инструмента и отсутствие контроля со стороны человека не одно и то же.
Кто действительно вайбкодит
Самая показательная статистика одновременно подтверждает и опровергает хайп. В последнем завершённом глобальном опросе Stack Overflow 84% разработчиков сообщили, что уже используют ИИ-инструменты или планируют их использовать. Среди профессиональных разработчиков 51% применяли такие инструменты ежедневно. Однако на отдельный вопрос о вайбкодинге 72% ответили, что он не входит в профессиональную работу, а ещё около 5% отвергли такой режим особенно категорично. Причём Stack Overflow использовал широкое определение, где вайбкодингом считалось создание программ из запросов к LLM. При более строгом определении Карпати доля была бы вряд ли выше.
Отсюда следует важная вещь. ИИ-кодинг стал массовым. Вайбкодинг среди профессиональных разработчиков массовым пока не стал.
Зато подход хорошо прижился у людей, для которых программирование раньше было слишком дорогим входным билетом. Дизайнеры, менеджеры продукта, аналитики, предприниматели и исследователи теперь собирают небольшие утилиты, интерфейсы, обработчики данных и прототипы самостоятельно. Опрос UX Tools среди 1478 дизайнеров и создателей продуктов весной 2026 года показал, что 31,1% респондентов уже генерировали с помощью ИИ большую часть или почти весь код во время такой работы, а 59,1% за предыдущие полгода хотя бы раз сделали собственный инструмент, приложение или утилиту с ИИ. Выборка специфическая и не описывает всех дизайнеров мира, но направление хорошо видно.
Другой интересный пример пришёл из Y Combinator. Ещё в Winter 2025 акселератор сообщил, что примерно у четверти компаний набора 95% строк кодовой базы были сгенерированы LLM. На первый взгляд звучит как окончательная победа вайбкодинга. Но представители YC отдельно поясняли, что речь шла о технических основателях, способных написать продукты самостоятельно. Количество машинного кода снова оказалось плохим индикатором того, понимает ли человек собственную систему.
На практике я вижу четыре области, где режим «сначала заставим работать, потом разберёмся» действительно оправдан. Одноразовые скрипты, личные утилиты, быстрые прототипы и проверка продуктовой гипотезы. Общий признак один. Стоимость ошибки низкая, результат легко проверить, а неудачный проект можно без сожаления выбросить.
Чем хуже проверяется результат, тем слабее преимущество вайбкодинга. Красную кнопку, которая должна стать синей, проверить легко. Корректность разграничения прав между тысячами пользователей, поведение распределённой системы при сбоях или отсутствие уязвимости в обработчике платежей уже нельзя подтвердить простым «у меня открылось».
Продакшен быстро возвращает инженерию обратно
Главная ловушка вайбкодинга связана не с плохими моделями, а с очень убедительной скоростью появления первой версии. За несколько минут возникает интерфейс, база данных наполняется, кнопки реагируют. Мозг легко принимает видимый прогресс за готовность системы.
Опрос Stack Overflow хорошо показывает обратную сторону. 66% разработчиков среди главных раздражителей назвали ответы ИИ, которые выглядят почти правильными, но всё-таки содержат ошибку. 45% столкнулись с ситуациями, когда отладка сгенерированного кода отнимала больше времени.
Эксперимент METR добавил ещё одну неудобную деталь. Шестнадцать опытных разработчиков выполняли 246 реальных задач в знакомых им зрелых open source-проектах. С инструментами начала 2025 года участники в среднем тратили на задачи на 19% больше времени, хотя до эксперимента ожидали ускорения, а после него всё равно считали, что ИИ помог работать быстрее. Делать из результата вывод «ИИ замедляет программистов» нельзя. Исследование касалось очень конкретной группы специалистов и конкретного поколения инструментов. В последующем исследовании METR уже увидела признаки заметного ускорения на новых моделях, но столкнулась с новой проблемой. Разработчики чаще отказывались выполнять без ИИ задачи, где ожидали большую выгоду, а параллельная работа нескольких агентов сделала старую методику измерения менее надёжной.
С безопасностью граница ещё резче. Исследование SusVibes, принятое на ICML 2026, проверяло агентов на задачах из реальных open source-проектов, где неправильная реализация могла приводить к известным классам уязвимостей. В одной из исходных конфигураций SWE-Agent с Claude 4 Sonnet функционально решил 61% задач, но одновременно функциональные и безопасные решения получились лишь в 10,5% случаев. Позднейшие тесты других комбинаций улучшили функциональные результаты, однако большой разрыв между «работает» и «безопасно» сохранился.
Такие проценты нельзя переводить в утверждение вроде «89,5% всего ИИ-кода уязвимо». Benchmark специально состоит из сложных задач с историей проблем безопасности. Исследование показывает другое. Функциональные тесты сами по себе плохо отвечают на вопрос, безопасно ли выпускать агентный код.
Карпати столкнулся с похожей проблемой на собственном MenuGen. Пользователь входил через Google, а кредиты покупал через Stripe. Агент решил связывать покупку и аккаунт по адресу электронной почты. Решение выглядело логичным и могло прекрасно проходить обычный счастливый сценарий. Но почта в Google и Stripe может различаться, поэтому купленные кредиты рисковали попасть не туда. Нормальная архитектура требует постоянного внутреннего идентификатора пользователя. Перед нами хороший пример ошибки, которую невозможно обнаружить вопросом «страница открывается?».
Именно поэтому сам Карпати позже стал разводить вайбкодинг и agentic engineering. Вайбкодинг, по его формулировке, поднимает нижнюю планку и позволяет гораздо большему числу людей создавать программы. Агентная инженерия должна сохранить верхнюю планку профессионального ПО. Агент пишет большую часть кода, но человек по-прежнему отвечает за спецификацию, архитектуру, тесты, безопасность и окончательное решение о выпуске.
Мне такая граница кажется намного полезнее разговоров о том, сколько процентов работы «забрал ИИ». Можно почти перестать печатать код руками и остаться инженером. Можно написать всего несколько запросов и потерять контроль над системой.
Для легальной и ответственной работы агентам стоит давать доступ только к собственным или разрешённым проектам, ограничивать права на файловую систему, терминал, сеть и секреты, а потенциально опасные действия подтверждать отдельно. Инструкции и агентные возможности нельзя применять для несанкционированного доступа, слежки, взлома, нарушения правил сервисов или незаконного обхода ограничений. Нужно учитывать законодательство своей страны, включая требования, действующие в России.
Поэтому я бы не называл вайбкодинг будущим всей разработки. Скорее перед нами новый нижний этаж программирования. Теперь от идеи до работающего прототипа можно добраться, почти не касаясь синтаксиса. Следующий этаж никуда не исчез. Как только появляются реальные пользователи, деньги, персональные данные, роли, внешние API и необходимость поддерживать продукт годами, снова требуются архитектура, тестирование, ревью и безопасность.
Дальше в цикле я отдельно разберу последствия такого перехода. Как принимать код, который никто в команде не писал вручную, почему агенты уносят секреты в репозитории, откуда берётся слопсквоттинг зависимостей, как prompt injection добирается до терминала разработчика и кто отвечает за инцидент после кнопки Accept All.
Пока достаточно одного правила. Если ИИ пишет код быстрее вас, проблемы нет. Если после работы ИИ никто не может уверенно объяснить, почему система устроена именно так и что произойдёт в ошибочном сценарии, скорость уже перестала быть преимуществом. Вот с этого места и начинается настоящий вайбкодинг.
