Границы вайбкодинга: когда прототип можно выпускать, а когда нужен специалист

01 · Граница

Прототип доказывает ценность. Продакшн обязан выдерживать последствия.

Прототип отвечает на вопрос: «Нужен ли человеку такой сценарий?» Он может работать на небольшом объёме, с ручным контролем и временными решениями. Продакшн отвечает на другой вопрос: «Что произойдёт, когда сервис ошибётся, зависнет, получит вредоносный ввод или столкнётся с пользователем, который действует не по инструкции?»

NIST SSDF описывает безопасную разработку как набор практик, которые встраиваются в жизненный цикл, а не добавляются после релиза. [1] CISA формулирует сходный принцип Secure by Design: ответственность за безопасность продукта начинается на этапе проектирования и должна быть включена по умолчанию. [8]

Это не аргумент против вайбкодинга. Наоборот, быстрый прототип помогает раньше увидеть реальный поток пользователя. Просто его нельзя незаметно превратить в продакшн добавлением домена и формы оплаты.

Полезное различие: код прототипа показывает сценарий, а система продакшна ограничивает последствия. В неё входят права доступа, резервное восстановление, журналы, лимиты, поддержка, обработка жалоб, договоры с сервисами и понятный способ остановить опасную функцию. Большая часть этого не видна на экране, поэтому AI легко создаёт иллюзию готовности раньше времени.

04 · Пример

VPN: интерфейс прост, скрытая система сложная.

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

Ошибка в цвете кнопки почти безвредна. Ошибка в выдаче конфигурации может открыть чужой доступ. Неверная маршрутизация влияет на трафик пользователя. Компрометация панели управления затрагивает весь парк серверов. Поэтому UI и закрытый demo относятся к прототипу, а сеть, криптография, ключи, эксплуатация и правовые вопросы требуют профильных специалистов.

Перед разработкой нарисуй границы доверия: где данные переходят от одного владельца или уровня доступа к другому. Отдельно отметь устройство пользователя, control plane — систему, которая выдаёт конфигурации и управляет серверами, data plane — путь реального сетевого трафика, платёжного провайдера, поддержку и администратора. Моделирование угроз как раз начинается с активов, границ доверия, угроз и мер защиты. [9]

Что защищать в первую очередь. Закрытые ключи не должны попадать в клиент или общие логи. Пользователь должен получать только свою конфигурацию. Компрометация одного узла не должна давать доступ ко всей инфраструктуре. Административные действия нужно ограничивать и журналировать, а отзыв ключа — регулярно проверять. Выбор протокола и криптографии перед запуском должен проверить специалист по сетевой безопасности.

05 · Пример

Маркетплейс: каталог можно прототипировать, движение денег нельзя считать обычной формой.

Каталог, поиск, карточку товара и черновик заказа можно тестировать на фиктивных продавцах и ручном подтверждении. Сложность появляется вместе с реальными платежами, возвратами, выплатой одной суммы нескольким сторонам, спором покупателя и продавца, мошенничеством, остатками, доставкой, налоговыми документами и правами сотрудников поддержки.

Одна операция должна быть идемпотентной: повтор webhook не создаёт второй заказ или выплату. Статус на клиенте не доказывает успешность платежа. Доступ сотрудника к заказу не должен автоматически открывать все данные покупателя. Эти требования затрагивают архитектуру, безопасность, бухгалтерию и применимое право.

Полезная граница пилота: деньги двигает проверенный платёжный провайдер, все рискованные операции подтверждаются человеком, суммы и число продавцов ограничены, а сверка и возврат имеют отдельный тестовый сценарий. Архитектурно платежи держатся за отдельным адаптером, как описано в карте слоёв AI-сервиса.

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

06 · Пример

Знакомства и рекомендации: алгоритм создаёт социальные последствия.

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

Рекомендация влияет на то, кого видит пользователь и кто видит его. Ошибка или злоупотребление может масштабироваться через сетевой эффект: один аккаунт контактирует со многими людьми, а неверное правило модерации затрагивает целую группу. Для генеративного AI добавляются внедрение вредоносной инструкции в запрос, раскрытие чувствительной информации и чрезмерные полномочия агента. Эти риски входят в актуальное руководство OWASP GenAI LLM Top 10 2026. [7]

Что скрыто за экраном анкеты. Нужны понятная подача жалобы, быстрая блокировка, защита от повторной регистрации нарушителя, очередь модерации, правила приоритета, журнал решения и безопасный канал для обращения. Рекомендательную модель проверяют не только на «точность», но и на сценарии преследования, дискриминации, появления запрещённого контента и концентрации показов у небольшой группы.

NIST Generative AI Profile предлагает рассматривать специфические риски генеративных систем в связке с целями и приоритетами организации. [4] На практике это означает отдельные тесты рекомендаций, жалоб, блокировок, обходов правил и действия модератора, а не только проверку «модель отвечает».

07 · Переход

Между демо и открытым продом есть ограниченный пилот.

1. Контур

   Ограничь аудиторию и данные.

   Приглашения вместо открытой регистрации, минимальный набор полей, отдельные тестовые организации или пространства, данные которых не смешиваются.

2. Полномочия

   Оставь необратимые действия человеку.

   AI готовит черновик, но не отправляет сообщение, не списывает деньги, не удаляет данные и не блокирует пользователя без подтверждения.

3. Лимиты

   Ограничь радиус поражения.

   Сумма, число сообщений, размер загрузки, скорость запросов, число получателей и дневной бюджет имеют жёсткие пределы.

4. Наблюдаемость

   Подготовь метрики и поддержку.

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

5. Выход

   Заранее определи критерий расширения.

   Пилот становится шире только после прохождения тестов, разбора инцидентов и закрытия критичных неизвестных.

После классификации собранный сервис нужно пропустить через пять технических проверок безопасности. Если сайт собирает данные в Казахстане, отдельно построй карту потока персональных данных.

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

Промпт для Claude

Классифицируй проект до того, как просить AI дописывать функции.

Начни Claude Code в режиме plan и ограничь доступные инструменты чтением. Такие параметры предусмотрены CLI. [10] Скачать полный промпт.

Сначала только изучи описание продукта и файлы. Не меняй проект и не запускай команды без подтверждения. Не проси реальные данные, токены и платёжные ключи.

Оцени восемь осей: данные, деньги, права, ущерб одной ошибки, интеграции, модерация, сетевой эффект и автономность AI. Для каждой укажи доказательство, неизвестное и уровень риска.

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

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

FAQ

Частые вопросы о границе между прототипом и продакшном.

Нужен ли специалист для любого вайбкодинг-проекта?

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

Кто именно нужен?

Зависит от красной оси. Для авторизации и инфраструктуры — опытный backend или security-инженер. Для персональных данных — профильный юрист и инженер, который построит карту. Для платежей — разработчик интеграций плюс финансовый или юридический владелец процесса. Для VPN — сетевой специалист. Для знакомств — ещё и владелец модерации и пользовательской безопасности.

Если платёж полностью ведёт внешний сервис, риск исчезает?

Нет. Провайдер снижает объём собственной платёжной инфраструктуры, но приложение всё равно обрабатывает статусы, повторные уведомления, возвраты, права на заказ и ошибки связи. Настройки доступа и бизнес-логика остаются твоей ответственностью.

Как понять, что пилот можно расширять?

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

Может ли AI сам провести финальный аудит?

AI полезен для карты системы, списка неизвестного и генерации тестов. Финальный допуск нельзя отдавать одной модели: она не наблюдает все внешние настройки, договоры и последствия. Красные риски подтверждаются независимыми тестами и профильными людьми.