Shift Left, Shift Right: Where Human Review Belongs When AI Writes the Code

The question is not whether to keep humans in the loop, but where to place them. Matt Pocock argues that automating engineering work well means deciding which checkpoints need a human, then moving those checkpoints based on the size of the change. Big work gets human review early, at planning. Small work gets human review late, right before it ships. He frames the whole thing around a simple timeline: plan, ship, review, with each checkpoint colored blue for AI or red for human.

The Pre-AI Baseline

Pocock starts with a process that predates AI: you plan some work, you ship some work, then you review some work. On his diagram, each of those moments is a checkpoint, and in the old world every checkpoint is human. The frames show a legend with a blue square labeled "AI" and a red square labeled "Human," sitting above a horizontal arrow with three markers along it. In the baseline, those markers are all red. The dream, as he puts it, is to translate all of them to AI at once. He does not think that makes sense.

Shift Left for Big Work

For very large pieces of work, Pocock wants to be involved at the initial planning stage. He calls this shifting the checkpoint left. Align with the AI first, before it writes anything, because the cost of fixing a large body of work climbs steeply the further along it gets. In the video he names three of his own Claude Code skills that do exactly this alignment work up front: GrillMe, GrillWithDocs, and Wayfinder. On the timeline, the leftmost checkpoint turns red while the shipping stages turn blue. The human reviews the plan, then the AI carries it through.

Shift Right for Small Work

Small changes get the opposite treatment. If the diff is a refactor, an internal documentation rename, a button color, a title change, or a two-line bug fix, Pocock says you often do not need heavy review up front. You can skip the grilling, specify the work in a single prompt, let the AI ship it through the process, and only review at the end before it goes live. On the diagram the checkpoints slide the other way: the early markers turn blue and the final marker before production turns red. That is shifting the checkpoint right.

Why Diff Size Decides

The reason the small-diff case tolerates late review is context. The smaller the change, the easier it is to regenerate the code from scratch and hold the whole thing in the model's context window. A late human catch is cheap to fix because the AI can just redo it. Massive work is the opposite. Once a large change has been built out, correcting it is expensive, so you pay for alignment early and shift the review left. Pocock reduces the whole framework to one rule: shift review left for big work, shift review right for small work.

Key Takeaways

Do not translate every human checkpoint to AI at once. Decide where human review actually adds value.
For big work, shift the review checkpoint left and align with the AI at the planning stage before it writes code.
For small work, shift the review checkpoint right and review only at the end, right before it ships to production.
The deciding factor is diff size. Smaller diffs are cheaper to regenerate and easier to hold in context, so late review is safe.
Large changes are expensive to fix late, which is why alignment up front pays off.
Pocock's GrillMe, GrillWithDocs, and Wayfinder skills are built for the shift-left case, forcing alignment before implementation.