Lovable чи Bolt застрягли в циклі виправлення багів? Як довести MVP до кінця

Ви просите конструктор виправити вхід. Він працює, але тепер дашборд порожній. Ще один промпт повертає дашборд — і знову ламає вхід. Якщо Lovable чи Bolt раз у раз лагодить ті самі баги, наступний корисний крок — зібрати кращі докази щодо однієї конкретної помилки. Більше змін не означає автоматично більше прогресу.

Чому AI-застосунок застрягає в циклі виправлень?

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

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

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

Зламався попередній перегляд у конструкторі чи ваш застосунок?

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

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

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

Що зберегти перед наступною спробою виправлення?

Збережіть останній корисний стан коду та визначте дані, на які може вплинути виправлення. Історія коду й резервні копії бази даних розв’язують різні задачі відновлення.

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

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

Який вигляд має корисний промпт на виправлення?

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

Investigate one issue: a signed-in customer cannot save a booking.
Steps: create a fresh customer account, open /bookings/new, choose a date, and select Save.
Expected: one booking is saved and appears after refresh.
Actual: the request returns 403 and no booking is saved.
Evidence: [sanitized error, request path, and timestamp].
First explain the likely cause and the files or policies involved.
Do not change roles, remove access checks, redesign screens, or rewrite unrelated features.
Propose the smallest fix and how to test it with two ordinary accounts.

Цей приклад гіпотетичний. Замініть його деталі тим, що ви справді спостерігали. Відповідь 403 — це підказка про збій доступу, а не дозвіл прибрати авторизацію. Не додавайте паролі, токени, рядки підключення та дані клієнтів у промпти й скриншоти.

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

Як переконатися, що виправлення справді спрацювало?

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

1. Повторіть початковий збій із новим обліковим записом і тими самими вхідними даними.
2. Оновіть або знову відкрийте застосунок і переконайтеся, що результат збережено правильно.
3. Повторіть із другим звичайним обліковим записом і перевірте задані межі власності даних.
4. У безпечному тестовому середовищі спробуйте один сценарій збою, наприклад некоректні дані або перерваний запит.
5. Перевірте суміжні сценарії, що використовують змінений код, а потім запустіть відповідні перевірки проєкту та продакшн-збірку.

Коли варто залучити розробника?

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

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

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

Що має увійти в наступний реліз?

Наступний реліз має закрити невеликий вимірюваний набір зламаних сценаріїв. Тримайте запити на нові функції окремо, доки ці сценарії не будуть перевірені в опублікованому застосунку.

Скористайтеся планом запуску MVP із 12 перевірок, щоб після виправлення виявити суміжні прогалини. Якщо застосунок працює в попередньому перегляді, але ламається після публікації на Replit, скористайтеся чеклістом деплою на Replit. Якщо потрібна практична допомога, оберіть свою відправну точку на сторінці Lovable або Bolt і забронюйте дзвінок. Приходьте зі зламаним сценарієм — перша розмова має допомогти визначити корисний наступний крок.