I ship like this every day (products and features for real users, not “lines of code”): sessions that run for weeks, 5 subscriptions, $30k a month in tokens, agents writing code I don't read. When Anthropic published how the Claude Code team does code review (the article (si apre in una nuova scheda)) and Theo read it on video (here (si apre in una nuova scheda)), I recognised my own process. Where the two disagree, I'm almost always with Theo.
Their numbers say what I see. On Claude Code, merged PRs more than doubled between June and September while the share of reverts fell by more than 40%. Theo gets up to 800 PRs a day on T3 Code with a team of three. More speed and fewer mistakes, at the same time. Here is how I keep that true on my side.
Reading the diff was never the safety net
I don't read every line, and I work better for it. The bugs that slip through today live between the pieces, in timing and in data, and staring at code rarely finds them. Theo says almost every regression he has shipped would have got past him in review anyway, and that's my experience too. The question I ask is the one Anthropic puts well: what could go wrong with this change, and which check, automated or human, should catch it?
I always get review from a model of another family. This autumn, on a research project about running coding agents in sandboxes, I had two independent reviews of my own code: both found real problems, and every fix landed with a test that failed before it and passed after. Theo calls his version Council: three models from three families, on subscriptions. He finds Anthropic's review product too expensive at this speed, and I agree. Right now the reviewers that let nothing slip are GPT-6.1 Sol and Astra. The bugs that get past Opus and Astra reviews are bugs I'd never have found by staring at the code intensely and passionately. Neither would you. My job is deciding which findings matter.
Every change arrives verified
Anthropic writes that most changes get a Claude review before a human sees them. Theo says all of them, and so do I: a PR your agent hasn't verified wastes the time of whoever reads it. On my side Claude literally tests the feature, the way a user would: no “trust me bro” sMoKe TeStS. Boris Cherny, who created Claude Code, estimates that giving the agent a way to verify itself makes the result two to three times better. Theo goes as far as letting every thread open its own desktop, run the app and attach a video of the change working to the PR.
What taught me most about verification was a green suite. In that same project the tests that needed containers skipped themselves silently whenever the container engine was off. The run said green, and it only meant that the tests it had run were green. A verification has to say what ran, what was skipped and what is still to do. On Yempik's Company Brain that is a release rule (the story is here).
My agent reads the review. I read the verdict.
Here I'm with Theo all the way. Review comments are for the agent that wrote the PR: it decides which feedback is good, fixes it, and only then calls me. Copying a reviewer's suggestion into a prompt by hand is 2024 work. Layers of checks also add code, though: Theo has seen 50-line PRs grow to 2,000 because the agent obeyed every comment. That's why a finding has to be verified before anyone acts on it.
Human attention follows the risk
The change sets the tier, never the author. Docs and copy behind a flag go through with no human once the checks are green, risky code needs one or two people, CI workflows always go through a person. Anthropic uses fixed tiers of zero, one or two humans. Theo wants them dynamic, with the bot describing the risk and never choosing which person to tag, and I prefer his version. One rule I don't negotiate: a bot's approval never replaces mine. It's a finding, and I'm the one who signs. Whoever prompted the change is its author.
The most useful review I did this autumn had nothing to do with bugs. An agent had opened a PR on this site with new service pages: build green, facts checked, everything in its place. I closed it the same day, because the direction was wrong: too safe, too much text for too little value. No check would have caught that. Deciding whether something should exist is the part of review that stays human.
A review loop needs a stop
At my scale this is the rule that matters most. With sessions that run for weeks, a loop nobody stops drains your weekly limit. At Anthropic one PR went through more than 50 rounds of review and fixes overnight, and about 59% of what the reviewer kept flagging was code that had been there since the first round. Theo forgot a loop in a folded tab and four days later the PR was around 80,000 lines. Noise costs more when the author is an agent: a person ignores a nit in seconds, an agent fixes it, with another commit and another round.
The fix is simple. Cap at three rounds, then the reviewer asks for a rethink of the approach. After the first rounds, review only the new diff. Flag the class of bug rather than the single line, and never repeat a finding. With these rules Anthropic took the mean number of reviews to pass from 2.08 to 1.32. My bar is a confidence score instead of a comment count: a PR with one comment scored 6 out of 10 comes before one with twenty nits scored 9 out of 10. I had already paid for this lesson with retries (here).
Going slower fixes nothing. Cheap rollback does.
Slowing down lowers your error rate mostly because you do less of everything. If your solution to not breaking things is going slower, you just did less. A team that goes brrrr has to learn to make mistakes cheaper and easier to revert. I'd rather get faster at noticing and fixing: flags that switch off without a deploy, internal use first, a staged release, one-step rollback. Whoever lands a change fixes it if it breaks, because they have the most context.
At Intarget this summer we changed how the agentic platform stores its conversations, with people using it every day. The old storage kept receiving every write in parallel, as a way back that cost nothing. Reads moved behind a flag. The old copy was deleted only after repeated comparisons came back with zero differences. At any point, rollback was one switch. Before any risky change I ask two questions: how do I revert this, and how fast will I notice that I need to.
The reviewer has its own eval set
A reviewer is a model plus a harness like any other agent, so I treat it the same way. Incidents and reverts become its eval set, and a change to its prompt, tools or model stays only if the score goes up. Anthropic also measures noise by running the reviewer on PRs it knows are clean. The rule I apply everywhere holds here too: a score measured on someone else's work tells you nothing about yours.
The strongest objection: this works for Anthropic, not for a small team
It works for Theo, who is three people with no merge queue, and it works for me. Until this week this site didn't even have a PR template: the gate was build, lint and typecheck green on my machine, then the platform's build. The layers cost little: a template, an AI reviewer on one repo, a cap on rounds, a flag. What doesn't scale is treating human reading as the guarantee. Since this essay, every PR on the site starts from a template that asks for Testing, Risk and How to revert.
From Monday
- Give your agent a way to verify its work, and ask for the output, never for “done”.
- Add Testing, Risk and How to revert to your PR template.
- Put an AI reviewer from another model family on one repo, tune what it flags for a few weeks, then widen it.
- Let the authoring agent read the review comments. You read the verdict.
- Set the tier from the change, never from the author. A bot's approval never counts as a person's.
- Cap review rounds, and after the first ones review only the new diff.
- Make every risky change revertable with one switch.
- Turn incidents and reverts into an eval set for your reviewer.
// weeks-long sessions, $30k a month in tokens. at this scale you either have a stop, or you pay for it.