Вайб-кодинг позволяет за часы или дни собрать приложение, в котором работают регистрация, формы, хранение данных и основные пользовательские сценарии. Но демонстрация показывает только поведение системы при ожидаемых действиях и штатной работе её компонентов.
Почему работающий прототип ещё не готов к production
Разработка включает требования, которые не видны в интерфейсе. Что произойдёт при двух одновременных запросах? Кто получит доступ к данным? Как система отреагирует на сбой внешнего сервиса? Что случится с оплатой после повторного запроса? Как изменится нагрузка после роста объёма данных?
Вайб-кодинг позволяет превратить описание задачи в работающий интерфейс. При этом часть требований к безопасности, надёжности и эксплуатации может остаться за пределами исходного запроса.
Чтобы учесть их до запуска, нужно заранее определить правила доступа, требования к данным, поведение при сбоях и условия эксплуатации системы.
«Работает» не значит «безопасно»
Представим приложение для работы с заказами. Пользователь входит в аккаунт, открывает заказ и видит его содержимое. Интерфейс не показывает чужие заказы.
Теперь изменим номер заказа прямо в запросе. Проверит ли сервер владельца заказа или вернёт данные только потому, что получил существующий идентификатор?
В интерфейсе разницы нет. Она проявится при обращении к серверу в обход предусмотренного сценария.
Таких требований много. Сервер должен проверять права доступа. Секретные ключи нельзя отправлять в браузер. Загруженные файлы требуют проверки. Входные данные внешних API нужно валидировать. Публичные методы требуют ограничения частоты запросов.
ИИ способен реализовать эти меры. Но сначала они должны появиться в требованиях или попасть в поле зрения инженера.
Работающий сервис может содержать уязвимости
Один из примеров — сервис EnrichLead. Его основатель Леонель Асеведо рассказывал, что создал SaaS в Cursor без вручную написанного кода. После запуска приложение столкнулось с атаками: злоумышленники расходовали лимиты API, обходили подписку и создавали записи в базе. The New Stack также писал о критических API-ключах в клиентской части приложения.
Разбор истории EnrichLead в The New Stack
Сервис выполнял свою основную функцию и обслуживал пользователей. Это не означало, что требования безопасности были соблюдены.
Другой пример даёт исследование RedAccess, о котором писал Axios. Исследователи нашли тысячи публичных приложений, созданных с помощью сервисов для генерации приложений, в которых были доступны чувствительные корпоративные данные. Среди проверенных случаев встречались финансовые сведения, данные медицинских организаций и переписка службы поддержки.
AI vibe-coding apps leak sensitive data — Axios
Эти случаи не означают, что код от ИИ обязательно содержит уязвимости. Они показывают другой риск: приложение можно запустить до проверки требований, которые не проявляются в интерфейсе.
Часть ошибок скрывается за штатными сценариями
Безопасность — только один пример.
Допустим, система принимает оплату. Базовый тест выглядит так: пользователь нажал кнопку, платёжный сервис подтвердил операцию, заказ получил статус «оплачен».
Но production-система должна учитывать и другие сценарии. Что произойдёт при повторном запросе? Что делать, если платёж прошёл, но ответ потерялся? Как обработать повторный вебхук? Что случится, если два процесса одновременно меняют один заказ? Как восстановить состояние, если деньги списаны, а запись в локальной базе завершилась ошибкой?
Для систем, которые работают с деньгами и данными, такие ситуации входят в требования к надёжности.
Запрос «добавь оплату через сервис X» этих требований не содержит. ИИ может выполнить сформулированную задачу и при этом не учесть поведение системы в сценариях, которые в неё не вошли.
Зелёные тесты не доказывают полноту решения
ИИ сократил трудозатраты на написание автотестов. Агент может создать набор похожих сценариев, тестовые данные и проверки граничных значений.
Но тест отвечает только на тот вопрос, который в нём записан.
Для регистрации недостаточно проверить создание пользователя. Нужно определить поведение при повторяющемся email, конкурентных запросах, недопустимых значениях, сбое почтового сервиса, превышении лимита запросов и попытке получить лишние права.
Эти сценарии должен кто-то сформулировать.
Есть и дополнительная особенность агентной разработки. Для ИИ тест — такой же файл проекта, как реализация. Команда «сделай так, чтобы тесты проходили» не задаёт, какие требования должны оставаться неизменными. Агент может изменить код, а может изменить сам тест.
Поэтому задача должна описывать требуемое поведение системы, а тесты — проверять это поведение.
ИИ сокращает время на написание тестового кода. Выбор сценариев и оценка полноты покрытия остаются инженерной задачей.
Опыт помогает находить требования до появления ошибок
Разработчики тоже пропускают проверки прав, ошибаются при работе с транзакциями и выпускают код с уязвимостями.
Ценность опыта состоит в знании типовых мест, где возникают такие проблемы.
Инженер, работавший с production-системами, проверяет дополнительные сценарии: кто имеет право выполнить операцию, что произойдёт при повторном запросе, возможен ли конфликт двух процессов, как система поведёт себя после частичного сбоя, какие данные попадут в лог и можно ли восстановить информацию из резервной копии.
Он также учитывает рост проекта. Запрос, который обрабатывается за приемлемое время на тысяче записей, может потребовать другой структуры данных на десяти миллионах.
Для этого инженер не обязан вручную писать всю реализацию. Код может подготовить ИИ. Задача инженера — задать ограничения и проверить результат по требованиям, которые нельзя оценить по интерфейсу.
Где использовать вайб-кодинг
Вайб-кодинг подходит для прототипов.
С его помощью можно проверить бизнес-гипотезу, показать интерфейс инвестору, провести внутренний эксперимент или проверить интерес пользователей без разработки всех механизмов, необходимых для эксплуатации продукта.
В таком проекте команда может принять технический долг как часть выбранного подхода к проверке идеи.
Условия меняются, когда прототип начинает обслуживать пользователей.
Появляются персональные данные, платежи, внешние интеграции и информация, потеря которой может привести к финансовым или операционным последствиям. Требования к системе меняются, даже если интерфейс остаётся прежним.
От неё теперь требуется не только выполнять основной сценарий. Она должна сохранять данные при сбоях, разграничивать доступ, выдерживать запланированную нагрузку, обновляться без повреждения информации и поддерживать восстановление после отказа.
На этом этапе скорость добавления функций становится одним из критериев, а не единственным.
ИИ помогает реализовать требования, но не определяет их автоматически
Мы используем ИИ-агентов для разработки, тестирования, анализа кода и поиска проблем. Они могут находить уязвимости, предлагать негативные сценарии и проверять варианты реализации.
Но агенту нужно задать требования.
Если никто не определил требование к идемпотентности (способности программы давать один и тот же результат при одинаковых входных данных), ИИ может его не учесть. Если проверку прав реализовали только в интерфейсе, работающая авторизация не защищает данные. Если проект не описывает поведение при частичном сбое, у агента нет критерия, по которому можно определить правильный результат.
Проблема вайб-кода не в том, что нейросеть не умеет писать код. Риск появляется, когда готовую реализацию принимают за готовый программный продукт.
ИИ сокращает часть трудозатрат на разработку. Требования, ограничения и критерии готовности всё равно нужно определить до запуска системы в production.
