In Defense of the Vibe Coder: the future has more builders, not fewer.

Let me make the critics' case better than they usually make it, because there is real substance in it.

A vibe coder ships an app. It works — for them, on the happy path, in the demo. Underneath, the auth flow has a hole you could drive a truck through. Secrets are committed to the repo. There are no tests, so the next change silently breaks the last feature. The database has no backups. When it falls over at 2 a.m., nobody knows why, because there's no logging and the person who “wrote” it can't read half of it. Multiply that by the thousands of people now shipping AI-built software to real users and you get the critics' nightmare: a generation of fragile, insecure applications built by people who don't know what they don't know.

That is not a strawman. I've reviewed code exactly like it. So have you, if you do this for a living. The failure mode is real, and it shows up often enough that the people sounding the alarm are not imagining things. Hold onto this section — I'm going to come back to it honestly near the end, because the answer is not to pretend it doesn't exist.

Here's where it goes wrong. The sneer treats “vibe coder” as a level of competence, when it's actually a method of production. Those are different things, and conflating them is the whole mistake.

Insecurity is not a property of building with AI. It's a property of building without a discipline — and that has been true since the first CGI script. Plenty of computer-science graduates ship insecure code; a credential is not a security control. The .env committed to the repo, the missing rate limit, the auth check that runs on the client and trusts the browser — these are gaps in process, not gaps in IQ, and they appear in code written by people with twenty years of experience. They're the boring, learnable stuff that Vol. 02 is entirely about.

What's genuinely new is that AI removed the syntax barrier to the front door. It did not remove the discipline barrier to the production-readiness bar. So we now have a lot of people standing somewhere they couldn't reach before — inside a working application — without the operational habits that the long, painful path used to install along the way. The critics see people in the building who didn't take the stairs and conclude they don't belong. The right read is: the elevator works now, and the job is to teach people what to do once they're on the floor.

None of this is new. Every abstraction layer in the history of software arrived to the same sneer, from the same people, for the same reason — and every one of them expanded who got to build.

The pattern is exact. A new layer lowers the barrier. The people who paid the old, high price to get in call the newcomers unserious. Some of the new work really is junk— that part of the sneer is always true. And then the layer wins anyway, because expanding the pool of people who can build produces far more value than the junk costs. The gatekeeping is never wrong about the junk. It's always wrong about the future.

Here's the thing the gatekeepers miss in every wave: the bottleneck on software was never the typing. It was the translation tax.

The person who understands the problem — the nurse who knows why the intake form is wrong, the logistics manager who can see the routing inefficiency, the underwriter who knows which fifteen questions actually matter — has almost never been the same person who can build the solution. So the idea had to survive a game of telephone: domain expert to product manager to engineer to code, losing fidelity at every hop, taking months, costing a fortune, and dying outright if it wasn't already big enough to justify the overhead. Most good small ideas never cleared that bar. They weren't bad. They were just too expensive to be worth building the old way.

Vibe coding collapses that chain. The person with the problem can build the solution directly — and often builds it better than a contractor would, because they're not working from a secondhand description of a domain they don't live in. The thing that used to die in the backlog now exists by Friday. That isn't a degradation of software. It's the removal of a tax that was quietly killing most good ideas before they were ever born.

I see it every week. The most useful internal tools are increasingly built by the person who felt the pain, not by an engineering department three priorities away from it. They're rough. They also work, get used, and solve a real problem that would otherwise have waited two years for a sprint that never came. Tell me which one is more “serious.”

So are these things viable? It's the right question, and it deserves a precise answer instead of a vibe.

Viability has nothing to do with the origin of the code. A function doesn't get more secure because a human with a CS degree typed it, and it doesn't get less secure because a model suggested it. Viability is about one thing: whether the software clears the production-readiness bar for what it actually does. That bar is real, and it doesn't move based on who's building. A weekend toy gets a low bar. An app that takes payments and holds customer data gets a high one. Same as it ever was — it's the entire subject of Vol. 03.

Here's the part the pessimists miss: the cost of clearing that bar just fell, for everyone, through the exact technology they're sneering at. The same AI that helped write the code can write the tests, harden the auth, add the logging, explain what a CSRF token is and where you're missing one, and walk a non-engineer through a security checklist they'd never have known to run. The bar didn't get lower. The ladder got cheaper. A motivated vibe coder in 2026 can get a piece of software across a real production bar faster than a credentialed engineer could a decade ago — if they know the bar exists and choose to clear it.

That “if” is the whole game. Which brings me to the honest part.

I'm not going to end by telling you it all just works out. The failure mode from section one is real, and the reason it persists isn't stupidity — it's that you can't review your way out of a gap you can't see. The dangerous bug isn't the one you're worried about; it's the one you don't know is a category.

And here a model will only take you so far. It will help with the security question you ask. It will not reliably volunteer the one you didn't know to ask — partly because it's trained to be agreeable rather than adversarial, which is its own whole essay (Vol. 07). Working the AI well is a real skill — the loop, not the tool, as Vol. 04 argues — but even a tight loop has a blind spot exactly where you have one. That blind spot is the same one that has always justified a second pair of eyes, in every era of software, for every kind of builder.

So the close isn't “go get a computer-science degree.” That's just gatekeeping with a syllabus. The close is this: the discipline is a finite, mostly-checklistable set of habits, and the fastest way to install them is to borrow them— from the AI for the things you know to ask, and from a human who does this for a living for the things you don't. Not a gate. A calibrated read at the moment it matters: before real customers, before payments, before regulated data.

That's the entire reason Hamilton Ridley exists, and why this series is free. We're not here to tell vibe coders they shouldn't have built it. We're here because they should have— and because there's a known, bounded distance between “it works for me” and “it's safe to put in front of the people I'm building for.” Closing that distance is a skill, not a credential. You can start with a free, calibrated read of your own code — a Quick Score— and decide for yourself whether the gap is where you thought it was.