Vibe Coding Isn't What You Think

I wrote my first lines of code in BASIC on a Commodore 64. Then assembler, because BASIC wasn't close enough to the machine and apparently I had something to prove. Later, a Sun workstation Terminal in college, where you built a complete mental model of what the system was doing or you were lost. No autocomplete. No debugger holding your hand. Just you, the compiler, and a very unforgiving machine.

So when I say I've seen this transition before, I mean I've seen it four times. And the pattern is always the same.

The word "vibe" is doing a lot of damage here.

When most senior people in tech hear "vibe coding," they picture someone typing "make it pop" into a chat box and hoping for the best. The name invites dismissal. It sounds like the opposite of rigor, the opposite of craft, the antithesis of everything we spent years learning about software quality and intentional design.

That framing is wrong, and it's costing people.

Vibe coding isn't the absence of thinking. It's a different interface for thinking. Instead of translating intent into syntax, you express intent in natural language and let the model handle the translation. The constraint moves from "can you write the code" to "do you know what you want, and can you recognize when you've got it."

That second constraint turns out to be much more interesting.

This has happened before. Four times.

I wrote my first serious code in a terminal, an admin CLI tool developed in C. You built a mental model of the machine, you typed, and you compiled. When it broke, you figured out why. That discipline was real, and it wasn't nothing.

Then Borland happened. Turbo C++, the Borland IDE, visual debuggers that let you watch state change in real time. Suddenly you could see what your program was doing instead of inferring it. Purists called it training wheels. What actually happened: an entire generation of developers came online who would never have survived the terminal era, and the practitioners who embraced the new tools shipped faster and built more complex systems than before.

The same arc repeated in the early 2000s with modern IDEs. Autocomplete, refactoring tools, integrated testing. Then again in the 2010s with low-code and no-code platforms. Yes, those produced brittle, unscalable garbage in the wrong hands. They also democratized internal tooling, enabled non-technical founders to validate ideas, and trained people to think in data flows and logic before they knew what a database was.

Four transitions. Same pattern every time: the abstraction layer moves up, the purists resist, the builder population expands, and the best practitioners use the new floor to go faster and deeper, not shallower.

Vibe coding is the fifth transition. The only question is whether you're going to resist it or use it.

What vibe coding actually requires.

Here's what I've observed watching people try to use AI to build things, including inside my own teams and through the platform I've been building for the past year.

The people who succeed are not the ones who know the least. They're the ones with the clearest mental model of what they're trying to build and the sharpest instincts for when the output has gone sideways. They think in systems. They ask precise questions. They know what "done" looks like before they start.

That's not a vibe. That's product judgment.

The people who struggle are usually the ones who never developed an opinion about the problem they're solving. They hand the AI a vague brief and accept whatever comes back because they don't have a frame to evaluate it against. The AI gives them something, they ship it, it doesn't work, they blame the AI.

The bottleneck was never the code. It was always the clarity of thought upstream of the code.

What this means if you're a builder, a PM, or a product leader.

The question worth sitting with isn't "should I learn to vibe code?" It's "do I have enough product instinct to use this well, and do the people I'm building with?"

The teams that will move fastest in the next few years are not necessarily the ones with the most engineers. They're the ones with the clearest thinkers who know how to direct AI execution with specificity. Domain depth plus AI fluency is the new competitive surface.

The Full Stack PM I wrote about last year is the early version of this person. Someone who operates across the full depth of the creation process when needed. Vibe coding doesn't change that thesis, it accelerates it. The bar didn't get lower. It moved.

I'll say the quiet part out loud.

If you've been dismissing vibe coding because the name sounds frivolous, or because the early demos looked like toys, you're making the same mistake companies made when they dismissed the web as a medium for serious software in 1997. The demos were toys. The shift was real.

The people building with these tools right now are developing an intuition that will be very hard to acquire retroactively. You don't have to build everything yourself. But you should understand what it means when someone who isn't an engineer can ship a working product in an afternoon.

That's not a curiosity. That's a new baseline.

I've watched this movie four times. I know how it ends.

What's your read? Are you seeing this play out differently in your organization?