Вайб-кодинг

Откуда взялся термин

Выражение ввёл Андрей Карпати (Andrej Karpathy) в посте в X 2 февраля 2025 года. Он описал стиль работы, в котором вы «полностью отдаётесь вайбу» и «забываете, что код вообще существует»: говорите ИИ, чего хотите, принимаете правки, не читая диффы, вставляете сообщения об ошибках обратно и обходите проблемы, которые модель не может исправить. Код при этом разрастается сам, и вы уже не помните, что в нём лежит. По его собственным словам, это нормально для одноразовых проектов на выходные, как пересказано в заметке Саймона Уиллисона.

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

Вайб-кодинг и разработка с помощью ИИ

Использование ИИ-ассистента само по себе ещё не вайб-кодинг. Саймон Уиллисон проводит границу по проверке: создавать ПО с помощью LLM, не просматривая написанный им код, это вайб-кодинг, а код, который вы прочитали, протестировали и можете объяснить другому человеку, это обычная разработка, где просто используется удобный инструмент.

Для новичка есть простой тест. Можете ли вы объяснить, что делает это изменение, каких данных оно касается и какие секреты ему нужны? Если нет, то вы занимаетесь вайб-кодингом, и подстраховка должна прийти не из вашего чтения кода, а из другого места: чек-листа, автоматических сканеров, серверной учётной записи с минимумом прав и малого радиуса поражения. Дело не в том, чтобы винить ИИ, а в том, где в процессе остаётся человек. Статьи про принцип наименьших привилегий и сдерживание (containment) объясняют две последние идеи.

Почему непроверенный код опасен

Никто не читает те места, которые ломаются тихо. Пять мест, на которые стоит посмотреть в первую очередь:

• Секреты. Ключи, вставленные в файлы с кодом, попадают в git. См. управление секретами и руководство о том, что делать после утечки API-ключа.
• Доступ к данным. Supabase предупреждает, что таблица в открытой схеме без RLS доступна на чтение и запись любой роли с правами. См. защиту на уровне строк.
• Зависимости. Модели могут выдумывать названия пакетов, а злоумышленники их регистрировать: слопсквоттинг.
• Запросы. SQL, собранный из строк, уязвим для SQL-инъекции.
• Агенты. Инструментами, которые читают недоверенный текст, можно управлять через промпт-инъекцию.

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

Как выпускать вайб-кодинг продукт безопаснее

Отказываться от ИИ не нужно. Нужно добавить проверки, которые ИИ сам не добавит:

1. Пройдите чек-лист безопасности для вайб-кодинга перед каждым запуском.
2. Дайте ассистенту письменные правила, как в статье о правилах безопасности для ИИ-ассистента, и ограничьте то, что может запускать агент, как в руководстве по безопасности ИИ-агентов.
3. Не держите ключи в репозитории и в коде, который уходит в браузер.
4. Разверните приложение на сервере с непривилегированным пользователем, файрволом и TLS: безопасный деплой приложения на VPS.
5. Подготовьтесь к сбою: резервные копии по правилу 3-2-1 и план реагирования на инциденты.

Риск растёт вместе с числом пользователей и чувствительностью их данных, значит, и проверка должна становиться строже. Для личного прототипа достаточно первых трёх пунктов, для продукта с платежами и персональными данными нужны все пять.

Связанные термины: Управление секретами, Защита на уровне строк (RLS), Слопсквоттинг, Промпт-инъекция, Наименьшие привилегии.