Lovable, Bolt, v0, Cursor — что делать, когда код от ИИ сломался

Сцена, которую я вижу почти каждую неделю. Человек за выходные собрал на Lovable, Bolt или v0 рабочее демо, обрадовался, показал друзьям. Потом хочет добавить одну вещь — оплату, авторизацию, ещё один экран — и всё начинает сыпаться. Просит нейронку починить. Чинит. Через час ломается то, что работало. Снова просит. После десятого круга код уже такой, что ни он, ни нейросеть не понимают, что вообще происходит.

Если вы узнали себя — это не ваша вина и не признак того, что вы что-то делаете не так. Эти инструменты ровно для того и сделаны: быстро показать идею. Проблема начинается, когда вы пытаетесь из демо собрать настоящий продукт, который отдают живым людям. В этой статье я честно разберу, где именно каждый инструмент упирается в стену, почему ИИ «чинит» и снова ломает, что подготовить перед обращением и когда вообще стоит спасать существующий код, а когда дешевле переписать начисто.

Говорю не из теории. Такие проекты я вижу постоянно, и мой путь с ними всегда один: сломанный код с Lovable или Bolt я не беру и не латаю, а использую прототип как техзадание и строю продукт с нуля — чтобы он работал в продакшне, с живыми пользователями и деньгами. Хочу, чтобы вы это знали с самого начала — потому что это меняет то, что вообще имеет смысл просить.

Почему ИИ доводит до 80% и там останавливается

Lovable, Bolt и v0 удивительно быстро делают ту часть, которую видно — кнопки, формы, экраны, красивую вёрстку. Это примерно 80% того, что выглядит как «приложение». Но оставшиеся 20% — оплата, авторизация, база данных, деплой, безопасность, 152-ФЗ и GDPR, граничные случаи — это самое сложное, самое дорогое и именно та часть, ради которой программа вообще работает с живыми людьми. Там ИИ не дорабатывает — там он врезается.

Причина простая. Этот видимый слой шаблонный: похожих форм и экранов в интернете миллионы, нейросеть их «видела» и воспроизводит мгновенно. А оставшиеся 20% уникальны для вашего проекта и требуют решений, которые надо принимать, понимая целое — как текут данные, где они хранятся, кто и что может видеть, что происходит, когда платёж не прошёл. Это не копирование, а инженерия. И именно там всё начинает ломаться.

Где ломается, по инструментам

У каждого инструмента свой «характер» и своя типичная точка отказа. Зная её, вы гораздо быстрее понимаете, что у вас на самом деле в руках.

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

Lovable строит полное приложение (React + Supabase) и многое тащит сам, поэтому поначалу выглядит магически. Но ломается обычно в двух местах. Первое — база Supabase: когда модель данных усложняется, начинается путаница с RLS (правилами безопасности на уровне строк), связи таблиц спутываются, и запросы возвращают либо слишком много, либо ничего. Второе — деплой и окружения: локально или в превью Lovable работает, а на реальном домене с настоящими переменными уже нет, потому что ключи, ссылки или CORS настроены только под «демо-режим». Для русскоязычной аудитории сюда же добавляется боль, о которой инструмент молчит: данные пользователей по 152-ФЗ должны храниться на серверах в РФ, а Supabase по умолчанию хостится за рубежом.

Bolt — state и интеграции

Bolt отлично и очень быстро генерирует интерактивный фронтенд. Стена — когда в приложении появляется много состояния (state): корзина, залогиненный пользователь, фильтры, формы, которые зависят друг от друга. Этот state начинает «убегать» — нажимаешь в одном месте, обновляется несвязанное в другом. Вторая болевая точка Bolt — интеграции с реальными системами: оплата, почта, внешний API. На уровне демо Bolt показывает, «как бы выглядело», но для настоящего подключения нужны серверная часть, управление секретами и обработка ошибок, которых быстрая генерация не делает. Для этой аудитории сюда прилетает ещё и санкционная реальность: подключить Stripe или PayPal без зарубежного юрлица не выйдет, а ЮKassa или СБП Bolt сам не настроит.

v0 — красивый UI, но бэкенд нужно проверять

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

Cursor — генерирует, но понимать должны вы

Cursor другой, чем три выше — это редактор с мощным ИИ для человека, который уже умеет читать код. Он может написать много и быстро. Но если вы не способны оценить, что он написал, он просто позволяет вам быстрее накодить того, чего вы не понимаете. Типичный сценарий: Cursor генерирует сложную логику, она почти работает, вы просите поправить деталь, он переписывает больше, чем нужно, и вдруг у вас 2000 строк, которые ни прочитать, ни безопасно изменить вы не можете. Cursor великолепен для профессионала и опасен для того, кто надеется, что он «сам всё разрулит».

Почему ИИ «чинит» и снова ломает

Это один из самых частых вопросов, которые я слышу: «почему он чинит одно, а ломает другое?» Ответ — потеря контекста. Нейросеть не видит весь ваш проект одновременно как единую систему. При каждой правке она работает с ограниченной видимой частью, «помнит» лишь столько, сколько влезает, и догадывается об остальном. Починив место А, она неосознанно меняет что-то, от чего зависит место Б, про которое в тот момент «не знала».

