Escaping the joyless loop of AI creation

I don't remembner signing up to supervise robots

There’s a kind of techno-theatre going on right now in engineering LinkedIn. People call it “vibe coding”. It’s usually accompanied by a shiny dashboard and a 30-second screen recording that ends in applause. But here’s the truth: most of it is smoke and mirrors.

Let’s get real. AI doesn’t write good code. It writes plausible code. It guesses. Sometimes those guesses are decent, sometimes they’re nonsense. That’s not a bug; that’s what it was trained to do. So when you drop an LLM into your dev pipeline and expect a productivity revolution, what you get - if you’re doing it properly - is an experienced engineer checking every line. And if you’re doing it properly, that engineer is cross-referencing against documentation, test cases, edge conditions, and business context.

And when you do that? Yes, the productivity gains are there. The boring stuff flies by. Unit tests, boilerplate, translations, documentation snippets—AI’s pretty good at that. It’s like having a room full of junior engineers ready to churn out first drafts 24/7, and you’re just walking the floor checking their work.

Which sounds brilliant.

Until you realise what it really means: you’re walking the floor. You’re not building. You’re not creating. You’re supervising.

And here’s the rub: great engineers don’t get into engineering to supervise code. They do it because they love to build. The joy of creation, of staring down the blank file and making something out of nothing, is hard to beat. And when you replace that with a loop of “check, fix, confirm, repeat,” it grinds. Fast.

So yes, AI is like a room full of juniors, but let’s not pretend that senior engineers want to spend their lives cleaning up after interns.

That’s the heart of the challenge.

AI can be a powerful tool, but only if we use it to amplify the creative joy, not dull it. That means shifting the AI conversation away from “How do we automate more?” to “How do we get more satisfaction out of the time we spend?” It’s not just about productivity metrics; it’s about designing workflows that leave engineers feeling like they still own the magic.

We’re not quite there yet. Most AI tools are still built to optimize throughput, not experience. They’re productivity engines, not joy engines.

But they could be. And if we want to stop AI from sucking the joy out of creative work, that’s where the focus has to shift: not replacing the work, but elevating the humans doing it. Let the machines take the grunt work. Keep the spark for us.

Because otherwise, vibe coding becomes just that: a vibe. All flash, no feeling.

Let’s talk about why we create in the first place.

Professionally, most of my creativity is channeled into coding. Away from the office I make a lot of music and am working on a couple of novels, but that’s a separate story.

So let’s talk about how I create at work. When I started out I spent all my time coding in C. And I loved it. The challenge of getting things working and the satisfaction when they did. Then Visual Basic came out, and I dropped Borland C for UI work almost overnight. Not because VB was a “better” language—it wasn’t. C had the performance, power, and precision. But Visual Basic had something else: ease. Suddenly I wasn’t wrangling pointers just to get a button to align. I wasn’t hand-coding pixel offsets to center a label or calculating window positions in my head.

It was amazing. The UI just worked. Drag, drop, done. Want a form? Drop it on the canvas. Need an event handler? Double-click the button. You could think about what you wanted to build instead of how to juggle the plumbing. The low-level stuff was still there, and if you needed it, you went back to C. But for 90% of the job, Visual Basic removed the friction. It didn’t kill the joy of coding—it gave it room to breathe.

That’s what AI needs to become.

Right now, it’s like we’ve built an AI-powered Borland C++. It’s impressive, powerful, and vaguely terrifying. But it still makes you write your mallocs. It still hands you vaguely helpful guesses and expects you to clean up after it. And worse—it inserts itself into the part of the process that people enjoy the most: the creation.

Here’s the shift we need: stop thinking of AI as the junior engineer. Start thinking of it as the layout manager.

You don’t hire a junior to draft all your interfaces and ask you to debug them. You hire a tool to make it easier to lay things out so you can focus on how it feels, how it flows, and how it works. That’s what Visual Basic did: it took away the pain of UI layout so you could get to the logic. So the experience.

AI should do the same for creative work. Take the parts we all dread:

• The repetitive copy-pasting.

• The placeholder content generation.

• The fifty ways of rewording the same headline.

• The boilerplate tests.

• The draft emails.

• The asset resizing.

If we can offload that to AI—reliably—then the creative process starts feeling like creation again. Not just supervision.

But we’re not quite there yet. Most current tools still sit in the uncanny valley between helpful and hindrance. They need to be watched. Checked. Reviewed. They still carry just enough uncertainty that you can’t trust them to own a task from start to finish. So instead of freeing you up, they trap you in a loop of “Did it get this right?” And that loop is joyless.

We have to build tools that, like Visual Basic, just work—at least for the stuff that’s meant to be easy. That’s how we regain the joy. Not by pushing humans out of the loop, but by building tools so good they disappear.

So here’s the challenge: stop asking how we replace people with AI. Start asking how we make the work feel better with it.

When VB showed up, I didn’t feel threatened. I felt liberated. That’s the bar. Let’s build toward that.