When Claude writes 90% of the code, what is left for the humans?

On 15 October, Anthropic published an engineering post with a plain title: How the Claude Code team does code review.

The numbers in it are not plain. Changes landing each day in Anthropic’s monorepo went from about 2,500 in May to more than 30,000 in September. Claude writes about 90 percent of Claude Code’s own code. From June to September, merged pull requests to Claude Code more than doubled, and the share that had to be reverted fell by more than 40 percent.

The Hacker News thread ran to nearly 500 comments, mostly about tokens, cost and who will maintain all this code.

I read it for something else. Every fix in the post is a fix to the system: the reviewer, the checks, the rules. But under each one is a person deciding something, and most of those decisions are ones the rest of us make every day with much less help. Here are five, and the habit each one asks of you.

The short version

Each section below has one habit and one thing to try this week.

1. The “agreed, agreed, agreed” trap

The post has a section called “The scarce resource: human time and attention”. Its aim is to “preserve human time and attention for issues only humans can solve and make sure automated checks catch the rest.”

There is a reason attention runs out faster than we think. In a 2005 lab study of baggage-style searches, people missed about 7% of targets when half the bags held one, and about 30% when only one bag in a hundred did (Wolfe, Horowitz and Kenner, Nature). When almost everything you look at is fine, you stop seeing the thing that isn’t. Now picture a day of agent diffs that are almost all fine.

The same thing happens in conversation. Matt Pocock wrote it down on his /grill-me page: “The failure mode is passivity: answering ‘agreed, agreed, agreed’ for forty questions and coming out with a plan the agent wrote and you nodded at.” (We wrote about his talk here.)

I have done this. In August an AI described how I work, I agreed with every line, and threw it out the next day. When an agent sounds polite, structured and confident, nodding along feels like teamwork.

Anthropic’s answer is not to read harder. “We give Claude something it can run, like tests, a build or a screenshot to compare against the design, and ask it to show the output instead of saying it’s done.” Boris Cherny, who created Claude Code, calls verification “probably the most important thing” and puts the gain at two to three times better results.

The habit: ask for the evidence before you read the code. The judgment is in choosing what would prove it works. I learned the hard way that a passing check is a claim, not evidence: nine of ours passed in three days, and all nine were wrong.

Try it: before your next review, write one line: “This works if I can see ___.” Then ask for exactly that, and notice whether what comes back is the thing you named or something that merely looks like it.

2. Fifty rounds overnight

The most candid story in the post: “One CLI PR went through more than fifty rounds of review and fixes overnight before its author stopped it.”

When they ran git blame on what the reviewer kept flagging, about 59% of it “was code that had been there since the reviewer’s first pass. The reviewer was rarely finding new bugs, it was finding a few more old ones each round.”

It is the Sorcerer’s Apprentice in Git. In Goethe’s poem, the apprentice enchants a broom to carry water and cannot remember the word to stop it. Disney gave the part to Mickey Mouse in Fantasia. Each agent did its job. Nobody had asked whether the job was the right one.

The fixes: diff-only re-review after the first few passes, flagging “the class of bug, so the author fixes every instance, not one line”, and a cap. “After three rounds, the reviewer asks the author to step back and reconsider the approach.”

Notice who the cap is for. It does not stop the agent. It hands the decision back to a person.

The habit: a three-round circuit breaker for yourself. If the same problem has gone around three times, a fourth polite nudge is rarely the answer. Go back to what you asked for. Churn is usually a sign that the request was unclear, not that the agent needs more effort. Matt Pocock spent months on an approach before giving it up, and he was watching closely.

Try it: next time you send the same correction a third time, stop and write one sentence: “What I actually want is ___.” If you can’t finish the sentence, that is the problem.

3. Nobody holds the whole thing

Senior engineers used to prove their worth by carrying the system in their heads. Anthropic says plainly that this is over: “Nobody on the team keeps a complete mental model of Claude Code in their head, and we don’t think anyone needs to.”

