On Vibe Coding

Earlier this month Andrej Karpathy gave a name to something many of us had started doing. He called it “vibe coding”: you describe what you want to the AI, accept what it gives you, paste back any errors, and keep going - without really reading the code. In his words, you “forget that the code even exists.”

The term spread instantly. Some people love it. Some people are horrified. I think both reactions are right, and the interesting thing is understanding when each one is right.

The joy of it

I want to start with the joy, because people who’ve been programming for a long time are sometimes too quick to scold.

Vibe coding is wonderful. Last weekend I built a small tool I’d wanted for years - nothing important, just something that makes my week a little nicer - in an evening, mostly by describing it. I didn’t read most of the code. It works. I’m happy.

For people who’ve never programmed, it’s even bigger. Someone with an idea and no technical background can now build a working prototype. That’s a real democratization, and I don’t think we should be snobs about it. The web was built by amateurs too.

The danger of it

And yet. There’s a reason Karpathy described it as fine for “throwaway weekend projects.” The moment software matters - when it holds other people’s data, handles their money, runs their business - not understanding the code stops being a vibe and becomes a liability.

Code you don’t understand still runs. It still has bugs. It still has security holes. It still breaks at the worst possible moment. And when it does, someone has to understand it. If nobody does, that’s not freedom. That’s debt with an unknown interest rate.

The question is not “should I read the code”

I think the real question is older than AI. It’s: how much does it matter if this is wrong?

A grocery list app for yourself? It doesn’t matter much. Vibe away.

A prototype to test whether an idea is worth pursuing? It matters a little. Vibe, but know you’ll rebuild it.

A system that other people depend on? It matters a lot. Read the code. All of it. Understand it well enough to own it.

Experienced developers have always made this judgment, mostly without noticing. We write quick, sloppy scripts for ourselves and careful code for production. AI doesn’t change the judgment. It just makes the sloppy end much more powerful, which makes the judgment more important.

What understanding is for

There’s a subtle thing that I think gets lost in this conversation. We don’t read code only to find bugs. We read it to build understanding - of the system, of the problem, of what’s possible. That understanding is what lets us make the next decision well. It accumulates. Over years, it becomes intuition.

If you never read the code, you don’t build the intuition. You can still produce software, but you don’t grow as the person who produces it. For a weekend project, that’s fine. For a career, it’s worth thinking about.

A middle way

What I’ve found works for me is somewhere in between. I let the AI write freely, and I read with intention: closely where it matters, lightly where it doesn’t, and always enough to know what the system is. I let go of the typing. I hold on to the understanding.

It’s a bit like the old teaching about attachment that I keep returning to: hold things loosely, but don’t let go of what matters. Most of the code doesn’t need you. Some of it does. Wisdom is knowing which is which.

Forget the code if you like. Just don’t forget who’s responsible for it.