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

Где заканчивается вайбкодинг и начинается продакшн?

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

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

Чем прототип отличается от продакшна?

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

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

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

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

По каким восьми осям оценить риск проекта?

NIST AI RMF предлагает управлять AI-рисками через govern, map, measure и manage в течение всего жизненного цикла. Практический перевод для маленькой команды: сначала опиши задачу и затронутых людей, затем сценарии ошибки, измерение и меры сдерживания.

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

Как по осям выбрать зону: прототип, пилот или специалист?

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

Можно прототипировать

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

Нужны тесты и пилот

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

Нужен специалист

• Высокий ущерб одной ошибки.
• Платежи, регулируемые или особо чувствительные данные.
• Сложная авторизация и админ-доступ.
• AI действует без человека.
• Ошибка масштабируется через сеть.

Для веб-приложений OWASP ASVS даёт проверяемые требования к техническим контролям, а OWASP API Security Top 10 напоминает про объектную авторизацию, ограничение ресурсов и риски внешних API.

Если сомневаешься между двумя зонами, выбирай более строгую до появления доказательства. Доказательством может быть тест, техническое ограничение, документ провайдера или заключение специалиста. Фраза «AI сказал, что всё безопасно» доказательством не служит.

Почему VPN-сервис сложнее, чем его интерфейс?

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

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

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

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

Что можно прототипировать в маркетплейсе, а что нельзя?

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

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

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

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

Какие последствия создаёт сервис знакомств?

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

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

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

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

Как провести ограниченный пилот между демо и продом?

• Контур. Ограничь аудиторию и данные. Приглашения вместо открытой регистрации, минимальный набор полей, отдельные тестовые организации или пространства, данные которых не смешиваются.
• Полномочия. Оставь необратимые действия человеку. AI готовит черновик, но не отправляет сообщение, не списывает деньги, не удаляет данные и не блокирует пользователя без подтверждения.
• Лимиты. Ограничь радиус поражения. Сумма, число сообщений, размер загрузки, скорость запросов, число получателей и дневной бюджет имеют жёсткие пределы.
• Наблюдаемость. Подготовь метрики и поддержку. Команда видит ошибки, стоимость, отклонения и жалобы. Есть kill switch: один проверенный способ быстро отключить опасную функцию без остановки всего продукта.
• Выход. Заранее определи критерий расширения. Пилот становится шире только после прохождения тестов, разбора инцидентов и закрытия критичных неизвестных.

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

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

Какие сигналы только кажутся доказательством готовности?

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

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

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

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

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

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

На какие документы опирается статья?

Все ссылки проверены 12 ноября 2026 года. Датозависимые требования, версии документов и настройки сервисов нужно перепроверить перед применением.

• NIST: SP 800-218 Secure Software Development Framework Практики безопасной разработки, подготовки, защиты, производства и реагирования на уязвимости. Версия 1.1, февраль 2022 года.
• NIST: AI Risk Management Framework Добровольная рамка управления рисками AI для людей, организаций и общества. Версия 1.0 от января 2023 года, NIST сообщает о её пересмотре.
• NIST AIRC: AI RMF Core Функции govern, map, measure и manage и непрерывный характер управления рисками.
• NIST: Generative AI Profile, NIST AI 600-1 Риски generative AI и предлагаемые действия на разных этапах жизненного цикла. Выпуск июль 2024 года.
• OWASP: Application Security Verification Standard База проверяемых требований к техническим контролям веб-приложений. Версия 5.0.0 от 30 мая 2025 года.
• OWASP: OWASP API Security Top 10 2023 Категории рисков API, включая объектную авторизацию, ресурсы и небезопасное потребление API.
• OWASP: OWASP GenAI LLM Top 10 2026 Актуальное руководство OWASP по критичным рискам LLM- и GenAI-приложений, сценариям атак и мерам снижения риска. Версия 1.0 от 3 августа 2026 года.
• CISA: Secure by Design Подход, при котором производитель отвечает за безопасность продукта с этапа проектирования и по умолчанию.
• OWASP: Threat Modeling Cheat Sheet Четыре вопроса: что мы строим, что может пойти не так, что с этим делать и достаточно ли хорошо справились. Границы доверия отмечаются на схеме потоков данных.
• Anthropic: Claude Code CLI reference Режим plan и ограничение доступных инструментов при анализе проекта.