Code Review in the AI Agent Era: the Trunk–Leaf Tree Model, Blast Radius, and Agentic Validation

As AI agents generate code at an exploding pace, reading every line the traditional way has become impossible. This synthesis by Lữ Minh Khương, based on a practical talk by John Kim — Senior Staff Software Engineer at Meta — proposes a gradient review strategy: how deeply you review depends on the safety and blast radius of the code.

Quick answer: The volume of code produced by AI agents makes line-by-line reading impossible; instead, review on a gradient based on blast radius. The codebase is classified with a tree model: Trunk Code (core, infrastructure, shared state) gets deep review, while Leaf Code (isolated components, new endpoints behind a Feature Gate) only needs a skim with evidence attached. The authoring agent must attach validation proof to every PR: tests, runtime logs, visual proof, and a confidence level. The reviewing agent must be a fresh agent with fresh context, never the same agent that wrote the code. Merge-ready is only 80% of the journey; the final 20% is a full-feature audit and a gradual rollout with Canary Deployment.

Gradient review is a strategy for reviewing AI-generated code by priority: instead of reading every line equally, reviewers focus deeply on parts with large blast radius and high risk, while skimming isolated parts that are wrapped in a feature gate and backed by solid validation evidence.

Two extremes in the AI-era code review debate

When it comes to code review in the AI era, the engineering community splits into two clear extremes. One side argues that if you still sit reading every line of AI-written code, you are moving too slowly, because today's AI agents already catch bugs better than humans. The other side is extremely wary of AI slop — garbage code produced by reckless vibe coding — leading to silly bugs and technical debt piling up in production.

John Kim's approach takes neither side outright: how deeply you review depends entirely on the safety and blast radius of the code in question. This article synthesizes the key takeaways from his talk, combined with a few practical perspectives from the author of the synthesis.

The tree model: how do Trunk Code and Leaf Code differ?

When one engineer can run several AI agents at once to write features, the volume of pull requests (PRs) arriving every day is enormous. Keeping the habit of reading every line equally for every file turns the reviewer into their own bottleneck. The solution is to see the codebase as a tree:

	Trunk Code (trunk and roots)	Leaf Code (branches and leaves)
Examples	Main entry points, infrastructure, networking, image processing, large shared state (reducers, core services)	Single UI components, brand-new API endpoints not yet wired into the main production flow
Risk	One-way door, many downstream dependencies; one mistake can bring down the whole application	Isolated, narrow impact
Review style	Read every line, analyze side effects, review architecture strictly	Skim, as long as evidence is attached and the code sits behind a Feature Gate

Why design Feature Gating from the planning step?

To dare skimming Leaf Code and still sleep well, the vital principle is to apply Feature Gating (Feature Toggling via LaunchDarkly, or simply a boolean flag in configuration) from the planning stage. When the new code behind the feature flag is clearly separated from the integration layer touching the old system, the most important review question becomes: if this code misbehaves in production, will the current experience be affected, and can we roll back immediately by turning off the flag? If the answer is yes, the pressure to review every line drops significantly.

Agentic Validation: forcing AI to provide proof in every PR

Instead of pulling the branch and running every case yourself, configure skills that force the AI agent to validate itself and attach proof directly in the PR:

• Unit and integration tests: glancing at test function names and assert statements reveals the logic quickly. But the agent needs a dedicated skill to avoid writing piles of useless tests — tests that only chase coverage without checking the actual business logic.
• Runtime evidence: give the agent the ability to read runtime logs so it can run, read error logs, and fix itself before reporting.
• Visual proof: for UI changes, require the agent to capture UI screenshots or screen recordings proving the feature works.
• Confidence level: require the agent to assess its own confidence in the code it just wrote and in the safety of the feature gates.

One practical detail: prepare a concise PR template for the agent. Without a template, AI tends to write PR descriptions and test plans like a novel — sometimes longer than the code diff itself.

Why kill the nits culture and use an Adversarial Review Agent?

The era of commenting line by line on PRs — "this variable name would be nicer" or "I prefer this style here" (nits) — is over. As code is generated faster and refactoring becomes extremely cheap thanks to AI, code style, formatting, and type checking should be handed entirely to Static Analysis and Linters.

In particular, when using AI to review AI-written code (via Claude Code or Codex GitHub integration), there is a major trap: using the very agent that wrote the code to review its own code. Because it holds the entire prior conversation context, it tends to "cheat" and favor the solution it just built. The standard practice is to spin up a completely new sub-agent — an Adversarial Review Agent — that knows nothing about the chat history and looks only at the code diff and the technical standards to find flaws objectively. Additionally, to avoid endless ping-pong between humans and machines over trivial GitHub comments, you can set up a periodic mechanism (for example, every hour) where an agent checks the PR, fixes issues per the reviewer agent's comments, re-runs local validation, and updates the PR.

How do merge-ready and launch-ready differ?

This is the part the synthesis author values most. Many people use AI to write a series of PRs, see all tests green, merge into the main branch, and think they are 100% done. In reality, following the broad-strokes approach, when code reaches merge-ready, you have only covered 80% of the journey.

The final 20% that turns that code into launch-ready is where the most judgment is spent and where an engineer's caliber shows — often taking as long as the first 80%. When preparing to open the gate to real users, run a full audit of the entire feature at the big-picture level:

• Review performance, security, and edge-case bugs.
• Check whether the product matches the original spec and preserves human taste (smoothness, real experience).
• Refactor and clean up the codebase structure to prevent garbage accumulation.
• Always open the feature through A/B Testing or Canary Deployment — releasing traffic gradually through the Feature Gate to watch crash rates, metrics, and alerts before opening to 100%.

In short, AI agents make the first steps extremely fast, but the responsibility for keeping the system stable still rests on safeguard design thinking and the engineer's judgment at the critical points.

Frequently asked questions

1. Should you read every line of AI-written code? No. Under this approach, only Trunk Code needs line-by-line reading; Leaf Code wrapped behind a Feature Gate with sufficient evidence only needs a skim.

2. What is blast radius? It is the scope of impact if the code misbehaves: changes to Trunk Code have a large blast radius because they affect the whole application, while isolated Leaf Code has a small blast radius.

3. What proof does Agentic Validation include? Unit and integration tests, runtime logs, visual proof (UI screenshots/videos), and a confidence level assessed by the agent itself.

4. Why not let the agent review its own code? Because the agent holds all prior context, it easily favors the solution it just built. A fresh Adversarial Review Agent is needed, looking only at the code diff and technical standards.

5. Is merge-ready enough to launch? No. Merge-ready covers about 80% of the journey; the remaining 20% is a full-feature audit, performance and security checks, spec verification, and a gradual Canary Deployment rollout.

Source: synthesis by Lữ Minh Khương in the VGU Tech Alumni group, published 12/11/2026, based on a talk by John Kim, Senior Staff Software Engineer at Meta. This article rewrites and restructures the original synthesis; the takeaways are those of the synthesis author and the original speaker.