There is a German expression for what is happening in our profession right now: die Spreu vom Weizen trennen, separating the wheat from the chaff. The AI era is doing that sorting, and it starts with output rather than with people. Generating something costs almost nothing now, so an enormous amount of what lands on your desk is bloat: well formatted but not load bearing. But every piece of output has a name attached to it, so the sorting does not stay on the output for long.

That draws a new line through our work, and it is not the line between developers who use AI and developers who refuse to. Almost everyone uses it now. The line runs here: between AI output that removes work from the team, and AI output that creates it.

As a freelance tech lead, I am on the receiving end of the second kind regularly, mostly as pull requests waiting for my review. It rarely announces itself as bad work. It usually arrives looking quite good.

There is even a word for it now. Researchers at BetterUp Labs and Stanford found that 41 percent of workers had received “workslop” in the past month: output that looks finished but is not, costing the receiver about two hours each time. Forty-two percent trusted the sender less afterwards.

Two Pull Requests, a Story

The first pull request implemented number localization. It worked. The numbers rendered correctly in the UI. But when I asked where the locale came from, whether from the user’s account setting, the browser, or the country stored on the record next to the amount, it was clear the question had never come up.

There was an intention, of course: localize the numbers. What was missing was the decision underneath it. The first two format the number for whoever is looking at it. The third formats it for whatever it describes. Those are different products, and the choice is architecture that every locale-dependent feature inherits. The agent had made it silently, and it surfaced in a review comment thread, the most expensive place for an architectural decision to appear.

The second pull request added multi-column sorting to data tables that previously sorted by one column. Also working. Then two questions.

When you sort by last name and then by first name, what does priority mean here? Does the second column sort within the groups of the first? The answer was not clear to the author. The implementation was correct, as it happens, and that is the part I keep thinking about. The agent had written code whose behavior exceeded its author’s mental model of it. That is genuinely new. Code you do not fully understand used to be code you inherited. Now it can be code you wrote this morning.

The second question: how does a user see which column is primary and which is secondary? There was one arrow per sorted column, identical for both. No numbering, no order badge, no double arrow. You can still operate a multi-sort like that, but you cannot reliably predict what it will do, which is an odd property for a feature whose entire job is ordering.

Neither of these is a hard problem. Both would have surfaced from thinking about the feature instead of the prompt. They surfaced in review, which means they cost two people instead of one, plus a round trip, plus the delay.

You Are Not the Meat in the Middle

A role is quietly emerging on a lot of teams, and it is not a good one. A ticket comes in from the product owner. It goes into the agent. The output comes back. The PR gets opened. Done.

If a developer’s contribution to that loop is forwarding the ticket into the agent and forwarding the output into a PR, then the loop is getting their latency and their name on the commit, but none of their judgment. That is the meat in the middle. And people usually end up there for structural reasons rather than lazy ones: the sprint is full, the ticket was vague, the output looked right, and nothing in the process ever asked them to have an opinion.

But the judgment does not disappear just because nobody supplied it. It relocates. It lands on the reviewer, who now has to reconstruct not just what the code does but what it was meant to do, and whether anyone had an opinion about it at all.

This is what makes AI-generated work different from ordinary sloppy work. Sloppy work looks sloppy and you can send it back in ten seconds. AI-generated work is fluent, formatted, plausible, so the reviewer has to read all of it carefully before they can tell whether anything is behind it. The cost of evaluating the work is now higher than the cost of producing it. That inversion is the entire problem.

And this is not a junior developer problem, which is what I assumed when I first started noticing it. I catch myself doing it constantly. Writing the extra document costs me nothing now, so I write it. The exhaustive test suite nobody asked for, the abstraction I added because it was free, the four paragraph explanation where one would have done. Producing it is free for me. Reading it is still expensive for everyone else. That asymmetry is new, and I do not think any of us have built the habit for it yet.

Spend the Surplus on the Other Person

AI hands you a surplus. The only question is who you spend it on.

I keep watching it go the wrong way. A frontend developer needs something from the backend team, so they generate a Jira ticket: twelve sections, acceptance criteria, a proposed architecture, edge cases, produced in a minute and now somebody else’s reading assignment. The intention is generous. The effect is a wall of text to mine for the two sentences that matter.

Here is the same surplus spent in the other direction. Write the ticket short and in your own words: three sentences on what you need and why. Then use the agent for the part you could never have afforded before. Pull the backend repository, read how the existing endpoints are shaped, and open a draft PR with a first attempt. Say plainly that it is a starting point and that you may have misunderstood their domain. You have just given a colleague a head start instead of homework.

The same holds outside of code. Twenty AI-generated slides sent to five people is a hundred slides of collective reading for content nobody committed to. Five slides and a short call is better on every axis, including for you, because a call gives you objections you can answer.

None of this is an argument against agentic coding. I am about as deep into it as anyone.

The argument is that the constraint has moved. Producing is cheap now, so producing is no longer where the value is. What you add is the part that does not compress: knowing what you want, deciding what needs deciding, and standing behind what you ship.

So now I run one test before I send anything, and it catches almost everything: would I be glad to receive this? If a teammate sent me this ticket, this PR, this deck, would I feel helped or would I feel assigned?

The developers who thrive in this era will not be the ones with the highest output. They will be the ones whose output other people are glad to receive. Everyone else is generating work and calling it productivity.