Maybe We Shouldn't Be Reviewing All This Code

# Why reviewing every change doesn't scale

AI and coding agents are producing far more code than humans can practically inspect. Rachel Laycock points to striking reported numbers: at Meta, significant lines of code per human-landed diff rose 106% in a year, and DX's data shows median pull request size grew 64%. That matters because the old pattern—relying on human code review as the central safety and learning mechanism—is breaking under this load.

# What we've been asking code review to do

Teams have piled many responsibilities onto the pull request ceremony: catching bugs, enforcing style, checking security, transferring knowledge, mentoring juniors, distributing architectural understanding, and signaling ownership. That makes each review heavy and slow. When an agent or another developer produces lots of code quickly, every line can queue up waiting for senior attention, creating a bottleneck and delaying value.

# Move feedback earlier (shift left)

If feedback is valuable, place it closer to the decision it informs. Concrete alternatives to using the pull request as the primary learning and alignment moment:

• Pair programming and mob programming for real-time knowledge transfer and mentoring.
• Collective design sessions and whiteboard reviews before code is implemented so architectural trade-offs are discussed up front.
• Trunk-based development and shorter-lived changes to avoid large, monolithic diffs.
• Automated static analysis, linting, security scanning, and fitness functions for deterministic checks.
• Encoding constraints as tests or fitness functions so CI can enforce architecture-level rules.

These practices shorten feedback loops and make the thinking of experienced engineers visible while the work is in progress, not after it's done.

# Keep human review, but change when and why it happens

Laycock does not say eliminate human review. She recommends review-by-exception: reserve human attention for the places where human judgment adds unique value. Examples include major architectural changes, anything crossing a sensitive security boundary, changes with a large blast radius, or work in unfamiliar critical systems. Those are the moments where a senior engineer or the team should inspect code together.

# Automate the rest

# Practical implications for teams

• Rework team workflows so ownership and operation of software are collective, reducing the need for PRs to inform everyone after the fact.
• Define explicit criteria for when human review is required so review effort focuses on high-impact cases.

# Bottom line

Code review still matters, but it should not be the default mechanism for every type of feedback teams want. Move learning and alignment earlier, automate deterministic checks, and use human review where judgment is essential. That approach addresses the practical bottleneck created by agent-driven code production while preserving the human benefits teams need.