AI Made Us Reviewers. Reviewers Burn Out.

Tue Oct 20 2026

In July I wrote about running a development process where agents write 100% of the code. I listed what's better and what hurts. Three months later, the thing that hurts most wasn't on either list.

It's not the async tax. It's not the small changes that got slower. It's the people. Engineers who used to build things now spend their day reading: task definitions, agent plans, diffs, AI-written summaries, documentation, more diffs. They are reviewers now. And reviewers, it turns out, burn out in a way that builders don't.

Generation stopped being the hard part

Two pieces from July say the same thing from different angles.

Martin Fowler's Fragments post from 21 July summarizes the Thoughtworks Future of Software Development retreat. The first headline finding: "Code generation is no longer the bottleneck — verification is." The second: "harness engineering", the discipline of building the rigs and guardrails that let you trust agent output, is becoming a job of its own. Third on the list, and the one I keep coming back to: organizations "are colliding with a real apprenticeship crisis."

Two days later, Gergely Orosz reported in The Pragmatic Engineer what engineering leaders were telling him: the bottleneck of building software had moved "from coding to the review phase." Models write more and better code, reviewers haven't gotten faster, and the result is a queue. The sentence that stopped me was this one: "Too much thorough code review is burning out engineers, and resulting in sub-par code reviews." And its consequence: developers can no longer "review code with intent", and if the AI reviewer has no comments, "they just approve it."

Both pieces count pull requests. Neither one talks about what it feels like to be the person the queue lands on. That's the part I want to add, because I'm watching it happen.

What it feels like

Here is the loop, from the reviewer's side.

You write a task. It takes minutes, and it's satisfying: you're deciding what gets built. The agent goes away. A while later a result lands: a plan, a diff, a summary of what it did and why, often a few hundred lines of prose and code. Now you read. Reading is slow. Deciding is slower. And somewhere in the second or third of these in a row, you notice you don't want to.

The closest thing I can compare it to is scrolling a short-video feed. Short bursts that feel like progress, then a crash the moment you have to stop and think. I'm not going to claim to know what the brain is doing, and I'd keep the word "dopamine" out of it. But the shape of the day is real: fast, rewarding generation alternating with slow, draining verification, all day, every day. Writing code for eight hours was tiring. This is tiring in a different way, and the difference is that the tiring part is now the only part.

Two panels. Left, Generating: minutes, feels productive, fast and rewarding. Right, Reviewing: hours, almost right, read everything and decide everything. Headline: AI made us reviewers. Reviewers burn out.
The reviewer's day: a fast, rewarding half and a slow, draining half. The draining half is the one that grows.

It's worth separating this from what Andrej Karpathy named "vibe coding" in February 2025. His definition was honest: "fully give in to the vibes, embrace exponentials, and forget that the code even exists", and "I 'Accept All' always, I don't read the diffs anymore." That mode has no reviewer. Nobody burns out, because nobody reads. Our process is the opposite: we read everything, because the code ships to production for paying customers. The whiplash I'm describing comes from living between those two modes. The tool invites you to stop reading. The job requires you to keep going.

A paper from 1983 predicted this

Lisanne Bainbridge published "Ironies of Automation" in Automatica in 1983, about industrial control rooms. Swap "operator" for "engineer" and "automatic process" for "coding agent", and it reads like a retrospective of the last year.

Her first irony: automate the easy parts of a job and the human is left with the hard parts, which are now harder because the easy parts were what kept them in practice. Her second: the human's remaining job is to monitor that the automation is working, and humans are bad at that. Quoting her directly, on vigilance research going back to 1950: it is "impossible for even a highly motivated human being to maintain effective visual attention towards a source of information on which very little happens, for more than about half an hour." Her conclusion was blunt: "it is humanly impossible to carry out the basic function of monitoring for unlikely abnormalities."

That is a precise description of reviewing agent output. Most of it is fine. The job is to find the part that isn't. And the Stack Overflow 2025 Developer Survey tells you what the part that isn't looks like: the top frustration with AI tools, named by 66% of developers, is "AI solutions that are almost right, but not quite." Almost right is the worst case for a monitor. Wrong is quick to reject. Right is quick to accept. Almost right forces you to read all of it, carefully, with the attention Bainbridge says you can't sustain past thirty minutes. Only a third of the same respondents said they trust the accuracy of AI tools, which is another way of saying they know they have to.

