Are we becoming QA for the machine?

4 min read Original article ↗

Lars de Ridder

Press enter or click to view image in full size

I was calmly yelling at my CLI because the button wasn’t the same green as stated in `CODE_STANDARDS.md`, and it hit me: It turned me into its QA guy.

I had just built my first real application almost entirely with coding agents. The app worked. It came together faster than anything I’ve ever shipped. And somewhere in that process, without noticing, I stopped being the engineer.

The moment it shifts

Don’t get me wrong, it’s fun seeing your vision come alive this quickly. But that’s all you’re doing. You’re not engineering it. You’re testing if it does what you think it should do. What you didn’t bother writing down. That’s on me, I suppose.

Nobody has ever been able to properly spec a non-trivial piece of software. I don’t think that’s going to change anytime soon. So if agentic coding tools plateau here, I think this is what we become: we take whatever thought bubble we manage to capture from somewhere in the organization, refine it, put it in an agent, and keep iterating until we think it’s fine. Then we release it to prod, get feedback that it’s completely wrong, and iterate further.

I guess that sounds familiar. It’s what we’ve always done. Except now the middle part, the part that used to be the job, takes minutes instead of days.

Why am I so tired?

I found myself exhausted after these sessions, more than after a day of regular coding. I haven’t fully figured out why.

Maybe it’s trying to keep up with the machine. I’m not used to being the bottleneck in software development. I type fast, so my brain-to-code connection always felt near instant. But with Claude generating files per second across multiple sessions, I try to match that speed. I open multiple terminals with multiple agents doing multiple things, planning for conflicts between them. It’s like air traffic control, except you also designed the airport and you’re not sure if the runways are long enough.

Or maybe it’s the constant abstraction. You have to continuously discuss the concept, dig up what something is supposed to do, articulate what you’d like to see, instead of taking the time to make a part of it happen. There’s a specific kind of fatigue that comes from translating intent all day without ever touching the material yourself.

I’ve read this from others too. If you’re feeling it, you’re not alone.

The addiction loop

It’s addictive. Once you start, it’s hard to go back. And I think that’s a problem.

An exception in this codebase? Let’s just paste it in Codex. A bug report? Let’s ask Claude. Claude says something I’m not sure about? Let’s ask Codex what it thinks.

It doesn’t feel healthy. Sometimes I feel like I’m throwing random ingredients in a pot, hoping to pick out something edible. The feedback loop is so tight that you never have to sit with a problem long enough to actually understand it. You just keep throwing it back at the machine.

And the agents keep getting more capable. Persistent memory. Actions. Personalities. OpenClaw is proof of the demand, how a “don’t ask, just do” philosophy generates a storm. But when I step back and look at my own workflow, I also wonder: where does this end? What am I actually getting better at?

So, are we?

Not exactly. But we won’t be what we were either. The job used to be building the thing, crafting it from minute details up to something grand. Like a carpenter building a house beam by beam, fitting every joint, feeling where the wood resists. Now it’s more like snapping together prefab walls; the house goes up faster, but you never really held the wood. It’s not just QA. But it’s closer to QA than to engineering, and I think we need to sit with that for a minute.

The craft is changing. I’d rather be honest about that than comfortable.

This is part two of my experience vibecoding Tether. Part one: Lessons from vibecoding my first real app. If this resonated, I’m writing more at @theRedbeardIO.