Can an AI agent review another AI agent's code?

Short answer: yes, and it catches real defects, but the condition that makes it work is not the brand of the model. It is three other things: the reviewing agent must run in a separate instance with none of the author's context, it must be told to hunt for a new defect rather than confirm the old ones are gone, and a person must still own the merge. In our own content pipeline, between August 12 and August 14, 2026, six technical articles went through a zero-context reviewing agent and all six were rejected at least once before passing, across 14 review rounds. That is our number for reviewing articles that carry runnable commands, not for pull requests against production code, and the difference matters.

Why does the test the AI agent wrote pass on the wrong behavior?

Because the same agent that wrote the code wrote the test, and a test written after the implementation tends to assert what the implementation already does. It goes green on the wrong behavior, and it only turns red the day you try to fix the bug. Here is the smallest honest example we could build, a path allowlist of the kind an AI coding agent needs when it is told which directories it may touch:

def is_allowed(path, allowed_root):
    """Return True when path is inside allowed_root."""
    return path.startswith(allowed_root)

And the test that came with it, in Python's standard library, so there is nothing to install:

import unittest
from allowlist import is_allowed

ROOT = "/home/dev/project"

class TestAllowlist(unittest.TestCase):
    def test_file_inside_the_project_is_allowed(self):
        self.assertTrue(is_allowed(ROOT + "/src/main.py", ROOT))

    def test_nested_file_is_allowed(self):
        self.assertTrue(is_allowed(ROOT + "/src/deep/util.py", ROOT))

    def test_unrelated_path_is_rejected(self):
        self.assertFalse(is_allowed("/etc/passwd", ROOT))

Run it with python3 -m unittest -v and it prints, on Python 3.14.3, with the elapsed time depending on your machine:

Ran 3 tests in 0.000s

OK

Three passing tests, and the function is broken. Two questions the test never asks:

/home/dev/project-secrets/.env   -> True
/home/dev/project/../other/.env  -> True

A sibling directory whose name merely starts with the same string is inside the allowlist, and so is anything reachable by climbing out with ... The green suite is not evidence. It is the author's opinion, restated by a machine.

Does the reviewing AI agent have to be from a different company?

We used to say yes, and we are narrowing that claim. Our earlier article on how to review code written by multiple AI agents states that an agent reviewing another agent is worth it on one condition, that it comes from another company. What we can actually defend is weaker and more useful: what we have observed is the effect of a separate instance with a clean context and an adversarial instruction. We have never run the controlled comparison that would isolate the brand, same model with a clean context against a different model with a clean context, so we cannot tell you how much of the benefit belongs to the vendor difference.

The market is arguing about exactly this. In the thread Reviewing AI code has quietly made me the slowest part of my own team, posted on r/cursor on August 11, 2026 (post 1vllfe1, 25 comments declared, 20 with a body in the page we read), one commenter states the failure mode plainly, that the same model writing code and tests produces a test that asserts whatever the code already does, and another answers that the vendor is irrelevant because models have no ego, and what matters is a separate instance without context contamination running under instructions tuned to be adversarial. Both positions are defensible, and neither side in that thread ran a controlled test either. Treat the vendor question as open.

What makes a second AI agent actually disagree with the first?

Three things, in the order that matters. The first is context. An agent that has the author's conversation in its window inherits the author's assumptions, including the wrong one that produced the defect. A fresh instance that receives only the diff and the requirement has nothing to be loyal to, which is the whole point of the exercise.

The second is the instruction. Asking an agent to check whether the code is correct produces agreement, because fluent code reads as correct. Asking it to find a specific class of defect produces findings. The instruction we use names the classes: something the change touched that it should not have, a test that would still pass if the implementation were wrong, and an assumption made without being stated.

The third is what you ask it to do on the second round, and it is the one most people get wrong. After a fix, the natural instruction is to confirm the reported defects are gone. That instruction is nearly worthless, because it points the reviewer at the part of the code that just received the most attention. Telling the reviewer to look for a new defect instead is what caught, in our own pipeline, three consecutive rounds where the fix itself introduced the next problem.

What does an AI reviewing agent actually catch, measured on our own pipeline?

