How to review code written by an AI agent

Reviewing code written by an AI agent means checking three things before the code itself: that the change does what was asked and nothing more, that the evidence for it is real, and that the tests were not bent to fit. Agent-written code is usually well formatted and reads confidently, so the problems tend to sit in assumptions, scope and verification rather than in obvious mistakes. A good review reads the task, the test results and the test diff first, then concentrates on the parts of the change where an error would be expensive.

This page expands the section on reviewing AI-written code in What is AI code review?.

What is different about agent-written changes

Human and AI changes fail in different ways, and a reviewer used to one can miss the other.

• Plausibility. Agent output compiles, follows the house style and has helpful comments. Surface quality is not a signal of correctness the way it often is with human work.
• Volume. An agent can produce a change touching dozens of files in minutes. The reviewer's attention, not the author's time, becomes the limit.
• Confident summaries. Agents describe their own work as complete and tested. That description is a claim, and it is sometimes wrong in ways the agent did not notice.
• No shared memory. A colleague remembers why the code was written a certain way. An agent only knows what was in its context, so it may undo a deliberate decision it did not know about.
• Scope drift. Agents fix things they notice along the way: a rename here, a refactor there. Each may be reasonable, but together they make the change harder to review and riskier to ship.

Start from the task, not the diff

Read the task the agent was given before opening any file. Then ask:

1. Does the change do what the task asked?
2. Does it do anything the task did not ask for?
3. Did the agent interpret an ambiguous task in a way you would not have?

An agent that misunderstood the task can produce a correct-looking implementation of the wrong thing. That is easier to see when you hold the request in mind than when you read code first and infer the intent from it.

Anything outside the task's scope deserves a closer look or a separate change. Unrequested edits to configuration, CI definitions, dependency manifests or authentication code are the ones to stop on.

Read the evidence before the code

Before reading the implementation, check what has been verified.

• Did the tests run on this exact version? A test run from before the last edit says nothing about the current code.
• Which tests ran, and were any skipped? A green result from a suite that skipped the relevant tests is not a pass.
• What did automated review find, and how was it triaged? Open high-severity findings, or findings dismissed without a reason, tell you where to look.
• Was anything not verified at all? "No tests ran" should be visible, not hidden behind a neutral status.

If the evidence is missing, the review is harder, and the approver should know that before deciding.

Read the test diff before the code diff

Tests are where an agent under pressure to make things pass can take shortcuts. Look for:

• tests deleted, commented out or marked as skipped;
• assertions loosened, for example an exact comparison replaced with a check that a value exists;
• expected values changed to match whatever the new code returns;
• mocks so broad that the code under test never really runs;
• new tests that execute code without asserting anything about the result.

A test diff that only adds tests and assertions is a good sign. A test diff that changes existing expectations needs a reason you can find in the task.

Mistakes coding agents commonly make

These patterns come up often enough to check for on purpose.

Swallowed errors and silent fallbacks deserve special attention. They make tests pass and demos work while turning a visible failure into wrong data, which is far more expensive to find later.

Keeping large changes reviewable

When a change is too big to review properly, the options are better than approving it unread.

• Split the task. Agent work is cheap to redo. Ask for the change in smaller pieces with a clear boundary each.
• Read by risk. Read files that handle money, authentication, personal data, permissions and persistence line by line. Skim generated or mechanical files.
• Protect sensitive paths. A rule that requires an extra review for changes under infra/ or CI definitions means those files never slip through inside a large change.
• Reject rather than repair. If the approach is wrong, a rejection with a clear reason and a better task is often faster than editing the agent's code by hand.

Approving responsibly

An approval should mean that a person looked at the change and the evidence and accepts responsibility for shipping it. Three habits keep it meaningful:

• Separate the author and the approver. The person who wrote the task should not be the only one approving the result when someone else can.
• Re-approve after edits. If the change is modified after approval, the earlier approval no longer applies to what will ship.
• Write a reason when you reject. It helps the next attempt, whether by a person or an agent.

How AI CodeOps supports the review

In AI CodeOps, every code change from a session opens a review request. On the session page, the approver sees the proposed changes, the findings and the Quality gates panel with the test results, which also shows when a change was not verified because tests could not run. A diff over 60 KB is refused with "Split the task into smaller changes", so reviewers are not handed changes too large to read.

The person who started the session cannot cast the approving vote while someone else in the workspace can approve. A rejection needs a reason and ends the request. Editing a change after approval sends it back for approval, and a test result only counts for the version it ran on. Workspace policies can require an approval for changes to paths such as infra/**, or deny them. A follow-up session can build on a change instead of starting over.

See Approvals and policies for who can approve and how votes are counted, Quality gates for what blocks a change, and What are quality gates? for the wider pattern.