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

0:00 – 6:12

The real debate is not whether to review code, but where to spend your attention

He opens with a jab at the current split in software culture: one camp thinks reading your own AI-generated code means you are too slow, while the other thinks skipping review is how "AI slop code" leaks into production. That tension is the hook for the whole talk. John does not take either extreme. His answer is "it depends," but not in a hand-wavy way. He is describing a decision framework. The first important shift is that code review is no longer a single step at the end. He says AI should be part of the whole journey to production: planning, building, reviewing, and launching. That matters because if you wait until the PR to think about quality, you are already too late. In planning, he wants specs, evaluation criteria, and a sense of what "done" means. During coding, he wants the agent validating and fixing itself. During launch, he wants feature gates and experiments. Review is just one layer in that larger safety system. Then he introduces the metaphor that carries the rest of the video: the codebase is like a tree. The trunk is the dangerous shared core, things like main entry points, infrastructure, networking, image processing, reducers, and shared state. If the trunk cracks, the whole app shakes. The leaves are isolated components, one-off endpoints, or gated features that do not yet affect production broadly. Once you see the codebase this way, the next conclusion feels obvious: review depth should track blast radius. That is the unexpected angle in the video. He is not saying "read less code" or "read everything." He is saying your effort should scale with the cost of being wrong. A core image-rendering change with many downstream dependencies deserves close reading. A fully gated UI component with good tests and screenshots might only need a skim. He keeps returning to safety questions: what is the control experience that must not change, how bad would failure be, and can this be rolled back? That is why feature gating shows up so early in his process. He describes gating as simple branching logic that turns a feature on or off, mentioning LaunchDarkly as a common tool but also saying you can start with a plain Boolean flag. The point is not sophistication. The point is optionality. If you plan broad strokes first, separate leaf-node work from integration work, and gate the risky seams, you buy yourself the right to move faster later.