A review checklist for AI coding agent output (7 things I check before trusting a change)

A developer published a seven-point review checklist for AI coding agent output, covering diff visibility, working directory pinning, isolated branches or worktrees, command and network logging, credential scoping, reproducibility, and termination states. The checklist grew out of an incident in which an unnoticed dependency change from an agent working directly in a checkout went undetected for weeks until a deploy. The developer packaged the workflow into TaskHandoff, an Apache-2.0 self-hosted control plane that gives each agent task a disposable Local or Docker workspace and delivers Git changes as a testable branch or worktree.

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 https://docs.thandoff.com/tutorials/worktree-session . 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 https://docs.thandoff.com/security/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 https://docs.thandoff.com/reference/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 https://github.com/edgestorage/task-handoff : 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 https://docs.thandoff.com/ installation https://docs.thandoff.com/guide/install , FAQ https://docs.thandoff.com/faq . What is on your checklist? I am particularly curious whether people gate on cost, on network access, or on the diff size.