AI-assisted coding, for a complete novice in development like me, is a revolution. It allows me to turn ideas into reality in a few hours where it would have been impossible before. But this speed comes at a price we too often overlook: technical debt.

The Development Context

Recently, as I mentioned here, I developed a small web application named HYCU Upgrade Path. The concept is simple: a clean interface to generate and visualize the upgrade path from version A to version B of backup software.

To do this, I used Lovable, a “no-code/low-code” solution that allowed me to get the application online in a few days.

A few weeks later, I decided to rebuild the application using Gemini, Google’s multimodal IA, to see what it was capable of.

I gave similar instructions to both AIs. I expected a functional and similar result from both sides. What I didn’t foresee was the abysmal gap in the code structure… And the time spent.

We’re talking about a difference of 628kb versus 115kb. We’re talking about going from 79 files to 21 files. We’re talking about one week versus half a day. A chasm.

The Lovable Experience

On paper, Lovable sells a dream: you describe, it displays. And it’s true, the user experience is stunningly fluid. I described my need for HYCU Upgrade Path, and in a few iterations, the application was running before my eyes. Visually, it was clean with a few adjustments needed. Functionally, it was a bit more shaky.

I’m not a developer, but my first reflex was to check the generated repository. And there… it was a rude awakening.

For an application as simple as an upgrade path generator, Lovable spawned a veritable Rube Goldberg machine:

• 79 files created.
• 8 nested folders.
• A total weight of 628kb.

Lovable fragmented the application into a myriad of tiny atomic components, generated duplicate configuration files, and imported libraries “just in case”. Looking at the components/ui folder, I found 38 files! Accordions, badges, carousels, “toasters”… when my app uses only a fraction of all that.

This is the “Black Box” approach: as long as it works on the surface, no one cares about the elegance of the engine. The result is a heavy application that is difficult to maintain over time. And for me, that’s a first red flag.

Regarding code modification through iteration, I didn’t find it very precise. I was forced to move forward in very small steps, which lengthened the development time… An iteration a bit too bold? It broke my interface half the time or gave a result that wasn’t what I expected. In short, not hyper-satisfied with the experience, although I managed to reach my goal in a short week of discussions.

The Gemini Experience: The Software Architect

After this week of struggle and a few weeks in production, I tried the same experiment with Gemini. Same prompt, same need, just “to see” what Google’s AI was capable of.

The result? At first, I thought pieces were missing.

• 21 files in total.
• 5 folders.
• 115kb on the scale.
• Development time: half a day.

Gemini adopted a radically different, much more mature approach. Instead of importing a massive graphic library, it structured the code and kept only what was truly necessary.

Opening the src/components folder, the difference is glaring: 7 files, all essential. No noise, no useless components.

Even more impressive, Gemini provided me with a “Production Ready” architecture. Where Lovable gave me a messy frontend, Gemini cleanly separated the frontend from the backend, and even generated a docker-compose.yml and a deployment script (deploy.sh) for my VPS. It didn’t just code the interface; it thought about how I would run it, complete with a nice README.md.

The Technical Match: Obesity vs Efficiency

Let’s compare apples to apples. Here is the scorecard for the same functionality:

Why “cleanliness” matters (even for non-devs like me)

You might tell me: “We don’t care about the code or the number of files as long as the app works!”. That is a mistake.

Maintenance: Manually modifying the project created under Lovable is like looking for a needle in a haystack of 79 files. With Gemini, every file has a name that describes actually what it does.

Consumption: 628kb of code to load for a mobile user is heavy. 115kb is almost instant.

Cognitive Load: When AI generates “messy” code, it has a harder time reading itself for subsequent iterations. That’s why Lovable “broke” the interface: it got lost in its own complexity.

Conclusion: The Choice of Tool Makes the Difference

My verdict is clear.

If you want to prototype an idea in 10 minutes to show your boss that “it moves”, Lovable creates a good illusion. It’s spectacular, it’s visual, it’s a beautiful tech demo.

But if you want to build a lasting application that you can evolve without breaking everything, Gemini is far more efficient in my eyes.

The ecosystem is evolving fast. I haven’t tested it yet, but a tool like Claude Code is probably capable of doing even better.