Вы собрали приложение с помощью ИИ. Нейросеть написала компоненты, предложила структуру проекта и помогла исправить ошибки. Сайт открывается по ссылке, формы выглядят аккуратно, кнопки реагируют на нажатия. Возникает желание показать результат настоящим пользователям. Но работающий прототип и приложение, которое можно оставить в эксплуатации, решают разные задачи. Первый показывает, как должна выглядеть идея. Второй должен сохранять данные, ограничивать доступ, выдерживать ошибки и позволять исправлять проблемы после публикации.
Разберём, как проверить результат вайбкодинга перед запуском, даже если часть кода была создана без подробного изучения каждого файла.
Проверяйте действия, а не внешний вид страниц
Предположим, нейросеть собрала AI-сервис. В нём есть регистрация, история переписки, тарифы и кнопка оплаты. По внешнему виду трудно определить, какие функции действительно подключены к серверу.
Начните с одного пользовательского сценария. Зарегистрируйте новый аккаунт, создайте диалог, отправьте сообщение, обновите страницу и войдите с другого устройства. Посмотрите, сохранилась ли история и принадлежит ли она нужному пользователю.
Затем повторите сценарий с ошибкой. Отключите тестовый API, отправьте неправильные данные или попробуйте обратиться к несуществующему чату. Проверьте, что приложение сообщает о проблеме и не показывает чужие записи. Так вы получите список конкретных несоответствий. Это точнее, чем спрашивать нейросеть, готов ли проект к production.
Отдельно проверьте доступ к данным
Интерфейс может скрывать чужие записи, но это ещё не означает, что сервер защищает их. Пользователь способен изменить адрес запроса или отправить его самостоятельно, минуя кнопки сайта. Представим endpoint для истории чата. Если запрос /api/chats/42/ возвращает содержимое диалога только потому, что передан существующий номер, другой человек может попробовать соседние идентификаторы. Сервер должен устанавливать владельца данных по подтверждённой учётной записи и проверять доступ при каждом обращении. Для такой проверки создайте два тестовых аккаунта. Сохраните данные в первом и попытайтесь получить их из второго. Повторите проверку для чтения, изменения и удаления.
То же относится к секретам. API-ключи нейросетей, платёжные ключи и доступы администратора не должны находиться в браузерном коде или публичном репозитории. Даже если ИИ предлагает поместить ключ в переменную NEXT_PUBLIC_, для серверного секрета такой вариант не подходит.
Узнайте, какие внешние сервисы использует прототип
Сгенерированное приложение может зависеть от языковой модели, хостинга, базы данных, почтового сервиса и платёжного провайдера. Пока вы тестируете проект самостоятельно, число обращений невелико. После запуска расходы и ограничения могут измениться.
Составьте таблицу зависимостей. Для каждой укажите, зачем она нужна, кто имеет доступ к настройкам, где хранятся ключи, есть ли лимиты и что произойдёт при недоступности. Например, AI-чат может отправлять каждый запрос через платный API. Если посетитель начнёт отправлять сотни сообщений, стоимость возрастёт. Поэтому серверу нужны ограничения использования, а не только красивый счётчик оставшихся сообщений в интерфейсе.
Также проверьте, можно ли восстановить работу после смены ключа или временного отключения одного из сервисов. Если проект зависит от конкретной модели, продумайте, как приложение сообщит пользователю о её недоступности.
Добавьте проверку основных сценариев
Не обязательно сразу создавать большую систему тестирования. Начните с нескольких действий, от которых зависит смысл продукта. Для AI-сервиса это вход, отправка сообщения, сохранение истории, выдача доступа после оплаты и отказ в доступе без подписки. Часть проверок можно оформить автоматически. Например, следующий тест на Python проверяет, что защищённый endpoint не отдаёт данные анонимному посетителю.
from django.test import TestCase
from rest_framework.test import APIClient
class ChatAccessTests(TestCase):
def test_anonymous_user_cannot_read_chats(self):
client = APIClient()
response = client.get("/api/chats/")
self.assertIn(response.status_code, [401, 403])
Это пример для Django REST Framework, где /api/chats/ существует и требует авторизации. В проекте с другим маршрутом нужно заменить адрес. Тест проверяет только один случай. Он не доказывает, что все пользовательские данные защищены, но помогает не пропустить очевидное нарушение при следующем изменении кода.
Другие проверки касаются ошибок внешнего API, недоступности базы данных и повторной отправки одного действия.
Проверьте деньги и права доступа отдельно
Если в приложении есть платные функции, демонстрационной кнопки «Оплатить» недостаточно. Сервер должен создавать платёж, получать подтверждённый результат и только после этого выдавать доступ. Нельзя предоставлять подписку лишь потому, что браузер открыл страницу успешной оплаты. Пользователь может перейти на такой адрес самостоятельно. Решение о доступе должно опираться на подтверждённое платёжное событие и запись на сервере.
Проверьте также повторную доставку уведомлений. Один платёж не должен продлевать подписку дважды из-за того, что провайдер повторил webhook. При отмене автопродления приложение должно перестать создавать следующие списания.
В статье «Как настроить повторные платежи через ЮKassa для подписки» показано, какие записи и проверки нужны для такого сценария.
Подготовьте приложение к проблемам после публикации
До запуска стоит ответить на вопрос. Как вы узнаете, что у пользователей перестала работать отправка сообщений? Одного сообщения «Что-то пошло не так» на экране недостаточно для диагностики. Серверу нужны журналы ошибок без секретов и личных данных. Для критических операций пригодятся идентификаторы запросов, записи о результатах платежей и сведения о времени ответа внешних сервисов.
Для базы данных продумайте резервное копирование и восстановление. Хранение в облаке само по себе не гарантирует, что удалённые записи можно вернуть в нужном состоянии.
Проверяйте не только исправление проблемы, но и способ его доставки. Изменение кода должно проходить сборку, основные тесты и проверку опубликованного приложения. Лучше знать заранее, как вернуться к предыдущей работавшей версии, если новый выпуск оказался неудачным.
Что делать с кодом, который написал ИИ
Нет необходимости переписывать весь проект вручную только потому, что его собрала нейросеть. Но у каждой критической функции должен быть понятный владелец и проверяемое поведение. Начните с участков, где приложение обрабатывает пользовательские данные, секреты, деньги и права доступа. Проследите путь запроса от интерфейса до сервера и базы. Если назначение файла непонятно, попросите ИИ объяснить его, но затем проверьте объяснение по коду и результатам тестирования.
Отдельная задача убрать временные решения, которые подходят для демонстрации, но мешают эксплуатации. Например, общие тестовые аккаунты, жёстко записанные адреса API и фиктивные ответы, выдаваемые вместо настоящих данных.
В статье «Как превратить созданное с помощью ИИ приложение в рабочий продукт» разобрано подключение первой реальной функции после генерации интерфейса. Здесь проверяем уже собранный сервис перед использованием другими людьми.
От прототипа к обслуживаемому сервису
В моей статье на Habr о платном AI-микро-SaaS показано, как интерфейс, сервер, AI-функции и платёжный контур складываются в одно приложение.
В демонстрационном AI-Chat можно посмотреть интерфейс сервиса с обращением к языковым моделям и серверной логикой.
Курс «LLM-Chat + Mermaid + ЮKassa» посвящён построению связанного приложения на Next.js и Django, подключению LLM, оплате, ограничениям доступа и деплою. Это курс о механике сервиса, а не о генерации готового продукта одной командой.
Результат вайбкодинга можно развивать дальше. Перед запуском убедитесь, что вы способны проверить доступ к данным, объяснить поведение основных функций и восстановить работу приложения после сбоя. Именно эти проверки отделяют демонстрационный прототип от системы, за которую можно отвечать.