Сцена, яку я бачу майже щотижня. Людина за вихідні через 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, а непорозуміння щодо того, для чого він призначений.
Cursor — генерує, але ти маєш розуміти
Cursor інший, ніж три попередні, — це редактор із потужним ШІ для людини, яка вже вміє читати код. Він може написати багато і швидко. Але якщо ти не можеш оцінити написане, він просто дає тобі швидше наробити того, чого ти не розумієш. Типовий сценарій: Cursor генерує складну логіку, вона майже працює, ти просиш виправити деталь, він переписує більше, ніж треба, і раптом у тебе 2000 рядків, які ні прочитати, ні безпечно змінити вже не можеш. Cursor чудовий для професіонала і небезпечний для того, хто сподівається, що він «сам усе залагодить».
Спільний знаменник
Усі чотири інструменти вільно роблять ту частину, що схожа на мільйон інших проєктів, і врізаються в ту, що унікальна для твого випадку. Оплата, яку треба звести з твоєю бухгалтерією та ПРРО. Вхід, що має бути безпечним. Дані, що мають відповідати закону про захист персональних даних. Граничні випадки, що стаються лише в твоїй бізнес-логіці. Жодне з цього не має готового шаблону — тому там і падає.
Чому ШІ «лагодить» і знову ламає
Це одне з найчастіших питань, які я чую: «чому він лагодить одне, а ламає інше?» Відповідь — втрата контексту. ШІ не бачить увесь твій проєкт одночасно як цілісну систему. У кожному виправленні він працює з обмеженою видимою частиною, «пам'ятає» лише стільки, скільки вміщується, і вгадує решту. Лагодячи місце A, він несвідомо змінює щось, від чого залежить місце B, про яке тоді «не знав».
Що більший проєкт, то швидше це коло розкручується. Спочатку, поки файлів мало, ШІ ще тримає все «в голові» і виглядає чудово. Досягнувши певного розміру, кожне нове виправлення має дедалі більшу ймовірність щось зламати. Ти просиш лагодити частіше, він переписує дедалі більше, код стає дедалі розкиданішим — і раптом ти в колі, з якого ШІ тебе не витягне, бо він сам і є причиною того кола.
Людина ламає це коло просто: тримає всю архітектуру в голові, розуміє причину, а не лише симптом, і виправляє один раз так, щоб лишилося виправленим. Там, де ШІ латає десять разів, людина, яка розуміє, виправляє один.
Що зробити ПЕРЕД зверненням
Якщо ти вирішив, що наявний код має виправляти людина — той, хто його писав, чи інший розробник, — є три речі, з якими оцінка відбувається швидко й точно, а не дорогим вгадуванням. Зробити це можна самостійно за пів години.
Три речі, які варто підготувати
1. Доступ до коду. Не скриншоти. Lovable і Bolt дозволяють синхронізувати у GitHub — зроби це й дай доступ до репозиторію тому, хто працюватиме з кодом. Якщо користувався v0 чи Cursor — експортуй усю теку проєкту. Без коду будь-яка оцінка — здогадка.
2. Доступ до сервісів. Supabase, Vercel, акаунт оплати (LiqPay, monobank, WayForPay), надсилання пошти — усе, що програма використовує. Часто проблема саме в конфігурації, а не в коді.
3. Опис на 5–10 речень. Що програма має робити, для кого вона і що саме не працює. «Користувач має зареєструватися, оплатити через LiqPay і отримати доступ; реєстрація працює, але після оплати доступ не відкривається.» Такий опис цінніший за годину розмови.
З цими трьома речами розробник досить швидко скаже, чи вистачить точкових виправлень, чи дешевше переписати, і яка реально ціна. Без них — лише загальні фрази, яких нікому не треба. Якщо ж обираєш чистий перепис у мене, з цього списку потрібен лише третій пункт і посилання на прототип: код я не переймаю, тож доступ до репозиторію не потрібен.
Рятувати чи переписувати?
Найважливіше рішення — і ухвалити його можеш ти сам. Всупереч очікуванням, не завжди правильна відповідь — «викинь усе й пиши з нуля». Логіка приблизно така.
| Ситуація | Що обрати |
|---|---|
| UI охайний, проблеми локальні (не під'єднується оплата, падає деплой, одна інтеграція) | Рятувати. Точкові виправлення — самому або з тим, хто писав код. Часто найдешевший шлях. |
| Фронтенд добрий, але немає реального бекенду чи моделі даних | Змішано. Лишити фронтенд і збудувати під ним чистий бекенд може автор коду чи інший розробник. |
| Логіка розкидана, кожне виправлення ламає інше, ніхто не розуміє структури | Переписати. Візуал стає специфікацією, код пишеться начисто з нуля на Next.js — це і є моя робота. |
| Це внутрішній інструмент чи демо, не для реальних клієнтів і грошей | Можливо, тобі вистачить ШІ. Скажу відверто, якщо я не потрібен. |
Хочу наголосити на останньому рядку. Якщо твій проєкт — це хобі, внутрішній інструмент для команди з кількох людей чи візуалізація ідеї, ШІ тобі справді вистачить, і я тобі це скажу. Я не намагаюся продати роботу там, де її не треба. Так само відверто кажу, що роблю сам: лише чистий перепис з нуля — рятування й латання лишаю тобі або тому, хто писав код.
Головна думка про переписування
Переписування нерідко виглядає дорожчим, але буває дешевшим за місяці латання, яке все одно закінчується переписуванням. Коли логіка розкидана, кожна нова функція займає дедалі більше часу, бо спершу треба зрозуміти те, чого не розуміє навіть сама програма. Чиста основа окупається вже після другої чи третьої функції.
І майже завжди я зберігаю те, що добре, — гарний візуал з v0 чи Bolt, охайну форму з Lovable — як технічне завдання і візуальний орієнтир. Переписування не означає, що твоя робота зникла. Воно означає, що під нею з'являється те, що не дасть знову розсипатися.
Який інструмент для чого — і де його стіна
Коротка таблиця, щоб не заплутатися у виборі. Це не рейтинг «найкращий–найгірший», а мапа, для якої роботи кожен призначений і де закінчуються його можливості.
| Інструмент | Для чого підходить | Де стіна |
|---|---|---|
| Lovable | Повне демо з БД і входом, швидкий MVP для перевірки ідеї | Правила Supabase, деплой на реальний домен, зростаюча модель даних |
| Bolt | Інтерактивний прототип фронтенду, швидкий вигляд того, як працювало б | Складний state, реальні інтеграції, оплата, серверна частина |
| v0 | Гарні компоненти й сторінки React/Next.js, основа UI | Бекенд, БД і вхід генеруються, але потребують ретельної перевірки |
| Cursor | Швидша розробка для того, хто вміє читати й оцінювати код | Без розуміння швидко наробиш того, чим уже не керуєш |
Якщо хочеш ширше про те, чому ШІ-прототип ще не продукт і що відрізняє «працює на моєму екрані» від «працює для реальних користувачів», я писав про це окремо — у статті про вайбкодинг: ШІ-прототип проти продукту. А якщо потрібен інженер, який перезбере застосунок з нуля так, щоб він справді працював, дивись мою сторінку розробки застосунків.
Реальні рамки цін
Відверто, бо цього прямо ніхто не каже. Виправлення й доробку на наявному коді я не пропоную, тож тут — мої ціни на чистий перепис з нуля, де твій прототип стає технічним завданням. Ціни — в євро:
- MVP / PWA із входом, даними й деплоєм (iOS і Android з однієї кодової бази): від 2 900 €
- Бізнес-застосунок з оплатою та інтеграціями, зі збереженням доброго візуалу як ТЗ: від 6 900 €
- Складна платформа з кількома типами користувачів і багатьма інтеграціями: від 14 900 €
Ціна залежить від того, що має робити продукт, а не від стану твого коду, — тож для пропозиції код мені навіть не потрібен. Локальні інтеграції (LiqPay, WayForPay, plata by mono, Нова Пошта, ПРРО) входять в обсяг робіт — зазвичай це рівень бізнес-застосунку від 6 900 €.
Твій ШІ-проєкт зламався? Перепишу його чисто.
Твій прототип на Lovable, Bolt чи v0 стає технічним завданням: екрани й сценарії зберігаю, а під ними з нуля будую міцний фундамент — бекенд, дані, оплату і деплой. MVP від 2 900 €. Опиши, що будуєш, — безкоштовно надішлю пропозицію, без туману.
Пропозиція на переписЧасті запитання
Чи можеш ти перейняти мій проєкт на Lovable?
Ні. Чужий або згенерований ШІ код я не беру, не виправляю і не продовжую — навіть якщо він синхронізований у GitHub. Натомість перезбираю продукт чисто з нуля, а твій прототип на Lovable використовую як технічне завдання і візуальний орієнтир: екрани, сценарії та логіка, яку ти продумав, нікуди не зникають. Тобі так вигідніше: не платиш за розбір чужого коду, не отримуєш у спадок плутанину з правилами Supabase і приховані діри, а отримуєш охайний фундамент, який зможе підтримувати будь-який розробник. Якщо хочеш продовжувати на наявному коді, це можна робити самому або з тим, хто його писав.
Чи придатний код з Bolt для продакшну?
Фронтенд часто виглядає достатньо добре, але «придатний для продакшну» означає не лише гарний UI — потрібні охайне керування станом, безпечний бекенд, реальна база даних, автентифікація, оплата та обробка помилок. Bolt генерує швидке демо, а не цей важкий шар. Тому код з Bolt я не переймаю: візуал і сценарії проєкту використовую як технічне завдання, а продукт із надійним бекендом та інтеграціями (оплата, Нова Пошта, ПРРО) будую чисто з нуля, щоб усе працювало з живими користувачами і грошима.
Чому ШІ постійно лагодить і знову ламає той самий код?
Бо ШІ не бачить увесь проєкт одночасно і не має сталого контексту. У кожному виправленні він працює з обмеженою видимою частиною коду, тому, лагодячи одне місце, несвідомо ламає інше, про яке «забув». Що більший проєкт, то швидше починається це коло. Людина тримає всю архітектуру в голові й виправляє причину, а не симптом, тому виправлення лишається виправленим.
Що мені підготувати перед зверненням щодо зламаного ШІ-проєкту?
Залежить від того, який шлях ти обираєш. Якщо наявний код виправлятиме той, хто його писав, чи інший розробник, йому знадобляться три речі: доступ до коду (GitHub-репозиторій або експортований проєкт, не скриншоти), доступ до сервісів (Supabase, Vercel, акаунти оплати чи пошти) і 5–10 речень про те, що програма має робити і що саме не працює. Якщо обираєш чистий перепис у мене, код не потрібен: досить посилання на прототип чи скриншотів, тих самих 5–10 речень про те, що має робити продукт, і інформації про вже наявні акаунти.
Коли варто рятувати наявний ШІ-код, а коли дешевше переписати?
Рятувати варто, коли UI і структура охайні, а проблеми локальні — не під'єднується оплата, падає деплой, не працює одна інтеграція. Такі виправлення можна робити самому або з тим, хто писав код. Переписати дешевше, коли логіка розкидана, немає реального бекенду чи моделі даних, а кожне виправлення ламає щось інше. Я працюю лише другим шляхом: чужий код не беру, а продукт будую з нуля, використовуючи твій прототип як технічне завдання.
Скільки коштує полагодити чи довести до кінця згенерований ШІ проєкт?
Лагодження й доробку на наявному коді я не пропоную — це можна робити самому або з тим, хто писав код. Мої ціни — на чистий перепис з нуля за твоїм прототипом: MVP / PWA (iOS і Android з однієї кодової бази) — від 2 900 €, бізнес-застосунок з оплатою та інтеграціями — від 6 900 €, складна платформа — від 14 900 €. Ціна залежить від того, що має робити продукт, а не від стану твого коду, тож для пропозиції код мені навіть не потрібен. Про приховані витрати «безкоштовних» ШІ-рішень докладніше пишу в статті про реальну ціну «безкоштовного» ШІ-сайту.
Коротко
Lovable, Bolt, v0 і Cursor — чудові інструменти для того, для чого призначені: швидко показати ідею. Вони ламаються не тому, що погані, а тому, що ти намагаєшся з демо зробити те, що потребує інженерії: безпечного бекенду, реальних інтеграцій (оплата, Нова Пошта, фіскалізація через ПРРО), охайних даних. ШІ латає симптоми й втрачає контекст; людина виправляє причину. Якщо твій проєкт застряг — не роби двадцятого кола. Виріши, який шлях тобі ближчий: виправляти наявний код (самому або з тим, хто його писав) чи переписати чисто. Якщо обираєш другий — опиши, чого хотів, і твій прототип стане технічним завданням: добру роботу збережу, а під нею з нуля збудую те, що не дасть знову розсипатися, — щоб працювало й заробляло, а не лише виглядало.
Із демо — у реальний продукт
Точкових виправлень я не роблю — роблю чистий перепис, який більше не розсипається. Твоє демо стає технічним завданням, а продукт будується з нуля: MVP від 2 900 €, бізнес-застосунок з оплатою та інтеграціями від 6 900 €. Опиши, що будуєш, — безкоштовно надішлю пропозицію з ціною і терміном.
Переписати моє демо