Where did the rest go?

A couple weeks ago, I travelled from Cork to SREcon ‘26 EMEA in Dublin - my first SREcon in about a decade. There, I felt a sense of community and mutual fatigue amongst my peers. On day two, I attended a talk by John Allspaw and Stuart Rimell: “Incident Response and AI: The Hard Parts” - and I left with a lot more to think about than just incident response.

A room of tired engineers

It started with a question from the speakers: “Raise your hand if you’re tired”. And a field of sprouting hands responded.

And we’re not alone in this feeling - researchers at BCG have dubbed it “AI brain fry”: the mental fatigue from using and overseeing AI beyond what our meatsack brains can hold. From their survey of nearly 1,500 US workers, 14% said they had it. The survey covered a broad swathe of occupations, but developers using coding agents were amongst the people describing it.

My theory: the same pitfalls Allspaw and Rimell spoke about with regards AI tools in Incident Response are the same stacked causes contributing to AI fatigue in general. The first is what Cognitive Systems Engineering (CSE) calls the leftover principle. The second is the law of stretched systems. The third is the cost of switching between parallel threads of work.

To quickly define “tired” as I’m going to talk about it: “Tired” can mean morale, job worries, a fading sense of craft.All real, and probably feeding each other. This post is only about cognitive load: why a day with agents can leave your head fuller than a day spent writing the code yourself.

Admittedly, the evidence is thin because most of it is from the last year, self-reported, and not exactly peer reviewed. I’ll try to flag where it’s solid and where I’m just joining the dots!

Where did it all go Pete Tong?

My hypothesis depends on the work having changed shape since we introduced LLM codegen tooling, so let’s dig into that first.

A two-wave survey of professional engineers by Vella and Blincoe asked people about their work six months apart - in late 2024, and spring 2025. Bang in the middle of the “Assistant Era” and not yet the agentic era, so I’m looking at it more as a lower bound on how much has changed. 82% of participants reported spending less time writing code than they did before, and the authors call what replaced it supervisory engineering work: directing, evaluating and correcting AI output. Sounds familiar.

Oddly, 84% reported productivity gains at both time points. Yet among the 95 who answered both times, the share reporting a worse developer experience in at least one dimension nearly doubled, from 14% to 27%. Flow and cognitive load took the hit. Faster, and worse off in exactly the ways you’d expect if the work had got denser.

Earlier this year, a controlled experiment also agrees. AI assistance cut workload and time, but fatigue and stress rose across tasks in both groups, and fatigue climbed more steeply in those using AI. A “verification load” measure (failures, time to first compile, code churn, pauses and switches) partly accounted for that rise. It’s a partial explanation, from one session of short Python tasks, with assistants rather than agents.

The work has moved from authoring to supervising, and supervising appears to cost us something. What we haven’t explained is why it costs more.

The leftovers

In 1983, Lisanne Bainbridge wrote five pages called “Ironies of Automation”. Her thesis: designers who try to remove the human from a system still leave them with whatever they couldn’t figure out how to automate. That’s an arbitrary pile of tasks, usually including watching the automation and taking over when it fails. The irony is that an operator in that role needs to be more skilled, not less, while getting less practice.

Erik Hollnagel set this approach out as the left-over principle: automate everything you can, and humans get the remainder. He set it against two alternatives, the compensatory principle (give each job to whoever’s better at it) and complementarity (design humans and machines to work as one system).

Allspaw and Rimell brought the idea to incident response, and it maps neatly onto our day jobs: Automate the easy work first and people are left with the hard, messy work, with less of the practice that built their judgement. An accompanying idea, the substitution myth, is the belief that you can swap a person for an agent and nothing else changes. Spoiler - it does: creators become verifiers, authors become reviewers, and new work appears (prompting, shaping the environment, checking output). If you’ve ever added “never push to main” or “check the imports exist” to a system prompt, congrats that’s supervision work.

So with coding agents, the leftovers are specifying, deciding, reviewing and coordinating. Not exactly the restful bits.

One thing to be straight about. None of these sources say the work we automated away was restful. Bainbridge and Hollnagel are about what’s left, not about what’s missing.

What we took out

My proposal: Writing code use to be slack in the human system, time to breathe and recover.

To pre-empt the objection: Coding isn’t mindless, but I do think that a lot of the time it can be quite meditative and absorbing. So I don’t mean it was easy. I mean it was self-paced, low-variance cognitive work: effort you mostly controlled, with a steady rhythm, wedged between the spikier tasks like architecture, research, reviews and untangling what a stakeholder meant. It was lighter in variance, not in effort, and that’s what let us recover.

The closest direct evidence comes from an eight-month study at a 200-person tech firm (Ranganathan and Ye, UC Berkeley). Employees using AI worked faster and took on more, and the work seeped into what the authors call “moments that used to function as pauses”. One firm, qualitative, and the authors describe it as in-progress research, so I wouldn’t lean on it too hard. But it’s the only study I found that watched slack disappearing.

Before and after: coding as slack between high-demand tasks

