A tweet showing that small PRs receive intense scrutiny while large PRs get a quick “looks fine”

TLDR;

This article captures my thinking about the future—or rather, the present—of code review, where reading code alone is rapidly losing relevance. I propose analyzing the signals emitted by code as sensors, much like an instrument panel, instead of relying only on a linear reading of the code. These sensors can quickly identify what deserves more attention and guide deeper investigation.

Written from my ideas, with AI assistance in the editing process.

Where review loses its way

In code review, we are often rigorous where review is cognitively cheap and superficial precisely where risk may be greater.

With agentic programming, that asymmetry is no longer just a process curiosity; it is an operational problem. Producing code is getting cheaper. Understanding context, estimating impact, and judging trade-offs remain expensive.

That is why I believe code review needs to change altitude. Not to remove the reviewer, nor to delegate judgment to AI, but to give people a better view of where their attention truly matters.

I have applied this idea in practice and seen good results: when review starts with signals about intent, risk, and structure, it becomes easier to reach the parts of a diff that deserve deep investigation. Code remains the final evidence. The difference is that we do not need to treat it as a uniform sequence of lines.

The bottleneck is no longer producing code

LLM-based tools already write features, tests, migrations, integrations, refactorings, and fixes at a speed that would have been difficult to imagine a few years ago. That does not guarantee quality. It means the marginal cost of producing a change has fallen.

Human review capacity has not followed the same curve. It is still constrained by time, attention, domain knowledge, familiarity with the codebase, and the ability to maintain context in memory.

The result is predictable: the larger the PR, the more energy is spent simply reconstructing what happened. The depth of analysis becomes limited not by the change’s risk, but by the cognitive capacity available to review it.

Asking reviewers to read more code, faster, and with the same depth does not solve that equation. Neither does eliminating human review. The path I have been exploring is using AI to make explicit the places that need human judgment.

Signal-guided review

A diff is not merely a collection of changed lines. It produces signals about important properties of a change: whether it matches what was requested, preserves future options, respects architectural boundaries, can be verified, and leaves the system simpler or more fragile to evolve.

Code review dashboard with Scope & Intent, Engineering Rigor, and Longevity signals, leading from evidence to code

These signals are not an automatic quality score, nor should they become algorithmic authority. They are hypotheses accompanied by evidence: something that deserves to be seen by a person with enough context to agree, disagree, or investigate.

A signal is not a blocker either. Mature, mechanical rules—for example, mandatory tests, a security policy, or a lint convention—can and should be checked automatically. A signal comes in where a rule does not reach: it helps reveal a change whose impact, intent, or trade-off still calls for interpretation.

A simple example:

Longevity — attention needed This PR introduces a second implementation of a rule that was previously centralized. Future changes may require synchronization across multiple places.

The value of that comment is not in the label. It is in the path it opens for investigation: is the rule really the same? Is there a legitimate reason to separate it? Is the duplication temporary? What cost will it create for the next change?

From signal to line of code

I think of it as instrumentation. A pilot does not inspect every engine component throughout a flight. They use instruments to notice relevant states and investigate more deeply when something draws attention.

A reviewer needs the same kind of variable zoom:

signal → evidence → file → method → line of code

Instead of beginning with a linear, uniform reading of the entire diff, review can begin with a broad view of intent, behavior, risk, and structural impact. When a signal appears, the reviewer descends into the code and exercises the judgment that no classification can replace.

This is not reviewing less. It is investing depth where it has the greatest return.

Guardrails first; observation afterwards

Agents need guidance before implementation: repository conventions, architecture patterns, domain constraints, and instructions such as those recorded in AGENTS.md. These guardrails reduce predictable errors and make expectations clear.

That guidance needs to be retrievable institutional knowledge, not a collection of memories scattered across people, chats, and old documents. Engineering standards, architectural decisions, and quality criteria work better when they have a clear source, are maintained alongside the work, and can be consulted by both implementers and reviewers.

But guidance does not guarantee an outcome. After implementation, an independent analysis needs to observe what actually appeared in the diff, without relying only on the narrative of the agent that produced the change.

These are complementary responsibilities:

  • before: how we expect a change to be built;
  • after: what was built and the signals it produces;
  • finally: the human decision to accept, investigate, comment, or request refactoring.

AI helps us see. Engineering responsibility remains human.

Continuous feedback, not only the final PR

Signals do not have to wait until a pull request is opened. Some can appear while a change is still being built, others in the local environment, in CI, during another round of review, or even in the specification that comes before the code.

This does not eliminate the review moment. It becomes the place where accumulated evidence comes together and judgment decides whether the change is ready, needs further investigation, or should return for another iteration. The earlier a reliable signal appears, the lower the cost of fixing it—and the more human attention remains for what truly cannot be automated.

The direction of this series

In future posts, I will explore these signals in three groups.

  • Scope & Intent: Scope alignment and Reversibility.
  • Engineering Rigor: Defensive programming, Architecture & design, Change verifiability, and Scale & performance.
  • Longevity: Maintainability, Observability, Consistency, and Automation surface.

They are not a checklist for approving or rejecting pull requests. They are lenses for asking better questions about a concrete change and finding the evidence that supports a decision.

For me, this is the most promising future for code review: not trying to read every line with the same depth, nor teaching a machine to say LGTM, but using AI to make relevant signals harder to ignore.

The goal is simple: make important risks and decisions more visible before they reach production.