Pace and Burnout in the AI Era: Where the Saved Time Actually Goes

Turn this article into takeaways for your work.
Each assistant summarizes the article only for you and suggests best practices for your work.
AI was supposed to reduce workload. For most workers, it has raised the tempo instead. Seventy-seven percent of employees say AI tools have added to their workload, not subtracted from it, and the workers with the biggest AI-driven productivity gains report the highest burnout in the workforce. The mechanism isn't mysterious: faster output creates faster expectations, reviewing AI work is real cognitive labor that rarely gets counted, and the time AI saves gets reinvested into throughput rather than recovery. None of that means AI is worthless. It means the gains have to be designed for, or the pace consumes them.
If this matches what you're seeing on your team, you're reading the data correctly, not overreacting to a rough quarter. It's a load-management problem with visible mechanics, and mechanics can be redesigned.
Key Facts
- 77 percent of employees say AI tools have added to, not reduced, their workload; 47 percent don't know how to hit the productivity gains their employer expects (Upwork and Workplace Intelligence, July 2024).
- 39 percent say they now spend more time reviewing or moderating AI-generated content, a direct measure of the verification tax workload planning leaves out (Upwork and Workplace Intelligence, July 2024).
- Among workers with the highest AI-driven productivity gains, 88 percent report burnout, and they are twice as likely to consider quitting (Upwork and Workplace Intelligence, July 2025).
- 80 percent of the global workforce lacks the time or energy to do its job, and knowledge workers are interrupted roughly every two minutes during core hours, about 275 times a day (Microsoft 2025 Work Trend Index; Microsoft WorkLab, June 2025).
- 40 percent of workers online at 6 a.m. are already triaging email, and nearly 29 percent still active at 10 p.m. are back in their inbox (Microsoft WorkLab, "Breaking Down the Infinite Workday," June 2025).
- The WHO classifies burnout in the ICD-11 as an occupational phenomenon with three dimensions: exhaustion, cynicism toward the job, and reduced professional effectiveness, from chronic workplace stress never successfully managed (WHO, May 2019).
- Workers who consistently have enough time to do their work are about 70 percent less likely to report high burnout, the single most direct lever in Gallup's original burnout research (Gallup, 2018).
Expectation Inflation: The Tool's Speed Becomes the New Baseline
The first mechanism is the simplest and the easiest to miss while it's happening. Before AI, a first-draft report took a day. With AI, it takes twenty minutes. The natural next step, the one almost every team takes without discussing it, isn't to bank the saved hours. It's to expect the report by end of day instead of end of week, because the tool made that speed possible.

This is expectation inflation: the ceiling of what AI can produce quietly becomes the floor of what a person is expected to deliver. Nobody announces a new policy for it to happen. A manager sees one fast turnaround, assumes it's now the standard cycle time, and plans the next request against that assumption. Multiply that across a dozen requesters and a worker is expected to operate at machine-adjacent speed on every task, not just the one where AI actually helped.
The trap is that the speedup is usually real for a narrow slice of the task, drafting, summarizing, first-pass code, while the surrounding work (understanding the request, checking the output, handling exceptions) doesn't compress at the same rate. Expectations inflate to match the fastest visible step, not the average of the whole job. That mismatch is a large part of why the AI productivity paradox exists at the company level: individual steps get faster, but the workflow around them wasn't redesigned, so the gain gets eaten by expectation creep instead of showing up as slack.
The Verification Tax: Checking AI's Work Is a Job Nobody Scheduled
The second mechanism is heavier and far less visible in how work gets planned. Every piece of AI output that matters has to be checked: for accuracy, for tone, for the wrong assumption buried in paragraph three, for the citation that doesn't say what the summary claims. That checking is real cognitive work, different from either drafting the thing yourself or approving a trusted colleague's draft.

