Приложение из Lovable или Bolt постоянно ломается. Переписывать с нуля или доводить до продакшена?

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

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

Почему приложение из AI-конструктора всё время ломается?

Lovable, Bolt, Replit и Cursor отлично собирают экраны, которые работают на демо. Гораздо хуже у них с невидимой частью продукта: правами доступа, сохранностью данных, повторами запросов и предсказуемыми релизами. Андрей Карпаты, который придумал слово «вайбкодинг», сам написал, что это «not too bad for throwaway weekend projects» (годится для одноразовых проектов на выходные) (Karpathy в X, 2025). Ваше приложение перестало быть проектом на выходные в тот день, когда заплатил первый клиент.

Поломки кажутся случайными по трём причинам:

• Нет тестов. Тест — маленькая программа, которая после каждого изменения проверяет, что функция ещё работает. Без тестов каждый новый промпт может тихо сломать то, что вчера работало, и узнаёте вы об этом от клиента.
• Нет тестовой копии (staging). Изменения сразу уходят в живое приложение, и любой эксперимент ставится на платящих пользователях.
• Правила не там, где надо. Если «пользователь видит только свои записи» обеспечено тем, что кнопка спрятана в браузере, то правила нет. Оно должно жить на сервере или в базе данных.

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

Доводить или переписывать: как решить?

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

Позиция в первых строках старая и проверенная временем. Джоэл Спольски назвал переписывание работающего кода с нуля «the single worst strategic mistake that any software company can make», то есть худшей стратегической ошибкой, какую может сделать софтверная компания (Joel on Software, 2000). Его довод: в старом коде сидят все исправления, которым научило реальное использование, и переписывание выбрасывает это знание. Мартин Фаулер описал практичный вариант, «strangler fig» (дерево-душитель): новые части растут вокруг старой системы, а старые куски отключают, только когда новые заработали (martinfowler.com).

У AI-приложения с платящими пользователями ценное знание — в экранах и сценариях. Клиенты уже подтвердили оплатой, что они работают. Слабое место — под ними, и его можно заменить так, что клиенты не заметят.

Пример из практики: пять месяцев по смете, около четырёх недель по факту

Нетехнический фаундер собрал продукт в AI-конструкторе, и у него было около 300 платящих пользователей. Каждую неделю что-то ломалось. Два агентства посмотрели на чужой код и оба предложили переписать всё с нуля: пять месяцев без единой новой функции.

При ближайшем рассмотрении ценной частью оказались как раз экраны и сценарии. Риск сидел ниже:

• любой залогиненный пользователь мог открыть записи другого клиента, поменяв число в адресной строке;
• бэкапов не было;
• платёжный запрос, который отвалился по таймауту и ушёл повторно, мог списать деньги с карты дважды.

Фаундер решил оставить интерфейс, к которому привыкли клиенты, и мы пересобрали то, что под ним, в порядке риска: правила доступа к данным — в первый день, бэкапы — в первую неделю, потом безопасный повтор платежей, потом нормальный репозиторий с тестами и выкладкой в один клик.

Ушло около четырёх недель. Дня переезда пользователи не заметили, а фаундер всё это время продолжал выпускать новые функции.

Что чинить первым?

Порядок задаёт вопрос «что сильнее всего ударит по клиентам или бизнесу, если случится сегодня ночью», а не то, насколько некрасив код.

1. Доступ к данным. Может ли один пользователь прочитать или изменить данные другого? Через эту дыру уже утекали данные реальных пользователей AI-приложений. В 2025 году исследователи проверили 1 645 приложений, собранных в Lovable, и у 170 из них информация о пользователях была доступна кому угодно (Semafor, 2025). Причина — не настроены правила доступа в базе (row-level security, RLS: какие строки видит каждый пользователь), уязвимость записана как CVE-2025-48757. Lovable эту CVE оспаривает: по его позиции, за защиту данных приложения отвечает сам клиент. Поэтому и проверка на вас. Документация Supabase говорит прямо: «A table in an exposed schema without RLS is readable and writable by any role with a grant on it». Иначе говоря, таблицу без RLS может читать и менять любой, у кого есть доступ к API (документация Supabase).
2. Бэкапы. Если базу сегодня сотрут, из чего вы её восстановите? Пока бэкап ни разу не восстанавливали, неизвестно, работает ли он.
3. Секретные ключи. Ключи платёжки и AI-провайдера должны лежать на сервере, а не в коде, который уходит в браузер.
4. Платежи. Сбой сети рано или поздно случится, вопрос в том, спишет ли повтор деньги дважды. У Stripe для этого есть ключи идемпотентности: они позволяют повторить запрос «without accidentally performing the same operation twice», то есть без риска выполнить операцию второй раз (документация Stripe).
5. Код и выкладка. Код — в репозитории, которым владеет ваша компания, с тестами на всё, что связано с деньгами, и с выкладкой, которую можно откатить одной кнопкой. Здесь «постоянно ломается» и заканчивается.
6. Мониторинг. Об ошибках вы узнаёте из оповещения, а не из письма клиента.

