Lovable, Bolt, v0, Cursor — що робити, коли код ШІ зламався

Сцена, яку я бачу майже щотижня. Людина за вихідні через Lovable, Bolt чи v0 збирає робоче демо, тішиться, показує друзям. Потім хоче додати одну річ — оплату, вхід, ще один екран — і все починає розсипатися. Просить ШІ полагодити. Лагодить. За годину ламається те, що працювало. Знову просить виправити. Після десятого кола код уже такий, що ні людина, ні ШІ не розуміють, що відбувається.

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

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

Чому ШІ доводить до 80% і там зупиняється

Lovable, Bolt і v0 чудово й швидко роблять ту частину, яка видима — кнопки, форми, екрани, гарне розташування. Це приблизно 80% того, що виглядає як «програма». Але решта 20% — оплата, автентифікація, база даних, деплой, безпека, захист персональних даних, граничні випадки — це найскладніша, найдорожча і саме та частина, через яку програма взагалі працює з живими людьми. ШІ там не вдосконалюється, а врізається у стіну.

Причина проста. Той видимий шар шаблонний: подібних форм і екранів в інтернеті мільйони, ШІ їх «бачив» і відтворює миттєво. А решта 20% унікальні для твого проєкту й потребують рішень, які треба ухвалювати, розуміючи ціле — як течуть дані, де вони зберігаються, хто що може бачити, що стається, коли оплата не проходить. Це не копіювання, а інженерія. І саме там усе починає ламатися.

Де ламається — за інструментами

Кожен інструмент має свій «характер» і своє типове місце збою. Знаючи його, набагато швидше розумієш, що насправді тримаєш у руках.

Lovable — деплой і база даних

Lovable будує повний застосунок (React + Supabase) і чимало робить сам, тому спочатку виглядає магічно. Але ламається зазвичай у двох місцях. Перше — база даних Supabase: коли модель даних ускладнюється, починається плутанина з RLS (правилами безпеки на рівні рядків), зв'язки між таблицями переплутуються, а запити повертають або забагато, або нічого. Друге — деплой і середовища: локально чи в попередньому перегляді Lovable працює, а на реальному домені зі справжніми змінними вже ні, бо ключі, посилання чи CORS налаштовані лише під «демо-режим».

Bolt — state та інтеграції

Bolt чудово й дуже швидко генерує інтерактивний фронтенд. Стіна — коли в застосунку з'являється багато стану (state): кошик, залогінений користувач, фільтри, форми, що залежать одна від одної. Цей state починає «втікати» — натискаєш в одному місці, оновлюється непов'язана річ в іншому. Друге болюче місце Bolt — інтеграції з реальними системами: оплата (LiqPay, WayForPay, plata by mono), пошта, зовнішній API. На рівні демо Bolt показує, «як би це виглядало», але для справжнього під'єднання потрібні серверна частина, керування секретами й обробка помилок, яких швидка генерація не робить.

v0 — гарний UI, але немає бекенду

v0 (від Vercel) найкращий із цієї групи в одному — створити справді гарний компонент інтерфейсу React/Next.js чи цілий вигляд сторінки. Але важливо зрозуміти, що він робить: він робить фасад. Немає бази даних, немає входу, немає серверної логіки, немає того, де зберігаються справжні дані. Люди застрягають, бо мають чудово виглядаючий екран і думають, що лишилося «тільки під'єднати» — а насправді лишилася вся важка частина, яку v0 навіть не мав робити. Це не вада v0, а непорозуміння щодо того, для чого він призначений.

Cursor — генерує, але ти маєш розуміти

Cursor інший, ніж три попередні, — це редактор із потужним ШІ для людини, яка вже вміє читати код. Він може написати багато і швидко. Але якщо ти не можеш оцінити написане, він просто дає тобі швидше наробити того, чого ти не розумієш. Типовий сценарій: Cursor генерує складну логіку, вона майже працює, ти просиш виправити деталь, він переписує більше, ніж треба, і раптом у тебе 2000 рядків, які ні прочитати, ні безпечно змінити вже не можеш. Cursor чудовий для професіонала і небезпечний для того, хто сподівається, що він «сам усе залагодить».

Чому ШІ «лагодить» і знову ламає

