A Developer’s Reflection on Vibe Coding with AI — You Don’t Run Faster Than a Car, You Learn to Drive

Yeah, vibe coding works. Really well, actually.

… Until it doesn’t.

I’ve built full features in hours, skipping boilerplate, moving fast. It’s definitely faster than me most of the time, and that’s the point. Once something like this exists, you don’t try to beat it — you learn to work with it.

You don’t run faster than a car. You learn to drive.

But once the code breaks — or gets just a bit too complex — I often find myself slowing down. Not because AI is useless, but because now I need to understand what it just did, and patch that small part manually. That single part ends up taking longer than if I had just done it myself to begin with.

And just to be clear, I’m not talking about asking AI to write a couple of functions or fix a bug in a file.
I’m talking about full-on project-level vibe coding with Claude Code, Cursor, and that kind of flow, where the AI is driving large chunks of implementation, end to end. That’s where these patterns really start to show.

Because AI tends to go for the lowest-effort solution, not the best-engineered one. No abstractions, no cost or scalability concerns, and definitely no thought about who’s going to maintain this a week later. Unless you tell it to. And even then, not always.

That’s where you need to step in, not just as a user, but as the engineer.
You need to know what you’re building, what pieces are in play, and how to guide the AI in doing what should be done, not just what can be done.

If you don’t, you’ll end up blindly accepting whatever suggestion it throws at you just to keep your vibe going. But that’s a trap. Because now you’re following the AI, not leading it.

(And no, this isn’t how I build things at work. That’s a whole different level of discipline and process. This post is more about how I explore things on the side, where the lines are blurrier and the temptation to move fast is higher.)

Even if you wrote a perfect CLAUDE.md with clear instructions and great context, at some point, the responsibility shifts back to you. Vibe coding might be perfect for a one-day MVP or a hackathon demo. But once it’s real, once there’s weight behind what you’re building — you have to engineer.

AI can help anyone look productive. But vibe coding != engineering.

Software engineers can vibe code.
But not all vibe coders can engineer.

And that difference eventually shows, usually when it hurts the most.

====
This is my original story I wrote on my LinkedIn.