Decades of research on human supervision of automated systems explain why this checking is so taxing. Raja Parasuraman and Dietrich Manzey's review of automation complacency and bias found that monitoring an automated system competes directly with a person's other tasks for limited attention, and that this complacency shows up in experienced experts just as much as novices, it isn't solved by practice alone (Parasuraman & Manzey, "Complacency and Bias in Human Use of Automation," Human Factors, 2010). Verifying AI output asks a person to hold two contradictory postures at once: trust the system enough to use its output efficiently, and stay skeptical enough to catch it when it's confidently wrong. That split attention is the real cost of any human-in-the-loop design, and it is more draining than either producing the work from scratch or reviewing a known-reliable colleague's draft, because the error rate and error location are both unpredictable.
Why the tax is invisible in workload planning
Nobody puts "review AI output for hallucinations" on a task list or a time estimate. It gets absorbed into whatever line item the output feeds into, so a manager sees "wrote the client proposal" and assumes the AI draft made that line faster, when in practice a meaningful share of the time went into checking, correcting, and re-checking the draft. Upwork's research puts a number on this: 39 percent of workers say they now spend more time reviewing or moderating AI-generated content than before, time that shows up nowhere in a capacity plan built around the old, pre-AI task list. Keeping human judgment sharp covers the skill side of staying a good verifier; this is the workload side of the same problem, the hours that verification quietly consumes.
The Infinite Workday, Now With an AI Accent
Microsoft's Work Trend Index research describes a pattern it calls the infinite workday: the average knowledge worker is interrupted roughly every two minutes during core hours, about 275 times a day, across meetings, email, and chat, and the workday itself has lost its edges. Forty percent of people online at 6 a.m. are already triaging email, and nearly 29 percent of active users are back in their inbox at 10 p.m. Eighty percent of the global workforce says it doesn't have enough time or energy to get its job done. Meetings are a large share of that interruption count on their own, which is part of why redesigning meeting culture is one of the few interventions that reduces raw interruption volume rather than just shuffling it.
AI enters this pattern from two directions that mostly cancel out. An AI assistant can draft the email or clear a backlog item in seconds, which should shrink the workday. But AI output also arrives faster and more constantly than a human collaborator's would; an agent can finish a task and hand it back for review at 11 p.m. as easily as 11 a.m., and the norm becomes "check it when it's ready," not "check it during work hours." The infinite workday was already a boundary-erosion problem before generative AI; AI-produced work landing at any hour, expecting the same review speed, tightens that erosion. The fix overlaps with how AI reshapes communication norms, since this pressure arrives through the same channels where "read" quietly means "respond now."
Why Faster Cycle Times Can Mean Less Recovery, Not More Slack
This is the part that trips up otherwise careful workload planning. The intuitive assumption is: if a cycle that used to take a week now takes two days, the freed-up five days become slack, recovery time, or room for deeper work. In practice, faster cycle times usually get reallocated to more cycles, not more rest, because throughput is the metric most teams are actually measured on.

Think of it as a queue, not a task list. If a support team resolves tickets twice as fast with an AI assistant, the queue doesn't sit empty, it refills, because request volume was never capacity-constrained by human speed alone, it was constrained by whatever generates the requests: customer volume, sales pipeline, internal demand. Compress the service side of that loop and, absent a deliberate decision to bank the gain as recovery time, the system defaults to processing more of the same queue at the same intensity, just faster. Output goes up. Rest time does not. That's the mechanical reason a genuinely faster process can still produce burnout: speed without a designed stopping point just moves the person to the next item sooner, indefinitely.
The AI productivity paradox shows the company-level version of this: individual speedups that don't survive contact with an unredesigned workflow. Pace and burnout is the individual-level version of the identical failure. Both come from treating a local speedup as if it automatically becomes organizational slack, when in fact slack has to be a deliberate design choice, not an assumed side effect.
Supervising Several Agents Is Its Own Kind of Load
A newer version of this problem shows up as teams start running more than one AI agent at a time: one drafting content, one triaging a queue, one monitoring a dashboard, each needing a different kind of human check-in at a different cadence. This looks like delegation, and in one sense it is. But supervising multiple semi-autonomous processes is a genuinely different cognitive task than doing focused work on one thing, and it inherits the well-documented cost of task switching.
Gloria Mark's research at UC Irvine, tracking real office workers across their actual workdays, found that after a single interruption it took an average of over 23 minutes to fully return to the original task at the same depth of focus (Mark, Gonzalez & Harris, "The Cost of Interrupted Work," CHI 2008). People compensate by working faster after each switch, but that shows up as measurably higher stress, not free recovery. Managing three agents that each need a check every twenty minutes isn't three times lighter than managing one large project; it can be heavier, because each check-in is a context switch with its own reentry cost. From doer to orchestrator covers how this reshapes the individual contributor role; the load-management version is treating "agents to supervise" as a cost, not a free multiplier on output.
Genuine Relief vs. Load Displacement
Not every use of AI raises load. Some genuinely removes drudgery with no offsetting cost: formatting a spreadsheet, transcribing a call, generating boilerplate nobody was reviewing line by line anyway. What matters for workload design is whether the saved time was reinvested as recovery, or displaced into a less visible form of work.

