Verification fatigue: why checking AI work all day wears people out

By eleven in the morning, a contracts lawyer has read fourteen first drafts she did not write. Each one is mostly fine. The clauses are in the right order, the defined terms are consistent, the liability cap matches the term sheet. Somewhere in draft nine, a governing-law clause quietly switched jurisdictions, and she caught it. She is not sure she would catch it in draft twenty-three, at four in the afternoon, and neither is anyone else.

We wrote earlier about the shift from creator to verifier: as agents take on first drafts, the human job moves towards judging and signing off. That piece was about the skill. This one is about the cost. Checking work all day is more tiring than making it, and almost nobody has designed a job around that fact.

Making work gives some energy back, checking mostly takes it

Anyone who has written a decent paragraph or fixed a stubborn bug knows the small lift that comes with it. Making something has its own rhythm: you struggle for a while, and then something exists that didn't before. The effort is real, but it pays a little back as you go.

Verification has no such loop. You read with suspicion, and suspicion is tiring to hold. When the work is right, nothing happens: you confirm and move on. When it's wrong, you have to find exactly where, and then decide whether the rest can still be trusted. The reward for a good check is the absence of a disaster nobody will ever hear about.

There is a second difference. When you make something, you carry a model of it in your head as you build. When you check someone else's work, you have to reconstruct that model from the outside, from cold, every time. A support lead reviewing forty drafted replies is not reading forty emails. She is rebuilding forty customer situations in her head, then deciding whether each reply fits the one she rebuilt.

The better the drafts get, the harder the job becomes

It would be natural to assume verification gets easier as the machines improve. In one sense it does: there's less to fix. In the sense that matters to the person doing it, it gets harder.

When a draft is wrong one time in three, you stay alert, because errors keep turning up and rewarding your attention. When it's wrong one time in fifty, your attention has nothing to feed on. Studies of radar operators in the Second World War found that people watching for rare signals get worse at spotting them as a watch goes on. The name for it is vigilance decrement, and it describes the modern reviewer uncomfortably well. Rare errors are exactly the ones a tired person misses.

Add automation bias, the well-documented tendency to accept a machine's output because a machine produced it, and you have a combination that should worry anyone running a review process. The reviewer is tired, the errors are rare, and the tool has been right all week. Approving starts to feel like the job.

The usual failure in verification, then, comes from careful people in a job whose structure slowly trains the care out of them.

Nobody wrote this job description

Look at how most teams adopted AI drafting. Someone found a tool that produced first drafts quickly. The drafts went to the people who used to write them, now relabelled as reviewers. Their targets stayed the same or went up, because surely checking is faster than writing.

Per item, it is. Across a day, the arithmetic changes. A paralegal who used to draft six contracts and now reviews thirty hasn't been given less work. She has been given a more draining kind of work, at five times the volume, with the same lunch break. Her manager sees throughput rising and assumes the change has been absorbed. What has actually happened is that the hard part of the job has been concentrated, and the parts that used to rest the mind in between have been removed.

Writing used to contain its own breaks. Looking something up, a call to confirm a detail, the dull formatting at the end: from the brain's point of view, none of that was wasted. It was recovery built into the work. Take it out and you get a day of pure judgement, which nobody can sustain at quality.

The engineering version is familiar to anyone who has watched a pull-request queue grow. An agent can open more changes in an afternoon than a senior engineer can review properly in a week. Either the reviews get shallower or the queue gets longer. Usually both, and the senior engineer starts to quietly resent a tool that was supposed to help her.

What a well-designed verification job looks like

Checking has to continue. Unchecked output is how a wrong governing-law clause ends up signed. What needs to change is that verification gets treated as work that deserves design, the way factories eventually learned to design inspection instead of leaving it to whoever stood nearest the end of the line.

A few principles go a long way:

• Cap the run. Long uninterrupted stretches of review are where attention decays, so break the day up and let checking alternate with making, calls, or anything that uses a different part of the mind.
• Check hard where it matters and sample where it doesn't. A drafted reply about delivery times and a drafted reply about a disputed refund should not get the same scrutiny.
• Make the machine show its working. A draft that flags what it was unsure of, cites a source for each figure, or lists what it changed from the template turns a cold read into a targeted one.
• Plant known errors. Seeding a review queue with deliberately flawed items gives attention something to find and tells you whether the review is still working.
• Rotate reviewers and measure misses as well as throughput. If the only number on the dashboard is items approved per hour, you are paying people to stop looking.

None of this is exotic. Quality control has looked like this in other industries for decades. Office work simply never needed it, because the person checking a contract was usually the person who wrote it.

The manager's half of the problem

Most of the fatigue in a review-heavy team is invisible from above. Output goes up, error rates look fine for a while, and the cost arrives later as a resignation, a sick day that becomes a fortnight, or one expensive mistake that everybody agrees should have been caught.

Managers have to account for it on purpose. That means asking reviewers how they feel at four o'clock, not just counting what they approved by then. It means accepting that a team reviewing AI output may need to handle less of it per person than the demo suggested. And it means resisting the obvious temptation to spend the whole productivity gain on higher targets, when part of that gain has to go back into keeping the checkers sharp.

There's a status question too. In many teams, writing was the respected work and checking was the junior's chore. If verification is now most of the job, it needs standing to match: senior people doing it, and credit for the errors someone caught as well as the output someone shipped. People will not stay alert for long in a role the organisation treats as a formality.

Keep some making in every job

The cleanest defence against verification fatigue is also the simplest: don't let anyone's role become pure checking. A support agent who writes the hardest replies herself and reviews the rest stays closer to customers than one who only approves. A lawyer who drafts the unusual clauses keeps her feel for what a good clause looks like, and that feel is precisely what makes her a good reviewer.

The reason is practical as well as humane. Verification depends on knowing what good looks like, and that knowledge comes from making things. Remove all the making and, a couple of years on, you have a team of reviewers who learned the work by approving it, which is a much thinner kind of knowing.

So when you plan the next rollout, put two numbers side by side: how much drafting the agent will take on, and how many hours of review that creates for a named person. If the second number fills her whole week, you haven't automated the job. You've moved the hardest part of it onto one desk.