Review Checklist: Report Only What's Actionable

Review AI output against a fixed checklist. Report only actionable findings; don't pad with style and hypotheticals.

Reviewing AI code, the worst is "I just feel something's off" and then hunting line by line. The faster, steadier way: run a fixed checklist. It either is or it isn't. That way you neither miss things nor overdo it.

After reading, you should be able to answer:

• What are the fixed points for reviewing AI output?
• What counts as an "actionable finding"?
• How do you avoid over-investing in review?

A fixed checklist

1. Against done criteria

• Tick each done standard you defined earlier
• "Didn't meet it" → reject directly, don't loop on details

2. Scan structure + data flow

• Which spots the change touched, which callers it affects
• Whether it overstepped and changed something you said not to touch

3. Check gaps and boundaries

• Input validation, error handling, permission checks
• "Should be handled, but isn't" places

4. Dependency review

• Whether it pulled in unfamiliar or unnecessary heavyweight dependencies

5. Close with a verdict

• Pass / needs change / reject, with location and concrete suggestion

Report only actionable findings

Only report what a developer can act on:

• Location + concrete suggestion → report
• Style preference, hypothetical design ("if requirements change later") → don't report
• Concerns you can't verify → don't report

Can a finding let AI or you "start fixing right now"? If yes, it's worth reporting. If it's just verbal worry, hold it—don't pollute the feedback list.

Don't over-review

• Don't second-guess decided architecture (that's design review, not code review)
• Don't nitpick perfectionism
• Save your energy for the 5% that breaks, not all 100% equal attention google-patterns

When to stop reviewing

AI writes and AI reviews has a distinctive failure: both sides are eager, so they can keep each other busy indefinitely. One team measured a single pull request that went through more than fifty rounds overnight. Tracing where the reviewer kept pointing, roughly six in ten of the flagged lines had been there since the reviewer's first pass — it wasn't finding new bugs, it was finding a few more old ones each round. cc-review

So "a few more rounds never hurts" is an illusion. Four practices make review converge:

• Cap the rounds. After three, ask the author to step back and reconsider the approach instead of continuing to patch inside the comments.
• Review only the delta after the first few passes. Full diff on round one; from then on, only what's new.
• Flag the class of bug, not the instance, so the author fixes every occurrence at once.
• Never re-post a finding already raised. If the author rejected it with a reason last round, it doesn't come back.

The measure isn't "how many rounds" but whether each round surfaces fewer real findings. If round three is still reporting things round one should have caught, the problem isn't the reviewer — it's the structure or the requirement upstream.

Who reviews depends on risk

Not every change deserves the same human investment. A workable split keys on the change itself, not who wrote it:

Two rules go with it: an approval covers one specific commit — new commits the system can't vouch for (an agent's push, a hand-resolved conflict) invalidate it and it must be re-given; and a bot's approval never fills a required human slot. It can clear a low-risk change; it cannot stand in for a person.

The point of the split is to spend human attention where judgment is actually needed: should we build this at all, does it touch a risky path, will others copy this architecture, is the evidence sufficient. Whether the code reads nicely is left to the layer that exists for exactly that.

After review, two roads

• It passes → enter verification: one command that runs all validation layers
• It doesn't → send it back to AI, fix, review again, until it passes

Multiple review rounds need a ledger. Write down, for every round, which issues were raised, which were fixed, which you rejected and why. The next round reads the last one first, so a finding the user already rejected does not come back. Never rewrite earlier rounds — "what did we abandon at round three" is as useful to the next step as "what did we change."

Reviewing is where "judgment" lands; verifying is where "evidence" lands. Once you've reviewed, let the evidence speak for you.