# Почему новичку не стоит начинать с Lovable и Bolt - и что вместо них

Собрался вайбкодить, но не знаешь, с чего начать? Разбираю, почему новичку не стоит стартовать с Lovable и Bolt, где их потолок и что взять вместо.

URL: https://posts.danashkin.ru/guides/pochemu-ne-lovable-i-bolt-novichku
Обновлено: 2026-08-10

---

## Коротко

**Главное**

- Облачные конструкторы вроде Lovable и Bolt заманивают простотой: описал словами - получил приложение. Для новичка звучит идеально, но лёгкий вход оборачивается ограничениями на выходе.
- Главная ловушка - vendor lock-in, привязка к поставщику. Маркетинг обещает «экспортируй код когда хочешь», и код фронта ты правда заберёшь. А вот данные, бэкенд и сама рабочая среда застревают в их облаке.
- Второй барьер - потолок. Кастомизация упирается в то, что платформа умеет, а агенту негде системно держать контекст твоего проекта, поэтому он быстро начинает ходить по кругу.
- Для чего конструктор реально хорош: разовый лендинг, прототип на выброс, быстрая проверка идеи глазами.
- Где ловушка: продукт, который ты собираешься растить месяцами и в котором копятся данные людей.
- Что вместо: инструмент, который живёт в твоих файлах (Claude Code, Cursor). Порог входа чуть выше, но проект с первого дня твой, и потолок не платформа, а только модель и твоя задача.

## Почему новичку советуют начать с Lovable и Bolt?

**Главное**

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

У лёгкого старта есть цена.

Ты открываешь Lovable или Bolt, пишешь в окошко «сделай мне сервис записи к парикмахеру», и через пару минут на экране кликается живой макет. Никакого терминала, никаких папок, никакого страшного кода. Для человека без тех-бэкграунда это выглядит как магия по кнопке. Именно поэтому их советуют новичку первым делом - вход почти нулевой.

Сам по себе этот способ собирать продукты называется [вайбкодинг](/concepts/vibecoding): код пишет ИИ, а ты задаёшь смысл и проверяешь результат. Облачный конструктор - лишь одна из дверей в него. Самая красивая витрина, но не единственная и, как выяснится, не лучшая для тех, кто пришёл всерьёз.

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

## Облачный конструктор или инструмент в твоих файлах?

**Главное**

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

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

**Облачный конструктор** - это Lovable, Bolt и им подобные. Всё живёт в браузере на их серверах: и то, что ты собрал, и данные, которые в приложение попадают. Ты не ставишь ничего на свой компьютер. Удобно въехать, но ты - арендатор.

**Инструмент, который живёт в твоих файлах** - это [Claude Code или Codex](/guides/chto-takoe-claude-code-i-codex) рядом с обычным редактором. Проект - это папка на твоём диске. Агент читает и меняет файлы прямо у тебя, а не где-то в облаке. Порог входа чуть выше: надо один раз поставить среду и привыкнуть, что проект - это папки. Зато ты владелец.

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

И вот когда доходит до «съехать», начинается самое интересное.

## Vendor lock-in: почему забрать проект сложнее, чем обещают

**Главное**

Vendor lock-in - это привязка к поставщику, когда уйти дорого или почти невозможно. Конструкторы клянутся, что лока у них нет. На практике код фронта ты и правда заберёшь, а данные, бэкенд и рабочую среду вынести куда труднее. Я прошёл это на своём проекте.

Vendor lock-in по-русски - «замок поставщика». Ты вложил месяцы в продукт, а забрать его и уйти к другому не можешь без больших потерь. Классическая ловушка, знакомая любому, кто хоть раз менял CRM или банк-клиент.

Формально конструкторы этот упрёк отбивают. Вот что пишет сам Lovable в своей документации:

