Every team running an AI coding agent eventually hits the same wall: the agent produces a lot of output, and reviewing that output is now the bottleneck. A terminal transcript is not a review artifact. Here is the checklist I use before I trust an agent's change, and the tooling each line implies.
1. Can I see the change as a diff, not as prose?
If the only thing you get is a summary, you are reviewing a claim, not code. Ask for the diff first. Everything after this line only matters if this one is true. 2. Do I know which directory the agent was in?
Ambiguous working directories are the root cause of a surprising number of "it edited the wrong file" incidents. Pin the path explicitly and make it part of the job record.
3. Is the change isolated to a ref I can check out?
A branch or a worktree means you can test the change yourself, and revert is one command. If the agent mutated your working tree in place, you have already lost the ability to compare. There is a full walkthrough of the worktree approach in the worktree session tutorial.
4. Which commands did it run, and did any of them touch the network?
Install scripts, dependency bumps and curl | sh are where the sharp edges live. Log tool activity, not just the final text.
5. Where did the credentials come from?
If the agent needed a private remote, the token should be scoped to that host and short-lived where possible. Broad credentials handed to an autonomous process is how a small mistake becomes an incident — see git credentials. 6. Can a second person reproduce the run?
Same image, same runtime, same starting commit. If reproducing it takes a verbal explanation, it is not a process yet.
7. What stopped it?
Time limit, token limit, an approval gate, or completion — you should be able to tell from the session state alone. Getting the states named unambiguously is worth doing early; a shared status glossary removes a lot of ambiguity from handoffs.
Once you write the checklist down, the requirements fall out almost mechanically:
Most of this checklist exists because I did the opposite first. I let an agent work directly in a checkout I cared about, reviewed the summary, and merged. It worked — for about three weeks. The failure was not a dramatic bug; it was a dependency change nobody noticed until a deploy.
Since then I run every agent task in a disposable workspace, with the diff as the deliverable. That workflow is what I packaged as TaskHandoff: a self-hosted control plane where each task gets its own Local or Docker workspace, sessions are reviewable, and Git changes arrive as a branch or worktree you can test. Apache-2.0, and the docs start at docs.thandoff.com (installation, FAQ).
What is on your checklist? I am particularly curious whether people gate on cost, on network access, or on the diff size.