Це одне з найчастіших питань, які я чую: «чому він лагодить одне, а ламає інше?» Відповідь — втрата контексту. ШІ не бачить увесь твій проєкт одночасно як цілісну систему. У кожному виправленні він працює з обмеженою видимою частиною, «пам'ятає» лише стільки, скільки вміщується, і вгадує решту. Лагодячи місце A, він несвідомо змінює щось, від чого залежить місце B, про яке тоді «не знав».

Що більший проєкт, то швидше це коло розкручується. Спочатку, поки файлів мало, ШІ ще тримає все «в голові» і виглядає чудово. Досягнувши певного розміру, кожне нове виправлення має дедалі більшу ймовірність щось зламати. Ти просиш лагодити частіше, він переписує дедалі більше, код стає дедалі розкиданішим — і раптом ти в колі, з якого ШІ тебе не витягне, бо він сам і є причиною того кола.

Людина ламає це коло просто: тримає всю архітектуру в голові, розуміє причину, а не лише симптом, і виправляє один раз так, щоб лишилося виправленим. Там, де ШІ латає десять разів, людина, яка розуміє, виправляє один.

Що зробити ПЕРЕД зверненням

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

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

Рятувати чи переписувати?

Найважливіше рішення. І, всупереч очікуванням, не завжди правильна відповідь — «викинь усе й пиши з нуля». Вирішую, подивившись на код, але логіка приблизно така.

