Руководство
Vibe coding — это плохо? Что идёт не так и как проверить свой код
Vibe coding сам по себе не плох; риск в том, чтобы выпускать код, который никто не читал. Типичные ошибки ИИ-ассистентов, когда они важны и как их найти.
· 7 мин чтения · Команда vetkit
Коротко
Нет, vibe coding сам по себе не плох. Это быстрый способ получить работающий софт, и для прототипов, внутренних инструментов и обучения он часто оказывается правильным выбором. Проблемой он становится в одной конкретной точке: когда код, который никто не читал, начинает работать с реальными пользователями, реальными данными или реальными деньгами. Риск не в том, что код написал ИИ. Риск в том, что его никто не проверил.
Поэтому полезный вопрос звучит не «плох ли vibe coding?», а «что мне нужно проверить, прежде чем это уйдёт в прод?». Остальная часть руководства отвечает именно на него.
Что такое vibe coding
Vibe coding — это разработка, при которой вы описываете ИИ-ассистенту, что хотите получить, и принимаете написанный им код, по большей части не читая его. Термин придумал Андрей Карпатый в начале 2025 года для стиля работы, в котором вы отдаётесь «вайбу» и забываете, что код вообще существует. Результат вы оцениваете, запуская приложение, а не просматривая изменения.
Это отличается от разработки с помощью ИИ, где разработчик пользуется теми же инструментами, но по-прежнему читает, тестирует каждое изменение и отвечает за него. Большинство реальных проектов находятся где-то посередине и сползают к vibe coding, когда поджимают сроки.
Что идёт не так
ИИ-ассистенты хорошо пишут код, который запускается. Менее надёжны они в том, что не видно, если один раз прокликать приложение. Одни и те же ошибки повторяются снова и снова:
| Проблема | Как это выглядит | Почему вы этого не замечаете |
|---|---|---|
| Секреты не на своём месте | API-ключ закоммичен в репозиторий или попал в браузерный бандл | Приложение в обоих случаях работает одинаково |
| Нет проверок доступа | Любой авторизованный пользователь может читать чужие записи; таблицы в базе данных без правил на уровне строк | Вы всегда тестируете только под своим аккаунтом |
| Несуществующие пакеты | Ассистент выдумывает правдоподобное имя пакета, а кто-то другой мог его уже зарегистрировать | Команда установки завершается успешно |
| Недописанный код | Функции-заглушки, ветки с TODO и проглоченные ошибки остаются в основном сценарии | Happy path по-прежнему проходит |
| Недоверенный ввод используется напрямую | Данные запроса подставляются в SQL, shell-команды, пути к файлам или HTML | Обычный ввод ведёт себя как обычно |
| Никакой готовности к сбоям | HTTP-вызовы без таймаутов, запросы внутри циклов, нет отчётов об ошибках | На десяти строках и одном пользователе всё быстро |
Ничего из этого не ново. Разработчики совершали каждую из этих ошибок задолго до появления ИИ-ассистентов. С vibe coding меняются объём и пропавший этап ревью: кода приходит больше и быстрее, а человек, который заметил бы проблему, его так и не читает. Три из них подробно разобраны в других материалах на этом сайте: API-ключи в браузере, выдуманные пакеты и утёкшие секреты.
Когда это важно, а когда нет
Vibe coding — разумный выбор, когда ошибка обходится дёшево:
- Прототип или демо, которое выбросят или перепишут.
- Личный скрипт или внутренний инструмент без чувствительных данных.
- Изучение нового фреймворка или проверка идеи.
Проверка перед релизом нужна, когда ошибка обходится дорого:
- В приложении есть пользовательские аккаунты, платежи или персональные данные.
- Оно хранит учётные данные других сервисов, например LLM-провайдера или базы данных.
- Другие люди будут рассчитывать на его стабильную работу, или поддерживать его придётся кому-то ещё.
Граница проходит не по тому, как был написан код, а по тому, что произойдёт, если код окажется неверным. Многие проекты пересекают эту границу, хотя никто этого не решал: у демо появляются первые реальные пользователи, и никто не возвращается, чтобы его прочитать.
Как сохранить скорость и избавиться от риска
Отказываться от скорости не нужно. Нужно вернуть проверку, которую vibe coding пропускает.
- Читайте изменения, которые касаются денег, входа и данных. Код вёрстки можно не читать. Аутентификацию, авторизацию, платежи и всё, что пишет в базу данных, пропускать нельзя. В чек-листе ревью кода, сгенерированного ИИ перечислено, на что смотреть.
- Тестируйте с двумя аккаунтами. Войдите под одним пользователем и попробуйте прочитать или изменить записи другого. Этот единственный тест находит самый опасный класс багов в приложениях, написанных через vibe coding.
- Проверяйте каждую новую зависимость. Убедитесь, что пакет существует, что это именно тот пакет, который вы имели в виду, и что его не опубликовали на прошлой неделе.
- Сканируйте репозиторий перед релизом. Автоматический аудит находит механические проблемы быстрее человека: закоммиченные секреты, уязвимые или несуществующие зависимости, отсутствие таймаутов и небезопасную обработку ввода. Каталог проверок vetkit показывает правила, которые он запускает, а бесплатный Security Quick Scan охватывает секреты, известные уязвимости зависимостей и базовую конфигурацию безопасности.
- Попросите ассистента исправить то, что нашёл сканер. Подключите сканер к своему coding-агенту, чтобы находки возвращались в тот же диалог. Как это сделать, показано в руководстве по MCP.
Когда будете готовы к релизу, чек-лист безопасности перед выпуском приложения, написанного через vibe coding шаг за шагом проведёт вас через решение о релизе.
Источники и ограничения
Список типичных проблем отражает категории, которые покрывают собственные правила vetkit для рисков ИИ-кода, безопасности, отказоустойчивости и доступа к данным, по состоянию на 10 ноября 2026 года. Это описание повторяющихся паттернов, а не измерение того, как часто они встречаются. Термин «vibe coding» взят из поста Андрея Карпатого от февраля 2025 года.
Автоматическое сканирование — это материал для проверки, а не доказательство того, что приложение безопасно. Сканер читает исходный код; он не тестирует права доступа в вашем развёрнутом окружении, конфигурацию хостинга или бизнес-правила. Тест с двумя аккаунтами и ручное ревью, описанные выше, остаются вашей задачей.