Reviewing AI‑Written Code: What To Read First

Why AI diffs need a different review order

Traditional human PRs are usually shaped by intent. You know what the author was trying to do, and the diff tends to be minimal around that goal. Reading top-to-bottom works because the changes often tell a coherent story.

Agent diffs are different. They’re opportunistic: the model may refactor adjacent code, rename things, or “clean up” imports while touching the real change. Some edits are excellent, others are subtly wrong, and they’re all mixed together.

If you read them like human PRs, you waste time on correct boilerplate and may still miss the risky parts. Instead, you need a triage order tuned to where agents fail most: shallow tests, sloppy public contracts, brittle error paths, overeager rewrites, and messy dependencies.

Spot your starting level

Before we get fancy, calibrate how you’re reviewing AI code today. That starting point matters more than any advice.

Ask yourself which description fits you most often:

Level 1 – Line-by-line panic

You scroll from top to bottom, reading almost every changed line. Reviews feel slow and exhausting. You still worry you’re missing things.

Level 2 – Ad-hoc skimmer

You skim and dive into anything that “looks weird,” but you don’t have a stable checklist. Some diffs get a deep look; others get a shrug.

Level 3 – Focused triager

You deliberately start with tests, APIs, and error paths, then only widen if needed. You sometimes send the agent back for a re-do without touching code yourself.

If you’re Level 1-2, this article will pull you toward Level 3 with a clearer order and a simple practice loop. If you’re already Level 3, you’ll refine your checklist and your run-vs-read decisions.

The five-place reading order for reviewing AI code

Agent diffs tend to fail in predictable places. Use them.

For any non-trivial diff, read in this order:

1. 1
   Tests: Are they meaningful, minimal, and actually exercising the change?
2. 2
   Public API surface: Functions, classes, endpoints, messages, DB schemas, events.
3. 3
   Error paths: Exceptions, error returns, retries, edge-case branches.
4. 4
   Over-confident rewrites: Large blocks it rewrote instead of editing in place.
5. 5
   Imports and dependencies: New libraries, cross-module calls, feature flags.

You’re not trying to certify every line. You’re trying to answer: “Given how this change will be used, where could it hurt us?” These five areas are where harm usually originates.

Treat AI diffs like an accident scene, not a novel. You are not here to appreciate the prose; you are here to locate impact. Start with the parts that touch users, data, and failure modes. Everything else is bonus. When in doubt, give your attention to where an incorrect assumption would be most expensive tomorrow.

First attempt: 15-minute triage on a real agent diff

Let’s turn this into practice right now. You’ll run a short triage loop on a real diff, not a toy example.

Pick a diff:

Your 15-minute triage task:

1. 1

   Set a timer for 15 minutes

2. 2

   Open the diff, but don’t scroll from the top

3. 3

   Jump straight to tests, then the other four hotspots, in order

4. 4

   Leave comments or notes as you go

   do not fix code yet.
5. 5

   At the end, decide

   approve as-is, edit yourself, or ask the agent to re-do.

You’re training the habit of where your eyes go first, not perfection. The feedback you get from this run is key.

Reading tests: do they actually test what changed?

Tests are the most visible place agents seem helpful—and one of the most misleading.

When you jump to the test changes, look for three things:

1. 1
   Alignment: Do the tests clearly match the described change? If the diff claims to add pagination, is there a test that fails without pagination and passes with it?
2. 2
   Specificity: Are assertions checking actual behaviour or just existence? A test that only checks a 200 status while ignoring the response body is weak.
3. 3
   Coverage of failure: Is there at least one test for a non-happy path (invalid input, empty result, permission issue)?

A common agent failure mode is tests that only assert that code runs, not that it does the right thing. Another is copying existing tests but changing names, leaving the real behaviour unverified.

Feedback signals from your first attempt:

• If you spot a too-broad, low-value test quickly, your triage is working. Comment on it explicitly.
• If all tests look plausible but you feel uneasy, note exactly why: vague naming, missing edge cases, or magic constants.
• If you realize you’re nitpicking style (spacing, naming) before behaviour, pause and reset to behaviour-first.