Ситуація	Що я роблю
UI охайний, проблеми локальні (не під'єднується оплата, падає деплой, одна інтеграція)	Рятую. Точкові виправлення, часто найдешевший шлях.
Фронтенд добрий, але немає реального бекенду чи моделі даних	Змішано. Лишаю фронтенд, під ним будую чистий бекенд.
Логіка розкидана, кожне виправлення ламає інше, ніхто не розуміє структури	Переписую. Спираюся на візуал як на специфікацію, код пишу начисто на Next.js.
Це внутрішній інструмент чи демо, не для реальних клієнтів і грошей	Можливо, тобі вистачить ШІ. Скажу відверто, якщо я не потрібен.

Хочу наголосити на останньому рядку. Якщо твій проєкт — це хобі, внутрішній інструмент для команди з кількох людей чи візуалізація ідеї, ШІ тобі справді вистачить, і я тобі це скажу. Я не намагаюся продати роботу там, де її не треба. Це, до речі, і є ознака того, що коли я кажу «тут треба переписати», я кажу це не заради рахунку.

Який інструмент для чого — і де його стіна

Коротка таблиця, щоб не заплутатися у виборі. Це не рейтинг «найкращий–найгірший», а мапа, для якої роботи кожен призначений і де закінчуються його можливості.

Інструмент	Для чого підходить	Де стіна
Lovable	Повне демо з БД і входом, швидкий MVP для перевірки ідеї	Правила Supabase, деплой на реальний домен, зростаюча модель даних
Bolt	Інтерактивний прототип фронтенду, швидкий вигляд того, як працювало б	Складний state, реальні інтеграції, оплата, серверна частина
v0	Гарні компоненти й сторінки React/Next.js, основа UI	Зовсім немає бекенду, БД, входу — лише фасад
Cursor	Швидша розробка для того, хто вміє читати й оцінювати код	Без розуміння швидко наробиш того, чим уже не керуєш

Якщо хочеш ширше про те, чому ШІ-прототип ще не продукт і що відрізняє «працює на моєму екрані» від «працює для реальних користувачів», я писав про це окремо — у статті про вайбкодинг: ШІ-прототип проти продукту. А якщо потрібен інженер, який доведе застосунок до робочого стану, дивись мою сторінку розробки застосунків.

Реальні рамки цін

Відверто, бо цього прямо ніхто не каже. Ціни залежать від того, скільки лишається придатним, але рамки такі. Цифри в гривнях, з приблизним еквівалентом у євро для орієнтиру (курс плаває, станом на середину 2026 приблизно 1 € ≈ 45 ₴).

• Локальні виправлення на охайному проєкті (деплой, одна інтеграція, помилка state): від 25 000–60 000 ₴ (≈ €550–1 300)
• Доведення ШІ-MVP до реального запуску з входом, оплатою, даними й деплоєм: 110 000–270 000 ₴ (≈ €2 400–6 000)
• Чисте переписування до продакшну зі збереженням доброго візуалу: від 180 000–360 000 ₴ (≈ €4 000–8 000) і більше, залежно від інтеграцій

Точну цифру називаю лише після перегляду коду — без цього будь-що було б здогадкою. Працюю як ФОП на єдиному податку, тож рахунок виставляю офіційно, а оцінку в гривнях багато хто з девелоперського B2B подумки прив'язує до $ чи € — це нормально. Ці рамки допомагають зрозуміти масштаб, щоб ти не здивувався ні в той, ні в інший бік. І часто ми починаємо з малого кроку: я оцінюю, показую, що насправді зламане, і тоді ти вирішуєш із повною картиною.

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

Чи можеш ти перейняти мій проєкт на Lovable?

Так. Lovable дозволяє синхронізувати код у GitHub — коли я маю доступ до репозиторію, я переймаю проєкт як звичайний застосунок React/Vite + Supabase. Спершу завантажую його локально, запускаю, дивлюся, що насправді ламається, і лише тоді вирішую: вистачить точкових виправлень чи дешевше частину переписати начисто. Тобі не треба нічого розбирати заздалегідь — просто дай доступ і короткий опис того, що ти хотів отримати.

Чи придатний код з Bolt для продакшну?

Фронтенд часто достатньо добрий, щоб його зберегти. Але «придатний для продакшну» означає не лише гарний UI — потрібні охайне керування станом, безпечний бекенд, реальна база даних, автентифікація, оплата та обробка помилок. Bolt генерує швидке демо, а не цей важкий шар. Тому реальний проєкт з Bolt я зазвичай залишаю як основу UI і під ним будую надійний бекенд та інтеграції (оплата, Нова Пошта, ПРРО), щоб усе працювало з живими користувачами і грошима.

Чому ШІ постійно лагодить і знову ламає той самий код?

Бо ШІ не бачить увесь проєкт одночасно і не має сталого контексту. У кожному виправленні він працює з обмеженою видимою частиною коду, тому, лагодячи одне місце, несвідомо ламає інше, про яке «забув». Що більший проєкт, то швидше починається це коло. Людина тримає всю архітектуру в голові й виправляє причину, а не симптом, тому виправлення лишається виправленим.

Що мені підготувати перед зверненням щодо зламаного ШІ-проєкту?

Три речі. Перше — доступ до коду: GitHub-репозиторій або експортований проєкт (не скриншоти). Друге — доступ до сервісів, якими користуєшся (Supabase, Vercel, акаунти оплати чи пошти). Третє — 5–10 речень про те, що програма має робити і що саме не працює. З цим я швидко оціню стан і скажу, чи вистачить виправлень, чи варто переписати, та реальну ціну в гривнях.

Коли варто рятувати наявний ШІ-код, а коли дешевше переписати?

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

Скільки коштує полагодити чи довести до кінця згенерований ШІ проєкт?

Залежить від того, скільки лишається придатним. Локальні виправлення на охайному проєкті — від 25 000–60 000 ₴ (≈ €550–1 300). Доведення ШІ-MVP до реального запуску з автентифікацією, оплатою, даними й деплоєм — зазвичай 110 000–270 000 ₴ (≈ €2 400–6 000). Чисте переписування до продакшну — від 180 000–360 000 ₴ (≈ €4 000–8 000) і більше, залежно від інтеграцій. Точну ціну називаю лише після перегляду коду. Про приховані витрати «безкоштовних» ШІ-рішень докладніше пишу в статті про реальну ціну «безкоштовного» ШІ-сайту.

Коротко

Lovable, Bolt, v0 і Cursor — чудові інструменти для того, для чого призначені: швидко показати ідею. Вони ламаються не тому, що погані, а тому, що ти намагаєшся з демо зробити те, що потребує інженерії: безпечного бекенду, реальних інтеграцій (оплата, Нова Пошта, фіскалізація через ПРРО), охайних даних. ШІ латає симптоми й втрачає контекст; людина виправляє причину. Якщо твій проєкт застряг — не роби двадцятого кола. Експортуй код, збери доступи, опиши, чого хотів, і дай подивитися. Часто я зберігаю твою добру роботу і під нею будую те, що не дасть знову розсипатися — щоб працювало й заробляло, а не лише виглядало.