How to review a pull request an AI wrote
Reviewing agent-written code is a different job from reviewing a colleague’s. What to check first, which failure modes are specific to agents, and how to review a 4,000-line diff without reading every line.
Reviewing agent-written code is a different job from reviewing a colleague's, because the failure modes are different. A human writing 4,000 lines has thought about the change for a day. An agent produced it in four minutes from a prompt, and the parts most likely to be wrong are not the parts a normal review looks at.
Start with what was asked
The first question is not whether the code is good. It is whether the code does the thing the session was asked to do. Agents drift: given "add rate limiting to the API client", a session may deliver rate limiting, plus a refactor of the retry logic, plus a change to the error type that nobody asked for. Read the goal, then read the change against it, before reading the code on its own terms.
The five agent-specific failure modes
| Failure | What it looks like | How to catch it |
|---|---|---|
| Silent deletion | A function that existed is gone, unmentioned in the summary | Diff the symbol list, not the lines. See deletion accountability |
| Stubbed work | todo!(), pass, or a function that returns a constant | Grep for stub markers; check that new functions have bodies that branch |
| Test theatre | Tests that assert the code does what it does, whatever that is | Read the assertions, not the count |
| Scope drift | Files touched that the task had no reason to touch | Compare the changed-file list with the declared scope |
| Plausible wrongness | Code that reads correctly and inverts a condition | Run it. Read the branch conditions out loud |
Reading a large diff without reading every line
Sort the change by structure rather than by file. What functions were added, changed, deleted or moved? Renames and moves usually account for most of the line count and almost none of the risk, so removing them leaves a much smaller diff that contains the actual decisions. This is what a semantic diff produces.
Then review in this order: deletions first, because they are the least recoverable; then changed function bodies; then new functions; then everything else. Most reviews go top to bottom through the file list, which puts the riskiest part of the change wherever the alphabet left it.
Do not let the author summarise itself
A pull-request description written by the model that wrote the code is not review, and it is confidently wrong in exactly the cases you care about. A check computed from the change itself, against the goal that was recorded before the work started, is a different kind of evidence. Aura reports which parts of the goal are wired, which are partly wired and which are missing, from the AST rather than from a summary.
What to automate
- Blocking unexplained deletions at commit time, so they never reach review.
- Flagging layer violations, such as a UI file importing a database client.
- Recording the session, the goal and the intent with the commit, so the next reviewer inherits context.
See also: intent poisoning, and proving a change against its goal.
How do you review a pull request written by AI?
Start from what was removed and what was widened, not from the top of the diff. Agent-written code reads well, so the usual scan for sloppiness finds nothing. Check deletions, changed defaults, loosened conditions, and whether the stated goal is what the diff actually does.
What should you look for in AI-generated code?
Deleted guard clauses and error handling, widened permissions or scopes, silently changed defaults, and tests edited to match the new behaviour rather than the other way round. These are the failures fluency hides; style problems are not the risk.
Is reviewing AI code different from reviewing human code?
Yes, because the signals differ. A tired colleague writes obviously rough code in one place; an agent writes uniformly polished code with a specific wrong assumption threaded through it. You lose the visual cue that something needs attention and have to check systematically.
How do you review a very large AI-generated pull request?
Do not read it linearly. Take the removals first, then the interface changes, then anything touching auth, money or data loss. If a diff is too large to review honestly, the correct outcome is to send it back to be split, not to approve it faster.
Should AI-generated pull requests be marked as such?
It helps, because it changes what the reviewer looks for. What helps more is recording which session and which instruction produced the change, so a reviewer can compare what was asked against what landed instead of inferring intent from the diff.
Aura Crew vs Claude Code Loops: the autonomous work-loop, compared
Claude Code defines four loop types — turn-based, goal, time, and proactive. Aura Crew is the same idea productized: a dependency-ordered work-loop with proof, collision-safety, and any agent. Full comparison.
Autonomous coding agent loops, explained: turn-based, goal, time, and proactive
A coding agent loop is an agent repeating cycles of work until a stop condition is met. The four types explained — turn-based, goal-based, time-based, proactive — with when to use each and how to keep quality high.
How to run multiple coding agents in parallel without merge conflicts
Running several AI coding agents at once collides on shared files. The fix: a worktree per agent, a live team radar, and soft-to-hard zone claims so parallel agents never touch the same symbol. How Aura Crew does it.
Goal-based agent loops: giving a coding agent a definition of done
A goal-based loop keeps a coding agent iterating until a success criterion is met. The trick is a deterministic definition of done — tests, a score, a proof — not an LLM guessing at "good enough." How to write one.