Pick your 40 lines on purpose

600 lines in, 40 lines read

Your agent just finished. It changed 600 lines, you scrolled for a minute, read about 40 of them, and clicked approve. Be honest: you've done this. Who checked the other 560?

Anthropic's Claude Code team has the same problem at a scale none of us have. They published how they handle it, and it's one of the more useful things I've read this year, because it isn't really about code. It's about what to do when the machine produces more than a person can read.

The numbers first, as Anthropic reports them. Changes to their main repository went from about 2,500 a day in May to more than 30,000 a day in September. Between June and September the number of merged pull requests more than doubled, and the share they had to roll back fell by more than 40%. They stopped reading everything. Fewer mistakes got through.

Two changes, one morning

Take the same agent on the same morning. Change one fixes a typo in a readme. Change two touches the auto-updater, the code that installs new versions on everyone's machine.

If both go through identical review, you're wrong twice. You over-check the typo, or you under-check the updater. So the team stopped asking "did a person read it?" and started asking "what could go wrong with this change, and which check catches it?" Everything below is the answer to that question.

Layers, in plain words

The work starts before anyone is asked to look at anything. The agent has to run the tests, the build and the style checks, and show the output. Not "done." The actual output. A claim costs nothing to make. A test run that passes is evidence, and a person can glance at it in seconds.

Then a second agent reads the change with fresh eyes, with none of the author's assumptions in its head. Think of a colleague who wasn't in the meeting.

When the change is proposed, several agents hunt for bugs at the same time, and a separate group votes on each finding. A bug only gets posted if enough of them agree it's real. Comments that are only about taste get dropped. Whatever survives is tagged Important, Nit or Pre-existing, so a problem that was already there doesn't get pinned on you. A security review and the usual automated checks run too, and any open finding blocks the merge until someone fixes it or answers it.

Then risk decides who looks

Here's the part I'd steal first. A classifier reads each change and assigns a tier. Docs, copy and flagged additive changes are low risk: once the automated and security checks pass, no human has to approve. Medium risk needs one person. High risk needs two.

Two rules keep it honest. An agent's approval never counts as a person's. Your agent can't sign its own permission slip. And whoever asked the agent to make the change counts as one of the required reviewers, exactly as if they'd typed it themselves. You can't hand off the responsibility along with the work.

So the typo merges before lunch with nobody else looking. The auto-updater waits in someone's queue with its evidence attached, and that person reads it properly.

The twist: agents reviewing agents can loop

As soon as a machine reviews a machine, you get a new failure. The reviewer flags a nitpick, an agent fixes it, the fix is a new change, the new change gets reviewed, and the reviewer finds something else. One change to their command-line tool went through more than fifty review rounds overnight.

The fix is almost funny in its simplicity. After three rounds, the reviewer stops patching and asks the author to reconsider the approach. Anthropic reports that changes needing five or more rounds fell from 8.9% to 1.5%, and changes passing in a single round rose from 65% to 78%.

If you've ever watched a draft go through its ninth round of small edits, you know the feeling. At some point the problem isn't the sentence. It's the paragraph.

Where a human still matters

What's left for people is what machines are bad at. Is this even what we wanted? That one lives in your head, not in the change, and AI reviewers rarely catch "this works but it isn't what you meant." Risky areas like billing. Reading the evidence itself. And owning the outcome.

There's also a quiet weakness. When the same kind of model writes and reviews, it can miss the same thing twice. Five reviewers agreeing is not five independent opinions if they share a blind spot. Treat these numbers as Anthropic's own measurements on its own repo, and the pattern as the thing worth borrowing. They also suggest a short REVIEW.md in your repo that says what failure looks like there. Claude Code has /code-review and /security-review commands if you want to try it.

Same discipline, no code required

None of this needs a developer. Every AI output has a typo and an auto-updater inside it.

A financial model: the formatting of the summary tab is the typo. The formula that turns revenue into cash, and the assumptions it hangs on, are the updater. Ask Claude to recompute the totals a second way and show you how they tie back to the source file. Then read those formulas yourself.

A contract summary: the background paragraph is low risk. Termination, liability caps, auto-renewal and payment terms are not. Ask for each of those with the exact clause quoted, so you can check the words against the page.

A campaign: a subject line typo is annoying. The discount percentage, the audience list and the send time are what actually hurt.

The move is the same every time. Demand evidence instead of "done." Sort by risk. Read the risky part on purpose.

Try this week

At the end of your next serious request, add: before handing it over, check your own work and show me what you checked and how. Then list the parts by risk: what's safe, what I must read myself, and where you're unsure. Read the second group closely and skim the rest.

Next time an agent hands you 600 lines, pick your 40 on purpose.