How to review AI generated code

When an AI agent writes code you did not, the review starts with reconstructing intent. The diff becomes readable only after you know what the agent was trying to do, which assumptions it carried, and which decisions it made. Without that context, every line is a potential risk.

Read the stated intent first

Before you open the diff, read the task description, the prompt thread, or the commit message that triggered the change. This is the only place where the agent’s goals are stated plainly. If the agent used a tool like start_work or update_work, the intent is recorded there. Without it, you are reviewing syntax, not behaviour.

Intent often lives in a prompt that you did not write. If the prompt is missing or vague, ask the agent’s owner to restate it in concrete terms: what problem it solves, what constraints exist, and what success looks like. A vague prompt produces a vague diff, and a vague diff is un-reviewable.

Overlap warnings arrive when an agent claims work, which the five tools each contribute to in a different way. If the intent overlaps with work another agent is doing, the overlap warning surfaces it before edits begin. Treat overlapping intents as a red flag: the agents may have made incompatible assumptions without realizing it.

Check assumptions against the diff

Assumptions are the unstated rules the agent followed while writing code. They appear in comments, variable names, or in the structure of the change. For example, if the agent assumed a function would never receive null, but the diff adds null checks, the assumption was wrong. Documented assumptions reduce review time because you can verify them line by line.

Look for assumptions that contradict the stated intent. If the intent says the change is a bug fix but the diff refactors the entire module, the assumption of scope was wrong. Either the intent was misstated or the diff overreached. In either case, the diff needs clarification before you can approve it.

Tools like inspect_work let you read the agent’s inbox and outbox, where assumptions often surface during live prompting. If the diff includes a change that wasn’t discussed in the prompt thread, ask why it wasn’t raised. Unexplained changes are the highest risk because they represent undocumented work.

What to do when the diff is too large

A diff that spans hundreds or thousands of lines is un-reviewable in one sitting. Ask the author to split the work into smaller, intent-aligned commits. Each commit should address one goal from the stated intent, not a laundry list of refactors. If the agent used transfer_work to hand off a task, the new owner can split the work further before marking it review-ready.

If splitting isn’t possible, focus on the core intent and the highest-risk areas. Skip cosmetic changes and concentrate on logic, data flow, and edge cases. Anything that doesn’t touch the stated goal can be deferred to a follow-up change.

Treat unexplained changes as highest risk

An unexplained change is any line or block that doesn’t trace back to a stated assumption, decision, or intent. These changes are risky because they represent work the agent did without telling anyone. Common sources are refactors that weren’t in scope, optimizations that weren’t requested, or defensive programming against imagined inputs.

If you see a change that wasn’t discussed in the prompt thread, ask the agent’s owner to justify it. Either the change belongs in a follow-up pull request, or the intent needs to be updated to include it. Leaving unexplained changes in the diff means you are approving work you didn’t review.

Tools like update_work record live decisions as they happen. If the diff includes a change that contradicts a recorded decision, the decision was either wrong or the diff is wrong. Either way, the contradiction must be resolved before the change can be approved.

Verify tests cover the behaviour that changed

Tests are the only way to know if the change behaves as intended. Focus on tests that cover the behaviour described in the intent, not the code that was written. If the intent says the change fixes a race condition, look for tests that stress concurrent access. If the tests only check the old implementation, they won’t catch regressions in the new logic.

AI agents often refactor code without changing behaviour. If the tests pass after the refactor, it means the tests are tied to the old implementation, not the behaviour. Update the tests to check the behaviour directly, or add new tests that exercise the changed paths. Tests that don’t cover the behaviour are noise, not signal.

Edge cases are where AI changes fail most often. If the intent mentions unusual inputs or error conditions, verify the tests cover them. If the tests don’t, either add them or ask the agent to address the gap. A change without edge-case coverage is a change that hasn’t been proven to work.

What to do when tests are missing or flaky

If the diff lacks tests entirely, ask the agent to add them before you approve the change. If the tests are flaky or cover the wrong paths, mark the change as requiring tests. A change without tests is a change you cannot trust. If the agent used finish_work to mark the task review-ready, the absence of tests should block the final step.

Sometimes the tests exist but don’t cover the behaviour that changed. In that case, the tests need to be updated to reflect the new logic. If the agent’s owner can’t update the tests, either revert the change or ask for a follow-up that adds the missing coverage.

Putting it together

Start with the intent, verify assumptions, flag unexplained changes, and confirm tests cover the behaviour. If any step is missing or unclear, pause the review. The diff is not ready for approval until you can trace every change back to a stated goal. Anything you can’t trace is a risk you didn’t accept.

If you are coordinating multiple agents, the problem scales. Each agent writes code in private sessions, and their context surfaces only at pull request review when mistakes are expensive. Tools like Concord AI keep intent, assumptions, decisions, and evidence in one shared workspace so nothing is reconstructed at review time. The agents call tools like start_work, inspect_work, update_work, transfer_work, and finish_work while they work, not after.

The review itself doesn’t change, but the preparation does. With shared intent and decisions recorded as you go, the diff becomes a summary rather than the primary artifact. You still verify assumptions and tests, but the work of reconstruction is done before the diff is written.

A diff that arrives with intent, assumptions, decisions, and tests is a diff you can review in minutes, not hours. Anything less is a diff you should send back.