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

EdgeStorage — Tue, 15 Sep 2026 02:08:05 +0000

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.

The checklist

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.

What this implies about your setup

Once you write the checklist down, the requirements fall out almost mechanically:

sessions need an explicit working directory and state,
workspaces need to be disposable and isolated, so a bad run cannot poison the next one (instances),
Git review needs to be native, not bolted on (repository workspace),
automations that repeat a routine need their own audit trail (automation, actions),
and the whole thing has to run where the code runs, or the credential question answers itself badly.

The uncomfortable part

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.

Self-hosting an AI coding agent workbench: running Codex on my own machines

EdgeStorage — Mon, 14 Sep 2026 17:34:57 +0000

Most AI coding assistants assume you are fine sending your repository somewhere else. For side projects that is a reasonable trade. For anything with a client contract, an internal service, or a repository you cannot move, it is not.

The interesting shift of the last year is that the agent part has become a commodity — Codex, OpenCode, Claude Code and friends all expose a CLI you can run yourself. What is still missing for most teams is everything around the agent: where does it run, which filesystem does it see, who reviews the diff, and how do you run the same routine twice without re-explaining it from scratch.

I have been building that layer for a while. Here is the model that ended up working for me, and the concrete pieces you need if you want to reproduce it.

1. Separate the control plane from the machine that runs the agent

The mistake I made first was treating "the agent" as the single thing to manage. In practice there are three distinct things:

a control plane that owns identity, sessions and routing,
one or more nodes — your laptop, a home server, a cheap VPS — that can actually execute work,
a set of workspaces that give each task an isolated filesystem and process tree.

Once those are three separate concepts, everything else gets easier. A session is not "a chat window", it is a job with an owner, a working directory, a runtime and a status. You can list it, resume it, hand it to a colleague, or kill it.

If you want the shape of that in practice, the first setup guide walks the control-plane/node split end to end, and remote nodes covers what it takes to attach a second machine — the interesting part is that node enrollment is a token, not a VPN, so a box behind NAT is reachable without exposing your whole network.

2. One workspace per task, not per conversation

The second change was moving from "one container per project" to "one workspace per task". A task workspace is disposable: it gets a working directory, a defined runtime, and a bounded life. Two agents working on the same repository in parallel stop stepping on each other's files, and cleaning up is a delete rather than an archaeology exercise.

That works with either a local runtime (run directly on the host, reuse the tools you already have installed) or a Docker runtime (each workspace in its own container). I default to Docker for anything that installs dependencies, and local for repositories where I want the host toolchain.

See instances for how workspaces are created and restored, and workspace: repository if you want the Git side of it.

3. Make the agent's output reviewable, not just readable

A terminal scrollback is a terrible review artifact. What I want after an agent finishes is:

the diff, in a form I can read like a pull request,
the commands it actually ran,
a branch or worktree I can check out and test myself.

The practical trick is to have the agent deliver onto a separate ref instead of mutating your working tree. Worktrees are the cheapest version of that: the agent works on its own checkout, git diff shows you exactly what happened, and merging is a normal Git operation. There is a walkthrough of that workflow in the worktree session tutorial.

If the agent needs to pull a private dependency, the credentials question comes up immediately. Scope the token to the specific remote, use it for provisioning, and keep it out of the agent's environment where possible — git credentials goes into that in more detail than is comfortable.

4. Automate the routines you repeat

After a few weeks you notice you are running the same sequence over and over: pull, update a lockfile, run the test suite, fix the lint, open a branch. That is where a small automation layer pays for itself. I ended up with four primitives that compose:

documents — the instructions, versioned,
triggers — what starts it (schedule, webhook, manual),
actions — what it does (run a session, run a command, notify),
schedules — when.

Once those exist you stop pasting the same prompt and start reviewing output instead. The automation docs cover the model, and actions is the part with the sharp edges.

What I would tell someone starting today

Run the agent where the code lives. Latency is the least of your problems; data residency and filesystem access are the real ones.
Give every task a disposable workspace. It removes an entire class of "which file did it overwrite" bugs.
Make the agent deliver a diff, not a summary. Reviewing summaries is how you end up trusting a black box.
Automate only after you have run the routine manually three times.

If you want to try this shape without assembling it yourself, this is exactly what I have been packaging as TaskHandoff — a self-hosted control plane for AI coding agents, Apache-2.0, with local and remote nodes, per-task Local or Docker workspaces, Codex and OpenCode sessions, Git review, and scheduled automation. Start with installation, or skim the FAQ if you are wondering whether it needs Docker or a public IP.

The docs are at docs.thandoff.com (also in Chinese — the site is bilingual, add /en/ for the English tree).

What is your setup? Are you running agents on your laptop, a home lab box, or somewhere properly boring like a VPS? I am curious which of the three layers above people are missing.

DEV Community: EdgeStorage