«На моєму комп'ютері працює»: як довести AI-автоматизацію від прототипу до продакшну (чек-лист для не програмістів)

«Без цього проєкт буде чудово працювати на локальному комп'ютері, але він завалиться або буде працювати некоректно, як тільки у вас з'явиться 2–3 користувачі». Це фраза з нашого відео про код, який Claude написав за промптом без правил. І це, мабуть, найчастіша причина розчарування в AI-автоматизаціях: у демонстрації все працює, а з першими клієнтами — ні.

У цій статті розберемо, чим прототип відрізняється від продакшну, і пройдемо чек-лист із 12 пунктів, який варто перевірити перед тим, як віддати бота, сервіс чи автоматизацію реальним людям. Програмувати для цього не потрібно: кожен пункт можна перевірити руками або разом з AI-агентом.

Що змінюється, коли з'являються реальні користувачі

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

Конкретно змінюються п'ять речей:

• Одночасність. Двоє людей одночасно змінюють ті самі дані: записуються на той самий час, редагують ту саму заявку.
• Тривалість. Проєкт має працювати тижнями без вашої участі, переживати перезапуски й оновлення.
• Збої. API моделі, CRM чи платіжний сервіс іноді не відповідають, і проєкт має це пережити.
• Чужі дані. Ви відповідаєте за дані клієнтів: хто їх бачить, де вони зберігаються, чи є копії.
• Гроші. Кожен виклик моделі коштує грошей, а помилка в циклі може витратити бюджет за ніч.

Прототип і продакшн: таблиця відмінностей

	Прототип (працює у вас)	Продакшн (працює для людей)
Де працює	На вашому комп'ютері, поки він увімкнений	На сервері чи платформі 24/7
Дані	У пам'яті програми, у файлі або в таблиці	У базі даних з резервними копіями
Користувачі	Одна людина, одна дія за раз	Багато людей одночасно, кожен бачить свої дані
Помилки	Ви бачите їх на екрані й перезапускаєте	Обробляються автоматично, пишуться в лог, ви отримуєте сповіщення
Ключі доступу	Часто прямо в коді	У змінних оточення чи налаштуваннях платформи, з лімітом витрат
Оновлення	Змінили файл — і готово	Перевірена версія, можливість повернутися до попередньої

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

Чек-лист перед запуском: 12 пунктів

Пройдіть цей список перед тим, як дати посилання першому клієнту. Якщо проєкт робив AI-агент, кожен пункт можна перетворити на запитання до нього: «Чи виконується пункт N? Покажи, де це в коді, і як я можу перевірити це сам».

Дані: де зберігаються і що буде після перезапуску

1. Усі дані — у базі даних. Не в змінній програми, не в JSON-файлі й не в пам'яті браузера. Запитайте агента прямо: «Де фізично зберігаються заявки клієнтів?»
2. Перезапуск нічого не губить. Створіть кілька тестових записів, зупиніть і знову запустіть програму або сервер. Усе має залишитися на місці.
3. Є резервні копії, і ви хоча б раз відновили дані з копії. Копія, з якої ніхто не пробував відновитися, — це лише надія. Багато хмарних баз даних і платформ мають автоматичні копії: з'ясуйте, як часто вони робляться і як з них відновитися.

Одночасні користувачі: проста перевірка «двох вкладок»

4. Тест двох вкладок пройдено. Відкрийте проєкт у двох браузерах або з двох акаунтів і одночасно виконайте ту саму дію: запишіться на той самий час, відредагуйте ту саму заявку. Дані не мають змішатися чи перезаписатися, а конфлікт — оброблятися зрозуміло.
5. Кожен бачить лише свої дані. Увійдіть як інший користувач і перевірте, що чужих записів не видно, у тому числі якщо вручну змінити номер запису в адресі сторінки.
6. Повільна дія одного не блокує інших. Відповідь моделі може займати кілька секунд. Поки бот «думає» над повідомленням одного клієнта, інші мають отримувати відповіді. Перевірте: двоє людей пишуть боту одночасно, і жоден не чекає, доки закінчиться розмова з іншим.

Помилки й сповіщення

7. Збої зовнішніх сервісів обробляються. Кожен виклик API моделі, CRM чи пошти має обмеження часу очікування й кілька повторних спроб. Перевірте навмисно: вкажіть неправильний ключ або тимчасово вимкніть інтернет. Користувач має побачити зрозуміле повідомлення, а не «мовчання».
8. Помилки записуються в лог. Коли щось ламається, ви маєте змогу подивитися, що саме, коли і в кого сталося. У no-code платформах це історія виконань, у коді — журнал помилок.
9. Про критичні збої ви дізнаєтеся першими. Налаштуйте сповіщення в Telegram чи на пошту, щоб дізнаватися про проблему раніше, ніж про неї напише клієнт.

Ключі API та доступи

