Як перетворити прототип на AI-застосунок у продакшені

Щоб вивести AI-прототип у продакшен, потрібно закрити розрив між «працює, коли я його пробую» і «працює, коли ним користуються інші люди». На практиці це п’ять речей: тестувати основні сценарії щоразу, коли ви щось міняєте, обмежити, хто що бачить і змінює, переконатися, що ви дізнаєтеся про помилки раніше за користувачів, робити резервні копії даних і підтвердити, що їх можна відновити, а також тримати застосунок достатньо швидким на телефоні. Нічого з цього не вимагає переписувати застосунок — це чеклист, який ви проходите разом із тим самим AI, що створив прототип.

Прототип проти продакшену: що насправді змінюється

У прототипу один уважний користувач: ви. Ви знаєте, які кнопки натиснути, вводите розумні дані, а якщо щось ламається, знизуєте плечима і просите AI виправити. У продакшені багато неуважних користувачів, кілька допитливих і зрідка один ворожий. Код не має стати «корпоративним»; він має обробляти ситуації, з якими прототип ніколи не стикається.

Решта посібника розбирає кожен рядок.

Крок 1: Зафіксуйте обсяг і запишіть основні сценарії

Перед тим як щось зміцнювати, визначте, що таке перша версія. Складіть список із трьох–шести сценаріїв, які важливіші за все, — наприклад, «реєстрація, створення проєкту, запрошення колеги, оплата». Вони стають вашим тестовим сценарієм, цілями моніторингу і тим, що ви перевіряєте після кожної зміни.

Все, чого немає в списку, або вирізається, або чітко позначається як бета. Зробити чотири сценарії надійними набагато легше, ніж чотирнадцять.

Крок 2: Тестуйте як стороння людина, а потім зробіть це повторюваним

AI-конструктори добре створюють код, який працює на щасливому шляху. Проблеми продакшену живуть на нещасливих шляхах. Тестуйте кожен основний сценарій так:

• Неправильні вхідні дані: порожні обов’язкові поля, ім’я на 5000 символів, email без @, від’ємна кількість, дата в минулому.
• Оновлення і кнопка «назад»: перезавантажте сторінку посеред оформлення замовлення; натисніть «назад» після надсилання форми. Чи нічого не створюється двічі?
• Дві вкладки, два користувачі: увійдіть у два різні акаунти і спробуйте відкрити сторінки одне одного, змінивши ID в URL.
• Повільно і на малому екрані: екран розміром із телефон і обмежене з’єднання (інструменти розробника в браузері можуть його імітувати).
• Порожні стани: новий акаунт без даних. Прототипи часто створюють із зразковими даними і без них виглядають зламаними.

Потім зробіть перевірку повторюваною. Щонайменше ведіть письмовий чеклист і проходьте його перед кожним релізом. Ще краще — попросіть AI написати автоматизовані тести для найважливіших сценаріїв:

Додай автоматизовані наскрізні тести для цих сценаріїв: реєстрація за email, створення проєкту, запрошення другого користувача і оформлення оплати в тестовому режимі Stripe. Також додай тести, які підтверджують, що користувач не може переглянути або змінити проєкт іншого користувача, змінивши URL.

Тести, які доводять, що користувач не може щось зробити, — саме ті, яких найчастіше бракує прототипам.

Крок 3: Базові речі безпеки, які прототипи пропускають

Більшість проблем безпеки в застосунках, створених AI, не екзотичні. Це відсутні перевірки. Пройдіться цим списком і подивіться повніший чеклист безпеки для застосунків, створених AI:

• Авторизація на сервері. Приховати кнопку — це не безпека. Кожен запит, який читає або змінює дані, має перевіряти на сервері, що користувачеві дозволено це робити. Якщо ваш застосунок використовує базу даних з правилами на рівні рядків, перевірте, що вони увімкнені і протестовані.
• Секрети поза браузером. Ключі API для платежів, email або AI-провайдерів мають бути у змінних середовища на сервері, ніколи — у фронтенд-коді. Якщо не впевнені, що це означає, прочитайте що таке змінні середовища і секрети.
• Валідація на сервері. Браузер можна обійти, тож повторюйте на сервері кожну важливу перевірку.
• Вхід зроблено правильно. Використовуйте перевірену бібліотеку або сервіс автентифікації, а не власноруч написане зберігання паролів. Наш посібник про додавання входу до застосунку розглядає варіанти.
• Обмеження частоти запитів для входу, реєстрації, скидання пароля і всього, що надсилає email або викликає платний API.
• Зрозумілі помилки. Користувачі мають бачити «щось пішло не так»; деталі йдуть у ваші логи, а не на екран.
• Замініть усе, що витекло. Якщо живий ключ колись вставили в чат, коміт або скриншот, замініть його у провайдера.

Промпт, який охоплює багато одразу:

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

Запит на список спочатку дає змогу побачити проблеми і вирішити порядок їх виправлення, а не отримати одну величезну зміну.

Крок 4: Знайте, коли щось ламається — логування і моніторинг

У попередньому перегляді ви бачите помилки в момент їх появи. У продакшені застосунок має сам вам повідомляти. Три рівні, від найдешевшого до найкориснішого:

1. Логи сервера. Переконайтеся, що помилки записуються з достатнім контекстом, щоб відтворити їх: який маршрут, ID користувача (не пароль і не картку), форма вхідних даних. Якщо застосунок лише виводить у консоль, попросіть AI додати структуроване логування.
2. Відстеження помилок. Сервіс на кшталт Sentry або подібний інструмент фіксує винятки на фронтенді й бекенді, групує їх і надсилає вам email. Для невеликого застосунку безкоштовних тарифів цих сервісів часто достатньо; актуальні ліміти перевіряйте на їхніх сайтах.
3. Перевірки доступності. Зовнішній сервіс, який кожні кілька хвилин завантажує вашу головну сторінку і один ключовий маршрут API і повідомляє, якщо вони не працюють. Це ловить проблеми, через які застосунок взагалі не може нічого логувати.

Додайте ще одну звичку: після кожного релізу відкривайте живий застосунок і проходьте чеклист основних сценаріїв на справжній адресі, а не лише в попередньому перегляді.

Крок 5: Резервні копії і шлях назад

Потрібно захищати дві різні речі, і їх легко сплутати.

• Код. Зберігайте проєкт у системі контролю версій, щоб будь-яку зміну можна було скасувати. Багато AI-конструкторів зберігають контрольні точки ваших файлів; синхронізація з Git-репозиторієм дає копію і поза конструктором.
• Дані. Відкат коду не відкочує базу даних. Погана міграція або кнопка видалення з помилкою можуть знищити рядки, які жодна контрольна точка коду не поверне.

Для даних налаштуйте регулярні резервні копії, що зберігаються не на хостингу застосунку, — для бази Postgres поширений підхід: запланований pg_dump у окреме сховище, а багато керованих хостів баз даних пропонують автоматичні бекапи або відновлення на певний момент часу. Потім зробіть крок, який більшість пропускає: відновіть копію в тимчасову базу даних і перевірте, що дані на місці.

Також попросіть AI зробити небезпечні дії безпечнішими: крок підтвердження для видалень і «м’яке видалення» (позначати рядки як видалені замість фізичного видалення) для всього, що користувачі можуть захотіти повернути.

Крок 6: Продуктивність, яка витримує на телефоні

Прототипи здаються швидкими, бо ви єдиний користувач і даних мало. Перед запуском:

• Завантажте дані реального розміру. Попросіть AI згенерувати кілька тисяч рядків і подивіться, які сторінки сповільнюються. Списки зазвичай потребують пагінації, а база даних — індексів на стовпцях, за якими ви фільтруєте й сортуєте.
• Зменште зображення. Завеликі зображення — найпоширеніша причина повільного завантаження сторінки. Попросіть стиснути і змінити розмір зображень та ліниве завантаження нижче згину.
• Виміряйте. Запустіть Lighthouse в інструментах розробника Chrome на живій адресі в мобільному режимі. Орієнтир — Core Web Vitals від Google: Largest Contentful Paint не більше 2,5 секунди, Interaction to Next Paint 200 мс або менше і Cumulative Layout Shift 0,1 або менше.
• Стежте за затримками «пробудження». Хостинг, який засинає без активності, економить гроші, але робить перший візит після тиші повільнішим. Для нового застосунку це часто прийнятний компроміс; просто знайте, що це відбувається.

