In 2026, GitHub announced that use of Copilot Code Review had grown tenfold in less than a year. Code is being produced faster. Reviewers have not multiplied.

Reviewing a PR still takes time: reread the ticket, understand what changed, check out the branch, look at the tests, and make sure nobody has already built the same thing somewhere else.

When you are the only person in your area, like me, this problem already exists without AI. It is very easy to ask your reflection:

“Are you sure about your code?”

And answer yes.

Of course I’m sure. I just spent a week on it.

Wrong. Total failure. Shameful.

Nothing is more misleading than a developer and the pride they feel in the feature they just finished.

When coding agents got really good in early 2025, I thought: yippee, finally a potential “colleague” who could judge my code and find flaws, or a misuse of the language… Because reviewing your own work forever is a bit like the ouroboros of software development.

Today, getting AI to review your code is easy. Copilot, Claude Code, Codex, CodeRabbit, Greptile: there is no shortage of options.

The real question is: how do I stop that AI from giving me a completely useless review?

A reviewer who wants to help too much

A model can be bad in two ways: it can congratulate you on your exceptional naming, or produce fifteen comments, twelve of which describe imaginary problems.

A 2026 study of CodeRabbit analyzed more than 31,000 comment-and-response pairs from over 10,000 PRs. Only 36.4% of the comments studied were accepted. Rejection reasons included false positives, redundant remarks, out-of-scope issues, and misunderstandings of the developer’s intent.

The problem quickly becomes one of signal versus noise. Asking the model to do more does not necessarily help.

A 2026 study finds over-correction on several code benchmarks: depending on the model and task, asking for an explanation or a fix can lead a model to reject correct implementations, sometimes by citing requirements that were never stated. The study does not directly evaluate PR reviews, but it shows that asking for more reasoning does not guarantee better judgments.

A good reviewer sometimes knows how to say, “Nothing to report.” I want the same from my agent: if it has nothing solid, it should stay quiet. That is not easy for an LLM.

Own your code

If I merge this code, it is my code. If it breaks, it is entirely my fault.

“Yeah, but they nerfed 5.6 yesterday…”

It is still your code. You are responsible for building it and for the consequences.

It does not matter whether I wrote it, Claude did, or someone else did: the agent will not be there six months later when the bug shows up.

Its role is not to decide whether I can merge. It should instead tell me: “Try to give me good reasons not to merge this.” I can defend my choices and their tradeoffs. The agent looks for the places where my reasoning falls apart.

What I want it to look for

Linting and formatting do not need an LLM, so I would rather use the model to look for a few specific patterns.

Duplicated code

Agents are very good at reproducing existing patterns. Sometimes too good. If your codebase has bad habits, the agent will repeat them unless you have built the right harness around it.

A new helper appears even though an equivalent one already exists three folders away. A 2026 study of agent-generated PRs found more redundancy and less reuse than in the human contributions it examined.

So when a new abstraction appears, I want my reviewer to search the repository before commenting. Not to ban duplication. Three repeated lines are sometimes better than a premature abstraction.

Tests that test nothing

Agents love producing tests. Oh, do they.

The test that checks the implementation instead of the behavior, the one that mocks absolutely everything, or the bug fix accompanied by a test that already passed before the fix.

For a bug fix, one question is often enough: does this test fail without the change? I do not want my reviewer to count tests. I want it to challenge their usefulness. For now, that is still my job.

Weird naming

Models are generally good at naming things. The problem comes when they invent new vocabulary.

If the whole application calls something Recipe, introducing a CulinaryContentEntity probably does not help. Two names for the same concept quickly turn into two concepts in the code. A glossary can help here: add your domain terms and their definitions.

Unnecessary abstractions

A simple feature can suddenly produce an interface, an implementation, a factory, an adapter, and three extensions.

What do we actually gain from this abstraction today? If the answer is “it might be useful later,” we can probably wait until later. QED.

A reviewer is not a coding agent

GitHub described how better exploration tools initially made Copilot Code Review worse.

The model explored too much of the repository. It behaved like an agent whose job was to write code.

They eventually narrowed its workflow:

diff ↓ potential issue ↓ targeted search ↓ evidence ↓ comment or silence

That approach makes much more sense for a review. When coding, I want an agent to explore. When reviewing, I want it to start with the diff, form a hypothesis, and then look only for what it needs to verify it.

Context is still useful, but it needs a reason to be there: a neighboring file, a referenced symbol, a shared component, or an architecture rule.

A good reviewer is not just a good model with lots of tools. You also have to teach it how to use them.

A comment needs evidence

“This condition could lead to unexpected behavior in some edge cases.”

The agent needs to be specific if it is going to save everyone time.

“When refreshToken() returns 401, retryRequest() can start a second refresh before the first one has finished. See AuthClient.swift:82 and TokenStore.swift:41.”

That gives us the details and precise references. That is what we expect from a tool that can take the time to provide exact feedback.