10. Ключі не лежать у коді. Ключі API, паролі до бази даних і токени ботів зберігаються в змінних оточення (файл .env) або в налаштуваннях платформи, а файл .env не потрапляє в Git. Попросіть агента перевірити це в усьому проєкті.
11. На витрати є ліміт. Встановіть ліміт витрат або бюджет у кабінеті провайдера моделі, якщо він це підтримує, і обмеження на кількість запитів від одного користувача. Так помилка в циклі чи зловмисник не витратять місячний бюджет за ніч.

Розгортання

12. Проєкт працює без вашого комп'ютера і є куди повернутися. Він розгорнутий на сервері чи платформі, автоматично перезапускається після збою, а остання робоча версія збережена в Git. Якщо нова зміна щось зламала, ви за кілька хвилин повертаєте попередню. Зміни спершу перевіряйте на тестовій копії, а не на версії, якою користуються клієнти.

No-code (n8n, Make) чи код від AI: що простіше довести до продакшну

No-code платформи знімають із вас частину пунктів чек-листа, але не всі. Код, написаний AI-агентом, дає більше свободи, але й більше рішень, які доведеться ухвалити самостійно.

Пункт	n8n Cloud / Make	Власний код від AI (Claude Code, Codex)
Сервер і доступність 24/7	Забезпечує платформа	Ви обираєте хостинг і налаштовуєте його
Повторні спроби й обробка помилок	Вбудовані налаштування: повтор кроку при збої, обробники помилок	Має бути прописано в коді
Історія виконань і логи	Є в інтерфейсі	Потрібно налаштувати
Де зберігати дані	Однаково ваше рішення	Ваше рішення
Ключі доступу	Зберігаються в обліковому записі платформи	Змінні оточення, ви стежите, щоб вони не потрапили в Git
Обмеження	Ліміти тарифу на кількість запусків чи операцій	Ресурси сервера, який ви обрали

Важливий нюанс: навіть у n8n чи Make рішення про дані залишається за вами. Google-таблиця зручна для старту, але це не база даних: у неї є ліміти на кількість звернень, і вона погано підходить для частих одночасних змін від багатьох людей. Якщо ви встановлюєте n8n на власний сервер, оновлення, резервні копії й доступність також стають вашою відповідальністю.

Детальніше про різницю між платформами — у порівнянні n8n vs Make vs Zapier, а покроковий приклад бота без коду — у статті як створити Telegram-бота з ШІ без коду.

Кейс із відео: що варто було зробити з самого початку

У нашому відео автор чесно розповідає, що «розслабився» і просто написав Claude «створи мені автоматизацію». Результат — код, який не витримав би більше, ніж 2–3 користувачів. Майже всі пункти цього чек-листа можна було закрити ще до першого рядка коду, якби в промпті були правила:

• скільки людей і як користуватиметься автоматизацією (пункти 4–6);
• яка мова, фреймворк і база даних (пункти 1–3);
• де вона працюватиме і як перезапускатиметься (пункт 12);
• що робити з помилками й ключами (пункти 7–11).

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

Де навчитися цьому системно

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

• курс «Як працює веб: від URL до HTTPS, API і безпеки» — база, без якої важко зрозуміти, що саме будує агент;
• n8n для початківців — якщо хочете почати з no-code;
• перший проєкт із вайб-кодингу з Claude Code — якщо хочете, щоб код писав агент;
• Docker з нуля — коли дійдете до власного сервера.

Курс AI Automation поєднує це в одну програму для людей без технічного бекграунду: від ChatGPT і Claude до Make, n8n, AI-агентів, вайб-кодингу з Claude Code і OpenAI Codex, а також деплою, публікації проєктів і створення MVP. Приклади задач, які бізнес автоматизує вже зараз, — у статті 15 прикладів AI-автоматизації бізнесу.

Часті запитання

Що таке продакшн простими словами?

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

Скільки користувачів витримає мій бот?

Це залежить не від кількості рядків коду, а від рішень у його основі: де зберігаються дані, чи обробляє бот кількох людей паралельно, на якому сервері або тарифі платформи він працює. Чесну відповідь дає лише перевірка: тест кількох одночасних користувачів, а для більших навантажень — навантажувальне тестування на тестовій копії проєкту.

Чи потрібен сервер для n8n-автоматизації?

Не обов'язково. У n8n є хмарна версія, де сервер, оновлення й доступність забезпечує сама платформа. Якщо ж ви встановлюєте n8n на власний сервер, за його роботу, оновлення та резервні копії відповідаєте ви. Make працює лише як хмарний сервіс.

Як перевірити навантаження без програміста?

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

Висновок

«На моєму комп'ютері працює» — це не провал, а чесний результат прототипу. Провал починається тоді, коли прототип без перевірки отримують клієнти. Між цими двома станами — 12 простих перевірок: дані в базі й з копіями, кілька одночасних користувачів, оброблені помилки зі сповіщеннями, ключі поза кодом і лімітом витрат, сервер, який працює без вас, і версія, до якої можна повернутися.

Пройдіть чек-лист до першого клієнта, а не після першої скарги.