From Lovable, Cursor and Bolt: Why AI Coding Needs Guardrails

From Lovable, Cursor and Bolt: Why AI Coding Needs Guardrails

In my first article, I shared the history of Vibe Coding — the flow state of hacking in the early days. We looked at the Homebrew Computer Club, where Steve Wozniak showed off early Apple designs written mostly by feel. We looked at the demoscene, where coders squeezed beauty out of hardware limits through sheer intuition. And we connected that creative spirit with the rise of Test-Driven Development (TDD) in the 90s, when Kent Beck formalized Red → Green → Refactor to give coding some much-needed guardrails.

That post sparked some great conversations, and I want to carry the thread forward.

Because in 2025, when people talk about Vibe Coding, they aren’t usually thinking about hobbyists soldering boards in a garage or democoders competing for bragging rights.

They’re talking about AI-assisted development.

Tools like Lovable , bolt.new and Cursor have redefined what "flow" looks like for developers. You describe the kind of app you want, and the AI scaffolds it out in minutes. You keep prompting, editing, and reshaping until it feels right. You’re not following a detailed requirements doc... you’re vibing with the machine.

That new flavor of vibe coding has real strengths:

  • 🚀 It’s fast. You can go from zero to prototype in a single afternoon.
  • 🎨 It’s creative. The AI often suggests approaches you wouldn’t have considered.
  • 💡 It’s accessible. Developers at every level can spin up working code without getting bogged down.

But it also has some very real risks:

  • ⚠️ Code quality is inconsistent, depending on the model, prompt, and your own experience.
  • 🧪 Testing is usually skipped or bolted on later (and AI-generated tests don’t always reflect intent).
  • 🧩 Maintainability becomes a nightmare when your "vibes" accumulate into production systems.

That's why I think we need to go beyond just "vibing."

👉 What if we paired the speed and creativity of AI-driven coding with the discipline of Test-Driven Development?

Imagine this workflow:

  1. Start with AI to generate an idea or prototype.
  2. Translate the successful "vibe" into a test that captures your real intent.
  3. Refactor safely, knowing you can't accidentally break what matters.
  4. Return to the flow — free to keep exploring, because the tests have your back.

That's the essence of what I'm calling Vibe-Driven Development (VDD).

It's not about rejecting AI coding tools. It’s about giving them a framework so the creative energy doesn’t collapse under its own weight.

In my next article, I’ll go deeper into why TDD still matters in an AI world and how it complements, rather than slows down, this new style of building software.

For now, I’d love to hear from you:

  • Have you tried Lovable, Bolt, or Cursor?
  • Did it feel like a shortcut, or like a sustainable way to build?
  • Do you see TDD as a natural fit for AI workflows, or does it feel like friction?

I actually attended a AI session recently and it we were instructed to use Lovable to create a marketing page for a new feature/product that would address a issue that our company was facing. I provided an image to see if it would try to match our branding guidelines and it generated a nice looking splash page, but I didn't even get into the code it generated because it was still off and I instead quickly tried to vibe code something in our internal platform instead using cursor. That too still generates a slew of errors, but we were able to get those resolved. I've been using Cursor in my day to day, and I am actually trying to use Co-pilot more in my side project. I think AI can help with planning, scaffolding out content, but you still need to have things be checked and having someone with experience to help with guided prompts are still needed (at least what I've seen in my experience)

To view or add a comment, sign in

More articles by Matt Dorman

Others also viewed

Explore content categories