# Сравнение ИИ-конструкторов приложений требует теста выхода

> Сравнение ИИ-конструкторов приложений Lovable, Bolt, Replit и v0 по владению кодом, экспорту, реальным расходам и пределам роста.

Основатель может за один день получить убедительную демонстрацию продукта в Lovable, Bolt, Replit или v0. Это уже не самая трудная задача. Гораздо труднее понять, превращается ли демонстрация в актив компании или в ежемесячную зависимость, которая дорожает и все хуже поддается изменениям с каждым новым запросом.

Я бы выбирал не столько по красоте первого экрана, сколько по пути выхода. Lovable лучше всего подходит нетехническому основателю для самостоятельной работы над продуктом, Bolt дает особенно прямой доступ к коду, Replit покрывает самый широкий путь от идеи до работающего бэкенда, а v0 сильнее всего там, где конечной точкой должна стать обычная команда с Next.js. Но ни один из этих инструментов не отменяет инженерную оценку, когда приложение работает с деньгами, правами доступа, конфиденциальными данными или обязательствами перед клиентами.

## Выбирайте по активу, который покупаете

У владения есть четыре разных уровня, хотя в сравнениях продуктов их постоянно сводят к одной галочке. Можно иметь юридические права на сгенерированный результат и копию исходного кода, управлять репозиторием с историей изменений, но все равно не контролировать эксплуатацию, потому что без исходного конструктора никто не умеет развернуть или починить приложение. Основатель, который спрашивает только о возможности экспорта кода, задает лишь четверть нужного вопроса.

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

- Lovable подходит основателю, который формирует веб-продукт. Выйти можно через синхронизацию с GitHub или полный ZIP-архив, естественными площадками остаются Lovable Cloud, Supabase или другой веб-хостинг, а ограничения становятся заметны, когда приложению нужен импорт существующего репозитория.
- Bolt подходит основателю, которому нужна среда разработки в браузере и понятный выход к файлам. Он предлагает ZIP, StackBlitz и GitHub, но по мере роста репозитория каждый запрос к ИИ расходует больше токенов и контекста.
- Replit подходит основателю, который вместе строит фронтенд, бэкенд и фоновые задачи. Git и GitHub дают выход к исходникам, а главным предупреждением становится необходимость отдельно управлять расходами на продакшен и Agent.
- v0 подходит команде, которая уже выбрала React и Next.js. GitHub может стать источником истины, развертывание вне основной платформы остается возможным, а предел проявляется, когда требования выходят за рамки предпочитаемого веб-стека.

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

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

## Lovable дает самый понятный путь основателю

Lovable проще всего рекомендовать нетехническому основателю, который хочет формировать веб-приложение, а не собирать отдельные компоненты интерфейса. В одном продукте есть диалоговая разработка, прямой доступ к коду, вариант с управляемым бэкендом и простой путь в GitHub. В официальном разделе FAQ сказано, что проекты и код принадлежат создателю, а редактор кода на платных тарифах позволяет скачать весь проект в ZIP-архиве. Это реальные пути выхода, а не экспорт снимка экрана.

Связь с GitHub умеет больше, чем разовое резервное копирование. В документации Lovable описана двусторонняя синхронизация с веткой по умолчанию, после подключения источником истины становится GitHub. Разработчик может клонировать репозиторий, редактировать его локально и отправлять изменения обратно в Lovable. После отключения связи репозиторий со всей историей остается в GitHub. Этого достаточно, чтобы начать обычную инженерную передачу проекта.

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

Сгенерированный стек переносим, но привязан к конкретным технологиям. Lovable сообщает, что новые приложения используют TanStack Start с серверным рендерингом, а старые проекты работают на React и Vite; Tailwind остается частью конфигурации. Для бэкенда могут применяться Lovable Cloud, Supabase или внешние API. Экспорт фронтенда бывает простым, но аутентификация, политики базы данных, хранилище, секреты и пограничные функции все равно требуют плана миграции. Попросите разработчика перечислить каждую управляемую зависимость, прежде чем называть проект переносимым.

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

Выбирайте Lovable, когда основателю нужно лично вести поиск продукта, целью служит веб-приложение, а разработчик сможет проверить репозиторий до запуска. Не выбирайте его только из-за законченного вида первых экранов. Выбирайте потому, что процесс позволяет основателю найти продукт, а затем передать инженеру узнаваемый веб-стек.

## Bolt дает самый очевидный выход к файлам

В Bolt легко понять способ ухода: в меню проекта можно скачать ZIP-архив, открыть проект в StackBlitz или связать работу с GitHub. Такая наглядность важна для основателя, который боится привязки к платформе. Скачанному приложению все равно нужны Node.js, установка зависимостей, переменные окружения и площадка для развертывания, зато файлы не спрятаны в закрытом визуальном формате.

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

