How I Review AI Code - (Meta Senior Staff Engineer)

Summary

John Kim argues that AI-generated code has increased code volume so much that engineers cannot deeply inspect every change. Rather than stop reviewing, he recommends adjusting review effort according to a change’s risk and potential impact.

Risk-based review workflow

• Think of the codebase as a tree. “Trunk” code—such as shared entry points, infrastructure, and state management—has a larger blast radius and deserves deeper review. Isolated or feature-gated “leaf” code can often be reviewed more lightly, with tests and other evidence.
• Plan for safety from the start. Break features into isolated pieces, identify risky integration points, and use feature gates or toggles so changes can be enabled, disabled, or rolled back.
• Ask agents for evidence in pull requests. Useful evidence includes unit and integration tests, runtime logs, screenshots or video of UI behavior, and confidence assessments. Meaningful evidence can reduce the need to inspect every line manually.
• Prioritize safety over style preferences. Use type checking, linting, and other static tools for many style and correctness checks. Focus human attention on possible regressions, failure impact, reversibility, security, performance, and whether the change matches its specification.
• Keep human review for high-risk work and launch readiness. A change that is ready to merge is not necessarily ready to launch. Kim recommends a substantial final pass for auditing, refactoring, performance, security, bugs, and product quality.

Agent-assisted review tools and practices

Kim says AI can be effective at code review, but recommends having a separate or adversarial review agent inspect the change rather than relying only on the agent that produced it. Giving the reviewer less of the original coding context may help it catch issues the coding agent overlooked.

He cites review capabilities in Claude Code and Codex, including a Codex reviewer integration for GitHub pull requests. He also recommends consistent PR templates with concise summaries, test plans, and validation evidence. For repeated review cycles, an agent can periodically check a PR, address comments, rerun validations, and update the PR.

Launch and validation

Kim recommends using experiments, canary deployments, or gradual releases behind a feature gate. These approaches can surface crashes, bugs, and alerts while limiting exposure.

His overall approach is to build an “agentic safeguard” of tests, validations, review agents, and rollout controls, while retaining the ability to disable or roll back risky changes.

Bottom line: Kim still reads code, but varies how deeply he reviews it based on its blast radius and the strength of its safeguards. He expects to review less code as models improve, while continuing to rely on validation, evidence, feature gating, and human judgment.

Guides and demonstrations mentioned

• A simple swipe-based “AI or Not” demo app illustrates the video’s discussion.
• Guide: Assess review effort based on code risk, dependencies, feature gating, and rollback options.
• Guide: Require tests or other concrete evidence in PRs, and use independent agents for adversarial review.
• Guide: Treat merge readiness and launch readiness as separate stages, and use staged rollout where possible.

Main speaker and sources

• John Kim — the video’s speaker, who identifies himself as a senior staff software engineer at Meta.
• Tools discussed: Claude Code and OpenAI Codex, including Codex’s GitHub PR-review integration.