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 didn’t understand the system enough to build it, you probably don’t understand it enough to maintain it without significant time investment. It’s true, but history has shown us that this isn’t an obstacle to change.

My argument here is that nobody wants to maintain software. In fact, nobody wants software per se; 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 I can get some tangible benefit from the app.

The most recent example of nobody caring about what’s underneath is the evolution of programming languages themselves. I grew up in the age of Assembly, 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.

.model small
.stack 100h

.data
message db 'Hello, world!$'

.code
main:
    ; Initialize data segment
    mov ax, @data
    mov ds, ax

    ; Print the string
    mov ah, 09h
    lea dx, message
    int 21h

    ; Exit program
    mov ah, 4Ch
    mov al, 00h
    int 21h

end main

The first abstraction I learned was C, and that was way easier than Assembly — 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, resistors, capacitors, maybe transistors, 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 behaviour directly, you could encode it.

The result of moving to chips was that electronics became cheaper, smaller, more powerful, but 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. Despite these drawbacks, chips are almost entirely the way we build things these days.

Software Is Going the Same Way

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

For a long time, serious software culture has worshipped maintainability: documentation, tests, abstractions, architecture, and documentation. Pull requests that had comments like “minor fix” would end in a blood feud. This made sense because software was expensive to build much more expensive to maintain.

But if building gets cheap enough, the economics change. For a huge amount of everyday business software, the thing may not need to be beautiful or to even last very long. It needs to solve this week’s problem without requiring a six-month procurement process and a nightmare (this is the correct collective noun) of consultants. For example a campaign microsite that dies after launch week, a dashboard built for one operational question, or some data cleaning tool to be used once.

These are not edge cases. These represent the swamp where most software work lives.

The Maintenance Problem Moves Up a Layer

The obvious retort is, “Ffine, 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 pour-over coffee and feeling morally superior.” Sounds like an easy paycheck, but that’s not the world we live in.

The answer is that maintenance becomes another agent task. Rather than pour over the ugly logs, broken tests and long, disorganised code, you just hand it to another agent. The key, as usual, is in good prompting — not just saying “It’s broken,” but passing a whole stack trace, reminding the agent of the expected behaviour, and giving boundaries to “Fix this without breaking that.”

This still will produce weird patches and bad code. But it’s faster than waiting three weeks for a human to figure out the context, and dealing with their grumbling in the process.

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.

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.

Disposable Software

I don’t like disposable electronics, but I don’t mind disposable software. Build it, use it, and move on.

Transitioning to the idea of disposable software is a little like moving from letters to emails. There was a time when people felt a need to archive every email — or even print them out. Those days, happily, are long gone!

Disposable software will still create waste: energy, money, security problems, and problems with archiving and evidence. But we’ll still go in that direction.

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.