Чем больше проект, тем быстрее этот круг раскручивается. В начале, пока файлов мало, ИИ ещё держит всё «в голове» и выглядит отлично. Достигнув определённого размера, каждая новая правка имеет всё большую вероятность что-то сломать. Вы просите чинить чаще, он переписывает всё больше, код становится всё более разбросанным — и вдруг вы в круге, из которого нейросеть вас не вытащит, потому что она сама и есть причина этого круга.

Человек разрывает этот круг просто: держит всю архитектуру в голове, понимает причину, а не только симптом, и чинит один раз так, чтобы осталось починенным. Там, где ИИ латает десять раз, понимающий человек чинит один.

Что сделать ПЕРЕД обращением

Если вы решили, что существующий код должен чинить человек — тот, кто его писал, или другой разработчик, — есть три вещи, при подготовке которых оценка проходит быстро и точно, а не дорогим гаданием. Это можно сделать самому за полчаса.

С этими тремя вещами разработчик довольно быстро скажет, хватит ли точечных правок или дешевле переписать, и какая реально цена. Без них — только общие фразы, которые никому не нужны. Если же выбираете чистую пересборку у меня, из этого списка нужен только третий пункт и ссылка на прототип: код я не беру, поэтому доступ к репозиторию не нужен.

Спасать или переписывать?

Самое важное решение — и принять его можете вы сами. Вопреки ожиданиям, не всегда правильный ответ — «выбрось всё и пиши с нуля». Логика примерно такая.

Ситуация	Что выбрать
UI аккуратный, проблемы локальны (не подключается оплата, ломается деплой, одна интеграция)	Спасать. Точечные правки — самому или с тем, кто писал код. Часто самый дешёвый путь.
Фронтенд хороший, но нет настоящего бэкенда или модели данных	Смешанно. Оставить фронтенд и собрать под ним чистый бэкенд может автор кода или другой разработчик.
Логика разбросана, каждая правка ломает что-то ещё, никто не понимает структуру	Переписать. Визуал становится ТЗ, код пишется начисто с нуля — это и есть моя работа.
Это внутренний инструмент или демо, не для реальных клиентов и денег	Возможно, вам хватит ИИ. Скажу честно, если я не нужен.

Хочу подчеркнуть последнюю строку. Если ваш проект — хобби, внутренний инструмент для команды из нескольких человек или визуализация идеи, ИИ вам действительно хватит, и я вам так и скажу. Я не пытаюсь продать работу там, где она не нужна. Так же честно говорю, что делаю сам: только чистую пересборку с нуля — спасение и латание оставляю вам или тому, кто писал код.

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

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

Инструмент	Для чего подходит	Где стена
Lovable	Полное демо с БД и авторизацией, быстрый MVP для проверки идеи	Правила Supabase, деплой на реальный домен, рост модели данных, 152-ФЗ
Bolt	Интерактивный прототип фронтенда, быстрый вид, как бы работало	Сложный state, реальные интеграции, оплата, серверная часть
v0	Красивые компоненты и страницы React/Next.js, UI-основа	Бэкенд, БД и авторизация генерируются, но требуют тщательной проверки
Cursor	Более быстрая разработка тому, кто умеет читать и оценивать код	Без понимания быстро накодишь то, чем уже не управляешь

Если хотите шире про то, почему ИИ-прототип ещё не продукт и что отличает «работает на моём экране» от «работает для живых пользователей», я написал об этом отдельно — смотрите статью вайбкодинг: прототип против продукта.

Реальные ценовые рамки

Открыто, потому что этого никто не говорит прямо. Правки и доработку на текущем коде я не предлагаю, поэтому здесь — мои цены на чистую пересборку с нуля, где ваш прототип становится техзаданием:

• MVP / PWA с авторизацией, данными и деплоем (iOS и Android из одной кодовой базы): от 2 900 €
• Бизнес-приложение с оплатой и интеграциями, с сохранением хорошего визуала как ТЗ: от 6 900 €
• Сложная платформа с несколькими типами пользователей и множеством интеграций: от 14 900 €

Для сравнения: медиана фриланса — лендинг 300–900 €, MVP 1 500–6 000 €. Я работаю не по логике «дёшево и быстро», а как сеньор, который доводит до прода и берёт на себя то, на чём вайбкод-проект обычно и спотыкается. Цена зависит от того, что должен делать продукт, а не от состояния вашего кода, — поэтому для предложения код мне даже не нужен. Локальные интеграции (ЮKassa, СБП, Stripe для диаспоры) входят в объём работ — обычно это уровень бизнес-приложения от 6 900 €. Если планируете полноценную разработку приложения, отдельно описал форматы и цены на странице разработки приложений.

Частые вопросы

Коротко

Lovable, Bolt, v0 и Cursor — отличные инструменты для того, для чего созданы: быстро показать идею. Они ломаются не потому, что плохие, а потому, что вы пытаетесь из демо сделать то, для чего нужна инженерия: безопасный бэкенд, реальные интеграции (ЮKassa, СБП, Stripe для диаспоры), аккуратные данные под 152-ФЗ. ИИ латает симптомы и теряет контекст; человек чинит причину. Если ваш проект застрял — не делайте двадцатый круг. Решите, какой путь вам ближе: чинить существующий код (самому или с тем, кто его писал) или пересобрать начисто. Если выбираете второй — опишите, что вы хотели, и ваш прототип станет техзаданием: хорошую работу сохраню, а под ней с нуля соберу то, что не даст снова рухнуть, — чтобы работало и зарабатывало, а не только выглядело.