Кривая расходов заслуживает больше внимания, чем цена подписки на главной странице. По данным Bolt, большая часть токенов уходит на чтение, понимание и синхронизацию файловой системы проекта. По мере роста репозитория внешне небольшой запрос может стать дороже, потому что агенту приходится загружать больше контекста до внесения изменения. Это свойство модели расходов, а не ошибка в формулировке запросов. Искусственное деление цельного приложения на фрагменты временно сокращает контекст, но повышает риск несовместимости и обычно ухудшает архитектуру.

У текущего бесплатного тарифа есть месячный лимит токенов и ограничение на день. Начальный тариф Pro стоит от 25 долларов в месяц и включает 10 миллионов токенов, хостинг и подключение собственного домена, а подписки с большим объемом токенов стоят дороже. Неиспользованные токены платной подписки переносятся еще на один месяц, пока подписка остается активной. Цены могут измениться, поэтому по этим цифрам стоит понимать устройство оплаты, а в бюджет проекта вносить актуальные значения в день принятия решения.

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

Bolt подходит основателю, которому нужны быстрая работа в браузере, прямой доступ к JavaScript-файлам и возможность перейти к обычному процессу разработки. Предел возникает, когда агент многократно перечитывает растущую кодовую базу, поведение бэкенда становится трудно объяснить или изменение требует осторожной миграции нескольких файлов. В этот момент используйте Bolt как ускоритель внутри дисциплины репозитория, а не как ее замену.

## Replit глубже всех охватывает среду исполнения

Replit охватывает внутри одного продукта больше этапов жизни приложения, чем три других варианта. Agent умеет планировать, создавать фронтенд и бэкенд, работать с базами данных, запускать проект, создавать контрольные точки и публиковать приложение через несколько типов развертывания. Для основателя маркетплейса, внутреннего инструмента или приложения с API такая широта экономит дни на создании учетных записей. Одновременно больше задач, расходов и операций сходятся в одной системе.

Контрольные точки Replit содержат больше данных, чем коммит Git. В документации сказано, что они сохраняют файлы проекта, контекст диалога с Agent и состояние подключенной базы данных, после чего их можно откатить в рабочей области. Git продолжает работать рядом с контрольными точками, включая командную строку и интеграцию с GitHub. Здесь важно различие: контрольная точка помогает восстановить рабочую область, а Git хранит переносимую историю, которая переживет смену платформы и подходит для проверки кода. Используйте оба механизма, но не заменяйте один другим.

Оплата Agent зависит от объема работы. Replit прямо сообщает, что оплачиваются все взаимодействия с Agent, включая рекомендации и планирование без изменения кода, хотя небольшие запросы стоят дешевле. Core сейчас стоит 25 долларов при помесячной оплате или 20 долларов в месяц при годовой и включает 25 долларов ежемесячных кредитов; Pro добавляет больший запас кредитов и больше одновременно работающих агентов. Тот же баланс оплачивает облачные сервисы, поэтому основателю нельзя считать цену подписки фиксированным бюджетом разработки.

У продакшена своя кривая расходов. Replit предлагает статические, автоматически масштабируемые и зарезервированные виртуальные развертывания, а также запуск по расписанию. Автоматическое масштабирование берет плату за запросы и вычисления во время работы, зарезервированные машины меняют риск недозагрузки на предсказуемую мощность, а развертывания по расписанию подходят периодическим задачам. Базы данных, хранилище, исходящий трафик и интеграции ИИ могут добавить расходы. Такая модель честнее обещания бесплатной эксплуатации, но нетехническому основателю нужны месячный лимит и назначенный ответственный.

У Replit самый высокий функциональный предел для основателя, которому нужен работающий бэкенд без ручной сборки сервисов. Здесь же сильнее всего соблазн сделать одну платформу редактором, агентом, консолью базы данных, средой исполнения, журналом инцидентов и системой оплаты. Экспорт исходников сам по себе не восстановит состояние базы, настройки развертывания, секреты или задачи по расписанию. Настоящая репетиция выхода должна описывать каждый из этих элементов.

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

## v0 подходит для осознанного выбора Next.js

v0 лучше всего подходит, когда конечной точкой уже выбраны Next.js, React, TypeScript, Tailwind CSS и shadcn/ui, а не абстрактное приложение без определенного стека. Его преимущество не в безусловно лучшем качестве каждого экрана. Преимущество в том, что сгенерированная работа попадает в стек, который знают многие веб-команды и могут принять через обычные запросы на слияние.

В текущем процессе GitHub репозиторий становится источником истины. Документация v0 описывает автоматические ветки и коммиты, запрещает прямую отправку в защищенную ветку `main` и позволяет команде сливать изменения через pull request. Можно импортировать существующий репозиторий GitHub или загруженный ZIP-архив. Для компании с разработчиками это самый чистый процесс совместной работы в четверке: менеджер продукта может предложить рабочие изменения интерфейса, не обходя проверку.

