Vibe coding gets treated like a confession. Someone admits they built a working app without reading a single line the model wrote, and the room reacts like they just admitted to skipping a safety inspection. Here's the claim I want to defend: that reaction is mostly wrong. Not typing syntax isn't the same as not knowing what you're doing — it's a different allocation of where your judgment goes, and for a huge share of what people build, it's the correct one.
The word itself is only a couple years old and already doing too much work. It gets used for two very different behaviors that happen to look the same from outside: someone who describes what they want carefully, checks the result against real criteria, and ships — and someone who pastes a vague idea, glances at a screenshot, and pushes to production hoping. Critics of vibe coding are usually, fairly, describing the second person. But they talk about it as if the first person doesn't exist, or as if the two are on the same spectrum separated only by degree of laziness. They're not on the same spectrum at all. One is a workflow. The other is an absence of one.
What the old skill was actually for
Reading code, line by line, tracing a stack trace back to a null pointer three files away — that was never the goal. It was the only available method for a goal that hasn't changed: does this thing do what I need, safely, and can I trust it tomorrow. For thirty years the only way to answer that question was to be fluent enough in the language to inspect the machinery directly. So fluency became a proxy for competence, and eventually the proxy got mistaken for the thing itself. People started treating "can read a diff" as a moral virtue rather than a means to an end.
Once verification stops requiring that fluency — once a build produces its own record of what it tested, what passed, what a reviewer agent flagged — the proxy stops being necessary. You're back to the actual question. Does it work. Can I trust it. We built verification records into every build specifically because that question needs an answer that doesn't route through "did a human read the source," because for most builders that was never going to happen anyway, prompt or no prompt. Nobody was reading their WordPress plugin's PHP either.
Where the skill actually went
It went into specification, and specification is harder than it sounds. Watch someone write a genuinely good build prompt and you'll see the same discipline a senior engineer applies to a design doc: what's the acceptance criteria, what's explicitly out of scope, what happens on the edge case where the cart is empty at checkout, who can see this data and who can't. A vague prompt produces a vague app for the same reason a vague ticket produces a vague pull request — garbage constraints, garbage output, no model involved required to make that true. The people shipping well with AI tools aren't skipping the thinking. They moved it earlier, into the fifteen minutes before the first message instead of the two hours after the first error.
The rest of the moved skill is judgment at the review layer, which looks less like reading code and more like reading a build's summary and its verification record and asking the right skeptical question. Does "handles payment refunds" actually mean handles the case where the refund fails halfway through? Did it test the empty state or just the happy path? That's a real skill, and it's teachable in a way that "learn to read Python" was only teachable to a subset of people who had the time and the aptitude for it. I've watched a shop owner with zero programming background ask sharper verification questions about their own inventory app than plenty of engineers ask about code they didn't write, because they know their business and they know exactly what breaking looks like for them. That's not a lesser skill standing in for the real one. For their build, it's a more relevant one than syntax ever was.
The story that actually justifies the mockery
Now the concession, because the critics aren't inventing this out of nothing. There's a genuinely bad version of vibe coding, and it's common enough that the mockery has a real target. It's the person who builds a login system, sees a green checkmark, and ships without ever asking what data that login system can reach or what happens when a request comes in with no token at all. It's shipping a database query built from a natural-language prompt without checking whether user input reaches it unescaped. The verification record can tell you the build ran and the tests passed. It cannot tell you the tests covered the right thing, and it will not stop you from deploying anyway if you don't look at it.
That's the floor that doesn't move, no matter how good the tooling gets: you are still responsible for knowing what "done" needs to mean for your specific build, and for actually reading the record instead of trusting the checkmark on faith. Skipping that isn't a new kind of competence. It's the old kind of carelessness wearing a new outfit, and it deserves exactly the reputation it's getting. The mistake critics make is assuming that's the only mode available — that because the failure exists, the discipline can't. It can. It just doesn't look like what discipline used to look like, and people who've only ever measured competence by syntax fluency don't have a way to see it yet.
Give it a few more years and the word will probably fade the way "hacker" narrowed from "clever tinkerer" to something scarier and then loosened back up again. What'll be left is the actual distinction, the one that mattered the whole time: builders who specify carefully and check their work, and builders who don't. The tool they used to get there was never really the point.
