A senior engineer's checklist before letting an agent commit.

AI-drafted diffs are getting good. They’re not yet good enough to let go of the human review gate. The gate has to be honest about what it’s checking — otherwise you’ve replaced a slow, thoughtful review with a fast, credulous one, and the review looked like it was still happening the whole time.

Here’s the checklist we run through, on our own engagements, before we approve an agent-drafted change. It’s short by design. A long checklist gets skipped.

The eight items

1. Would I have made this change?

Not “is it acceptable”. Would I have written this? If the answer is no, why not — and is the difference a stylistic preference or a correctness concern? Style is fine; correctness is a merge block.

2. Does the test coverage delta match the code delta?

New code should ship with new tests. New tests without new code is sometimes fine; new code without new tests is almost never. If the agent added twenty lines and no tests, either the change didn’t need tests (rare, needs an explicit reason) or the tests were skipped (unacceptable).

3. What’s the failure mode I’m not seeing?

The agent is optimising for a plausible-looking solution. It’s very good at that. The question is what the failure mode is on the path it didn’t consider. Spend two minutes trying to break the code in my head before I approve it. This is the highest-value two minutes of the review.

4. Is there anything security-relevant?

Auth, secrets, input handling, user-generated content, permission boundaries. The agent will happily produce a diff that touches one of these; the review has to specifically ask “does this diff cross a security boundary?” If yes, the review is a different, slower review.

5. Is there anything migration-relevant?

Schema changes, config changes, environment changes, data-shape changes. Migrations are the class of change most likely to have surprising downstream consequences. The agent doesn’t have the whole system in its head; I do.

6. Is the revert plan obvious?

Every merge is a bet. The bet is safer when the revert is a single git revert away. If reverting this merge would leave the system in a worse state than not merging (partial schema changes, one-way data transformations, downstream consumers already updated), the merge needs a rollback plan documented in the PR.

7. Does the commit message tell the truth?

Agents produce plausible commit messages. Plausible is not the same as accurate. The message should say what the change actually does, not what a reasonable change of this shape would probably do. If the message and the diff disagree, rewrite the message.

8. Would I sign my name to this in six months?

The final question. If I get paged at 03:00 in six months and it turns out this merge caused it, am I comfortable owning it? If not, I need to either reject the change or add whatever safeguard would let me answer yes.

What the checklist assumes

Two prerequisites make the checklist actually work:

The reviewer has to be senior enough. A junior engineer running this checklist on an agent-drafted change is not doing review; they’re performing review. The value of the checklist is proportional to the judgement of the person running it.

The change has to be small enough. A ten-file agent-drafted refactor is not a merge-in-one-review situation. Break it up. Small changes are reviewable; large changes are checkable-for-plausibility, which is different.

What we’ve caught

Two examples worth naming:

An agent-drafted change added a new controller endpoint and forgot the authentication middleware. It passed lint, passed tests (the tests mocked authentication at a higher layer), and would have shipped. Item four caught it.

A different agent-drafted change to a database migration reordered columns in a way that would have broken an in-flight ETL. It was technically correct; it would have caused an incident. Item five caught it.

Both were small changes. Both would have been unremarkable had they been human-drafted; a human would have paused before merging. The checklist is the pause, made explicit.

So what?

AI-drafted code review is a discipline in the same shape as security-focused code review or performance-focused code review. Skim for structure; ask specific questions; refuse to be rushed by a diff that looks tidy.

Speed comes from having fewer, smaller, higher-quality changes to review — not from applying less judgement to each one.

Related reading

• Three ways to bound an agent loop before it eats your budget — the same discipline, applied to a running agent instead of a diff.
• We measured our prompts. Here’s what changed. — the eval side of the same argument.