Reviewing AI-written work

Producing work got dramatically cheaper. Checking it didn’t. That asymmetry is the entire subject of this page: an agent can hand you more output in ten minutes than you can carefully read in an hour, so any review habit built on “read all of it” quietly stops functioning — usually without anyone announcing that it has.

It’s worth separating this from its neighbour. Reviewing changes is the moment-by-moment act of accepting or rejecting an edit as Claude proposes it. This page is the larger question that comes after: you now have a finished body of work, and you need a defensible reason to believe it’s correct.

What replaces line-by-line reading is verification of intent and behaviour. State what the change should do before you look at it, then check that it does — run it, use it, try the case you actually care about. A cheap and underrated move is asking Claude to explain the change back in its own words: a confident explanation of something different from what you asked for is the fastest tell there is that the two of you were solving different problems.

Then spend attention unevenly, because uniform attention is how the important thing gets missed. The parts that deserve slow human reading are the ones that are expensive to get wrong — anything touching money, personal data, permissions, deletion, or anything you can’t easily reverse. The routine remainder is exactly what a machine reviewer is good at: /review reads a diff and calls out bugs and rough edges, and cloud review sends the whole change to a fleet of agents hunting for real defects in parallel while you do something else.

A note on scope, so nothing below surprises you. /review, /pr-comments and /autofix-pr are developer-facing tools built around pull requests — genuinely useful if that’s your workflow, irrelevant if it isn’t. The judgment described above survives either way, and so does the underlying safety argument: reviewing confidently is much easier when a bad answer costs you one git command to undo.