Когда прототип на вайбкодинге пора передавать в полноценную разработку

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

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

Почему прототипный режим заканчивается

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

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

Шесть сигналов перехода

1. Ошибка затрагивает реальную запись

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

2. Появились разные роли

Одно окно для автора и пользователя быстро превращается в правила видимости. Менеджер может менять статус. Клиент видит только свой заказ, а руководитель экспортирует отчёт. Эти права нужно описать и проверить на сервере.

3. Интеграции стали частью процесса

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

4. Требования расходятся между пользователями

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

5. Никто не может объяснить, как откатить изменение

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

6. Поддержка зависит от одного чата

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

Что оставить ИИ

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

Меняется точка контроля. Модель предлагает изменение; человек проверяет намерение, diff, тесты и последствия для данных. Чем выше цена ошибки, тем меньше должен быть размер изменения и тем яснее критерий его отмены.

Минимальный инженерный шлюз

Перед первым рабочим запуском зафиксируйте:

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

Для веб-приложения OWASP ASVS даёт основу для проверки технических средств безопасности. NIST SSDF даёт язык для обсуждения практик безопасной разработки. Используйте релевантные пункты, а не превращайте небольшой продукт в формальный отчёт на сотни страниц.

Как принять решение

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

Это не спор о том, какой инструмент «правильный». Это изменение ответственности. На VibeMarket можно оформить такую задачу как аудит и поэтапную передачу: сначала карта рисков и приоритеты, затем исправления с критериями приёмки. Так AI-built проект не приходится переписывать вслепую только потому, что его временные решения никто не зафиксировал.

Полезно почитать на VibeMarket

• when vibe coding is not a good fit
• what projects can vibe coder build
• how to check ai built project before launch