Instead, someone who needs to understand a part of the code asks Claude “to write an explainer for exactly that slice. It takes minutes and reflects the code as it is today.” Some have Claude build a small visual that teaches it the way they like to learn.

That is a real gain, with a catch. A fluent explanation feels like understanding. Matt Pocock’s /teach skill calls it out: “fluency can give the user an illusory sense of mastery.” You feel competent until something load-bearing moves.

The post has its own guard: “A one-line copy change teaches you almost nothing. An explainer for the module you’re about to change teaches you a lot.” The explainer is for the code you are about to touch, and you still have to test what it told you.

The habit: borrow the map, then check the edges. When an agent explains a module, ask two more questions: “What does this assume about the systems that call it?” and “What breaks first if those assumptions are wrong?” Then check one answer yourself.

Try it: the next time an AI explains code to you, close it and write down, from memory, what the module depends on. Compare. The gaps are what you only felt you knew.

4. Should we even do this?

In a 1991 episode of The Simpsons, Homer’s long-lost half-brother Herb runs a car company and lets Homer design a car for the average American. Nobody tells him no. The Homer gets two bubble domes, three horns that all play “La Cucaracha”, and a price of $82,000. It sinks the company.

Every feature in that car was easy to say yes to. That is the problem with cheap building. When software took weeks, the effort was a filter. Weak ideas died because nobody wanted to write the boilerplate. That filter is gone. The post says it directly: “Agents make it cheap to start things, so some work shouldn’t land.”

What catches it is people, not checks. Anthropic works in open Slack channels, so “you see what others are building while they build it”, and “usually someone in the channel asks why, points at an earlier decision, or suggests a simpler route, and the author closes or reshapes the PR.” One team that called its review bottleneck solved still kept human review for changes from outside the team, “so someone asks ‘should we even do this?’”

The post files this under “direction, taste and scope”. It is the one layer no automated check covers. Theo Browne made the same point from the other side: the urge to build is the thing to catch.

The habit: decide whether before you decide how. Can you close a pull request that works? Can you say no to the third horn?

Try it: before starting your next piece of work with an agent, write who asked for it and what happens if it never gets built. If the answer is “nothing much”, ask someone else before you start.

5. You land it, you own it

The rule that matters most in the post is one line: “Whoever prompted the change is on the hook for it. On an agent-written PR, the person directing the agent counts as one of the required reviewers, the same as if they’d typed the code themselves.”

An agent does not join the on-call rotation. Anthropic is explicit that “an agent’s approval never counts as a person’s, either.” How many people must approve depends on the risk:

The same speed that makes ownership heavier makes letting go lighter. “Since the code was fast to write, closing the PR doesn’t feel like a loss.” The trick, they say, is to “raise a different direction in the thread early, not as a blocking comment on a finished PR.”

The habit: no attachment to the code, full ownership of what it does. Throw away agent code the moment a better direction appears. Once you merge, it is yours.

Try it: before you merge, ask yourself the question the post asks reviewers: “If you can’t say what the checks would miss, ask for a real review rather than a quick approval.” If you can’t name one thing the checks would miss, you are not ready to own it.

The bottom line

This is not the end of software engineers. It looks more like air traffic control. A controller does not fly the planes. They decide what goes where, when to hold, and when something is wrong, for many flights at once. The skill is the one we wrote about in August: steering, not babysitting.

Anthropic rebuilt its review system around that idea. Every fix in the post makes the machines better at their part. None of them tells the person whether they are getting better at theirs: whether they still ask for evidence, still stop at round three, still ask “should we?” That part is up to us. It is also the part we are most likely to stop doing without noticing.

Source: How the Claude Code team does code review, Addy Osmani, Morgan Westlee Lunt and Qing Wang, Anthropic, 15 October 2026. Discussion on Hacker News. Matt Pocock’s /grill-me is at aihero.dev. The search study is Wolfe, Horowitz and Kenner, “Rare items often missed in visual searches”, Nature 435, 2005.