John, a senior staff engineer at Meta, argues that with AI-generated code volume exploding, the right answer to "do you still read your code?" is a gradient, not a yes/no. He proposes treating the codebase like a tree: review depth should scale with blast radius, so trunk/infrastructure changes get deep reading while gated leaf code gets a skim backed by agent-produced proof (tests, logs, screenshots, confidence levels). He also covers using a fresh adversarial review agent, PR templates, feature gating, and the claim that landing code only gets you 80% done s the final 20% of cleanup, auditing, and taste still takes as long and is still human work.
- Think of the codebase as a tree: trunk code (entry points, shared infrastructure, reducers with shared state) gets deep review; isolated or feature-gated leaf nodes get skimmed.
- Review depth should be set by blast radius and reversibility s the more a change is a one-way door, the more time he spends reading it.
- Feature gating should be planned from the start (even a simple boolean flag), separating leaf work from integration layers so bad changes can be rolled back.
- Require agents to attach proof to every PR: unit tests, runtime logs, screenshots or video of the UI, and a stated confidence level s proof is what lets you read less code.
- Use a separate, context-free "adversarial" review agent (Claude Code's /code-review, Codex's review agent), because an agent that wrote the code will cheat by leaning on its prior context.
- Nitpicks and style debates are effectively dead in code review; leave them to type checking, linting, and static analysis.
- Use a PR template so diffs look consistent; a summary and test plan longer than the code change is the speaker's biggest pet peeve.
- Merged is not launch-ready s after the "broad strokes" phase he runs audit agents for performance, bugs, and security, refactors by hand, then ships behind gates with canary deploys or A/B tests to catch crashes early.
This is the core mental model of the video and the one concrete rule for deciding how much to read.
I think of the code base like a tree. And like a tree, there are different parts of the tree that is more important... the review depth... should really be based on the blast radius of that code change.
A specific, actionable failure mode of AI code review that most people get wrong.
One thing that's kind of important to do is to use a new sub agent... an agent that doesn't have the context of the code that it was used to create the code. Because the agents will cheat.
My biggest pet peeve right now is when people submit PRs or diffs to review where the summary and test plan is longer than the code changes itself.
Even if it's merged ready, I don't think it's launch ready.
This last 20% actually takes as long as the first 80%, but it's actually the thing that is the most important.