Как проверить проект, созданный с помощью вайбкодинга, перед запуском

Проверять нужно не «код от ИИ», а готовый продукт

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

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

1. Зафиксируйте, что именно считается готовым

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

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

2. Запустите проект в чистом окружении

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

Для веб-приложения полезен отдельный Preview-стенд. Он позволяет проверить изменения в среде, похожей на Production, до переключения рабочего домена. У Vercel Preview и Production имеют отдельные окружения и переменные, поэтому их нужно проверять раздельно.

3. Пройдите сценарии с разных ролей

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

Важный вопрос звучит не «есть ли авторизация?», а «проверяется ли право на каждое действие на сервере?». Если система работает с заказами, деньгами или личными данными, это должен подтвердить разработчик, а для серьёзного запуска — отдельный специалист по безопасности.

4. Проверьте данные и восстановление

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

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

5. Проверьте секреты и внешние сервисы

Секреты не должны храниться в репозитории, скриншотах, клиентском JavaScript или переписке без контроля доступа. Составьте перечень внешних сервисов: база, почта, платежи, хранилище файлов, аналитика, Telegram, CRM или API.

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

6. Запустите автоматические проверки

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

Посмотрите на историю изменений. В GitHub pull request объединяет описание, проверки, список изменённых файлов и обсуждение ревью. Это удобнее, чем принимать большой набор файлов по архиву без объяснения, что и зачем менялось.

7. Проверьте безопасность по отдельному списку

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

Для приложения с платежами, медицинскими или финансовыми данными, персональными сведениями и постоянной доступностью нужен другой уровень проверки. В таком случае критерий «страница открывается» явно недостаточен.

8. Смоделируйте сбой и откат

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

Затем попросите показать, как вернуть предыдущую версию приложения и восстановить данные. Если ответ звучит как «разберёмся, когда что-то случится», запуск ещё не готов.

Какие доказательства попросить у исполнителя

Область	Что должно остаться после проверки
Сценарии	Список проверенных действий и критериев приёмки
Сборка	Команда запуска, результат сборки и версии среды
Данные	Описание схемы, миграций, резервной копии и восстановления
Доступы	Перечень аккаунтов, ролей и владельцев без передачи секретов в чате
Ошибки	Место логов, уведомления и план отката
Изменения	Репозиторий, история коммитов и понятный список известного долга

Когда можно запускать

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

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

Итог

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