Vibe Coding and the Death of Giving a Damn

I’ve been thinking about this for a while, and I’ve decided I’m going to be blunt about it.

There’s a trend the industry has decided to brand “vibe coding.” The pitch goes something like: you describe what you want in plain English, an AI spits out the code, and you ship it. No need to understand what’s happening underneath. Just keep prompting until it works.

And look, I get the appeal. I genuinely do. The barrier to entry for building software has never been lower. People who couldn’t write a line of code six months ago are now shipping functional apps. That’s interesting. Parts of it are even exciting.

But something is being lost in the process, and almost nobody wants to talk about it.

The black box problem

When a non-engineer generates code with AI, they get a thing that (mostly) works. What they don’t get is any understanding of why it works. Or more importantly, how it fails.

I’ve reviewed code produced this way. It’s a specific flavour of bad. Not the kind of bad you get from a junior developer who’s learning (that kind of bad has logic to it, you can see what they were trying to do). This is structureless. Functions duplicated three times with slightly different names. Business logic scattered across files with no discernible pattern. Error handling that’s either completely absent or wildly paranoid in all the wrong places.

Spaghetti is generous. Spaghetti at least implies something continuous.

The person who generated it can’t explain it because they didn’t write it. They can’t debug it because they don’t know what it’s doing. They can’t extend it because they don’t understand the assumptions it was built on. It’s a black box that happens to produce the correct output right now, today, with the exact inputs they’ve tested.

Tomorrow? Who knows.

The bit people don’t talk about

Here’s what bothers me most. It’s not that the code is bad (bad code has existed forever, I’ve written plenty of it myself). It’s that nobody involved seems to care that it’s bad.

The whole culture around vibe coding treats the code as irrelevant. An implementation detail. “It works, ship it, move on.” And if something breaks, just prompt the AI again and bolt on another layer.

Slop on top of slop. You know what that gets you? More slop. A deeper, more confusing pile of code that nobody understands, built on assumptions that were never examined, solving problems that were never properly defined.

I remember, the feeling of solving a problem and then spending another hour or two making the solution better. Not because anyone asked me to. Not because there was a ticket for it, but because I could see a way to shave 40ms off a response time, or reduce a function from fifteen lines to six without losing clarity.

Each millisecond saved was a little hit of dopamine. That probably sounds sad to some people. I think it sounds like someone who gives a **** about their craft.

Pride in the work itself

There’s this idea floating around that only the end result matters. That the code is just a means to an end. And on one level, sure, the user never sees your beautiful abstraction or your elegant recursion. They see a button that does a thing.

But I’ve been at this for over a decade, and I can tell you with absolute certainty: code quality shows up in the product. Maybe not on day one. Give it six months. The app built on clean, thoughtful foundations scales smoothly when traffic doubles. The one built on vibe-coded spaghetti falls over, and rebuilding it costs five times what doing it properly would have.

Sometimes the journey matters as much as the destination. A senior engineer solving a problem isn’t just writing code that works. They’re thinking about edge cases, about what happens when the data looks weird, about how the next developer who reads this will understand what’s going on. That thinking is the value. The code is just the artefact.

Strip that out and you’re left with something that compiles. Congratulations.

The optimisation nobody asked for

I once spent an entire afternoon refactoring a data pipeline. It already worked. Tests all green. Nobody had complained. But the query pattern was nagging at me. It was doing four round trips to the database where one would do.

Four hours later, the response time dropped from 600ms to 90ms. The code went from 200 lines to about 80. Cleaner, faster, easier to reason about.

Was that “productive” by modern standards? Probably not. No new feature shipped. No user story closed. A project manager would have struggled to justify it in a sprint review.

But six months later, when that endpoint needed to handle ten times the load, it just… handled it. No panic. No production incident at 2am. No frantic rewrite under pressure.

That’s what caring about code quality buys you. Time. Resilience. Sleep.

What this means for Halfbyte Media

This is part of why I started this company. I’ve seen what happens when businesses get software built by people who treat code as disposable. They end up back at square one eighteen months later, paying someone to unpick the mess and rebuild it properly.

When we build something at Halfbyte Media, it’s built to last. Not because we’re precious about it, but because I’ve cleaned up enough disasters to know the difference between “done” and “done right.”

If you want something thrown together fast and cheap, there are plenty of options for that now. More than ever. But if you want software built by someone who actually understands what the code is doing, who thinks about what happens next month and next year, that’s a different conversation entirely.

I’m not anti-AI. I use AI tools daily. Claude 4.6 sits right there in my editor. But there’s a world of difference between a skilled engineer using AI to move faster and a non-engineer using AI to skip the understanding entirely. One of those produces good software. The other produces a time bomb with a nice UI.

I’d rather build things I’m proud of. Call me old-fashioned.

— Jason