One reviewer per layer: splitting code review by the way code is read

As AI-generated code increases review volume, sequential checks and rollback safeguards can reduce defects, but asking one reviewer to judge every aspect of a change overloads its attention. The proposed alternative separates review by the kind of understanding required. Six layers run from human judgment about intent, through form and a function’s local behavior, to system wiring, runtime behavior, and user experience. Compilers, type checkers, linters, and formatters should handle most form checks; agents focus on questions those tools cannot settle, such as edge cases, compatibility, concurrency, or whether documentation still reflects how the system works.

Reviewers organized as a tree would each receive narrowly scoped context. Function-level reviewers report concise contracts upward; reviewers above them assess boundaries, runtime effects, and user impact without rereading every implementation detail. Questions can travel downward, while findings and unresolved conflicts move upward to the layer equipped to judge them. This applies information hiding - a principle for modular software design - to review prompts, giving each agent a fresh, limited view. The proposal also crosses five review layers with four lenses: correctness, security, historical decisions, and reversibility. Security, for example, may concern input handling, trust boundaries, or user permissions at different layers. Rather than build a separate agent for each of the resulting twenty combinations, teams can combine five context retrievers with four lens-specific prompts. Intent remains a human decision, while deterministic tools handle mechanical checks.