How do you review code an AI agent wrote before it lands?
Make the agent's work land somewhere that cannot merge itself, then read the diff rather than the agent's description of it. In practice that means a branch per agent, a review of every hunk before merge, and tests that run on the branch. The summary an agent writes is a claim about the change, and the diff is the change.
What is true regardless of what you pick
- An agent's summary and its diff can disagree, without dishonesty, because the summary is generated from intent rather than from the final state of the files.
- The most common surprises in agent diffs are collateral: a reformatted file, a bumped dependency, a deleted test that was failing, a stray debug line.
- Review effort scales with diff size, so the strongest lever is asking for smaller changes rather than reviewing faster.
- Plan-first workflows, where the agent states its approach and waits for approval, catch wrong-direction work before any code is written and are cheaper than reviewing the result.
- A test suite that runs on the branch converts part of review into something automatic, which is what makes larger volumes of agent work tolerable.
Your options, and where each one stops
| Approach | Good for | Breaks when |
|---|---|---|
| Read the agent's summary and mergeTrust the description of what changed. | Throwaway work, prototypes, and code nobody will run. | The summary describes intent rather than result. Collateral changes are exactly the ones that do not appear in it. |
| git diff before committingRead the working tree changes yourself, in the terminal or an editor. | Small changes, and anyone already comfortable reading diffs. It is the honest minimum. | The change is large, or several agents are working, at which point the diffs pile up faster than they get read. |
| A branch and a pull request per agentEach agent's work becomes a PR that a person approves, with CI attached. | Teams, anything with existing review culture, and getting automated checks for free. | For one person on their own machine the ceremony can be heavier than the work, and PR review still needs someone reading hunks. |
| Plan approval before any codeThe agent states what it intends to change and waits for approval before writing. | Catching a misunderstanding at the cheapest possible moment, before there is a diff at all. | It does not replace reading the result, because plans and outcomes diverge. It reduces review, it does not remove it. |
| Tests and checks on the branchThe suite, the type checker and the linter run before a human looks. | Turning a class of review into something that happens automatically, which is what makes volume workable. | Coverage is thin, or the agent adjusted the tests. Both are common enough to check for specifically. |
What to actually do
Two habits carry most of the value. Approve the plan before the work starts, and read the diff rather than the description before it lands.
Everything else is about making those two affordable: smaller tasks, tests on the branch, and one agent's work at a time so each diff is attributable.
intentic arranges the workflow that way by default. Every agent starts in plan mode, permission is a per-turn decision, finished work waits on its own branch, and the changes are reviewed hunk by hunk before anything reaches your working tree.
Read the diff, not the summary
An agent writes its summary from what it set out to do. The diff records what actually happened, including everything the agent did not think worth mentioning. Those are the same changes that break a build a week later.
Reading every hunk sounds slow and mostly is not, because the surprising parts stand out immediately: a file nobody asked about, a dependency version, a deleted assertion.
- Check the file list before the contents, because an unexpected filename is the fastest signal available.
- Look specifically at test files, since a passing suite means less if the assertions moved.
- Check dependency and lockfile changes, which are easy to skim past and hard to undo quietly.
- Look for debugging leftovers, commented-out code, and files added outside the task's scope.
Make small changes the default
The single most effective review technique is asking for less at a time. A four-file diff gets read properly; a forty-file diff gets skimmed, and skimming is where the mistakes get through.
This also improves the work itself, because a narrow task gives the agent less room to invent scope and less context to lose track of.
Where automation genuinely helps
Type checkers, linters and tests catch the categories of error that are tedious for a person to find, and they scale with the number of agents in a way that human attention does not.
What they do not catch is whether the change was the right thing to build. That remains a judgement, which is the argument for approving the plan up front rather than discovering the misunderstanding in the diff.
Related questions
Can you trust code written by an AI agent?
Treat it the way you would treat a competent contributor who does not know your codebase's history: usually correct in the small, occasionally confident about something wrong, and worth reviewing every time. The practical answer is not trust or distrust, but a workflow where nothing merges without someone reading the diff.
What should you look for when reviewing AI-generated code?
Start with the list of changed files, because unexpected filenames are the fastest signal. Then check test changes, dependency and lockfile changes, and anything outside the task's stated scope. Collateral edits are the usual problem rather than wrong logic in the part you asked for.
Should an AI agent be allowed to commit and push?
Committing to its own branch is fine and makes the work reviewable. Pushing to a shared default branch removes the review step entirely, which is the one control that catches everything else. Keep the branch, keep the merge as a human decision.
How do you review the work of several agents at once?
Serially, one branch at a time, with tests already run on each. Review capacity is the real limit on parallel agents, so the way to raise it is smaller tasks and automated checks rather than reading faster.
Read next
Written against the state of the field in 2026-08. This area moves fast. Spot something out of date or wrong? Open an issue and it is fixed in the next build.