Bainbridge's third irony is the apprenticeship crisis from the Thoughtworks list, forty years early. Skills "deteriorate when they are not used", so "a formerly experienced operator who has been monitoring an automated process may now be an inexperienced one." A junior who has only ever reviewed agent output never becomes the senior who can tell when it's wrong. And her final irony is the one that should worry anyone running a mature agent pipeline: "it is the most successful automated systems, with rare need for manual intervention, which may need the greatest investment in human operator training."

It has been measured, at least in outline

A CHI 2025 paper from Carnegie Mellon and Microsoft Research, by Hao-Ping Lee and colleagues, surveyed 319 knowledge workers and collected 936 first-hand examples of using generative AI at work. Their finding is the shift I'm describing, measured outside software: effort moves "from information gathering to information verification", "from problem-solving to AI response integration", and "from task execution to task stewardship." In their words, as workers move from execution to oversight, "they trade hands-on engagement for the challenge of verifying and editing AI outputs."

They also found the failure mode Orosz's leaders described: higher confidence in the AI is associated with less critical thinking. The reviewer who trusts the tool stops reading with intent. The paper opens by citing Bainbridge for exactly this reason: automate the routine, leave the exceptions to the human, and you "deprive the user of the routine opportunities to practice their judgement."

Put those two findings next to each other and you get the part that should worry a CTO more than the wellbeing argument. The way a tired reviewer copes is to trust the tool more. That's not a character flaw, it's the only move left at four in the afternoon with six diffs in the queue. And trusting the tool more is precisely the behavior that lets almost-right code through. Burnout and rubber-stamping aren't two problems. They're one curve, and the review process degrades along it silently, because an approved PR looks the same whether someone read it or not. The cost shows up weeks later, as an incident, with no line connecting it back to the afternoon the reviewer stopped reading with intent.

Where I'd push back, including on myself

In July I called "the process runs unattended" the win that changes the economics. I still think that's true. What I underestimated is that the time it gives back doesn't go to building. It goes to reading. The hours came back and some of the motivation left with them. That tension is the honest version of the story, and I'd rather write it than pretend the July post had it all.

Some fairness is due the other way too. This is one team in one transition, and other engineers describe the opposite: more flow, less drudgery, and relief at never writing boilerplate again. Part of what I'm seeing may be transition cost. Reviewers do get faster, and the tooling for reviewing agent output, as opposed to human output, barely exists yet. Orosz lists a dozen AI review tools and says the solutions "feel more like experiments." And none of this is an argument for going back. The process is faster than any team I've managed without it. The argument is that "faster" has a human cost line that nobody is putting in the spreadsheet.

What I'd change

Bainbridge wrote her remedies for control rooms, and most of them translate directly.

  1. Give engineers hands-on time, on purpose. Her suggestion was to "allow the operator to use hands-on control for a short period in each shift." For us that means every engineer still writes some code by hand, every week, not as a treat but because it's the only thing that keeps the judgment you need to review. Review is a skill you keep by building.
  2. Cap review the way you'd cap on-call. If half an hour of sustained attention is the limit, a six-hour review day is a plan to miss things. Rotate who reviews, bound it, and treat reviewer load as a metric next to PR throughput, because one is the cost of the other.
  3. Make the agent pay for the reader's attention. The agent should lead with the why and the risk, not a wall of what it did. If a diff can't be summarized in a way a reviewer can verify in a few minutes, that's a signal the task was too big, not that the reviewer is slow.
  4. Move verification out of people's heads. Fowler's retreat calls this harness engineering; Orosz calls it verification over review. Tests, contracts, characterization suites, observability. Every check a harness makes is one a tired human doesn't have to. It is, as Orosz says, easier said than done. It is also the only fix that scales.
  5. Keep the apprenticeship. Juniors need to build things, with the tool off sometimes, or there are no seniors in five years. Thoughtworks called it a crisis. Bainbridge called it an irony. Either way, it's a hiring plan.

Generation got cheap. Verification didn't, and it never will, because it's done by people. The bottleneck moved to the reviewer, and the reviewer is the one part of the system you can't scale by adding tokens. Plan for them.

References