Только после этого имеет смысл говорить о красивой архитектуре и производительности.

Что я могу проверить сам за 15 минут?

Читать код для этого не нужно.

• Тест адресной строки. Зайдите под тестовым пользователем, откройте запись и поменяйте число или ID в адресе. Видите чужие данные — остановите новые функции и чините это.
• Проверка Supabase. Если приложение работает на Supabase, откройте панель управления и найдите таблицы, где выключен RLS.
• Вопрос про бэкапы. Спросите того, у кого есть доступ к базе: где бэкапы, насколько свежий последний и когда его в последний раз восстанавливали.
• Список аккаунтов. Выпишите все аккаунты, от которых зависит приложение: репозиторий, база, хостинг, домен, Stripe, AI-провайдер. Напротив каждого — чья почта владелец. Всё, что не на вашей компании, — риск.
• Тест двойного списания. Задайте разработчику или чату конструктора один простой вопрос: «Что будет, если платёжный запрос отвалится по таймауту и пользователь нажмёт ещё раз?»

Если все пять проверок чистые, дальше в основном тесты и выкладка, и доводов за переписывание становится намного меньше.

Сколько стоит довести приложение до продакшена?

Честной единой цифры нет: всё зависит от того, что найдут проверки выше. Цену определяют:

• Сколько из шести пунктов отсутствует. Починить только доступ к данным и закрыть все шесть — разные работы.
• Где живут данные. Настоящая база, которую можно перенести на свой аккаунт, — дешёвый случай. Данные, которые надо перестраивать или переносить, — дорогой.
• Сколько логики в браузере. Всё, что проверяет правила, придётся перенести на сервер.
• Выпускаете ли вы функции параллельно. Стоит выпускать, но это добавляет координации.

В примере выше агентства предлагали пять месяцев переписывания, а доводка заняла около четырёх недель. Открытых цифр со стороны мало. На Hacker News один разработчик рассказал, что оценил для клиента в $43 тыс. рефакторинг SaaS, собранного в Cursor и за шесть недель вышедшего на $11 тыс. выручки в месяц (Hacker News). Это один анонимный пост о другой работе, а не рыночная ставка.

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

Агентство говорит «переписывать». Что у него спросить?

Предложение переписать не обязательно плохое, но оно должно выдержать эти вопросы:

• Какие конкретно проблемы нельзя исправить в текущем коде и почему?
• Что будет с пользователями в день переезда? Кто перенесёт их данные, аккаунты и подписки?
• Через сколько недель после подписания я получу первую новую функцию?
• Можете ли вы в первую же неделю закрыть доступ к данным и настроить бэкапы, что бы мы ни решили насчёт остального?
• На кого будут оформлены новый репозиторий и облачные аккаунты?
• Если мы остановимся на полпути, что у меня останется?

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

Когда переписывать всё-таки правильно?

Бывает и так. Честные случаи:

• у приложения нет своего сервера, данные хранятся в браузере;
• продукт разворачивается, и большая часть нынешних экранов не понадобится;
• платформа не даёт выгрузить код или перенести данные;
• проблемы дают всего пара частей — тогда заменяйте только их, по одной, и пусть старая версия работает, пока новая не начнёт давать те же результаты.

Даже тогда лучшее ТЗ для новой версии — текущее приложение. Оно показывает, чем клиенты реально пользуются, а этого не покажет ни один документ.

Что бы я сделал на вашем месте

1. Сегодня же проведите тест адресной строки и проверку Supabase. Если что-то не прошло — сначала доступ к данным, всё остальное потом.
2. Убедитесь, что бэкап есть и его хотя бы раз восстановили.
3. Переведите все аккаунты (код, база, хостинг, домен, Stripe) на свою компанию.
4. Сначала получите список рисков по важности, потом цену. Чините в этом порядке и параллельно выпускайте функции.
5. На первый месяц возьмите опытного технического человека, чтобы фундамент построили один раз. Это работа fractional CTO: технические решения принимаются на вашей стороне стола, а код и аккаунты остаются вашими.

Опишите, что делает приложение и что в нём ломается, — отвечу письменно, с чего бы я начал.

Free консультация