If you’ve read anything of mine before, you probably aren’t surprised by this, as in 4d6 Psychic Damage I wrote about Kurt Vonnegut refusing to order a hundred envelopes online and going out to buy a single one instead, because the errand was the point: the people, the dogs, the passing fire engine. Computers, he reckoned, would do us out of that. We’re dancing animals, after all. Slow typing and slow builds were never as charming as a walk to the shop. But I suspect they share something: a bit of inefficiency that was quietly doing a job nobody explicitly asked of it.

We’re not just inefficient CPUs

The second half of my hypothesis is that agents don’t just take over writing the code - they also let us run several different threads of work at the same time, and we pay the overhead of context switching.

Sophie Leroy’s research on attention residue shows that when you switch tasks, part of your attention stays behind on the old one, and your performance on the new one suffers, especially when it’s demanding. Mark, Gudith and Klocke found in a lab experiment that interrupted people speed up to compensate, but pay for it in stress, frustration, time pressure and effort.

Context-switching cost across parallel agent threads

BCG’s survey adds a hint of a ceiling: perceived productivity rose with up to three AI tools in use at once, then dipped.

The law of stretched systems

The leftover principle is only half of the story, the other half is David Woods’ law of stretched systems - when something improves a system (such as new technology), it gets used to push the tempo and intensity up to the new limit, not to build in headromo.

Allspaw and Rimell pointed to a 1983 book on household technology, More Work for Mother: washing machines and tumble driers didn’t free up time, expectations of cleanliness rose. Then email, then Slack, then replies in minutes. Their restaurant example was cautionary: prep automation means four line cooks do the job of six, so you cut two, add tables, and a dropped batch of sauce on a busy Friday brings the whole system to a crashing halt. Fewer people, no slack, and one wobble becomes a meltdown.

The agent-era evidence for this is at least as good as for the leftover principle. BCG notes that some firms are rewarding token consumption as a proxy for performance. And a chapter by Rayo, Morey, Grøtan and Woods (2026), which the talk showed on a slide, describes four pressures squeezing organisations towards rapid AI adoption:

top-down (management wants cost savings),
bottom-up (front-line workers weaving AI into critical work),
outside-in (competitors’ narratives that you must adopt it),
and inside-out (staffing cuts that make AI necessary to cope with the overload).

I think the two ideas complement each other - The leftover principle explains the kind of work you’re left with: dense, high-cognition, hardly any gaps. Stretched systems explains how much of it you end up with. Together they’re a decent account of why a productivity gain can leave you more tired.

Other candidates deserve a mention. It could be transitional: IBM’s small interview study found most people said fatigue eased after a calibration period, though Vella and Blincoe saw experience getting worse over six months. Sleep loss, job insecurity and plain throughput are all plausible contributors too. I’m not ranking any of these. I’m guessing they stack.

What would change my mind

I’m not an academic, and anything I find is my own armchair research. So what I failed to find, our would love to see are the below:

A within-person study where people delegate code-writing but their workload, hours and number of concurrent tasks stay constant, and fatigue doesn’t change. Though that would point to stretched systems having more of an impact over the leftover principle.
Evidence that agent fatigue fades for most people within a few months of steady use.
Experience-sampling data showing pre-AI coding blocks didn’t lower momentary fatigue any more than meetings or reviews did.
A controlled comparison where one agent versus several makes no difference to fatigue at matched output.
Fatigue that tracks job insecurity, mandated AI metrics or sleep loss better than it tracks the share of supervisory work.

What I’m going to try

With everything above, I do so desperately want to not be tired any more, so here’s some stuff I’m going to be trying:

Deliberate slack. Scheduling low-demand gaps between the heavy tasks instead of hoping they appear.
- Nearest evidence: a micro-break meta-analysis (small effects).
- Watching for: how I feel at the end of the day, and fewer afternoons spent re-reading things.
Batched, structured review. Review agent output in dedicated blocks, with small diffs and a checklist, rather than as pings arrive.
- Nearest evidence: the interruption-cost research (Mark et al.).
- Watching for: fewer interruptions, and whether review quality holds.
Better handoffs. Ask the agent to summarise where it is, what it ruled out and what it’s unsure about, so each switch costs less. This borrows from Allspaw and Rimell’s “common ground” and Leroy and Glomb’s finding that a short ready-to-resume plan eases switching.
- Watching for: how long it takes me to re-orient after a ping.
Limits on parallel threads. Start at two, not five. BCG’s three-tool dip is a rough anchor, not a rule.
- Watching for: whether output holds while fatigue drops, and whether threads get abandoned.
Bank the gains as time. A question I took away from the talk: when an agent helps us recover faster, do we shorten the targets and shrink the team, or keep some slack? I’d like to try the second.
- Nearest evidence: the Berkeley study’s finding that gains turned into intensification.
- Watching for: whether the time really stays ours, because that’s the hard bit.

Letting the rest back in

Obviously, this is just my hypothesis that we’ve unintentionally removed much-needed slack for the humans in our engineering systems. If the hypothesis holds up, though, the fix isn’t to abandon agents: It’s to design the rest back in on purpose, and acknowledge its importance.

Vonnegut could buy his one envelope because nobody was timing the trip. Most of us are being timed now: by dashboards, by expectations, by our own excitement. So I’d think of these bets as small, quiet protests against stretching our humans. A gap left empty. A thread not started. An afternoon given back. Not a full revolution, just a few envelopes.

Table of contents