Сторінка проєктів повільна з 5000 рядків. Додай пагінацію на сервері (по 25 на сторінку), додай індекси бази даних для стовпців, за якими ми фільтруємо і сортуємо, і покажи стан завантаження, поки йде завантаження наступної сторінки.

Крок 7: Операційні основи

Кілька дрібниць відрізняють хобі-застосунок від того, якому люди довіряють:

• Власний домен з HTTPS. Див. як підключити власний домен.
• Транзакційні листи з верифікованого домену для підтверджень реєстрації та скидання пароля — розглянуто в як надсилати листи з застосунку.
• Політика конфіденційності й умови, які описують, що ви справді збираєте. Не копіюйте заяви про відповідність вимогам, яких ви не досягли.
• Канал підтримки — хоча б контрольована поштова скринька.
• Окремі тестові і робочі ключі для платежів і пошти, і чітка примітка, яке середовище що використовує.

Крок 8: Чиста передача проєкту

Рано чи пізно над застосунком працюватиме хтось інший: фрилансер, новий співзасновник або ви через півроку. Зробіть це легким:

• README, який пояснює, як його запустити, які змінні середовища потрібні (лише назви, ніколи значення) і як його розгорнути.
• Чеклист основних сценаріїв і автоматизовані тести.
• Коротка примітка про архітектуру: фронтенд, бекенд, база даних, сторонні сервіси і де що розміщено.
• Список доступів: хто має адміністративний доступ до домену, хостингу, бази даних, платіжних і поштових акаунтів. Ці акаунти має бути під діловою поштою, а не особистою.
• Код у Git, бажано синхронізований з репозиторієм, який належить вам. Якщо ви можете згодом змінити хостинг, прочитайте як експортувати застосунок, створений AI, і розгорнути його самостійно.

AI може написати більшу частину цього за вас:

Напиши README для цього проєкту для розробника, який його ще не бачив: що робить застосунок, стек технологій, як запустити його локально, кожну змінну середовища, яку він читає (лише назви і призначення), як організовано схему бази даних і як його розгорнути.

Чеклист готовності до продакшену

• Основні сценарії записані і протестовані, включно з перевіркою «не може отримати доступ до чужих даних»
• Авторизація і валідація на сервері для кожного маршруту з даними
• Немає секретних ключів у фронтенд-коді; витеклі ключі замінено
• Обмеження частоти для автентифікації та всього, що коштує грошей
• Відстеження помилок і сповіщення про доступність надходять на скриньку, яку ви читаєте
• Резервні копії бази даних зберігаються не на хостингу застосунку, і одне відновлення успішно перевірено
• Пагінація та індекси перевірені на реалістичних даних
• Власний домен, верифікований домен для надсилання, політика конфіденційності
• README і список доступів для наступної людини

Робота з Mythex

Якщо ви створили прототип у Mythex, більшість цих кроків — це промпти в тому самому проєкті. Введіть /test, і Mythex пройде живий попередній перегляд як користувач і повідомить про зламані сценарії — див. App Testing. Ключі додаються в секрети проєкту, а не в чат; кожен успішний хід агента зберігає контрольну точку ваших файлів, до якої можна повернутися; публікація дає живу адресу з хостингом, а база даних оплачується з того самого балансу кредитів (ліміти хостингу пояснює, як застосунки і бази даних засинають і прокидаються). Контрольні точки охоплюють файли, а не рядки бази даних, тож резервні копії даних все одно плануйте. На тарифі Pro можна підключити власний домен і експортувати код або синхронізувати його з вашим GitHub-репозиторієм для передачі проєкту.

Запитання