I have been thinking a lot about how code review may change as agentic programming becomes a normal part of software development.

I do not have a definitive answer—and I am wary of anyone who claims to. We are still at the beginning of this transition, and we will probably make many mistakes before we understand which practices truly work, which need adaptation, and which simply stop making sense.

What I want to share here is a thesis. It comes from practical experience, from ideas I have accumulated over years of reviewing code, and from a recent realization: perhaps AI does not need to replace the reviewer to profoundly transform how we review software.

The metaphor in the title comes from the Bible: “straining out a gnat and swallowing a camel” describes being rigorous about small details while letting something much larger pass by. In code review, the comparison is almost unavoidable: a five-line diff can receive ten comments; a thousand-line diff sometimes receives only “LGTM.”

The joke works because we recognize the behavior.

The smaller the PR, the easier it is to discuss names, implementation details, small optimizations, and local decisions. The larger the PR, the more effort is required just to mentally reconstruct what is happening. At some point, the depth of analysis becomes limited not by the risk of the change, but by the reviewer’s cognitive capacity.

With agentic programming, that imbalance is likely to become more apparent.

Producing code is getting cheaper. Reviewing it is not.

LLM-based tools can 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 mean all of that code is good. It only means that the marginal cost of producing it is falling quickly.

Human review capacity, on the other hand, remains essentially constrained by the same things as always: time, attention, domain knowledge, familiarity with the codebase, and the ability to hold enough context in memory.

Where one developer once produced an amount of code another could reasonably keep up with, agents may significantly change that ratio.

The answer probably cannot be to simply ask reviewers to read more code, faster, and with the same depth.

Nor does it seem prudent to conclude that we should simply remove human review.

My hypothesis sits somewhere in between.

Perhaps the reviewer needs to move up one level of abstraction

Much of traditional code review begins with the diff.

We open the pull request, walk through the files, and start looking at details:

  • this name could be clearer;
  • this loop may be doing unnecessary work;
  • this ToList() may be materializing data too early;
  • this condition is duplicated;
  • this method is growing too large;
  • this error handling looks incomplete.

All of those comments can be valid.

But they share one characteristic: they are very close to the implementation.

There are other questions that may matter even more:

  • Is this PR actually doing what was requested?
  • Are there acceptance criteria with no apparent implementation?
  • Does the diff contain changes beyond the declared scope?
  • Is a rule that once had a single source of authority now being replicated?
  • Is a responsibility moving to a layer that should not know about it?
  • Does this change increase the blast radius of future changes?
  • Are we introducing a structural exception that is likely to repeat?
  • Did behavior change in an area the ticket or MR description does not mention?

These questions are not necessarily harder because they require more knowledge of syntax or a framework.

They are harder because they require context.

And that may be exactly where AI can make a particularly useful contribution.

Code review as signal observation

I have been thinking of a pull request as something that produces signals across different dimensions.

Some changes can signal intention and alignment. Others can signal longevity, coupling, testability, complexity, security, or other properties that matter to that codebase.

I do not see those signals as an absolute quality score.

I prefer something closer to a qualitative classification:

  • Unknown — there is not enough evidence or context to evaluate it;
  • Weak — there is concrete evidence of risk or degradation in that dimension;
  • Adequate — the context is sufficient and there is no material evidence of a problem;
  • Strong — there is positive evidence that the change preserves or improves that property.

The classification alone should not be enough.

It needs a verifiable rationale: where the signal was observed, which evidence supports it, and why it may matter.

For example:

Intention & Alignment — Weak
The ticket requires publishing an event after a given action, but no corresponding implementation appears in the diff.

Or:

Longevity — Weak
The PR introduces a second implementation of a rule that was previously centralized, increasing the chance that future changes will need to be synchronized in multiple places.

The goal is not to turn architectural opinion into algorithmic authority.

It is to make explicit what deserves human attention.

The reviewer does not leave the code. They gain variable zoom.

The best way to explain this idea may be to think about instrumentation.

A pilot does not need to directly inspect every engine component throughout a flight. They have instruments that make certain states visible.

When everything looks normal, they can operate at a higher level.

When an indicator draws attention, they investigate more deeply.

I see potential for something similar in code review.

Instead of having to begin with a linear, uniform reading of every line in a diff, a reviewer could begin with a broader view:

  • intention;
  • behavior;
  • risk;
  • structural impact;
  • alignment with what was requested.

A signal draws attention.

The reviewer then drills down:

signal → rationale → evidence → file → method → line of code

The human still has access to the code and remains responsible for judgment.

The difference is that they gain an augmented view of where it is worth investing cognitive depth.

This is not about taking the reviewer away from the code.

It is about giving them variable zoom.

Guardrails before and after implementation

Agentic programming also makes it more important to think about controls at different points in the process.

Before implementation, repository instructions, conventions, architecture, patterns, and files such as AGENTS.md can guide agents on how to work in that codebase and, just as importantly, what not to do.

Those are preventive guardrails.

But guidance does not guarantee outcomes.

After implementation, an independent analysis can observe what actually appeared in the diff, preferably without relying on the narrative and context carried by the agent that wrote the change.

Those are different functions:

before: how we expect the change to be built;

after: what was actually built and which signals it produces.

Then the human enters the picture.

Accept. Reject. Investigate. Comment. Consciously accept a trade-off. Request a refactoring.

AI can help us see.

The decision remains an engineering responsibility.

From checklists to signals

This way of thinking did not begin with LLMs for me.

For years, I kept informal notes about things I did not want to forget during development and review: accessibility, usability, default values, feature flags, privacy impact, decisions that could affect other parts of the system, and other recurring concerns.

They never became a public checklist or a complete framework.

But they taught me something: a large part of engineering is remembering to ask the right questions at the right time.

Later, while reading The Pragmatic Programmer, I found many of those concerns expressed far more maturely through principles such as orthogonality, DRY, reversibility, contracts, feedback, and fighting software entropy.

The novelty I see now is not the existence of those concerns.

It is the possibility of using AI to observe them systematically in a concrete change, without depending exclusively on the reviewer’s memory and attention.

We do not need to review less. We may need to review at a different altitude.

There is an old tendency in code review: the easier a change is to understand, the more deeply we can analyze it.

That creates a paradox.

Small PRs receive intense scrutiny precisely because they are small enough to allow intense scrutiny.

Large PRs, which may carry more risk, can receive proportionally shallower analysis.

In the age of agentic programming, this asymmetry is likely to become harder to ignore.

My hypothesis is that the future of code review is neither abandoning humans nor trying to preserve exactly the same process while code volume grows.

Perhaps it lies in changing the altitude of the review.

AI can help expose signals about intention, risk, behavior, and structural impact.

The reviewer can begin higher up and drill down when something deserves attention.

The goal is not to outsource judgment to a machine.

It is to make important engineering signals harder to overlook.

I do not know whether this will be the dominant model for code review in a few years. Better approaches may emerge. Some of these ideas may prove wrong. We are all learning while the tools and processes change.

But it seems increasingly difficult to imagine that we will keep reviewing code in exactly the same way while the way we produce it changes so profoundly.

In future posts, I want to explore some of these dimensions individually: what each signal tries to observe, what kind of evidence can support a classification, where AI can fail, and what role human judgment should continue to play.

Because perhaps the challenge is not teaching AI to say LGTM.

Perhaps it is making sure that we do not keep swallowing the camel.