Shift left code review: catching problems before the pull request exists

Shift left code review means moving review earlier in the development cycle: from a single inspection at the end to design review, draft pull requests, author self-review, and automated pre-review, so each defect is caught at the moment it is cheapest to fix.

The cost curve of late defects

The argument for shifting left is arithmetic, not fashion. A wrong direction caught at the design stage costs a conversation. The same mistake caught in a finished pull request costs a rework round, a second review, and a bruised author. Caught in production, it costs an incident, a rollback, and some measure of trust. The defect is identical in all three cases; only the discovery date changed the bill. Review effort placed early buys more correction per hour than the same effort placed late, because early feedback arrives while the work is still soft.

The classic review process ignores this curve. It spends its entire budget at the most expensive point: after the code is written, polished, and emotionally finished. By then every comment is a demolition order. Google’s small CLs guidance attacks the same problem structurally: work split into small units early is work that can be reviewed, corrected, and merged before mistakes compound. Splitting is itself a shift-left move. You cannot split a change you have already welded together.

The shift left code review ladder

In practice, shifting left is a ladder of four rungs, each catching what the next one would catch too late:

1. Design review. A short written design, reviewed before any code exists, is the cheapest review your team will ever run. It catches wrong direction, duplicated effort, and missing constraints while changing course costs nothing. Most changes do not need one; the ones that touch architecture, data models, or public contracts almost always do.
2. Draft pull requests. Opening a draft PR at thirty percent done invites feedback on approach while the approach is still negotiable. The social contract is different: comments on a draft are steering, not judgment, and authors accept them far more cheaply.
3. Author self-review. Reading your own diff before requesting eyes, the way a reviewer would, removes the leftover debug code, the accidental file, the misleading name. Every one of those caught by the author costs seconds; caught by a reviewer, it costs a round trip and a little dignity.
4. Agent pre-review. An AI pass before the human one, doing the work machines are actually good at. The evidence says that work is substantial: Cotera’s analysis of 47 AI review suggestions across 30 pull requests found 31 were catchable by ordinary linters. That is noise a human reviewer should never have to spend attention on, and pre-PR is the right place to burn it off.

What shifting left does not remove

The tempting misread of shift left code review is that enough early gates add up to a merged PR with nobody reading it. They do not. The rungs remove direction errors, embarrassments, and mechanical noise; they do not exercise judgment about correctness, system fit, or blast radius. That judgment is the irreducible human part, and it matters more, not less, as generation gets cheaper. We made the longer version of this argument in the agentic code review piece: automation can pre-filter everything, and a human still owns the merge.

The honest promise of shifting left is narrower and better: the final read gets faster and sharper because everything that could have been caught earlier already was. The reviewer opens a diff that is small, self-reviewed, mechanically clean, and pointed in a direction someone already agreed to. What remains is the part only a human could have done anyway.