AI generates the scaffold in minutes. But who owns the code afterward? The answer defines your entire workflow.
Lovable = scaffold · Git = home · One source of truth per project · On the second hand, choose git
Lovable turns a prompt into a real React app. You describe the screen, it generates the components, spins up a live preview, and pushes the code to a GitHub repository. In minutes you go from zero to a working interface — with Tailwind, shadcn/ui, and everything wired up.
For prototyping, it's hard to beat. Most of our dashboards and landing pages started as a Lovable scaffold. It solves the blank page, which is the most expensive problem at the start of any project.
The problem isn't what Lovable generates. It's what happens next — when the project grows and Lovable is still the owner of the code.
Every project has a source of truth: the canonical place where the code lives and from which everything is built. It can be your local git repository. It can be Lovable. What it can't be is both at the same time.
→ The question isn't “is Lovable good?”. It's “who owns the code when two different hands touch it?”.
The friction showed up on our own marketing site. It's bilingual — each page has a PT version and an EN mirror file. While we edited locally via Claude Code, Lovable was also pushing commits on its own, mostly to the files ending in En.tsx.
→ No tool was wrong. The mistake was having two sources of truth writing to the same branch without coordination. Every pull became a coin toss.
We decided to treat Lovable as what it's best at: a scaffolding tool. It takes you from nothing to a working app. But the place where the code actually lives is our git. When a project goes from prototype to product, we pull it local and disconnect Lovable.
Lovable creates the scaffold from the prompt. Components, routes, base styling.
We clone the repo to the machine. From here on, local git is the source of truth.
Features, refactors and fixes happen in the editor + Claude Code, with reviewed commits.
Lovable is unlinked from the repo. No auto-commits, no ghost branch, no conflicts.
That's exactly what we did when consolidating the agency's projects into a single monorepo: we disconnected Lovable, and one git push now covers everything. The old Lovable repos were archived — history preserved, but read-only.
This isn't “never use Lovable”. The rule is simpler: one source of truth per project. The criterion is how many hands edit the code.
→ The problem was never the quality of the generated code. It was the ambiguity of who's in charge. On the second writer, choose git.
Use Lovable guilt-free to escape the blank page. A scaffold in minutes is a real advantage, not a lazy shortcut.
Decide the source of truth BEFORE you start editing locally. That choice defines your commit, deploy and review flow.
Disconnect Lovable from the repo the same day. Don't leave two writers on the same branch “just for now” — the conflict will come.
One source of truth per project. Document which one. Anyone joining the project needs to know where the code really lives.
An AI tool is great at generating. Terrible at owning. Let Lovable build the scaffold and let git be the home. The day a second hand touches the code, the source of truth is your repository.