Why 'Vibe Coding' Fails in Mission-Critical Systems

Let me start by defending vibe coding, because I do it too. On a Saturday, for a toy, it is one of the best things to happen to software in years. Andrej Karpathy, who named the practice, described it honestly: you let the model write, you accept what comes out, you run it, and if it seems to work you move on, steering by feel rather than by reading. For a weekend project that nobody depends on, that loop is fast, cheap, and genuinely joyful. I am not here to take that away from anyone.

The problem starts the moment you point that exact posture at a system where money or lives depend on the output. The loop that made the toy delightful is the loop that quietly builds a liability. Nothing about the model changed. What changed is the stakes, and vibe coding has no answer for stakes.

The posture that works for a toy is the one that fails in production

Karpathy's definition is precise, and the precision is the point: accept what comes out, and if it seems to work, move on. "Seems to work" means the happy path ran once. In a toy that is the whole test. In a payroll system, a clinical scheduler, a settlement engine, "seems to work" is the beginning of the questions, not the end. What happens on the input you did not try? On the edge case the model never considered because you never described it? On the day the requirement changes and someone has to alter code that no human ever read?

Generated code that nobody has read is debt at minute zero. Not debt that accrues over years of neglect, debt that is already there the instant it ships, because the gap between what the code does and what anyone understands about why is maximal on day one. The only documentation is that it ran. And "it works, don't touch it" is the epitaph of every system that later becomes impossible to change.

LLMs guess syntax brilliantly. That is not the hard part.

Here is the distinction the market keeps blurring. A large language model is extraordinary at syntax. Give it a function signature and it will produce plausible, idiomatic, well-formed code faster than any human alive. That is real, and I use it every day. But syntax was never where mission-critical systems fail.

They fail in business logic: the rule that this discount never applies to that customer tier, that this transaction must be reversible, that this record can never be deleted, that this threshold is a hard stop and not a suggestion. That logic is not a matter of plausibility. It is a matter of determinism. It must be exactly this and not approximately this, on every input, forever. A model that guesses is the wrong tool for a requirement that cannot be guessed. Where the output governs money or safety, plausible is not a synonym for correct, and the difference is the whole job.

The net is human-authored, or it is not a net

This is where test-driven development stops being a preference and becomes the mechanism. The human writes the tests that encode what the system must never do, and writes them deterministically: given this, the result is exactly that, no negotiation. Then the generated code has to pass them before it ships. The model can draft as fast as it likes; the tests are the gate, and a human authored the gate.

That inverts the vibe-coding loop completely. You are no longer steering by feel and accepting what comes out. You have written down, in advance, the boundaries the output is not allowed to cross, and the machine's speed is now spent trying to satisfy constraints you own rather than producing constraints nobody set. TDD is the human net under the machine's productivity. Remove it and there is no net, only velocity toward a cliff you cannot see.

Supervised copilot, never autonomous agent

So the shape of the answer is not "use less AI." It is governance. The model drafts and does the tedious parts at ten times the pace. A human reads the diff and decides what enters the system. The tests are the net, and the human writes the ones that matter. Module boundaries are held on purpose. And for every meaningful piece, one human can tell you why it is the way it is. That is a supervised copilot. It is not an autonomous agent, and the difference is not ideology, it is where accountability sits.

Look at the numbers everyone quotes quietly. Depending on the survey, only around one in eight AI agents that companies build ever reach production. The interesting part is that the model on the failed side is the same model as on the shipped side. The gap is not quality of generation. It is the absence of a human who owns the architecture, who can hold the boundaries and answer for the result. AI multiplies an engineer who owns the system. It cannot replace one, because the single thing it cannot produce is accountability.

The debt everyone worries about is the effect. Unsupervised vibe coding is the cause. Governed AI, with a human who owns the boundaries, is the fix. That is the entire argument, and it resolves into one practical question for anyone about to buy software.

The fork in the road

There are two things on offer that look identical from the outside and are opposites underneath. One says: the AI does everything, walk away, sign the cheque. The other says: the AI does an enormous amount, at speed, and a named human owns the result. Same models on both sides. Completely different thing being sold.

So when you are buying, ask the one question that separates them. Who is the human accountable for what the AI produced? If your vendor can name that person, and can tell you how the boundaries are held and how the net is authored, you are on the governed side. If they cannot, you already know which side you are on, and you are the one who will inherit the debt.