The Five Lenses of AI Code Review

A green build is one lens of five. That was the argument of the last post in this series: your test suite passed because the failure was never in it, and an AI-assisted diff routinely ships four other kinds of problem that a green build says nothing about.

This post is the working version of the fix. Not the diagnosis, the framework: the five reads we run on every AI-assisted diff on client codebases, what each one is looking for, and how to run all five on every pull request without turning your senior engineers into the merge bottleneck.

One diff, five reads

Reviewing AI-generated code is not one read done harder. It is five different reads, each asking a different question, each performed by a different reviewer with different attention.

The distinction matters because the genre is drowning in AI code review checklists, and a checklist is the wrong mental model. A checklist is a list of things to remember while you do the one read you already do. A lens is a whole role: a persona who reads the entire diff hunting for one class of problem and nothing else.

The reason one read no longer suffices is volume plus polish. A December 2025 analysis of 470 open-source pull requests found AI-assisted PRs carried roughly 1.7 times more issues than human-only ones, 10.83 versus 6.45 per PR, and the surface reads clean while the defects sit underneath (The Register).

One human reviewer, sampling that firehose at the same rate they always did, is now under-sampling by definition. More change arrives per week, each diff reads more convincingly, and attention per line drops. Five focused reads keep up where one cannot, but only if a machine does most of the reading.

Each lens below is described the same way: the question it asks, the reviewer persona that asks it, and what that persona catches. The first lens is the one your pipeline already runs. The other four are the ones a green build never sees.

Lens 1: Functional. Does the change do what was asked?

This is the lens you already run, and the one CI automates. The tests written while planning the change pass, the existing tests still pass, and none were skipped, disabled, or deleted along the way. Coverage on the changed files sits at or above where it was before the change.

One extra thing this lens has to verify on an AI-assisted diff that it never worried about before: that the tests still mean something. An agent asked to make a suite go green can do it two ways, by fixing the code or by weakening the test. Functional verification confirms the test names still describe the contract, not the implementation, and that a passing test is passing for the right reason.

Lens 2: Regression. Did it break what worked?

The persona for this lens is the wary teammate, the one who reads your change and asks: tell me every behavior that could have changed silently, even the ones you are sure didn't.

A regression is a behavior that was observable and now isn't, or the reverse. Most regressions are silent, and none are intentional. They are the by-product of a change that did its job and quietly moved something else on the way.

AI-assisted diffs need this read more than hand-written ones do, for a specific reason. When a human writes the change, the old behavior is in their head as they type, so they tend to notice when they disturb it. When an agent writes it, nobody was holding the old behavior in mind, so nobody flinched when it moved.

Lens 3: Security. Did it widen the attack surface?

The persona is a security engineer reviewing a diff before a production merge. Their output is a severity-ranked table of findings, and they skip style entirely. This is a security review, not a linter pass.

Security earns its own lens because the numbers are stark. Veracode's 2025 GenAI Code Security Report, testing more than 100 models across four languages, found that 45 percent of AI-generated code samples introduced at least one OWASP Top 10 vulnerability (Veracode). A problem that shows up in nearly half of generated code cannot ride along inside a general review; it needs a reader whose only job is to find it.

Lens 4: Budget. Does the change stay within latency and resource limits?

The persona reads the change against production-sized data, not the ten-row fixture CI runs on. Most latency and resource problems are invisible at fixture size and obvious at production size, which is exactly why the test suite stays quiet about them.

Not every change earns this read, and that is fine. A pure CRUD change with no query work can skip the budget lens. Skip it explicitly and say so in the pull request; the anti-pattern is ambiguity, not skipping.

Lens 5: Maintainability. Can a future human change it safely?

The persona is the senior engineer who will be on-call for this change in three months, after it has fallen out of everyone's head. Their output is blockers and warnings only, and they skip formatting and naming-style preference the way the security reviewer skips nitpicks.

This is the lens that matters most on AI-assisted code, and the one CI is structurally blind to. Maintainability debt passes every test today. It causes the incident in month three, when the context that would have explained the code is gone and the person paged is not the one who prompted it.

The severity rubric: how findings become decisions

Five reads are only useful if their output is decidable. A lens that says "looks fine" tells you nothing, and a lens that dumps forty nitpicks tells you less. Every lens ends the same way: a short table of findings, each tagged with a severity, nitpicks omitted.

The maintainability lens collapses this to two levels, blocker and warning, because a maintainability finding is either going to page someone or it isn't. Severity is what turns five reviews into one prioritized list a human can act on in minutes. Without it, five lenses produce five times the noise, and the team learns to ignore all of it.

Running all five without slowing merges

The objection writes itself: five reads on every pull request will bury my team. It would, if all five were senior-engineer hours. They are not.

Each lens is a focused review pass with its own instructions, a regression scout, a security reviewer, a wary maintainer, run by a model rather than a hire. The marginal price of one more lens is one more pass, a chat message or a review request, not another person on the team. This is the same economics that made AI generation cheap, applied to verification.

Your senior engineers' job changes shape rather than growing without bound. They stop trying to read every line, a job that is already impossible at agent speed, and start triaging the severity-ranked findings the five lenses produce. They push back on the false positives, confirm the blockers, and make the merge decision with the whole picture in front of them.

If five lenses on day one is too much, start with three, even if two of them are one-paragraph reports. The rule that matters is not five, it is more than one. Running only the lens CI automates is the anti-pattern the whole framework exists to kill.

Where this framework stops

Be careful with the idea that five lenses make code correct. They do not. They catch known classes of problem, and a novel domain bug that violates a rule nobody encoded can pass all five, the same way it slips past a human review.

AI reviewers also produce false positives, and the triage step is not overhead you can optimize away. It is the job. A lens with no severity discipline drowns the reviewer and, worse, trains the team to skim its output, at which point you are paying for reviews nobody reads.

This is a discipline, not a product you install. Tools help: Copilot PR review, Claude Code, Cursor, and managed reviewers like Anthropic's Claude Code Review can each run one or more of these passes. But buying a reviewer bot without deciding which lenses you run and who triages the findings just automates the noise at higher volume.

And none of it rescues a shaky foundation. If your pull requests are large, your version control habits are loose, or your feedback loops are slow, five reads will not save you, because AI amplifies whichever foundation you have. Small batches first, then lenses.

Five questions, asked of every diff

You do not need to hand-read every AI-assisted line. That job stopped being possible the moment agents started writing a real share of your diffs, and pretending otherwise is how diffs start merging unread. What you need is five questions asked of every diff, and a way to triage the answers.

The exact reviewer setups, the instructions that make each lens sharp and the prompt files behind them, are what we teach engineering teams in the workshop, and we are consolidating this framework and the rest of the cluster into a field guide you can request when it ships. The model itself, five lenses and a severity bar, is yours to run this week. It is the second half of how we engineer AI-assisted development on client codebases; the first half, understanding the system before an agent touches it, we have written about in why AI made coding faster but not projects faster and in the codebase archaeology most AI workflows skip.

If your team is shipping AI-assisted code through a review process that still assumes a human thought through every line, that gap is worth a conversation, whether with us or inside your own leadership team.

A green build answers one of those five questions. The other four are now yours to ask.

AnAr Solutions engineers AI-assisted software delivery for teams that have to answer for what reaches production. The five-lens verification discipline, and the workshop that teaches it, grew out of production agentic and AI-assisted delivery work on client codebases, not a slide deck.