Вайбкодинг: что это на самом деле и где заканчивается прототип

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

Откуда взялось слово

Термин ввёл Андрей Карпати в феврале 2025 года. Смысл был почти шуточный: садишься, описываешь словами, что хочешь, ИИ генерирует код, ты его не читаешь — «отдаёшься вайбу и забываешь, что код вообще существует». Принимаешь всё подряд, ошибки скармливаешь обратно модели, пока не заработает.

Важно: Карпати описывал так выходные проекты, вещи «на один вечер». Не production. Само выражение появилось как ироничное наблюдение, а не как методология разработки.

Дальше слово ушло в народ и расползлось. Сейчас «вайбкодингом» называют три довольно разные вещи:

1. Буквальный вайбкодинг по Карпати — не читаю код, принимаю всё. Работает для прототипов и «поиграться».
2. AI-assisted разработка — инженер пишет код вместе с ИИ (Cursor, Claude Code, Copilot), но читает каждую строку, ревьюит, тестирует. Это то, что реально используют в проде.
3. Маркетинговый шум — когда словом просто называют «мы используем ИИ», без содержания.

Смешивать первое со вторым — источник большинства проблем и споров.

Что вайбкодингом не является

Раз уж в интернете гуляют странные определения: вайбкодинг не имеет отношения к эмоциональному дизайну, сенсорным интерфейсам, VR/AR или «адаптации приложения под настроение пользователя». Это про то, как пишется код, а не про то, что чувствует пользователь. Если вам где-то попалось такое объяснение — его писала нейросеть, которая не знала термина и додумала по созвучию со словом vibe.

Где реально проходит граница

Граница не в инструменте — Cursor и Claude Code одинаковы и у любителя, и у сеньора. Граница в том, что происходит с сгенерированным кодом дальше.

Прототип (можно вайбкодить буквально):

• проверить идею, показать заказчику кликабельную версию;
• внутренний скрипт на один раз;
• обучение, эксперименты, хакатон;
• цена ошибки — ноль.

Продакшен (буквальный вайбкодинг недопустим):

• код читает и понимает человек, который отвечает за результат;
• есть ревью, тесты, CI/CD;
• понятно, что происходит при ошибке, отказе внешнего API, гонке запросов;
• есть логи и возможность разобрать инцидент.

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

Почему «не читая код» ломается на второй неделе

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

Код перестаёт быть цельным. Модель не держит в голове архитектуру всего проекта. Она отвечает на конкретный запрос — и делает это локально-разумно. Через двадцать таких итераций получается три разных подхода к одной задаче в одном проекте, дублирующаяся логика и никакой общей структуры.

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

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

Безопасность. Модель радостно напишет запрос к базе со склейкой строк, положит ключ в репозиторий или сделает эндпоинт без проверки прав — если её об этом не попросить отдельно.

Ни один из пунктов не является аргументом «ИИ не нужен». Все они — аргумент за то, что сгенерированный код должен проходить те же процедуры, что и написанный руками.

Как выглядит здоровая версия

То, что работает в проде, устроено скучно:

• ИИ пишет черновик, инженер задаёт архитектуру и границы;
• каждый значимый кусок проходит ревью человеком, который отвечает за проект;
• автотесты на критичные сценарии — их, кстати, тоже удобно генерировать;
• CI/CD, чтобы сломанное не доезжало до пользователей;
• код в репозитории заказчика, а не «где-то у подрядчика».

Ускорение при этом остаётся реальным и большим — просто оно берётся не из «не читаем код», а из того, что рутина (бойлерплейт, типовые формы, миграции, тесты, обвязка) пишется в разы быстрее. Инженерное время уходит туда, где оно действительно нужно: архитектура, краевые случаи, интеграции.

Как проверить подрядчика, который говорит «мы вайбкодим»

Три вопроса, которые быстро всё проясняют:

1. Кто читает сгенерированный код и отвечает за него? Если ответ «ИИ хорошо пишет» — это не ответ.
2. Что с тестами и CI? Отсутствие — сигнал, что принимают всё подряд.
3. Кому принадлежит репозиторий? Если код не у вас, вопрос качества становится второстепенным по сравнению с вопросом зависимости.

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

---

Пишу из практики студии MKDGRUPP: делаем продукты на AI-assisted разработке — ИИ ускоряет, сеньор ревьюит каждый PR, автотесты и CI/CD, код остаётся у заказчика. Подробнее о подходе: mkdgrupp.ru/vaybkoding.