How to Review Agent-Written Code Without Reading Every Line

TL;DR: You review agent-written code safely without reading every line by reviewing in layers ordered by risk, not in file order from top to bottom. Start with the claim: does the stated change match the diff, and does the diff stay inside the task scope? Then verify behaviour with tests you trust, including at least one test the agent did not write. Read in full only the lines that carry risk: security boundaries, data handling, concurrency, error paths, and anything irreversible. Skim mechanical changes with tooling doing the line by line work it is good at. The moment scope, tests, or the risky sections fail inspection, the shortcut ends and you read everything, because layered review is a triage method, not a trust grant.

Key Takeaways

• Review the claim before the code. If the summary of the change and the actual diff disagree, nothing else in the review can be trusted yet.
• Scope is the cheapest high value check. Files changed outside the task and silent dependency changes are where agent reviews are won and lost early.
• Tests carry the middle of the review, but only tests you have reason to trust. Run the existing suite, and demand at least one check the agent did not author.
• Read the risky lines completely. Authentication, authorisation, data writes, migrations, and error handling get a full human read regardless of how clean the rest looks.
• Layered review has an abort condition. Confusion, scope creep, or failing checks demote the change to a full read, every time.

Why does agent code need a different review order?

Because the failure profile is different from human code. An agent produces fluent, plausible, well formatted changes at speed, and its characteristic errors are not typos or messy style. They are confident misunderstandings: the wrong requirement implemented cleanly, an edge case handled by quietly changing its meaning, a helper rewritten in a way that alters behaviour for callers outside the task. The failure catalogue in what actually breaks in coding agents is mostly a list of exactly these moves. A review that proceeds line by line in file order spends the reviewer freshest attention on imports and formatting, and reaches the consequential lines tired. Reordering the review by risk puts the freshest attention where the damage would live.

There is also a volume problem. Agent workflows produce more diffs, and a practice that requires a full careful read of every line either becomes the bottleneck or quietly degrades into rubber stamping. The honest choice is a method that is rigorous where risk concentrates, explicit about what it skims, and clear about when it escalates to a full read.

What do you check first, before reading code?

The claim and the scope. Read the task, then the agent stated summary of what it changed and why, then look only at the diff statistics: which files changed, how much, and in what proportions. 3 mismatches end the quick review immediately. The summary describes work the diff does not contain, or the diff contains work the summary never mentions. Files outside the task area changed without explanation. Or the change is far larger than the task warrants, which usually means the agent refactored its way to a solution and the review now includes every refactor as hidden risk.

Only after the claim and scope agree do tests enter. Run the existing test suite rather than reading the agent report of it, because a summary of a test run is a claim, and claims are what this layer exists to verify. Check that tests covering the changed behaviour existed before the change and still pass, and look specifically for tests the agent edited. An agent that weakens or rewrites a test to make its change pass has told you something essential, and that edit deserves a full read before anything else proceeds. The stuck run signals in how do you know when a coding agent is stuck have a review time cousin here: a diff that thrashes the same area repeatedly is a diff to read completely or send back, not to skim.

Which lines do you always read in full?

Read completely anything that crosses a trust boundary or cannot be undone. That list is concrete: authentication and authorisation checks, permission handling, input validation at external boundaries, database writes and migrations, deletion paths, payment or messaging actions, concurrency and transaction handling, and error handling that decides whether a failure is visible or swallowed. These lines are where a plausible looking mistake becomes an incident, and they are usually a small fraction of the diff, which is what makes the method practical.

Also read in full any code you do not understand on a first pass. Comprehension is a gate, not a courtesy. If a section cannot be explained plainly after reading, it does not get skimmed into production on the strength of passing tests, because tests only check the cases someone imagined. Ask the agent to explain or simplify it, or read it until it is understood. A reviewer who accepts permanent confusion has outsourced the exact judgement the review exists to supply.

What can tooling and skimming honestly carry?

The mechanical layer. Formatting, naming consistency, import order, lint classes, type errors, and dead code are machine checkable and should be machine checked on every change, rather than performed by a human eye scanning for them.

Skimming also carries low risk, well tested interior logic: straightforward transformations, presentation changes, and additions that follow an existing pattern in the same file so closely that the pattern itself is the specification. The discipline is to sample honestly. Read the first instance carefully, confirm the pattern is correct and safe, then verify the remaining instances match the pattern rather than assuming they do.

When does the shortcut end?

At the first failed layer, without exception handling. If scope creeps, if a test was weakened, if the risky sections contain a flaw, if the change cannot be explained, the review stops being layered and becomes either a full read or a rejection back to the agent with specific findings. This abort rule is what separates triage from negligence. It also shapes agent behaviour over time: an agent whose changes are reliably escalated when they wander learns, through review comments, to keep diffs narrow and claims accurate, the same loop as the measurement discipline in we measured AI coding productivity, where what gets checked is what improves.

FAQ

Is it ever acceptable to merge agent code nobody read completely?

Yes, under the conditions in this post: the claim matched the diff, scope was clean, trusted tests passed including checks the agent did not write, the risky sections were read in full, and the mechanical remainder was verified by tooling and sampling. That is a complete review by risk. It is not the same as merging on a summary and a green tick alone.

Can an automated reviewer replace this process?

An automated reviewer is one layer, a good one for mechanical checks and pattern consistency, and it belongs in the stack. It does not replace the claim and scope judgement or the full read of trust boundary code, because those steps exist precisely to catch the confident, plausible errors that automated pattern matching shares a blind spot with.

Bottom Line

Reviewing agent code without reading every line is not about trusting the agent more. It is about spending human attention where agent errors actually live: in the gap between claim and diff, in scope, in tests the agent might have bent, and in the small set of lines where a mistake becomes an incident. Layer the review, write down what each layer found, and escalate to a full read at the first failed check.