Addy Osmani, Morgan Westlee Lunt, and Qing Wang describe how the Claude Code team reviews code faster than humans can read it. From June to September, they report, merged pull requests more than doubled while the share needing reversal fell by more than 40%. Their target is human time saved without more reversals or incidents.

  • Verify before review. Agents run tests, builds, and linters; a second agent examines the change with fresh context. Recurring findings become written instructions or automated rules.
  • Match approval to risk. Some low-risk changes from trusted authors can merge without human approval. Sensitive changes require people, and an agent’s approval never fills a required human slot.
  • Stop endless review loops. One change went through more than fifty rounds overnight. Capping rounds, checking only new changes on later passes, and suppressing repeated findings brought mean reviews-to-pass from 2.08 to 1.32.
  • Make mistakes recoverable. Small changes, switches that disable features, staged releases, and fast reversal limit the damage. Past incidents become daily tests of the reviewer itself.

The authors treat review as a system with checks before and after merging. They also acknowledge an unfinished part: preserving shared understanding when machines do most of the reading. Their team asks Claude for explanations of particular code sections, but has no formal process for spreading that knowledge.

These are the team’s own before-and-after figures; they do not isolate which changes caused the improvement.

The 228-comment thread on Hacker News adds practical checks and objections to the team’s account.

What the thread adds

  • visarga — “For intent realignment I like to have the agent re-read all user messages posted in that project.” “Then use this fresh derivation of user intent to check code and tests.”
  • vavkamil — “Dismissing a critical finding as a false positive should still involve AppSec.” “You could improve revert rates while simultaneously introducing more security vulnerabilities.”
  • RGS1811 — “Having claude write an explainer (something I do a lot!) doesn’t get you to the point where you can confidently assess a complex diff.” “And you’ve funneled your priors on what the diff says and does through the same system that already reviewed and approved it.”
  • cush — “How big are the PRs? Maybe there’s an auto-bug-fixer agent that runs around the codebase making thousands of single-line fixes per day. Who knows. The number means nothing in isolation.”
  • stillpointlab — “These processes often also involve spot checks where some statistical sample is selected and viewed carefully.” “I don’t think we’ve gotten to that level of reliable review with code, but I don’t see any reason we can’t continue moving in that direction.”

What does this cost outside an AI lab?

Three commenters raise the cost objection, which the article leaves unpriced. avinoth argues that “Anthropic can afford to do this because they have virtually unlimited tokens and labs to train models for their specific usecase.” YmFzZTY0ZGFkZHk asks the authors to consider “someone who has to think about cost to use the models.” vb-8448 asks: “I really want to know what is the churn rate (and the cost per LOC) here.” These are objections and questions, not a measured cost comparison.

HN handles are pseudonymous; no per-comment scores are published, and ordering is HN’s ranking. This is a slice of the thread, not a consensus.