After the timer, check a sample of these tests by actually running them or temporarily breaking the code they should guard. If broken code doesn’t fail tests, you’ve uncovered a serious gap—and a good candidate for an agent re-do focused on testing.

Public API surface: silent breaking changes

Next, inspect the code that other systems or teams depend on: exported functions, HTTP endpoints, message schemas, DB migrations, public classes, CLI flags.

You’re looking for signature drift. Did the agent:

These changes often look fine in isolation but quietly break callers.

During your first attempt, pick one affected public entry point and mentally walk a typical caller through it. Does the new contract still make sense? Would any existing callsites behave differently without changing their code?

If you find drift, resist the urge to patch it silently. Leave a comment or tell the agent:

Error paths: where agents stumble most

Agents are decent at happy paths; they’re usually worse at unhappy ones. That’s why error paths are third in the reading order, not an afterthought.

Scan for:

Look for these smells:

On your first attempt, pick one new error path and ask: “If this fires in production at 3am, would I know what happened and what to do next?” If not, that’s a change request.

Strong feedback signal: you catch at least one shallow or overbroad error handler in 15 minutes. Weak signal: you never even reached error handling because the diff description didn’t mention it; update your habit to scan for it regardless.

Over-confident rewrites and imports: what looks fine but isn’t

By now you’ve touched tests, APIs, and error paths. Next are the big chunks the agent rewrote and the imports/dependencies it changed to support them.

These are the changes that “look fine” at a glance but hide deeper risk:

For rewrites, compare old vs new at the level of behavioural checkpoints: inputs, side effects, and outputs. Ask: “Did any step disappear or move?”

For imports and dependencies, you’re watching for scope creep:

If everything looks fine but your gut says “this is more change than we needed,” that’s a signal—not to re-read every line, but to push back on the scope. Ask the agent for a smaller, edit-in-place diff that changes only what’s required.

Spot-checks vs full reviews: run-vs-read decisions

You won’t always have time or need for a full review. After a five-place pass, decide whether to deepen or stop.

Use this table as a quick guide after your 10-20 minute triage:

This is also where run-vs-read comes in:

• When behaviour is complex and test coverage looks solid, lean on running tests over reading every branch.
• When behaviour is simple but error paths or contracts are subtle, lean on reading over more test runs.

Aim for most AI diff reviews to land in the 10-20 minute range, with only critical or hairy changes getting deeper attention.

When and how to ask the agent to re-do

The biggest upgrade in an AI-heavy workflow isn’t catching every bug yourself; it’s pushing work back to the agent effectively.

You should ask for a re-do when:

When you do, be specific. A useful re-do request has four parts:

1. 1
   Scope: What should the change cover, and what must stay untouched.
2. 2
   Constraints: Backward compatibility, performance, security notes.
3. 3
   Testing requirements: Exact behaviours to test, including at least one failure path.
4. 4
   Format: Ask for a smaller diff or a single-file edit if the previous attempt sprawled.

For example:

Your diff changed the shape of the `getOrders` API and added several refactors.

Re-do this change with these constraints:
- Keep the existing `getOrders(userId, { limit, cursor })` signature unchanged.
- Only modify the pagination logic; do not rename other functions.
- Add tests that fail if pagination is off by one page or returns duplicates.
- Include at least one test for an empty result set.

Return a minimal diff touching only the orders service and its tests.

On your next attempt, run the same five-place reading order. You should see fewer, sharper changes and tests that respond to your previous feedback.

Putting it together: a repeatable AI review loop

You now have a focused order and a sense for when to stop reading and start rerunning the agent.

Here’s a compact loop you can carry into daily work:

• Triage (10-20 min): Apply the five-place reading order: tests → public APIs → error paths → rewrites → imports/deps.
• Decide: Based on what you find, classify the diff as “approve with nits,” “agent re-do,” or “needs human redesign.”
• Respond: For re-dos, send a structured prompt; for approvals, ensure tests and monitoring are in place.

Over a week of doing this deliberately, you’ll notice patterns: which agents are trustworthy in which modules, which hotspots are most fragile in your codebase, and where additional automated tests or tooling would pay off more than more human reading.

You’re not trying to outthink the model on every line. You’re building a reviewing style that lets you focus your human judgement exactly where AI is weakest.