The agent should answer these questions:

  • Where?
  • Under what conditions?
  • What is the impact?
  • What is the evidence?

I would take this a step further. A review should not be published as soon as an agent thinks it has found something. To limit false positives, it should have to pass a second validation step first:

detection ↓ look for evidence ↓ verification ↓ enough confidence? ↓ comment or silence

This is the kind of architecture we now see in several agentic reviewers: multiple passes or agents look for problems, then another step filters out the least convincing findings.

A reviewer should not only know how to find problems. It should also know how to eliminate its own hallucinations before sending them to me.

Teach it about the project

A model knows how to review Swift, Dart, or TypeScript. It knows the documentation by heart. But it may not know my project or its constraints.

It does not know that I use a feature-first structure, that a particular repository is the source of truth for some data, that an abstraction was deliberately avoided, or that I want to adopt a particular language feature.

That is where AGENTS.md, repository instructions, or a custom skill become useful. Not to explain that a function should have a good name, but to share the house rules:

Architecture: - feature-first - domain independent from API models - DTO → domain mapping at the repository boundary Review priorities: - duplicated sources of truth - duplicated domain concepts - unnecessary abstractions - async and concurrency issues - useless tests

The agent can access the architecture, domain vocabulary, review rules, and, when useful, the ticket or Definition of Done. That is when I can start defining what I expect from the reviewer.

Test your reviewer

Like any agent, it needs to be evaluated.

I can reuse old PRs or create fake ones with a list of issues the agent should find.

Then I can look at its feedback:

  • Correct?
  • Useful?
  • Out of scope?
  • False positive?

The interesting metric is not the number of comments. It is the signal-to-noise ratio.

If my reviewer gives me twenty comments and I have to review them myself for fifteen minutes to find the two useful ones, I have only moved the problem. And code review is the current bottleneck in AI Engineering, so let’s not make it worse.

Every comment can end up in one of three simple categories:

Addressed Won't fix Incorrect

If the reviewer regularly produces Incorrect comments, we need to understand why and refine it. If it keeps raising the same kind of issue that I mark Won't fix, my skill is probably poorly written.

The best review skill is one that has learned from several real reviews.

Not every PR needs the same review

If agents produce much more code but every line gets exactly the same level of human review as before, we have simply moved the bottleneck.

One useful approach is to adapt the review to the blast radius, the potential scope of impact (you will often see the term “blast radius” in other articles).

A copy change does not need the same level of scrutiny as a change to authentication, a migration, or storage, unless you really do not care about your tokens.

And diff size is not enough to tell you the risk:

if user.isAdmin if !user.isAdmin

One line can be enough.

For a simple change:

Agent coding ↓ Agent review ↓ Tests ↓ Merge

For something riskier:

Agent coding ↓ Agent review ↓ Targeted report ↓ Human review ↓ Tests ↓ Merge

A human steps in where their context and judgment actually matter. HITL, or human in the loop, is the term for when a person needs to intervene during an agent’s work.

Make smaller PRs

Finally, there is the least glamorous solution: produce less code at a time. Smaller PRs lead to better results when possible, no matter who created them, a human or an agent.

Agents can turn a simple request into a PR with dozens of files. They like to overengineer, especially when you use a model that is too “intelligent” for the task.

They may have completed the task correctly from a functional standpoint, but touched four files and refactored something because they got carried away, instead of fulfilling the request in two lines.

Instead of:

Implement authentication

I prefer:

PR 1: Domain + contracts PR 2: API implementation PR 3: Authentication state PR 4: Login UI PR 5: Error / retry flows

Creating five PRs with an agent does not cost much anymore. Understanding a 2,000-line PR three days later costs a lot more. You should already be doing this on a human team, too.

Generic tool or custom skill?

Copilot Code Review, Claude Code Review, CodeRabbit, and Greptile integrate directly into the workflow, but you can also build your own solutions.

On my projects, I am currently trying iterative workflows: create an initial skill, test it on simple and complex PRs, evaluate it, and refine it until I get the result I want. That applies to code review and other agent integration workflows too.

In these skills, I include:

  • my architecture
  • my domain
  • my tradeoffs
  • what I consider a blocker
  • what I prefer to ignore.

Gradually, the skill starts to feel less like a generic checklist and more like a colleague we have trained on the project.

A good review can be empty

At first, I mainly wanted a second pair of eyes, an artificial colleague who could spot mistakes I no longer saw after spending three days on the same feature.

But finding things is easy. Finding relevant things, verifying them, and knowing which ones truly deserve my attention is much harder.

In the end, making a practical review agent feels a lot like training a human reviewer who has just joined a project (except they get to skip the Scrum Masters’ Lego activity, lucky thing). We give them the keys to understand the project and what we expect from them, including the idea that a review with no comments can still be a review.

Sources

Some passages in this article were edited, rephrased, and fact-checked with the help of generative AI.