Vercel служит естественной средой продакшена и дает самый полный набор предварительных просмотров, переменных окружения и развертываний, но в официальном FAQ сказано, что код можно экспортировать и развернуть в другом месте. Такая переносимость реальна с одной оговоркой: приложение Next.js может зависеть от особенностей развертывания, обработки изображений, серверных функций, аналитики или хранилищ конкретной платформы. Исходники уйдут, но часть эксплуатационных предположений останется. До заявлений о легкой миграции разработчик должен выполнить продакшен-сборку на выбранном альтернативном хостинге.

Сейчас v0 предлагает бесплатный тариф с небольшим месячным балансом кредитов, Team стоит 30 долларов на пользователя в месяц, а Business 100 долларов на пользователя. Месячные кредиты оплачивают генерации, неиспользованный остаток переносится лишь на ограниченный срок, а команды могут покупать дополнительные кредиты. Модель на пользователя предсказуема для небольшой продуктовой группы, но расходы растут вместе с числом мест и итераций. Она менее привлекательна, когда доступ нужен многим редким участникам или основная работа связана с бэкендом, а не с интерфейсом и веб-приложением.

Нетехнический основатель может успешно применять v0, но продукт предполагает более четкий архитектурный замысел, чем Lovable. Кто-то должен определить структуру репозитория, работу с окружениями, границы данных и правила развертывания. Если такие решения уже приняты, v0 их соблюдает. Если их нет, основатель может получить технически знакомые файлы без цельной системы вокруг них.

Выбирайте v0 для приложения, которое должно стать обычной кодовой базой Next.js под командной проверкой. Откажитесь от него, если выбор стека остается открытым, преобладает нативная мобильная разработка или основатель ожидает, что один агент возьмет на себя весь продакшен.

## Кривая расходов начинается после первой демонстрации

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

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

- Для работы ИИ записывайте кредиты, токены или оплату усилий по каждой функции. Считайте предупреждением рост стоимости при неизменном объеме задачи.
- Для ручных исправлений записывайте часы основателя и инженера на диагностику сгенерированного кода. Сравнивайте время проверки со временем, за которое разработчик написал бы изменение сам.
- Для среды исполнения учитывайте хостинг, базу данных, хранилище, передачу данных и вызовы моделей. Каждая сумма должна относиться к функции, окружению или группе клиентов.
- Для переносимости записывайте часы на воспроизведение сборки и развертывания в другом месте. Релиз, который возможен только из исходной рабочей области, не прошел проверку.
- Для восстановления после сбоя учитывайте откаты, ремонт данных и время поддержки. Восстановления кода недостаточно, если данные или конфигурация остаются поврежденными.

Не сокращайте число токенов, пока не измерили время на исправления. Дешевая генерация с ошибкой в правах доступа обходится дорого. Не учитывайте только успешные запросы. Отброшенные попытки и обсуждения плана входят в разработку продукта, а некоторые конструкторы берут за них плату. Смотрите на счета и панели использования, а не полагайтесь на память основателя.

Заложите отдельный бюджет на передачу проекта. Репозиторий может выглядеть обычно, но первый сторонний инженер потратит часы на поиск сгенерированных политик базы данных, отслеживание переменных окружения и выяснение того, какое действие развертывания меняет продакшен. Отнесите эти часы к решению о конструкторе, даже если работа началась после отмены подписки. Учитывайте задержку основателя: если функция ждет три дня, потому что никто не доверяет сгенерированной миграции, счет за подписку занижает расходы. Поэтому чуть более дорогой конструктор бывает дешевле, когда создает обычные файлы, понятную историю и процесс выпуска, который способен повторить другой человек. В сравнении должно учитываться время на объяснение приложения следующему владельцу.

Смоделируйте один плохой месяц вместе с обычным. Добавьте неудачное развертывание, срочное исправление прав, дополнительные попытки агента, восстановление базы данных и работу инженера, который проверит результат. У конструктора, который выглядит дешевым лишь при каждой успешной генерации, нереалистичный бюджет. Затем определите, кто может повышать лимиты расходов и какие данные он должен сначала увидеть. Разделите уведомления о продакшене и кредитах разработки, чтобы всплеск клиентского трафика не выглядел как неудачная сессия с агентом. Каждую неделю проверяйте расходы на уровне функций, пока команда не поймет закономерность. После стабилизации хватит месячной проверки, но оставьте уведомления включенными: цикл в коде приложения способен увеличить расходы без нового запроса.

