Code Review Scales Quadratically

The effort and cognitive load of code review scales roughly quadratically with the size of the change. That’s because reviewing each line requires:

1. Assessing the individual change structurally, or whether the change makes sense on its own. Does it follow appropriate abstractions and fit preferred style guidelines?
2. Assessing the broader impact & risk of the change, or whether the change makes sense in the context of other changes. Does it accomplish its stated goal and is it consistent with assumptions made in other parts of the system?

The first grows roughly linearly with the size of the diff. However, assessing the impact of changes grows much faster. Each additional line changed requires careful reasoning against other lines of code both inside and outside of the pull request. This results in a roughly quadratic complexity.

The natural conclusion is that the smaller a PR is, the faster it is to review. There’s obviously exceptions to this. Thousand line PRs containing innocuous, generated changes may not require as much scrutiny. In other cases, seemingly harmless one line changes are the most likely to cause outages. But most day-to-day project work doesn’t fall in these extremes.

Clear Pull Requests Help Reviewers#

Part of software engineering is an exercise in translating product requirements to functional execution. Code review is the culmination of this effort. Through this lens, smaller pull requests are easier to review because they ask the reviewer to understand a narrower part of the story. This means explaining the what and the why behind a change to make its intent, scope, and consequences easy to follow.

A little empathy towards the reviewer also goes a long way. Each new review requires a context change, and reviewers may not always have as much familiarity as the author who most recently made changes.

Besides being mindful of the size of the change, a pull request should be structured to make it as easy as possible for the reviewer to understand. A few habits go a long way here:

1. Split changes into logical, well-ordered commits. Each commit should have a clear explanation of the reasoning behind the change. The idea is to include sufficient detail for the reviewer to understand the thought process behind the changes. An analogy is that each pull request is a chapter in a book, with every commit representing a paragraph.¹ Each paragraph can be self-contained, but read sequentially they form a cohesive topic encompassed in a single chapter.
2. Always start with a self-review. A pull request isn’t ready for another reviewer until it’s been reviewed by the author. The goal is to catch obvious errors, to call out areas that might require more scruitiny, or to clarify potentially confusing or unexpected changes.
3. Build confidence in the correctness of the change. Demonstrate why the change accomplishes its stated goal by describing how it was tested. This makes it easier for the reviewer to identify any flaws in methodology, if any.

Ultimately, code review is an inherently human process with some degree of subjectivity. Humans have a tendency to procrastinate on reviews when faced with the unknown. Small, coherent, and self-reviewed PRs go a long way in reducing the burden on a reviewer.

AI Does Not Make Code Review Free#

These principles become even more important in an AI-assisted workflow. Although AI makes large code changes cheap to produce, the cost to review code hasn’t changed. Code review still requires roughly quadratic effort because assessing both structure and impact still requires evaluating every line against other lines in the PR and across the codebase. This means that agentic code review requires a roughly quadratic amount of tokens, scaling with the size of the code change.

In this new paradigm, code review becomes an even narrower bottleneck as the volume of pull requests overwhelms human reviewers. Code review agents solve part of the problem, but often give a false sense of security due to their probabilistic nature. Their reliability gets worse as scope grows. Larger diffs create more possible interactions to pull into context. Even if the model catches many local issues, it may miss larger architectural inconsistencies.

They also lack the judgement from lived experiences humans often take for granted (popularized as “taste”). An off-hand piece of customer feedback, a recent production incident, or a planned product direction can all change whether a technically valid change is the “correct” change to make.²

At the end of the day, code is a liability. Every line of code leads to extra complexity, which requires more extensive testing. AI workflows are a double-edged sword. It’s as easy to add unnecessary complexity as it is to address and reduce complexity. As a result, it’s more important than ever to build on a solid, well-tested foundation of reusable components, so subsequent changes don’t have to rebuild from first principles.³ The less net-new code is introduced, the easier it is to keep pull requests small and contained.

Clear Pull Requests Help AI and Human Reviewers#

AI reviews are helpful as a first pass, often faster than a human and capable of catching subtle bugs that would otherwise be missed. But the best way to make AI review reliable is the same way to make human review reliable: reduce the scope of each change, make the intent explicit, and give the reviewer a narrow, coherent set of changes to understand.

LLMs have the added benefit of making it easier to structure changes for human reviewers. It’s easier to organize changes into logical commits and summarize intent clearly. So really, AI can be viewed as a forcing function to encourage even better pull request hygeine.

Now that code review volume is higher than ever, reviews are often considered a “bottleneck”; however, this is not the correct framing. Human review should be treated as a good bottleneck. It’s the last quality check where judgment, taste, and product understanding are deliberately applied before code ships. It becomes a bad bottleneck when that attention is spent compensating for oversized, unclear, or poorly tested changes.

So help spare both human and AI reviewers from quadratically increasing effort: keep pull requests contained, structured, and clear.