Прототип на вайб-кодинге: как довести его до промышленной эксплуатации

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

Вайб-кодинг: что это и где он экономит деньги

Термин запустил Андрей Карпатый в начале 2025 года. Идея простая: вы описываете задачу словами, модель пишет код, а результат оцениваете по тому, работает оно или нет, почти не читая сам код. Для прототипа это отличный режим. Проверка гипотезы, которая раньше стоила 200-300 часов работы команды, теперь занимает несколько вечеров одного человека. Внутренние утилиты, разовые скрипты выгрузки, черновик интерфейса для обсуждения с отделом продаж - всё это спокойно делается вайб-кодингом. Сложность возникает, когда результат тихо переезжает из демо в промышленную эксплуатацию. Осознанного решения запустить непроверенный код обычно никто не принимает: прототип показали, он понравился, первые клиенты уже что-то в нём делают, останавливаться жалко.

Что ломается при выходе в промышленную эксплуатацию

Есть замеры. Veracode в 2025 году прогнала больше сотни языковых моделей через 80 задач с требованиями к безопасности: 45% сгенерированного кода содержало уязвимости из списка OWASP Top 10, а защиту от межсайтового скриптинга модели проваливали в 86% случаев. Крупные модели показывают примерно тот же результат, что и компактные: генерация оптимизирует работоспособность кода, а не его устойчивость к атаке. Дальше - то, что мы находим в прототипах чаще всего.

Секреты и ключи лежат прямо в коде

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

Никто не проверяет права доступа

Самая частая находка в аудитах. Интерфейс показывает пользователю только его заказы, но запрос вида /api/orders/1043 возвращает чужой заказ любому, кто подставит другой номер: проверку прав сделали на фронтенде, ведь визуально всё выглядело верно. Сюда же - отсутствие валидации входных данных, склейка SQL-запросов из строк, загрузка файлов без ограничения типа и размера.

Нет тестов, логов и мониторинга

Прототип проверяют глазами: нажал, сработало. В проде вопрос звучит иначе: почему у клиента вчера в 14:20 не прошла оплата. Без логов ответа нет, а без тестов любая правка превращается в лотерею. Мы видели проект, где починка одной кнопки ломала оформление заказа, и об этом узнали от клиентов через неделю.

На реальных объёмах всё замедляется

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

Зависимости, которые никто не выбирал

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

Код никто не понимает, включая автора

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

Чек-лист самопроверки прототипа: 10 пунктов

Пройдите по списку и честно ответьте да или нет. Каждое нет - это работа, которую придётся сделать до запуска.

1. В коде и в истории репозитория нет паролей, токенов и ключей.
2. Каждый запрос к API проверяет право пользователя на объект, а не просто прячет лишнее в интерфейсе.
3. Входные данные проверяются на сервере: типы, длина, формат, размер и тип загружаемых файлов.
4. Запросы к базе параметризованы, пользовательский ввод не склеивается в SQL.
5. Пароли хранятся хешами современным алгоритмом, у сессий и токенов есть срок жизни.
6. Есть логи ключевых действий с временем, пользователем и результатом.
7. Есть автотесты хотя бы на сценарии с деньгами и доступом к данным.
8. Проект запускается на чистой машине по инструкции, а не только на ноутбуке автора.
9. Есть резервное копирование базы и проверенная процедура восстановления.
10. Для персональных данных известно, где физически лежит база, и это согласуется с 152-ФЗ.

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

Чем проверить код самостоятельно

Часть пунктов чек-листа закрывают бесплатные инструменты, которые запускаются локально за вечер. Аудит они не заменяют, потому что не понимают бизнес-логику, но грубые дыры находят.

Цены по состоянию на июль 2026 года, актуальные условия уточняйте на сайтах вендоров. Начинать логично с бесплатных инструментов, которые работают в вашем контуре. Российские платные продукты берут при требованиях по реестру отечественного ПО, локализации данных или отчётности перед службой безопасности. И помните про ограничение: ни один сканер не скажет, что менеджер видит скидки чужого клиента, для кода это корректная выборка.

Как проходит аудит программного кода за 3-5 дней

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

• День 1. Доступ к репозиторию и стенду, разговор с автором прототипа, разбор архитектуры и стека, автоматические сканы.
• День 2-3. Ручной разбор критичных мест: авторизация и права, работа с деньгами, персональные данные, интеграции, качество данных в базе.
• День 4. Нагрузочная прикидка на реальных объёмах и проверка того, как проект разворачивается с нуля.
• День 5. Сборка отчёта и встреча с командой заказчика.

В отчёте: находки с приоритетами и последствиями для бизнеса, оценка поддерживаемости кода, схема архитектуры, разбор лицензий зависимостей, план работ по трём сценариям с вилками. Такая работа стоит от 80 до 250 тысяч рублей в зависимости от объёма кода и числа интеграций.

Три сценария доработки: сроки и деньги

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

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

Когда прототип лучше переписать

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

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

Ориентир по деньгам: если оценка рефакторинга подобралась к 60-70% стоимости новой разработки, спорить не о чем.

Что забрать из прототипа в любом случае

Даже при полном переписывании прототип не пропадает. Из него забирают то, что стоит дороже кода: проверенные гипотезы, обкатанный UX и требования - прототип работает как ТЗ, по нему аналитик снимает спецификацию за дни. Накопленные данные переносят в новую систему, и для клиентов переход выглядит обновлением.

Главное

• Вайб-кодинг экономит деньги на прототипах, внутренних утилитах и проверке гипотез.
• Проблемы начинаются на границе с промышленной эксплуатацией: по замерам Veracode 45% сгенерированного кода содержит уязвимости из OWASP Top 10.
• Типичные находки: секреты в коде, нет проверки прав на сервере, ноль логов и тестов, падение скорости на реальных данных, лицензионные сюрпризы в зависимостях.
• Чек-лист из 10 пунктов оценивает прототип за час, часть проверок закрывают Gitleaks, Semgrep и Trivy.
• Аудит за 3-5 дней даёт находки с приоритетами и план: рефакторинг, переписывание бэкенда или рестарт.
• Гипотезы, UX и требования переезжают в любой сценарий, потраченное время не пропадает.

Частые вопросы

В чём главные минусы вайб-кодинга для бизнеса? Код выглядит рабочим, но не проверен на безопасность и нагрузку, а поддержка ничем не обеспечена. Пока это прототип, минусов почти нет. Как только внутри появляются деньги и персональные данные, риск переходит на компанию. Можно ли использовать вайб-кодинг в enterprise-контуре? Да, при двух условиях: генерация идёт в изолированной среде без боевых данных, а результат проходит ревью человеком и автотесты перед попаданием в основную ветку. Сколько занимает аудит безопасности кода? Для прототипа обычно 3-5 рабочих дней. Система из нескольких сервисов с интеграциями требует больше, объём оцениваем после первого просмотра репозитория. Что делать, если прототип уже используют клиенты? Три шага за день: отозвать и перевыпустить все ключи, которые лежали в коде, закрыть регистрацию новых пользователей при наличии платежей или персональных данных, включить резервное копирование базы. Дальше можно разбираться с остальным спокойно.

Обсудить свой прототип

Есть работающий прототип и непонятно, что с ним делать дальше? Мы посмотрим код и скажем: доводить или переписывать. Напишите на mail@drsofter.ru, в Telegram @drsofter или через форму на drsofter.ru.