Jun 27, 2026

Coding Agents Need a Dry Run and an Approval Gate

A retry loop spins up runaway infrastructure. A tool silently rewrites files from UTF-8 to UTF-16. Agents that touch files, APIs, and deploys need dry-runs, edit provenance, and approvals.

1DevTool Team • 4 min read

Two incidents capture why coding agents make people nervous. In one, an autonomous agent gets stuck in an edit-test-regenerate loop and quietly spins up runaway infrastructure, turning a coding task into a cloud bill and a wave of API-cost anxiety. In another, a tool rewrites backend files from UTF-8 to UTF-16 with a byte-order mark, and converts TypeScript to JavaScript, with no visible reasoning and no announcement. Both are cases of an agent acting irreversibly before any human got a chance to say no.

The common thread is the missing pause. The agent went from intention to action with nothing in between — no preview of what it was about to do, no record of why, no gate where a person could approve or veto. That gap is where the damage lives, and closing it is more important than making the agent slightly smarter, because a smarter agent that still acts without a checkpoint will simply make more confident mistakes faster.

The retry loop is a spending decision in disguise

An agent stuck retrying a failing build is not just unproductive; it is expensive, and the expense compounds silently. Each loop consumes API calls and sometimes provisions real resources, and because the loop looks like progress, nobody intervenes until the cost shows up. The agent never decided "I will now spend a lot of money." It decided "I will try again," many times, and the spending was the emergent result.

A dry-run changes the shape of this. If the agent has to show what it intends to do — which commands, which resources, which files — before it does it, the runaway loop becomes visible at step one instead of step fifty. The checkpoint converts an invisible, compounding cost into a decision a human can make while it is still cheap to make.

Silent edits destroy trust faster than wrong edits

The UTF-16 rewrite is worse than a bug, because a bug is at least legible. The file was changed in a way the developer did not request, did not see, and could not explain, and the encoding change is the kind of thing that breaks tooling subtly and is miserable to trace back. The problem is not only that it happened; it is that it happened without provenance. Nobody can answer "why did this file change," which means nobody can trust that other files did not change the same way.

Edit provenance is the antidote: a record of what the agent changed, where, and why, attached to every modification. Without it, every agent-touched file is suspect, and the team is back to reviewing everything by hand. With it, a surprising change has an explanation you can inspect and reject. The trust difference is enormous, and it comes entirely from the layer around the agent keeping receipts.

Approvals are where irreversibility gets a human

Some actions should never be autonomous. Touching the database. Hitting a production API. Deploying. These are irreversible or expensive enough that the right design is an explicit gate: the agent proposes, a human approves, and only then does it act. People are already building exactly this — local safety layers with dry-runs, logged actions, and explicit approval before an agent touches files, APIs, or deploys — because the need is obvious the moment an agent has done one irreversible thing you did not sanction.

The gate is not friction for its own sake. It is friction placed precisely at the points of no return, and nowhere else. The agent stays fast on reversible work and stops for a human exactly where stopping is cheap insurance against catastrophe.

A cockpit, not a leash

Put dry-runs, edit provenance, hook wiring, and approval gates together and you get something closer to a cockpit than a leash. The agent still does the work, at speed, on everything that is safe to automate. But its actions are previewed before they run, recorded as they happen, and gated where they are irreversible. That is the configuration that lets a developer actually leave an agent alone — not because the agent is perfectly trustworthy, but because the layer around it makes untrustworthy actions visible and reversible before they land.

The agents are good enough to do real work. What is missing is the checkpoint between intention and action, and the teams that add it are the ones who get to run agents without watching them every second.