Что должен делать прототип?
Опишите поведение программы до того, как попросите ИИ написать код. Кто пользователь, что он хочет сделать, что вводит и какой результат ожидает получить? Очень помогает небольшой конкретный пример: «посетитель вводит имя, адрес почты и короткое сообщение; сообщение сохраняется, посетитель видит подтверждение» гораздо проще и собрать, и проверить, чем «сделай форму обратной связи».
Сразу опишите, какие данные считаются неправильными и что программа делает при ошибке: пустое поле, адрес почты с опечаткой, внешний сервис, который не отвечает. Если этого не сделать, сгенерированный код, как правило, будет рассчитан только на случай, когда всё идёт гладко.
Просите об одном ограниченном изменении за раз — таком, которое можно просмотреть и понять, — а не о постоянно растущем списке функций. Храните прототип в системе контроля версий, чтобы вернуться к последнему рабочему состоянию, если очередное изменение что-то сломает. И чётко подписывайте тестовые данные и демонстрационные экраны, чтобы никто не принял демонстрацию за работающую функцию.
Как проверить весь сценарий и код?
Проверяйте сценарий целиком, включая экраны, над которыми вы сейчас не работали. Сначала пройдите его обычным путём до конца, а затем попробуйте оставить поля пустыми и повторить действия: что будет, если отправить одну и ту же форму дважды или обновить страницу на середине?
Затем загляните глубже. Выясните, где хранятся данные, к каким внешним сервисам обращается код и как проверяются права доступа. Пароли, API-ключи и другие секреты никогда не должны попадать в код, который выполняется в браузере, или в репозиторий. Сгенерированному коду нужна независимая проверка, особенно там, где речь идёт о входе в систему, данных извне и изменении записей. Хорошей отправной точкой для такой проверки станет руководство OWASP по безопасной разработке с ИИ — ссылка на него приведена ниже.
И наконец, проверьте настоящий результат. Надпись «Готово» на экране ещё не значит, что данные действительно сохранились или письмо действительно ушло. Откройте базу данных, почтовый ящик или целевую систему и убедитесь, что нужная операция выполнена.
Готов ли прототип к реальной работе?
Прототип может ответить на вопрос об удобстве или о самом продукте и при этом быть не готовым к реальной эксплуатации. Это два разных вида готовности, и их лучше прямо разделять. Прототип, который показал, что пользователи понимают сценарий, свою задачу выполнил, даже если он не выдержит настоящей нагрузки или невнимательного пользователя.
Запишите, что вы узнали: известные ограничения, проведённые проверки и их результаты, а также изменения, без которых прототип нельзя запускать в работу. Если проект двигается дальше, ещё до запуска продумайте развёртывание, мониторинг, восстановление после сбоев и поддержку. Именно о них легче всего забыть, когда прототип быстро собран с помощью ИИ, а на этом этапе это уже разработка MVP.
В обучении держите цель на виду: понимать пользовательский сценарий и уметь проверить небольшую реализацию. Это реалистичный и ценный результат. А вот обещать, что любое сгенерированное приложение готово к запуску, нельзя.
Чек-лист: проверка прототипа
- Опишите небольшое поведение, включая неправильные данные и ошибки.
- Просите о небольших изменениях и храните версию, к которой можно вернуться.
- Проверьте сгенерированный код, права доступа, секреты и внешние вызовы.
- Убедитесь в настоящем результате в базе данных или целевой системе, а не только по надписи на экране.
- Запишите ограничения и то, что нужно для реальной эксплуатации.
Разбор на примере
Прототип собирает бриф и сохраняет его файлом. Прежде чем он начнёт отправлять настоящие заявки, команда добавляет серверную интеграцию, обработку ошибок и защиту от спама и проверяет каждый шаг.
