Vibe Coding Is a Terrible Name for Something Revolutionary

A 13-year-old walked into a room full of Google and Oracle executives, sat down, and built an AI-powered sports coach in two days. His 18-year-old sister built an astronomy app. Neither of them wrote a single line of code in the traditional sense.

The tech press is calling this "vibe coding."

I hate that name.

The Problem with "Vibe"

"Vibe coding" sounds like something you'd do at a wellness retreat between sound baths. It diminishes what is arguably the most significant shift in who can build software since VisiCalc democratised financial modelling in 1979.

When we called spreadsheets "electronic worksheets," we accidentally communicated their power: they replaced physical worksheets. When we call prompt-driven development "vibe coding," we communicate nothing except that it's somehow unserious. Something you do when you can't do the real thing.

This matters because language shapes adoption. And adoption is about to reshape entire organisations.

What's Actually Happening

A father who works in financial services at Google attended a weekend class. He came home with a working financial statement analyser. Not a mockup. Not a wireframe. A working application.

His kids saw this and enrolled in the same class. Within 48 hours, the 13-year-old had built something that would have taken a professional development team weeks to scope, quote, and deliver.

This isn't "vibes." This is intent-driven development. You describe what you want. The machine builds it. You refine through conversation.

The Enterprise Implications

Every large organisation I've worked with has a backlog. Hundreds of "small tools" and "quick apps" that would make people's lives easier but never rise to the priority threshold for the development team's attention.

That backlog is now buildable by the people who actually need those tools.

The question isn't whether your employees will start building their own solutions. They already are, or they will be soon. The question is whether you'll pretend it's not happening, try to stop it, or create the conditions for it to happen well.

What We Should Call It Instead

I don't have the perfect term yet, but I know what it needs to communicate: that this is a legitimate way to build software, that the output is real and deployable, and that the skill is in precise communication and iterative refinement, not in pretending to "vibe" your way to an application.

"Intent-driven development" is my current best candidate. It's accurate: you express intent, the AI interprets and builds, you evaluate and redirect. It's also boring enough to be taken seriously in a boardroom, which might be exactly what we need.

The Uncomfortable Truth for IT Leaders

Here's what the Business Insider article doesn't say explicitly but implies clearly: the gatekeeping function of technical complexity is dissolving.

For decades, building software required specialised knowledge that took years to acquire. That knowledge became a moat. It justified headcount, budgets, and organisational power. It created a priesthood.

That moat is now fordable by teenagers with clear thinking and two days of practice.

This doesn't mean developers are obsolete. The hard problems (security, scale, integration, architecture) still require deep expertise. But the "we'll get to your small request eventually" leverage that IT departments have held over business units? That's evaporating.

The organisations that thrive will be those that separate the genuinely hard work from the commodity work, and let both be done by the people best positioned to do them. Right now, most organisations have those two categories completely tangled together.

What the Kids Got Right

The most revealing quote from the article came from the 13-year-old: "Prompts are supposed to have good details and good information. You have to instruct the AI like a teacher to a student."

He's describing a skill that has nothing to do with technology and everything to do with clear thinking: knowing what you want, breaking it into components, communicating precisely, and iterating based on feedback.

That's not a "vibe." That's the core competency of effective work in any domain.

Maybe that's what we should be teaching. Not "how to code" or "how to vibe code," but how to think clearly enough that machines can execute your intent. It's a skill that will outlast any particular tool or interface.

And it's a skill that a 13-year-old can learn in a weekend, which tells you something about where the bottleneck actually was all along.