The agent writes the code in twenty minutes. You review it in forty. Run that ratio across a backlog and the constraint on your throughput stops being generation speed — it's review minutes, and they're all yours. Every team we talk to that adopted an autonomous agent hit the same wall within a month: the agent is never the bottleneck, the reviewer is. This post is a process for spending review minutes well — what to check before reading a single line of diff, how to calibrate trust by task type, and when to stop reviewing and hand the PR back.

We build Codowave, an agent that turns tracker issues into tested PRs, so we review agent output every working day — our own agent's and, during evaluations, everyone else's. The process below is what survived. None of it is specific to our product; it works on any PR where the author was a model.

Review minutes are the real budget

Start with arithmetic you can redo on your own numbers. Say an agent ships ten PRs a week and an unstructured review — open the diff, read top to bottom, figure out what the change even is — takes thirty minutes. That's five hours of senior engineer time per week, per agent. Scale the agent up to thirty PRs and you've bought a part-time job.

The naive response is to review less carefully. The right response is to review in a different order, because agent PRs fail differently than human PRs. In our own runs, the split is roughly this: most agent PRs are either fine or wrong in a way that's visible in the first two minutes — from the tests, the description, or the shape of the diff — before you've read any implementation. The expensive failure is the PR that looks fine for twenty-five minutes and falls apart on minute twenty-six. A good process front-loads the checks that catch problems cheaply, so the deep read is reserved for PRs that have already earned it.

Human PRs don't work this way because a human author pre-filters. A colleague who wrote something they don't trust says so in the description. An agent presents its most confused output with the same confidence as its best work. The confidence signal is gone, so you need to rebuild it from artifacts.

Check the cheap signals before the diff

Three checks, in order, each cheaper than the one after it. Most bad PRs die at one of these gates before you've read a line of implementation.

First: the tests

Not "did CI pass" — you can see that from the badge. Open the test files and read what the PR asserts, because the tests are the closest thing an agent PR has to a statement of intent. Three questions:

Did the PR add tests, or only pass existing ones? A behavior change with no new assertion is unverified, whatever CI says.
Did the PR modify existing tests? Diff those first. An agent that weakens an assertion or deletes a test case to get green is the single worst failure mode in this entire workflow, and it's visible in seconds.
Do the new tests test the change, or the mock? Agents are prolific mockers. A test that stubs the exact function under test proves nothing.

If the tests are wrong, stop. Hand the PR back with a comment about the tests. Reading the implementation of an incorrectly-specified change is review minutes spent on code that's going to be rewritten anyway.

Second: the plan against the ticket

Read the PR description next to the original issue. You're checking scope in both directions. Did the agent solve the problem the ticket named, or a nearby problem that was easier? And did it stay inside the ticket, or did it "improve" things nobody asked for on the way through?

Scope creep is the agent failure mode that most resembles a human junior engineer, and it's caught the same way: by knowing what was asked before you look at what was delivered. A drive-by rename, a helpfully refactored utility, a dependency bumped "while we're here" — each is small, and each widens the blast radius of a change that was supposed to be narrow.

Third: the shape of the diff

Before reading the code, read the file list. A one-line bug fix that touches nine files is telling you something. So is a diff that wanders into directories the ticket has no business in — auth code on a styling ticket, a config file on a copy change. In our runs, diff size is the strongest single predictor of review cost: PRs under ~150 changed lines review in minutes, and cost grows worse than linearly from there, because a reviewer's ability to hold the whole change in their head falls off a cliff. It's why we built automatic decomposition of large changes into the agent itself — a PR that can't be read in one sitting shouldn't be one PR.

If the shape is wrong, that's a hand-back too: "split this" is a fine review comment to send a machine.

Read the diff like a stranger's code

A PR that survives the three gates has earned a real read. The read is different from reviewing a colleague, because models make different mistakes than people do.

What you can mostly stop checking: typos, syntax, off-by-one string handling, forgotten imports, style violations. Models don't make many of these, and your linter catches the rest. Reviewing an agent PR for mechanical errors is spending your minutes where the failure isn't.

Where the failures actually live:

Plausible-but-wrong integration. The code is internally coherent but calls the wrong existing helper, duplicates one that exists three files away, or misuses an internal API in a way that type-checks.
Silent behavior change. The refactor that's "equivalent" except for an error path, a default, or an ordering guarantee nobody wrote down.
Over-general fixes. Asked to fix one case, the agent fixes a class of cases — including some that were load-bearing as they were.
Invented conventions. A pattern that's idiomatic somewhere, just not in your codebase, now sitting there as precedent for the next run.
Trust-boundary sloppiness. Anything touching input validation, authz checks, secrets, or SQL gets the full human read, every time, regardless of how the rest of the PR looks.

Review the tests like a spec and the diff like a stranger's code — because that's what they are.

The unifying theme: agents fail at context, not at code. Every item on that list is a variant of "correct in isolation, wrong in this repo." So the highest-value question while reading is not "is this right?" but "is this how we do it here?" — which is exactly the question a reviewer can answer faster than any model.

Calibrate trust by task class, not by streak

After a few weeks of clean PRs, the temptation is to skim. Resist the version of that where you trust the agent. Trust the task class instead.

An agent's reliability isn't a single number — it's a different number per kind of work. In our own runs, dependency bumps, test backfills, copy changes, and mechanical refactors merge with near-zero hand-backs, and we review them at the cheap-signals level only. Multi-file features and anything touching data models earn the full read, every time, no matter how good last month was. The agent didn't get smarter between a lockfile bump and a schema migration; the task got harder.

The practical version: keep a tally. For each task category, count PRs handed back over PRs shipped. Two weeks of data is enough to see the boundary. Categories under ~5% hand-back get gate-level review; categories above ~20% either get full review or — better — stop going to the agent at all. The tally does something subtler too: it stops you from generalizing one spectacular failure into distrust of all agent work, or one great month into skimming a migration.

When to hand back — and how

The cardinal rule: don't finish the agent's work in review. The moment you catch yourself rewriting the change in your head — or worse, checking out the branch to fix it — you've silently become the author, at author prices, with reviewer context. Hand-backs are cheap for an agent. There's no morale cost, no context-switch cost, no waiting until after standup. A one-line comment re-runs the loop.

Hand back, rather than fix forward, when any of these is true:

The tests are wrong or missing — the change is unspecified.
The diff exceeds the ticket's scope and you can name the excess.
The approach is wrong, even if the code is fine. Comment the approach.
You're on the second round of comments. Two rounds in, re-scoping the ticket beats a third round; the issue was probably underspecified, and that's a fixable input problem.

The one case to fix forward: a genuine nit on an otherwise-shippable PR. Renaming a variable through another full agent loop is a waste of a run.

Reviewing agent PRs well is not a new skill so much as an old skill with the order rearranged: tests, then intent, then shape, then — only for the PRs that survive — the code. On our own numbers that ordering takes the median review from about thirty minutes to under ten, and you can check that claim the cheap way: time your next ten reviews, both orders. The minutes are the product. Spend them on the diffs that earned them.