Our content pipeline publishes technical articles that contain commands, and every article passes through a reviewing agent that did not write the text, runs with an empty context, and is instructed to run the published commands rather than believe them. Counting the last 100 entries of our automation log, a window covering the two days up to August 14, 2026, six articles reached that gate. They consumed 14 review rounds: 8 rejections and 6 approvals. Every one of the six was rejected at least once, and one of them needed four rounds.

The defects were not stylistic, and these three are ones the reviewing agent found, not ones we caught ourselves. A comment count read from the wrong element of an HTML page, which reported a thread as having 68 comments when the thread had 15, because the number belonged to a different post on the same page. A quotation that had lost a single word, turning no soft blocking rule into no blocking rule, which silently removed an entire class of rule from a cited source. And a published command that did not do what the paragraph around it claimed, filtering nothing while the text said it excluded binary files. Those are the kind of thing a fluent read never catches and a machine instructed to verify does.

State the limits of that number honestly, because they are real. It is one pipeline, a two-day window, and the artifact under review is a technical article carrying runnable commands, not a pull request against production code. It shows that a zero-context reviewing agent finds defects the author missed at a high rate. It does not show that the same rate holds for application code, and we have not measured that.

What can an AI code reviewer not catch?

Intent, and absence. An AI reviewing agent reads what the diff contains, so it can judge whether the code does what the code says. It cannot tell you that the feature solves the wrong problem, that the requirement was misread, or that a case which should exist is simply not there. Absence has no line number, and reviewing agents are anchored to lines.

It is also a poor judge of consequence. A reviewing agent will flag a missing null check and a wrong currency rounding with the same tone, and only a person who knows the product knows that one of those is cosmetic and the other is money. That is the reason the merge stays human even when the reading is delegated: approving is an act of responsibility, and responsibility does not transfer to a process you can rerun.

The realistic division of labour is that the machine reads first and the person decides. It narrows the diff you must read carefully, which is worth a great deal on a day when the agents delivered more than a person can read. It does not shorten the part where somebody has to understand what was merged.

How do you set up an adversarial review for AI agent code?

Four rules, each one the fix to a failure we hit. Start a new session, with none of the writing conversation in it. Give it the diff and the requirement, not the story of how the code got there, because the story is where the wrong assumption is most persuasive. Name the classes of defect to hunt: what changed that should not have, a test that would pass with an empty implementation, an assumption never stated, and a number or quotation that does not match its source. Require it to run what can be run, since a command nobody executed is a claim, and a claim is what you were trying to verify.

On the round after a fix, change the instruction rather than repeating it: tell the reviewer that the previously reported defects are already fixed, that it should not spend time on them, and that its job is to find a defect that was not there before. In our pipeline that single change is what turned the second and third rounds from a formality into the rounds that found the most dangerous problems.

Is an AI reviewer enough to let you approve without reading?

No, and the argument for it is weaker than it looks. The case people make is that generation is cheap, tests are cheap, and outcomes are what matter, so a green suite plus an agent review should be enough. The allowlist above is the counterexample: three green tests and an exploitable function. Add a reviewing agent with the author's context and it agrees with the author. Add one with a clean context and an adversarial instruction and it has a real chance of asking why startswith is the check, which is the question that fixes the bug.

What changes with a good agent review is the order of your attention, not the need for it. You read a diff that has already been probed, so you spend your reading where the machine could not go: on whether this was the right thing to build. That is the part nobody has automated, and it is also the part that was always the expensive one.

What this is based on, and what it does not prove

The numbers about review rounds are ours, taken from our automation log on August 14, 2026, covering a two-day window and six deliveries, on technical articles with runnable commands rather than on production pull requests. The allowlist example was written for this article and run on Python 3.14.3 on macOS; the output shown is transcribed from that run. The market positions come from a public thread on r/cursor dated August 11, 2026, which we read through the page rather than the API, and which two of its own commenters call AI written, one of them adding that it is engagement farming, a caveat we pass along rather than hide.

What none of this settles is the vendor question. Whether a reviewing agent from a different company beats the same model running with a clean context is a comparison we have not run, and until somebody runs it, an answer either way is a preference wearing the clothes of a finding.