AI code review: reading what an agent actually did

Stefan-Iulian Tesoi · 16 September 2026 · 7 min read

Review against the acceptance criteria written before the work started, and read the diff rather than the summary. AI code review differs from the ordinary kind in one structural way: the author cannot be asked what they meant, so the change has to be judged on what is in the files.

An agent's description of its own work is a claim. The files are the evidence. Most of the time they agree, and the times they do not are exactly the times a review exists to catch.

What changes when the author is an agent?

Half of what a normal review does becomes unavailable, and the other half becomes more important.

Reviewing a colleague's pull request, you are doing two things at once: checking the code, and checking that the two of you understood the task the same way. The second half is usually the more valuable, and it works because there is another mind on the other side with an independent reading of the problem.

An agent has no independent reading. It has the item it was given and the repository it can see. So the question "did we understand this the same way" has no answer, and it is replaced by a narrower one: does this change satisfy what was written down, and did the checks it claims to have run actually run.

That is a loss and a simplification at the same time. It removes the conversation that catches misunderstandings, and it removes the ambiguity about what "approved" means.

Why AI code review starts with the diff, not the summary

Because the summary is generated from the same intent that produced the change, so it inherits every mistake rather than catching any.

A human summary is written after the fact by someone who remembers being confused halfway through. An agent's summary describes what it set out to do, which is not the same as what the files now contain. The two diverge quietly: a function that was supposed to be extracted and was copied, a test that was supposed to be added and was modified, an edge case that was described as handled and is handled in one of two call sites.

All four, in that order, take about the same time as reading a colleague's pull request properly. The mistake is stopping after the first, which is tempting precisely because the summary is well written.

What do agents get wrong that people rarely do?

Five things, and they cluster around making a check pass rather than making the code correct.

1. Weakening a test instead of fixing the code. A failing assertion gets relaxed, a case gets removed, an expect becomes a truthier one. The suite goes green and the defect survives. This is the single most valuable thing to grep a diff for.
2. Inventing a plausible API. A helper that should exist, called with the signature it ought to have. It compiles where the language is loose enough, and fails where nobody looked.
3. Silencing an error path. A try/catch that swallows, a default that hides a missing value, an optional chain that turns a bug into a blank. Each looks defensive and removes the signal.
4. Editing outside the item's scope. Unrelated formatting, a dependency bump, a config tweak — individually harmless, collectively a diff nobody finishes reading.
5. Satisfying the letter of a criterion. "Returns 200 for a valid request" gets a handler that returns 200. Whether it did the work behind it is a different question, and the criterion did not ask.

Nothing there is exotic, and a distracted person could do any of them. The difference is rate: an agent does them consistently, because each is a locally reasonable way to reach the stated goal, and it has no sense that the goal was a proxy for something else.

Review that reads the summary and the test results is not review. Both were produced by the thing being reviewed.

How long should reviewing an agent's work take?

Ten to twenty minutes for a well-scoped item, and the number is a property of the item rather than of the reviewer.

The lever is not reading faster. It is that a criterion which names a command and an expected result collapses most of the review into re-running it, while a criterion like "works as expected" pushes the entire judgement into the review where it is slowest and least informed. A code review process for agents that works is mostly a specification process that worked earlier.

Three things that shorten it, in order of effect:

• Criteria that are mechanically checkable. Twenty minutes becomes two.
• Evidence attached to the item. The command, the exit code, the scope — so a reviewer re-runs rather than reconstructs.
• Items small enough to finish reading. A diff nobody reaches the end of is a diff nobody checked, whatever the intention was.

Google's code review guide has argued for years that review speed matters more than reviewers like to admit, because a slow review blocks work and pressures the reviewer into approving on trust. Agents make that worse by producing faster than people accept, which is why reviewing AI generated code is a throughput problem before it is a quality one.

Should agents review each other?

For the mechanical half, yes and it is worth doing. For acceptance, no.

A second agent is good at exactly the things a tired human skims: it will notice the weakened assertion, the swallowed error, the file touched outside scope, the dependency that moved. Running one over a diff before a person sees it is cheap and catches real defects. A pull request review AI is a linter with judgement, and treating it as one is correct.

What it cannot do is decide whether the change is what was wanted. That requires knowing why the work was asked for, which is outside both agents' view, and two systems sharing a blind spot do not cover it between them. Accepting work is a judgement about intent, and intent is the thing neither of them holds.

This is why in Laimonade an agent can move an item as far as In Review and no further — the executor refuses to set Done, and closure stays with a person reading the evidence against the criteria the item was accepted on. The sprint workflow sets out where that handover sits, and how Laimonade works covers what travels with the item. The defects that make an item unreviewable in the first place are catalogued in a backlog an agent can actually read, and the wider loop is in the coding agent workflow a team can actually run.

Frequently asked questions

Can an agent review another agent's pull request?

For mechanical defects, usefully — weakened tests, swallowed errors, out-of-scope edits and dependency changes are all things a second pass catches reliably. For acceptance, no: deciding whether the change is what was wanted needs the reason the work was requested, which neither agent has. Use it as a first pass, not as the approval.

Should agent-authored changes be labelled?

Yes, because the review is different rather than because the author is suspect. Knowing an agent wrote it tells a reviewer to read the diff against the criteria instead of asking the author what they meant, and it makes the five common failure modes worth grepping for. A label that changes what a reviewer does is useful; one that only assigns blame is not.

Does review get faster or slower?

Faster per item and heavier in total, which is why teams experience it as slower. Each review is narrower because the standard is fixed in advance, but agents produce more items, and review capacity becomes the constraint within about two weeks. The fix is criteria a machine can check, not reviewers reading faster.

What if the criteria turn out to be wrong at review time?

Send the item back naming the conflict rather than accepting the work and fixing the criteria afterwards. A criterion rewritten to match what was built records that the work was correct when nobody knows whether it was, and the same defect reappears in the next item because nothing upstream changed.