How do you supervise an AI agent that runs without you?

The last handful of posts on this blog went live while I was asleep. A pipeline drafts them, runs them through a set of checks, and pushes to production on a schedule that fires before I wake up. When I get up, I find out what shipped the same way you would: I read the record it left behind. I do not watch it work, because I am not awake for it, and watching was never going to scale to something that runs every day whether I am at the desk or not.

So when a vibe coder asks me how to stay in control now that coding agents run in auto mode by default, executing commands on their own and only pausing for the actions a classifier judges destructive, my answer is not "watch more carefully." The fix is to stop supervising the run and start supervising the record. Make every run leave a trail you can reconstruct it from later: what it decided, what it changed, which checks refused and why. You move your attention off the live event, which you will miss, and onto the artifact of the event, which waits for you. Control becomes a property of the record, not of whether you happened to be looking.

Why did watching the agent ever count as control?

Watching felt like control because for a long time the agent stopped and asked. Every risky step surfaced an approval prompt, you read it, you clicked yes, and the clicking felt like the moment you were in charge. The uncomfortable thing the default change admits out loud is that the click was mostly theater. When a tool asks you to approve almost everything, you approve almost everything; the reported numbers on the auto-mode change put the human catch rate at roughly one in seven dangerous commands, because a person clicking through a firehose is doing pattern-matching, not review. Attention does not scale, and the agent already runs faster than you can read.

Once you accept that live watching was never doing the work you thought it was, the question changes. It is no longer how to watch harder, which loses to arithmetic, and not whether to let a second agent watch for you, which inherits the same blind spot as the thing that wrote the code. The question becomes: what survives the run and lets me hold it accountable afterward? That artifact is the record. A vibe coded system that runs unattended is only as governable as the trail it leaves, so the trail is the thing worth engineering, not the willpower to sit and stare at it.

What does supervising the record actually mean?

On my own pipeline the control is not a person, it is a gate with three independent legs, and each leg leaves its verdict in writing. One leg is the instruction the agent runs under. One is a separate voice and scope check. One is a pre-commit hook that refuses the commit outright if a rule is broken. They do not share a brain, which is the whole point; three independent checks tend to fail in different ways, so a miss in one is usually caught by another. And when any leg refuses, it does not just block, it records the exact reason in a place I read in the morning: a line in the run log, a status flipped in the pipeline state file, a pointer marked blocked with the specific violation quoted back.

That is what supervising the record looks like in practice. A while back the agent tried to ship something off-voice and I was not there to catch it; I saw the refusal sitting in the log when I woke up, with the offending line quoted right there. The gate did the catching in real time, and the record did the reporting on my schedule instead of the agent's. This is the same reason a spec-first habit and honest AI orchestration pay off everywhere else in vibe coding: the durable asset is the written contract and the written trail, not the live moment you were present for. If your leverage depends on you being in the room, you lose it the first night you are not.

What makes an audit trail trustworthy instead of theater?

Here is the part that took a real incident to learn: a record you cannot trust is worse than no record, because you will lean on it instead of your own eyes and it can be confidently wrong. The audit trail has to be legible and correct, not silently wrong. A gate that reports a green check while it actually scanned zero bytes has not saved you time, it has passed without running and written a lie into the exact document you now use in place of watching. The failure surface has to be built with the same care as the happy path, or the trail quietly becomes a comfortable fiction you keep signing off on.

So trustworthy comes down to a few boring properties. Every stage is guarded, not just the one that failed loudly last time, because the unguarded stage is where the silent pass hides. A refusal has to be louder in the record than a success, so a bad night is impossible to skim past. And the checks themselves get tested against failure, deliberately fed a violation to confirm they actually refuse, because a gate you have never seen say no is a gate you are only assuming works. This is why vibe coding needs observability before you hand it the keys: the instrumentation is not decoration, it is the organ you supervise with once you stop watching.

The failure mode nobody plans for

The trap is treating the record as paperwork you generate rather than the interface you govern through. Plenty of teams log everything and read nothing, which is the same failure as watching nothing, only with more disk usage. A trail counts as supervision only if you actually read it and it actually tells the truth, which means it has to be short enough to read, honest about failure, and pointed at the decisions that mattered instead of a flat dump of every line the agent emitted. The question of who owns the code you did not watch has one honest answer, and it is still you; the record is how you make that ownership real instead of nominal.

If you are letting a coding agent run further ahead of you than it used to, and you want the trail it leaves to be something you can genuinely audit instead of a green light you have to take on faith, that is the kind of workflow I help design: the gates that refuse, the state that reconstructs a run, and the honest failure surface underneath both. /work-with-us.

Questions that keep coming up

If the agent runs on its own, why keep any approval prompts at all? Keep them only for the actions that are both irreversible and rare, where stopping costs little and a mistake costs a lot. For everything else, an approval prompt you hit constantly just trains you to auto-approve, so it decays into noise. Reserve the interruption for the handful of moves you genuinely want to think about, and let the record carry the rest.

Is more logging the same as a better audit trail? No, and it is often the opposite. A giant undifferentiated log is where accountability goes to hide, because nobody reads it and a silent failure blends right in. A good trail is curated: decisions, changes, and refusals, each legible on its own, with failures surfaced louder than successes. You are optimizing it for a human reading half-awake, not for completeness.

Can I just have another AI review what the first one did? It helps for some classes of bug and misses the ones that come from a shared blind spot, since the reviewer often reasons the same way the author did. Use it as one leg, never the only leg, and make sure its verdict lands in the same written record you already trust, so a second opinion is something you can inspect rather than another unwatched process you take on faith.