> Lovable намеренно устроен так, что ты никогда не оказываешься запертым: код можно выгрузить в GitHub, данные - перенести, а часть или весь стек - развернуть на своей инфраструктуре.
>
> Документация Lovable, [раздел про портируемость и владение кодом](https://docs.lovable.dev/tips-tricks/deployment-hosting-ownership)

И это не враньё. Код фронта - того, что видит пользователь, - ты правда выгрузишь: Lovable синкается с GitHub, Bolt даёт скачать проект архивом. Но вот где привязка сидит на самом деле:

- **Bolt по умолчанию генерирует только фронт.** Базу данных и серверную логику подключаешь отдельным сервисом вручную. Забрал ты, по сути, витрину без склада.
- **Данные вынести - отдельная спецоперация.** Штатный путь переноса из облака Lovable болезненный: каждому пользователю приходится сбрасывать пароль, таблицы выгружаешь по одной в правильном порядке, файлы качаешь и заливаешь поштучно. Народ устал настолько, что пишет отдельные сторонние утилиты, лишь бы автоматизировать этот переезд.
- **Сам редактор и агент никуда не переносятся.** Среда, в которой ты работал, остаётся в облаке. Уносишь результат, но не рабочее место.

Теперь как это выглядит на практике, не в теории. У меня есть проект, который я начинал именно в облачном конструкторе. Когда решил развивать его всерьёз, я вынес фронт на свой хостинг - склонировал репозиторий, и это сработало. А бэкенд остался в заложниках.

**Что реально застряло в облаке**

К собственной базе данных проекта у меня нет прямого доступа обычными инструментами - только через их интерфейс. Серверную функцию нельзя починить в редакторе, правки идут через чат платформы. А часть бэкенда существует только в облаке, и из моего же гита её не восстановить. Вынес половину проекта - вторая половина осталась на привязи. Вот это и есть lock-in вживую, а не в теории.

И это только про переезд. А ведь есть ещё потолок.

## Где потолок - и почему агент «тупеет»?

**Главное**

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

Пока ты хочешь стандартное - конструктор летит. Форма, список, кнопка, оплата по шаблону - собирается на ура. Шаг в сторону от накатанного, нестандартная логика или интеграция - и упираешься в стену «платформа так не умеет». Для витрины неважно. Для продукта, который должен отличаться от соседнего, это потолок.

Есть и вторая, менее очевидная стена - контекст. В облачном конструкторе почти негде системно вести то, что я называю [вторым мозгом](/concepts/vtoroy-mozg): файлы-инструкции, где записано, что за продукт, какие правила, что уже сделано. Агент каждый раз стартует почти с чистого листа. Отсюда знакомое ощущение «модель тупеет к вечеру».

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

Чтобы разница была видна одним взглядом, сведём всё в таблицу.

## Конструктор против инструмента-в-файлах: таблица

**Главное**

Пять осей, по которым видно разницу: порог входа, где живёт проект, реальность переноса, потолок и контекст. Честное «за» у конструктора ровно одно - вход.

| Ось | Облачный конструктор (Lovable, Bolt) | Инструмент в файлах (Claude Code, Cursor) |
|---|---|---|
| Порог входа | Минимальный: браузер, описал словами | Чуть выше: поставить среду, освоить папки |
| Где живёт проект | На их серверах, ты арендатор | На твоём диске, ты владелец |
| Забрать и уйти | Фронт заберёшь, данные и бэкенд застревают | Проект целиком твой, уносишь одной папкой |
| Потолок | Упираешься в то, что платформа умеет | Ограничен только моделью и твоей задачей |
| Контекст проекта | Негде системно вести | Второй мозг: файлы-инструкции рядом с кодом |

Смотришь на таблицу и напрашивается вывод «конструкторы - зло». Нет. Инструмент не виноват, виновата задача не по инструменту.

## Когда Lovable и Bolt всё-таки хороши?

**Главное**

Для разового лендинга, прототипа на выброс или быстрой проверки идеи глазами облачный конструктор - отличный выбор, честно. Ловушка захлопывается только тогда, когда из прототипа ты решаешь растить продукт.

Скажу прямо, без вкусовщины: есть задачи, где конструктор - правильный инструмент, и тащить туда Claude Code было бы из пушки по воробьям.

- **Разовый лендинг под акцию или мероприятие.** Собрал за вечер, откручиваешь неделю, забыл. Переносить нечего - и вопрос lock-in просто не возникает.
- **Прототип показать и выбросить.** Нужно накликать что-то живое, чтобы объяснить партнёру или инвестору идею на пальцах. Через день он не нужен.
- **Проверить идею глазами.** Иногда дешевле собрать кликабельный макет за час, чем неделю обсуждать его на словах.

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

Хорошо, растить - не в облаке. Тогда с чего начать?

## С чего начать вместо: путь новичка

**Главное**

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

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

1. **Инструмент в файлах**

   Поставь [Claude Code или Codex](/guides/chto-takoe-claude-code-i-codex) рядом с обычным редактором. Проект будет папкой на твоём диске - твоим с первой минуты.

2. **Начни с малого**

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

3. **Заведи второй мозг**

   Сделай проекту файлы-инструкции: кто ты, что за продукт, какие правила. Агент читает их и работает как сотрудник, который знает карту офиса.

4. **Git как машина времени**

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

5. **Проверяй результат**

   Ты не читаешь код построчно, ты проверяешь результат и заставляешь агента проверить себя. Как - в разборе [12 принципов вайбкодинга](/guides/vibecoding-dlya-predprinimatelya-12-principov).

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

**Разбираю это на реальных задачах**

Каждую неделю показываю такие штуки на живых проектах - инструменты, кейсы, ошибки. Если тема твоя, заглядывай в канал [@ai_anashkin](https://t.me/ai_anashkin).

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

**Главное**

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

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

**Lovable же проще - почему бы новичку не начать с него?**

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

**Claude Code и Cursor - это не слишком сложно без тех-бэкграунда?**

Порог выше на день-два: поставить среду и привыкнуть к папкам. Дальше общение с агентом такое же, словами, как в конструкторе. Разница в том, что проект остаётся твоим.

**У меня уже есть проект в Lovable или Bolt. Всё потеряно?**

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

**Что дороже по деньгам - конструктор или инструмент-в-файлах?**

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

## Главный вывод

**Главное**

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

Если свести всё к одной мысли: выигрывает не тот, кто быстрее накликал прототип в браузере, а тот, у кого проект остаётся под контролем и его есть куда растить. Лёгкий старт - это приятно ровно до того момента, когда упираешься в потолок или пытаешься забрать своё.

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

Как думаешь: конструкторы вроде Lovable станут ступенькой, с которой люди перерастают в полный контроль, - или удобной клеткой, где большинство так и застрянет под потолком?

Если хочешь пройти этот путь не наугад, а собрать систему работы с ИИ под свою задачу и команду, я провожу [интенсив по нейросетям для бизнеса](https://danashkin.ru/workshop): без магии по кнопке, по делу, с результатом, который остаётся у вас.

### Источники

- [Andrej Karpathy, X - определение термина «vibe coding», февраль 2025](https://x.com/karpathy/status/1886192184808149383)
- [Документация Lovable - деплой, хостинг и владение кодом (портируемость и lock-in)](https://docs.lovable.dev/tips-tricks/deployment-hosting-ownership)
- [Bolt Help Center - экспорт и скачивание проекта для работы в своём редакторе](https://support.bolt.new/building/using-bolt/projects-files)
- [lovable-cloud-to-supabase-exporter, GitHub - сторонняя утилита переноса данных из облака Lovable в собственный Supabase](https://github.com/dreamlit-ai/lovable-cloud-to-supabase-exporter)