Vibe coding and the fairy tale that anyone can build software

There's a narrative that has been making the rounds for a couple of years now, and it sells extremely well: write two sentences in plain English to a model, and it spits out an application. No syntax, no architecture, nothing at all. The underlying idea is that the technical barrier has collapsed, and now anyone with an idea in their head and a subscription can build software products.

It's a lie. Or rather: it's a half-truth told in the most deceptive way possible, and the difference between the true half and the false half is exactly what separates those who produce things that work from those who produce rubble that looks like software.

I say this as someone who really does vibe coding, every single day, on systems that go into production and have real users on the other end. I hardly write code by hand anymore. I orchestrate. I define the architecture, set the constraints, write the specifications, and let the model implement. It works. But it works because I know what I'm doing, not in place of the fact that I should know it.

What vibe coding really is when it works

When vibe coding works, you're not "not programming." You're programming at a higher level of abstraction. The work doesn't disappear: it shifts. Instead of writing the for loop, you write the specification of the behavior. Instead of typing out the query, you decide the data model and then verify that the generated query isn't some non-sargable mess that sends your database CPU to 100%.

A prompt is not a chat. A prompt is a technical specification. And writing a decent technical specification requires exactly the same skills that were needed before: knowing what you want, knowing how to structure it, knowing how to recognize when the answer is wrong. The model is a lever. A lever amplifies the force you put into it. If the skill you bring is zero, the lever amplifies zero.

Why without the fundamentals you produce rubble and don't even notice

Here's the point that the salesman's narrative takes great care not to mention.

The problem isn't just that without the fundamentals you write bad code. It's that you're unable to notice it. The model hands you something that looks like an application: it starts up, it does what you asked in the happy path, the screens are there. For someone without the fundamentals, that's where the story ends: "it works." For someone who has them, that's where the real work begins: but will this hold up under load? What happens with ten parallel requests? Does error handling exist or is it a pretense? Is this authentication secure, or did I just put an open door online? Is this data safe, or does a single malformed query bring everything down?

Whoever can't read the generated code can't answer any of these questions. And a system that doesn't hold up under load, that doesn't handle errors, that has fake security, is not software. It's a demo that blows up at first contact with reality.

The model gives you the average, and the average is mediocre

Two things I've learned in the field that, on their own, demolish the idea that "anyone can do it."

The first concerns where the model's answers come from. A model has learned from an enormous mass of code written by others, and most of the code out there is, at best, average, often below. When you ask it something without giving it anything specific, it hands you the most probable solution, that is, the one most people would write. The median solution. The trouble is that the median of the code in circulation is mediocre stuff, and nobody has ever built a product that holds up starting from the median.

The model doesn't know your constraints, your load, your edge cases, the real context in which the thing will run. It gives you the textbook answer, good for the generic case, which is never your case. To push it above average you have to steer it away from its default: tell it that the general rule doesn't apply here, that you need a different route because your context is different. And to tell it that, you must know exactly how your case departs from the norm. Whoever doesn't know accepts the median and ships it to production, convinced they've hit the bullseye.

The second: the model is agreeable. If you tell it your wrong idea is right, it tends to agree with you and build on top of it. It loops down wrong paths with great enthusiasm, and it has no internal brake to stop it. The only brake is you. If you don't have the technical judgment to tell it enough, it won't stop on its own: it walks you straight into the wall, and does it with a smile.

What you really need to do vibe coding seriously

To sum up, without sugarcoating anything. To do vibe coding in a way that produces something sensible, you need:

• The ability to read code. Not to write it from scratch, but to read it, yes. You must be able to verify what has been delivered to you. Without this you're blind.
• Software architecture. Knowing what to ask for, knowing how a system is structured, and recognizing when the solution being proposed is the textbook median one rather than the right one for your case.
• IT and infrastructure knowledge. Deployment, databases, security, performance. Code is the easy part. Putting it online so that it doesn't collapse and doesn't get hacked is where amateurs die.
• The ability to break down and specify. Translating a vague problem into a sequence of precise requests. It's the skill that prompting hides behind the mask of "conversation."
• The judgment to say no. To the model and to yourself. It's the only thing that keeps an agreeable tool from taking you down.

Note one thing: none of these skills disappeared with the arrival of AI. They're all still there. Some matter more than before, not less, because now you apply them to volumes of code that you could never have produced alone in the same amount of time. The lever is longer, so mistakes in direction cost more.

The barrier hasn't collapsed, it has moved

The honest truth is this: the barrier to entry hasn't vanished. It has moved. Before, you had to know how to write code. Today you have to know how to direct the writing of code. And whoever directs without knowing what should come out never notices when it comes out wrong.

I'll add the only concession I feel I can make, and it's the reason for the "at least for now": the tools are improving fast, and some of these skills will sooner or later be absorbed by the models. Maybe in a few years the sentence "anyone can build software" will be less false than it is now. But today, in the real world, in production, with real users, it isn't. Today vibe coding is a multiplier of skill, not a substitute for it. Give it to an expert and you get an expert ten times faster. Give it to someone who knows nothing and you get rubble delivered ten times faster, plus the dangerous illusion of having built something.