One reviewer per layer: why a single AI agent can't read code the way humans do
One reviewer per layer: splitting code review by the way code is read
The Claude Code team's monorepo went from roughly 2,500 merged changes a day in May to over 30,000 by September, so they layered review into six gates instead of reading line by line. The author argues the AI review stage still asks one agent to hold every level of abstraction at once, and proposes splitting it into a tree of reviewers—intent, form, local meaning, wiring, runtime, and use—each with narrow context, passing contracts up and questions down, with cross-cutting lenses like security and reversibility applied across every layer.
We follow that rule in our code, and then break it in our prompts.
- jwpapi
My problem is right now that every kind of reviewing process adds un-needed complexity which later slows down your agility and increases your cost and performance degrades.
If you have feature and 6 different reviewers go over it the logic bulks up easily. I wonder how other guys handle that? I’m all up and I want this to work, but this is my current constraint.
I often get bad suggestions from reviewing monitors because they get something wrong. Sometimes I get good ones, very good ones, but some are bad. So I’m always down to look at reviews about bugs, but I would be afraid after 6 reviewers its just a bunch of text and its confusing me so end result is worse as me looking through actual critical stuff. My context is limited too and completely hands-off is not reliable enough...
How do you guys do it?
- visarga
I think it is a good approach for this year, but it misses something important - how do you know the code still reflects your intention after steering for weeks and months, across many sessions? Messages flow in the session and zoom out of view, and across compactions/new sessions they get forgotten. To solve this, I log every user message in a chat log, and review it from time to time to distill the latest form of user intent.
Another kind of review not mentioned here or in Anthropic's article is the plan review. I generate the plan for some stretch of work, then have the plan (saved as a file) reviewed by one or more agents. This checks the plan against project constraints before executing it.
If we can solve testing then coding is almost fully automated. The only remaining problem was always trust, why should we trust that code? If you read it manually then it's like walking a motorcycle. If you don't, then you need some way to derisk it. There are many ideas flowing around about how to do this, the OP and Anthropic showed their takes. I think the approach is project specific though, no general method.
- zomtorg
I wonder if we would see more engineering teams transitioning away from git to Sapling. We do need a refresh on how we review and ship code.
I'm aware that GH recently released stacked PRs, but it still seems like a long way to go both from usability and reliability perspective compared to what Meta and likely Anthropic have internally.