Agents write code faster than anyone can read it, and review has become the new bottleneck. Practitioners disagree about reading every line, but they agree on how to review well: scale depth to blast radius, review your own work first, use a fresh-context reviewer, and turn repeated comments into rules.
Key takeaways
- Review is a gradient: go deepest where the blast radius is biggest (shared infra, money, auth), lightest on isolated leaf code.
- Know what's load-bearing in your system, and watch every change there closely.
- Never open a pull request you haven't reviewed yourself. Attach evidence that it works.
- Use a reviewer agent in a fresh context; it isn't biased toward code it just wrote.
- If you keep leaving the same review comment, turn it into a lint rule or a test.
Try it with your agent
In a NEW session, on your branch:
Review the diff of this branch against main with fresh eyes. List, prioritized P0/P1/P2: what could break elsewhere (blast radius), changes to load-bearing code, missing or weak tests, and anything you'd push back on. Quote the exact lines you're worried about.
Transcript
Intro
Agents can write code far faster than any human can read it. So who reviews it, and how much is enough? This is where agentic engineering gets hard.
The new bottleneck
At Uber, the time it takes an engineer to get a first code review grew from three hours in 2024 to nine hours in 2026, as pull requests got bigger and more frequent. And Beyang Liu from Sourcegraph hears developers say they now spend around ninety percent of their time reviewing code.
Two camps
Practitioners genuinely disagree about how much to read. Peter Steinberger says much of an app is boring plumbing, and he ships code he doesn't read. Dex Horthy's team tried not reading agent code for six months. It did not end well. They had to rip out and replace large parts of the system.
A gradient
Both can be right, because review isn't a yes or no. Meta's John Kim calls it a gradient. How deeply you read should depend on the blast radius of the change: how much can break if it's wrong.
He pictures a codebase as a tree. The trunk is entry points and shared infrastructure, like networking, authentication or payments. Break it, and the whole app breaks, so read every line. The leaves are isolated, one-off code. There, tests and a screenshot of it working may be enough.
Three questions
To set the depth, he asks three questions. What must not change? How bad is it if this goes wrong? And can I roll it back? A change that's hidden behind a flag and easy to roll back needs far less scrutiny than one that can't be undone.
Load-bearing code
Thorsten Ball adds a related idea. Even if agents write ninety-nine percent of your code, you need to know what's load-bearing: the protocols between components, the business logic, the things that keep the system standing. When an agent touches those, watch it like a hawk.
Review your own first
Simon Willison calls out the most common anti-pattern: don't file pull requests with code you haven't reviewed yourself. Your reviewers could have prompted an agent themselves. Your value is the verification, so attach evidence: how you tested it, screenshots, notes on tricky choices.
A fresh reviewer
Agents can review too, if you set it up right. Anthropic's guide recommends a writer and reviewer pattern: a fresh session reviews the change, because it isn't biased toward code it just wrote. Matt Pocock warns that a review in the same long session happens in the dumb zone. At Anthropic, Claude reviews every pull request, and then a human does.
What humans review
So what should the human focus on? Leave typos, style and obvious bugs to automation. Spend your attention on the questions only you can answer: do we want this in our product? Is the boundary between these services in the right place? Will this design hold up?
Make rules
One more habit from Lauren Tan. If you find yourself leaving the same review comment again and again, treat that as a smell. Turn it into a lint rule, a test, or a CI check, so no one, human or agent, ever has to say it again.
Quick check
Quick check. Which of these changes deserves your most careful, line by line review? Tap your answer.
Try it
Try a fresh-context review on your last change. Open a new session and paste this. You'll get a prioritized list of risks before anyone else spends time on your pull request.
Recap
Recap. Review is a gradient: go deepest where the blast radius is biggest. Know what's load-bearing. Review your own work first and attach evidence. Use a fresh-context reviewer, and turn repeated comments into rules. Next: what to do when an agent goes off the rails.