| Where the load actually went | Why it's invisible in workload planning | What to do about it |
|---|---|---|
| Verification tax (checking AI output for errors, tone, wrong assumptions) | Absorbed into the task's existing time estimate; nobody schedules review as its own line item | Add a review-time allowance to any task with an AI first draft, and track it for a few cycles before assuming it nets to zero |
| Expectation inflation (fastest visible step becomes the new floor) | Happens informally, through requester assumptions, not a written policy anyone can revise | Set and communicate an explicit standard cycle time per task type, independent of the tool's top speed |
| Infinite workday creep (AI output arriving and expecting review at any hour) | Framed as flexibility rather than an always-on obligation, so it doesn't register as added load | Define response-time windows for AI-generated work, the same way a team would for human-generated requests |
| Queue refill (faster cycle time absorbed into more volume, not more slack) | Throughput metrics reward the refill; nobody measures the recovery time that didn't happen | Decide in advance what share of a speedup gets banked as capacity versus converted to throughput |
| Agent-supervision switching cost (context switching across monitored processes) | Looks like delegation, coded as "less work," not as attention-splitting work | Cap how many agents one person actively supervises, and batch check-ins instead of scattering them |
| Genuine relief (drudgery removed with no meaningful review burden) | Not invisible; this is the case that shows up honestly as saved time | Protect it. Don't let a real win get reabsorbed into more volume by default |
Workload Design Responses That Actually Work
Fixing this isn't a matter of using AI less. It's a matter of treating the categories in that table as workload variables that need explicit decisions, the same way headcount and deadlines already get explicit decisions, and it's squarely a job for the middle manager, whose role is already changing under AI.
Budget verification time as its own line item. If a task now includes an AI-generated first draft, the time estimate should include a separate allowance for review, not an assumption that drafting time simply shrank. Track actual review time for a month before setting that allowance; guessing tends to undercount it badly.
Set cycle-time standards independent of tool speed. Decide deliberately what the expected turnaround is for a given deliverable, and hold that standard even when the tool could technically go faster. This is the single fastest way to stop expectation inflation from becoming the default.
Give AI-generated work the same off-hours boundaries as human-generated work. If a colleague's 11 p.m. message doesn't require a same-night reply, a report an agent finished at 11 p.m. shouldn't either. Write the norm down; unwritten norms default to whatever's fastest, which is usually worst for recovery.
Decide in advance how a speedup gets spent. Before a tool ships that compresses a cycle, name the split: how much saved time becomes throughput, and how much becomes protected recovery or deeper work. Left undecided, the answer defaults to 100 percent throughput, because that's what gets measured. This connects directly to performance management when AI does part of the work, since it changes what a fair workload looks like.
Cap and batch agent supervision. Treat the number of AI processes one person actively supervises as a real capacity constraint, the same way a manager caps direct reports, and batch status checks into scheduled reviews instead of letting each agent interrupt independently.
Watch for load displacement disguised as relief. When someone reports a tool "saved a ton of time," ask where that time went. If the honest answer is "I took on more work," that's throughput, not relief, worth naming before it becomes the unspoken new normal.
None of this requires a large program. It's a handful of explicit decisions made in a single planning conversation, decisions currently being made by default, silently, in the direction that favors more throughput and less recovery every time. Making them on purpose is the whole fix. This is a workload-design problem, not a culture problem; for the norms and trust side of working alongside AI, see burnout culture and workslop, effort, and ownership.
A workflow layer that logs how long review steps actually take, rather than assuming they compress along with drafting, makes the verification tax visible instead of guessed at. Neither replaces the manager decisions above; it just makes the invisible parts of the table measurable.
A speedup with no destination defaults to more work. Pick the destination first.

Co-Founder, Rework.com
On this page
- Key Facts
- Expectation Inflation: The Tool's Speed Becomes the New Baseline
- The Verification Tax: Checking AI's Work Is a Job Nobody Scheduled
- Why the tax is invisible in workload planning
- The Infinite Workday, Now With an AI Accent
- Why Faster Cycle Times Can Mean Less Recovery, Not More Slack
- Supervising Several Agents Is Its Own Kind of Load
- Genuine Relief vs. Load Displacement
- Workload Design Responses That Actually Work