A popular take is doing the rounds. Vibe coding is fine for toys, the argument goes, but it does not survive contact with the enterprise. I have spent twenty-five years inside that enterprise. I have helped deliver national systems in health and regulated public services, the kind where one bad release becomes an executive escalation by lunchtime. The rigour people invoke to dismiss AI-built software is often the first thing those same systems cut when the budget tightens.
I want to take the argument seriously, because the half that is right matters, and the half that is wrong is doing real damage.
The dichotomy flatters the wrong side
The case against vibe coding rests on a clean split. Impressive demos on one side, serious engineering on the other. Almost no real software lives at either pole. It lives in the long middle, where someone is trying to ship something that works under constraints they did not choose.
The enterprise is not a synonym for quality. It is a place where quality competes with delivery dates and the cost of a test suite nobody wants to fund. I have watched testing reduced under exactly that pressure, on systems with consequences far beyond anything a beginner ships from a laptop. The enterprise carries scars it does not advertise.
Early in my career, at a trade show I will leave unnamed, a salesperson on our stand closed a customer on a feature that did not exist. The fix was me, a full-time senior developer, building it live behind the partition while the pitch was walked slowly towards the moment it was needed. The man behind the curtain was real, and he had a compiler. This was no beginner with a clever tool. I was the rigour, and the rigour was a performance staged to hold a sale.
So when the enterprise is held up as the bar that AI-built software cannot reach, remember who staged the demo. No software, vibe-coded or not, follows the rigour it should. The bar slips the moment the pressure arrives, and the pressure always arrives.
What the new tooling makes cheap is what delivery cuts first
The honest objection to vibe coding is narrower than the slogan. A novice may not know which safeguards a serious system needs, and may ship without them. That is a real risk, and it is worth naming plainly.
But look at what agentic engineering now makes almost free. Full test-driven development. End-to-end coverage across the paths a user actually takes. Behavioural science and the psychology of the person on the other side of the screen, designed in from the first screen rather than retrofitted if the timeline survives.
These used to be luxuries. A traditional delivery, costed by the day, drops them the moment the plan slips, and the plan always slips. The marginal cost of doing the careful work has collapsed. For the first time the thorough option is also the fast one.
I can speak to this directly. Two of the products I have built, TenantSafe and ScoreView, serve UK social housing, a sector with statutory duties, an active regulator, and tenants who carry the cost when software is wrong. I stood the first working version of each up solo, in a fortnight of evenings, with end-to-end tests and the legislative edge cases handled. That fortnight was the MVP, not the finished article. Both have had months of hardening since: security work, a sharper proposition, interfaces rebuilt as real users arrived. The first version was built the way the slogan says cannot be done. What followed was built the way any serious product is, over months rather than a fortnight.
The risk is the operator, not the method
A beginner with no feel for a sound architecture is a genuine hazard. That has always been true, of every powerful tool handed to someone who has not yet learned to use it. That does not make the tool illegitimate. It makes the case for teaching the person and building safeguards into the work.
Take the strongest concern. In a large estate, one bad command does not break a feature, it triggers a cascade across business units. True. But that is an argument for rollback, audit trails, and access controls, not an argument about who or what wrote the line. Those guards are themselves quicker to stand up with the same tooling. The cascade is contained by process, and the process is more reachable than it has ever been.
We do not meet a sharp instrument by pretending it is not in the room. We train people to handle it, and we build the guards into the work so a mistake is caught before it ships. Generalising from the worst untrained user to the whole method is how a profession talks itself into irrelevance while the work moves on without it. The genie is out of the bottle, and guarding the empty bottle is not a strategy.
The scarce skill is real, and it is now teachable
Here is the strongest version of the enterprise argument, and it is correct. The rare skill is no longer typing code. It is understanding the systems that code has to survive inside: its dependencies and failure modes, the way one change ripples through a dozen others. The interesting work lives in that gap.
I agree. I have spent a career in that gap. What I do not accept is that the knowledge belongs only to those who took twenty years to acquire it the slow way. The safeguards can be taught. The patterns can be learned in months by someone motivated, with tools that now carry much of the load.
So educate, rather than dismiss. Show people the pitfalls, and the safeguards that keep a build honest. The alternative is to keep insisting the work requires a priesthood, right up until the congregation notices it does not.