Never Going Back Again (from Vibe Coding)

Ask any engineer what they think of vibe coding and you’ll usually get one of two responses: the eye roll, or the sermon. The eye roll says enough, and the sermon is a diatribe on spaghetti code, unmaintainable codebases, and the emotional damage of breaking down a stack you never built up in the first place.

Fair enough. I’ve seen what happens when someone asks a model to “just add auth” and comes back with a cursed lasagne of middleware, helpers, global state, and one mysterious function called maybeAuthenticateAgain() (“Maybe“?? I felt like screaming). Nobody is wrong to be suspicious.

But I’m making the boring, annoying, inevitable statement anyway: there is no going back.

Nobody Cares

The standard complaint about vibe coding is basically this: if you understand the system enough to build it, you probably don’t understand it enough to maintain it. It’s true, but history has shown us that this isn’t an obstacle to progress.

The obvious explanation is that nobody wants software; we want the result of software. I want the thing the software does. I want the process that makes life easier or more fun in some way. I care less about whether the codebase has a coherent model and more about whether the button works in a responsive manner.

The most recent example of nobody caring is the evolution of programming languages. I grew up in the age of Assembler, which was just one step beyond hard-coding hexadecimal instructions. It was fast, but really hard to read, and you had to think all the time about memory.

The first abstraction I learned was C, and that was way easier than Assembler — elegant, even. But I still had to think about memory… though I still didn’t, which is why my code crashed all the time.

Then came C++ with its classes, Java, and eventually all these other languages we know today like JavaScript, Python, and so on. With every evolution, languages become more computationally intensive, but much easier to use. Most programmers (see how old I am? I still say that, sometimes, rather than “engineer”) think much less about memory consumption or efficient code than they used to, and think more about the end result, and we’re all happier for it.

Electronics has followed a similar path. In the 60s and 70s, electronics still had a visible craft element. You could open up an appliance, a radio, or an audio device and actually see the work: wires, components, and solder joints. A human hand had been there, swearing quietly, if it was my hand.

Those things were not magic. They failed, too. But you could fix them. It had a kind of mechanical dignity.

Then integrated circuits entered the chat. More and more behaviour moved into chips, boards, firmware, and hidden logic. Instead of wiring every behavior directly, you could encode it. The result was cheaper, smaller, more powerful, and often less repairable. When a chip fries, you do not lovingly replace one transistor with tweezers, inhaling solder fumes. You swap the board. Or, more likely, you bin the whole thing and buy the next plastic rectangle.

Software Is Going the Same Way

Coding is going the same way with AI. We’re moving beyond languages and into prompts, design, and exploration of ideas, and thinking much less about architecture and what someone defines as good code.

For a long time, serious software culture has worshipped maintainability: documentaiton, tests, abstractions, documentation, architecture, and documentation. Pull requests with comments that begin “minor nit” and end in a blood feud. This made sense because software was expensive to build and painful to replace.

But if building gets cheap enough, the economics change. Not everywhere. Not for aviation systems, banking rails, medical devices, or anything where failure means someone gets sued into powder. But for a huge amount of everyday business software, the thing may not need to be beautiful. It may not even need to last very long. It needs to solve this week’s problem without requiring a six-month procurement process and a priesthood of consultants.

• The internal tool that only three people use.
• The campaign microsite that dies after launch week.
• The dashboard built to answer one operational question.
• The data cleaner nobody wants to maintain anyway.
• The prototype that becomes “production” because everyone is a coward.

These are not edge cases. These are the swamp where most software work lives. Not the glorious cathedral of computer science. The swamp. The swamp has budgets. The swamp has deadlines. The swamp is very interested in agents that can bash something together before lunch.

The Maintenance Problem Moves Up a Layer

The obvious retort is: fine, but what happens when it breaks? Good question. The answer is probably not “a senior engineer lovingly refactors the whole thing into clean hexagonal architecture while drinking black coffee and feeling morally superior.” I would enjoy that world. It is not the one we are getting.

The answer is that maintenance becomes another agent task. The code is broken. The logs are ugly. The tests fail, assuming tests exist, which is a generous assumption and possibly a hate crime against optimism. So you give the agent the repo, the stack trace, the expected behavior, and a boundary: fix this without breaking that.

Will that produce weird patches? Yes. Will some of them be bad? Absolutely. Will people still use it because it is faster than waiting three weeks for a human to rediscover the context? Also yes. The market has never needed a technology to be spiritually correct before adopting it. It only needs the technology to be useful enough and annoying in a cheaper direction.

The New Skill Is Not Typing Code

This is the part that makes engineers twitch, because it sounds like I’m saying engineering stops mattering. I’m not. I’m saying the scarce skill moves. Less time typing syntax. More time specifying intent, setting constraints, reading outputs, designing tests, understanding trade-offs, and deciding when the generated mess is acceptable versus when it is a loaded mousetrap made of YAML.

The person who can frame the problem clearly will get more leverage. The person who can inspect a system quickly will still matter. The person who understands product risk, data flow, security, and user pain will matter a lot. The person whose only identity is “I manually type the sacred brackets” is going to have a rough little decade.

Related: for the less gloomy version of this argument, read this earlier post about betting hard on the tools instead of pretending the wave is polite enough to stop. Going All In on AI

Disposable Does Not Mean Worthless

I don’t love the idea of disposable software. I don’t love disposable electronics either. I would prefer a world where everything is repairable, legible, durable, and built with care. I would also like a world where printers are not cursed goblin machines, but here we are, suffering in full color.

Disposable software will create waste. It will create security problems. It will create armies of half-working tools that nobody understands. It will also let tiny teams and solo operators build things that used to require entire departments. That trade-off is not clean. It is just real.

So yes, vibe coding will make messes. It will produce code that makes serious engineers stare into the middle distance. It will generate systems that should probably be taken behind the barn and gently deleted. And then it will generate the next version faster than anyone expected.

There is no going back to hand-wired software purity. The boards are sealed. The chips are cheap. The agents are already in the repo.