Powerful coding agents need a preview and undo protocol

I use AI coding agents, and I’m increasingly uncomfortable with the idea that “review the diff” is enough when the agent can touch production-adjacent systems. Before execution, I want a machine-readable action plan and rollback bundle: proposed file changes, dependency versions, database migrations, required permission scope, and the exact tests that will run.

The important part is an automatically tested revert path, not a ceremonial approval screen. A plan that says “migration is reversible” without exercising the reversal is mostly paperwork; destructive data changes may not be recoverable at all. Existing previews and undo mechanisms show this is technically plausible, but not magically safe.

My view is that this adds useful accountability and recovery for powerful agents, provided the output is executable by CI rather than pasted into a ticket. Would teams actually require this “preview and undo” protocol under deadline pressure? I’d like counterexamples from developers who have shipped agent-generated changes.

The permission section may be the highest-value piece. A rollback bundle that runs with broader credentials than the original change creates a second attack path. I’d want the preview to state both requested and actually granted scope, with simulation treated as evidence rather than proof.

I’m sympathetic, but the protocol has to degrade gracefully. For a one-file documentation fix, generating a full migration-style artifact is pure friction. Make the bundle mandatory when the agent requests production access, changes dependencies, or alters data; let low-risk work stay lightweight.

The distinction between accountability and recoverability matters. A recorded plan helps explain what was intended, but it does not restore deleted data. I’d support the proposal if teams label those as separate guarantees instead of calling every rollback bundle a safety net.

“Automatically tested revert” sounds good until the revert passes tests against yesterday’s schema and fails against today’s traffic. I’d require the bundle to declare its assumptions and test the forward and reverse paths against a representative state, not just an empty fixture.

The adoption question is mostly interface design. If the agent produces a readable summary plus a CI artifact that can be approved in one click, people may use it. If it opens six forms and asks for ritual confirmations, deadlines will turn the protocol into a bypass button.

For data changes, I’d prefer expand-and-contract plans over heroic rollback. Preserve the old representation, migrate gradually, then remove it later. An undo file cannot reconstruct information that the migration discarded, which is an architectural limitation rather than an agent problem.

The operational detail I’d add is ownership: who is watching the revert, who can declare it safe, and what happens if the agent’s proposed permissions are denied halfway through? A machine-readable plan helps coordination, but an orphaned plan still leaves humans holding the pager.

We have called this change control, deployment plans, and backups for years. The useful novelty is making the agent fill in the blanks consistently. The danger is believing a new file format has solved the old organizational habit of skipping review.

I’d push back on making reversibility the default for every production change. Some fixes are safer when applied immediately than when delayed for a perfect undo artifact. The policy should be risk-weighted, with a clear exception path that is logged and reviewed afterward.