Лучший способ контролировать расходы состоит в сужении объема. Оставьте в первом выпуске один тип пользователя, один оплачиваемый результат и минимальные процессы для его получения. Это продуктовая дисциплина, а не уступка ограничениям ИИ. В меньшей предметной области агент видит меньше лишнего контекста, проверяющий изучает меньше путей доступа, а репетиция выхода занимает часы вместо недель.

## Проверка выхода из пяти частей выявляет привязку

Кнопка экспорта почти ничего не доказывает, пока приложение не запустится вне исходной рабочей области. Проведите проверку выхода до того, как клиентские данные станет трудно переносить, и повторяйте после каждого крупного изменения инфраструктуры. Основатель может организовать проверку, но результат должен подтвердить инженер.

1. Поместите репозиторий в организацию под контролем компании. Клонируйте его в чистый каталог через учетную запись, которая не создавала проект. Проверьте наличие истории, ресурсов, миграций и файлов блокировки зависимостей.
2. Соберите приложение без предварительного просмотра конструктора. Установите описанную среду исполнения, восстановите зависимости из файла блокировки и выполните продакшен-сборку. Запишите каждое недокументированное ручное действие.
3. Замените управляемое окружение. Загрузите секреты в новое окружение, создайте пустую базу данных, выполните миграции и добавьте только неконфиденциальные тестовые данные. Не копируйте рабочую базу, чтобы проверка формально прошла.
4. Разверните приложение на второй площадке. Используйте временный хостинг вне контроля конструктора, проверьте аутентификацию, загрузку файлов, вебхуки электронной почты или платежей, фоновые задачи и регистрацию ошибок. Проверьте скучные сценарии с неудачными миграциями.
5. Выпустите одно изменение. Попросите инженера, который не создавал приложение, исправить небольшую ошибку через ветку и pull request, развернуть исправление, а затем откатить его. Измеряйте пробелы в документации, а не подсказывайте каждый шаг.

Результатом станет короткая запись о выходе: владелец репозитория, стек и версии среды, имена переменных окружения, процедура экспорта и восстановления базы, команда развертывания, управление доменом, периодические задачи, внешние сервисы, последняя успешная репетиция и открытые препятствия. Не помещайте значения секретов в эту запись. Храните ее вместе с репозиторием, чтобы она уходила вместе с кодом.

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

## Соотносите конструктор со следующим риском

Выбирайте продукт, который снимает следующий бизнес-риск, а не побеждает по самому длинному списку функций. Основателю без выручки обычно нужны доказательства интереса пользователей. Компании с финансированием и существующим репозиторием нужен контролируемый вклад в код. Работающему приложению нужны предсказуемая эксплуатация и ремонт. На разных этапах оправданы разные конструкторы.

Берите Lovable, когда нетехнический основатель должен вести поиск веб-продукта и хочет понятную передачу в GitHub. Берите Bolt, когда важны прямой доступ к файлам, среда разработки в браузере и гибкие эксперименты с JavaScript, особенно если с первого дня нужен заметный выход в ZIP. Берите Replit, когда ближайшая задача состоит в совместной работе фронтенда, бэкенда, фоновых процессов и развертывания. Берите v0, когда целевой стек и процесс проверки в GitHub уже выбраны вокруг Next.js.

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

Есть четкие условия отказа. Не принимайте конфигурацию, которая не позволяет хранить код в учетной записи компании, воспроизводить продакшен-сборку, экспортировать данные, ограничивать права пользователей в базе или устанавливать лимиты для сервисов с оплатой по потреблению. Откажитесь от сгенерированной зависимости, которую нельзя лицензировать или исправлять. Отложите запуск, если никто не может простыми словами объяснить пути аутентификации и авторизации.

Основателю все равно придется оплатить техническую оценку. Вопрос только во времени и задаче. Разумно нанять инженера для ограниченной проверки архитектуры и безопасности до запуска. Восстанавливать месяцы недокументированных изменений по запросам во время аварии гораздо дороже и этого можно избежать.

## Предел проявляется в координации изменений

ИИ-конструкторы редко упираются в неспособность нарисовать еще одну страницу настроек. Предел появляется, когда одно изменение одновременно затрагивает права, миграции данных, фоновые задачи, внешние API, тесты и развертывание. Агент может изменить все файлы, но кто-то должен определить безопасный порядок, задать неизменные условия и знать, какое состояние нельзя откатить. Это работа инженерного руководителя.

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

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

Основателям, которые не понимают, наступил ли этот момент, Team & AI Audit на oleg.is предлагает за пять рабочих дней проверить команду, набор инструментов и расходы. Цена фиксирована на уровне 5000 долларов, а заявленная гарантия обещает не менее 50 000 долларов найденной годовой экономии, иначе аудит будет бесплатным. Такой аудит особенно уместен до найма обычной команды вокруг приложения, архитектуру которого никто не оценивал.

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