A developer on one of my teams messaged me on a Tuesday asking how a discount rule should behave when two promotions overlapped. Reasonable question. The spec didn’t say.
I was between meetings, so I dropped the thread into a model and asked for a short clarification. What came back was clean and confident — three sentences, one worked example, the kind of thing that would have taken me fifteen minutes to write properly. I skimmed it, thought yes, that’s about right, and sent it.
It wasn’t about right. The example resolved the conflict by applying the higher discount, which sounds sensible and was not what our product lead had decided in a conversation the model knew nothing about. The developer built it. QA tested against my clarification instead of the ticket, so it passed. It surfaced two days later when the product lead saw it in staging and asked, quite reasonably, who had signed off on that.
Now, if you work in engineering you’ve already spotted something: QA should never have been testing against a Slack message from me. That’s a process problem and it’s mine, and it predates any of this. But it had never cost us anything before, because before, a clarification from me took fifteen minutes to write and carried fifteen minutes of my thinking. The gap was always there. The model just found it.
The build, the test cycle, the rollback, and then a long conversation to establish that nobody had actually decided anything. Half a day, spread across four people, none of whom did anything wrong.
I saved four minutes.
Everyone has noticed. Nobody has quite named it.
You’ve read a version of this already. Stanford and BetterUp called it “workslop.” Glean called it “botsitting.” Sage and IDC published a white paper titled The Verification Tax. Holweg and Davenport wrote it up in HBR as “knowledge decay.”
Those aren’t four names for the same thing, to be fair — workslop is about receiving bad work, botsitting is about the labour of making the tool usable, knowledge decay is what happens to the org afterward. But four adjacent coinages in nine months usually means people can feel something they haven’t located yet.
And I think the reason is that almost every version of this gets told as a personal-discipline story. You are moving too fast. You aren’t checking carefully enough. Here’s a framework for reviewing AI output before you send it.
Fine as far as it goes. But it isn’t what happened on my Tuesday. I wasn’t careless in any interesting way — my carelessness was just suddenly much cheaper for me than it was for everyone downstream of me.
Follow the money, not the minutes
Here’s the detail that reframed this for me, buried in the workslop research: they tracked who sends it to whom. Around 40% moves between peers. Roughly 18% goes from direct reports up to managers. Another 16% flows from managers down to their teams.
So this isn’t really a story about individual time management. It’s a story about a cost that gets transferred — sideways or downward, usually to someone with less context and less standing to push back, and always after the productivity gain has already been booked.
To be fair to the numbers: Glean’s report says AI saved those workers about eleven hours a week against 6.4 hours of botsitting. Still net positive. Anyone telling you the savings are a mirage is selling you something.
But eleven hours landed in one column and 6.4 landed in another, and only one of those columns has a dashboard. That’s the actual problem — not that AI costs more than it gives, but that the gain and the cost land on different people, at different moments, in different parts of the org chart.
Penny wise, pound foolish. The old phrase is about money, and money at least gets recorded.
The part that worries me more
There’s a passage in the Glean report almost nobody has quoted. They describe what happens when the checking work stays untracked and unrewarded long enough: workers first stop fully understanding the output, then stop interrogating it, and eventually stop feeling responsible for it at all. They call it a slow surrender of agency.
They put a number on it too — around 28% of AI users admit to blaming AI for a bad output, rising to 41% among heavy users. I’d hold that one loosely, because heavy users produce more output and therefore have more opportunities to blame anything. But it points at something I’ve watched happen in smaller ways, and it’s this: if the verification work is invisible, it feels optional. If it feels optional, skipping it feels reasonable. And once skipping it feels reasonable, the output starts to feel like something that happened to you rather than something you did.
That’s the failure mode I’d worry about long before I’d worry about lost hours. Hours you can recover. A team where the tool is the responsible party is much harder to walk back.
Why “review it more carefully” doesn’t fix it
The obvious response is to tighten up. Mandate review, add a checklist, tell everyone to slow down and actually read what they’re sending. We tried a version of this. More on that in a minute.
There’s research that explains why it mostly doesn’t work. BCG looked at workers whose AI tools demanded heavy oversight, published in HBR earlier this year: those workers spent around 14% more mental effort and reported noticeably higher information overload. And the people carrying the heaviest cognitive load made major errors at a rate roughly 39% higher than their less-overloaded colleagues.
So verification isn’t a free action you can simply add more of. It draws on the same account as the work itself, and past a certain point, telling people to check more carefully produces more errors rather than fewer, because the checking is what wears them out.
Microsoft’s Work Trend Index puts the alternative in numbers: organisational factors like culture, manager support and talent practices accounted for about 67% of the AI impact they measured, against roughly 32% for individual mindset and behaviour. Two-thirds of this lives in how the work is designed. We’ve spent a year writing personal productivity advice about a structural problem.
What we changed, and what didn’t stick
The checklist didn’t stick. We wrote one — six items, sensible, everyone agreed to it in the meeting. It survived about three weeks. Nobody defected loudly; it just stopped being mentioned, the way these things go. My read is that it asked for effort at exactly the moment people had least of it, which is the BCG finding arriving in my own inbox.
What did stick was smaller and slightly embarrassing in its simplicity. Anything AI-assisted that goes to another person carries one line at the bottom saying what was checked and what wasn’t. Numbers confirmed, names not confirmed. It takes seconds. It works because it doesn’t ask anyone to do more verification — it just makes the amount you did visible, which turns out to be enough. Hard to drift quietly when you’re signing for it.
We also stopped celebrating time-to-first-draft, which had crept into a couple of our sprint reviews without anyone deciding it should. If the first version arrives in a tenth of the time and the thing still ships Thursday, nothing happened.
What I haven’t solved is measurement. I still can’t tell you what the displaced cost across my teams is, because it shows up as slightly slower reviews and slightly more confused handoffs and one extra meeting, spread across people who have no reason to connect it back to a source. I suspect it’s substantial. I can’t prove it, and I’m wary of anyone who claims they can.
But here’s the shift I didn’t expect, and the one I’d tell you to watch for if you lead engineers.
Code review has changed character. It used to be mostly correctness — does this work, does it handle the edge case, is this the right pattern. Increasingly what my reviewers are doing is archaeology: this code is locally fine, but why does it exist? What did the author intend? Was this deliberate or did the model just produce it? Reviewing something whose reasoning you can reconstruct is a different job from reviewing something whose reasoning was never there. It’s slower, and it’s more tiring, and it doesn’t look any different on a dashboard.
Nobody I know has a good name for that yet.
The medium-stakes trap
If you take one thing: the danger isn’t in the high-stakes work. Everyone’s careful with the contract and the production deploy. It’s the spec clarification and the status update and the internal doc — important enough that people act on it, unimportant enough that nobody checks, and specific enough that the reader can’t tell.
That’s where my Tuesday lived.
We spent a long time assuming the bottleneck in knowledge work was making things. Making things turned out to be the easy part. We’d simply been paying for it in a currency we could see.
The bill hasn’t gone away. It’s arriving in someone else’s name, and after a while nobody thinks to look for it.
Sources
- BetterUp Labs & Stanford Social Media Lab, “workslop,” Harvard Business Review, September 2025 — survey of 1,150 US full-time workers; just over four in ten had received workslop in the prior month, at roughly two hours per incident
- Glean Work AI Institute, Work AI Index 2026, June 2026 — 6,000 digital workers across the US, UK and Australia. Vendor-published; sample skews toward high AI adoption, seniority and tech-sector work
- IDC, commissioned by Sage, The Verification Tax: The Emerging Economics of AI in Finance, June 2026
- Holweg & Davenport on knowledge decay, Harvard Business Review, June 2026
- BCG on AI oversight and cognitive load, via Harvard Business Review, 2026
- Microsoft, Work Trend Index 2026, May 2026
