When Using AI Stops Counting as Real Work

Have you noticed this too? No matter how good you are as a software developer, the moment you've used AI for even part of the work, your own work gets quietly devalued.

You sit for hours in front of the monitor, watching the terminal window where an agent is working, alert as a fox outside a rabbit hole, waiting for the exact moment the agent starts to go off the rails — so you can hit ESC before it does something you'll regret.

In between, the agent keeps asking questions, and you have to answer them as precisely as you possibly can. If you don't, five minutes and three units later you get the bill: the agent just assumed something, because it simply misunderstood you.

Often the biggest hurdle isn't that the question runs forty lines or more — it's that you have to ask a follow-up just to understand the question in the first place. Especially when a sub-agent has been working for an hour where you couldn't follow along, and suddenly there are facts in the world you have no idea about. It's one reason I actually prefer an agent to open a real terminal window for inter-agent communication, so I can read along there too.

Here's the flip side of the coin: the moment "the others" find out you use AI, it stops mattering from that point on whether you typed it yourself or an agent did. It no longer counts as real work.

I think a shift in thinking has to happen here.

Sure, the models keep getting better, and they can generate entire flows, games, or complex websites from a single long prompt. But there's a steep gradient in how good the models actually are -  proportional to how much material was available at training time.

Still, the result isn't uniform — at best it only mirrors the task you gave it. Much like handing a kid the instruction: clean your room, and once you're done you can go play. If it has to happen fast, everything ends up under the bed or stuffed in the closet, not actually put away.

It's no different with agents. We call it the feedback loop — a reward for the agent, or the lack of one, that it uses to judge its own work. In our case, that's unit tests, for example. If the task is "all unit tests must be green before a commit," the agent will happily take a shortcut built specifically so that exactly those unit tests turn green — which is a long way from proving the application actually does what we designed it to do.

A method an agent writes on its own is not the same as a method we describe precisely, with a fixed goal, and then let the agent type out. That's exactly where the difference lies.

Left to its own devices, the agent might reach for an array and search it with a for-loop. What we actually want is a linked list, a dictionary, or a B-tree. This is where the developer comes in. Only the one who steers the agent precisely gets what they actually wanted. This is exactly where the wheat separates from the chaff.

Can you see that from the outside? Not necessarily — and in a lot of places, performance simply doesn't matter these days anymore, sadly. Even if we no longer look at every single line of code, we know what we built by the end of the day, and that's ultimately what makes the difference.

The era of developers typing every line themselves is pretty much over, and the typing developer will eventually "go extinct" - even if plenty of people don't want to believe that yet. Especially in software development, the speed and the demands on new applications have risen so much that typists simply can't keep up over the long run.

There will certainly still be a need for a software engineer to look closely at core routines. But what percentage of the whole industry will that actually be?

---

Note on the Use of AI: This article was created with the "assistance" of generative AI. The content, technical statements, and conclusions have been reviewed and revised by the author. The author bears full responsibility for the publication.