Control the Blast Radius

When teams discuss AI coding, their first questions are often still the same: Who reviews the code after an Agent writes it? Can it merge? Who is responsible when something goes wrong?

These are valid questions, but they inherit an old premise: a code change is expensive and dangerous, so it must be inspected in one place and approved carefully before it enters the main branch.

The PR workflow developed under that premise. People write code slowly, so changes tend to accumulate. Reviewers are scarce, so teams need a clear checkpoint where code can be held and inspected. A merge then looks like a gate: before it, the code is a draft; after it, the code enters the real world.

Agents change that calculation. They can make a steady stream of small commits, run tests automatically, and continue fixing what fails. Git preserves the complete history. When changes are small enough, problems are detected promptly, and failures can actually be recovered from, requiring every change to queue for a solemn human review may become the slowest part of the system.

The real question is no longer “Was there a PR?” It is: How large is the blast radius of this change?

Trust Comes from Bounded Loss

A personal todo list is usually software with a low cost of failure. A core banking system has a high cost of failure and a high density of responsibility. The risk level of software depends not only on the complexity of its features, but also on the real-world consequences it carries.

Letting an Agent handle work with a low cost of failure does not require us to prove that AI never makes mistakes. We grant it autonomy not because we believe it is smart enough, but because its mistakes are cheap, visible, and reversible.

Good Agent infrastructure should therefore do more than help Agents accomplish more. It should continually reduce the blast radius of each action:

• Use isolated workspaces so tasks cannot contaminate one another.
• Keep commits small enough to locate and revert at any time.
• Use feature flags, staged rollouts, and automatic rollback to limit impact.
• Run in test environments first, then move gradually closer to real users.
• Require Agents to submit evidence, not just code.
• Break one large change into many small changes that can be verified independently.

A sandbox turns these constraints into properties of the task environment: each Agent gets an isolated environment, an explicit lifecycle, and a limited task boundary. A task can run without someone watching every terminal, and a failure does not have to take down the entire workspace.

Git Can Undo Code, Not the World

Git’s reversibility can create a comforting illusion: we have version control, so what is there to fear? If something goes wrong, just revert it.

Data deleted from a database does not return automatically when the code is rolled back. A sent email cannot be recalled. Money already charged does not refund itself. A leaked secret cannot become secret again. When a customer system consumes an incorrect API response and acts on it, those actions do not disappear either.

These are the nuclear buttons in front of an Agent.

A nuclear button does not always look frightening. It may be an ordinary DELETE, a database migration, an API call that sends a notification, or a routine-looking production deployment. The danger is not the command itself. It is that once the command runs, the world has changed, and Git cannot change it back for you.

Agent governance therefore needs neither human approval for every operation nor total automation backed by “we can always roll back.” A better boundary is to let Agents handle low-blast-radius operations autonomously while leaving final authorization for irreversible, high-blast-radius operations to people.

Put the Boundary in Permissions, Not Just the Prompt

This boundary cannot live only in a prompt. If a coding Agent simultaneously has write access to the production database, administrator access to the cloud account, and the ability to send external messages, even the finest system prompt is merely a polite reminder.

A reliable Harness—the runtime, tools, and permission system around an Agent—should separate capabilities. An Agent may prepare a migration script but not execute it directly. It may draft an email but not send it on behalf of the company. It may deploy to an isolated environment, while production requires a separate, independent verification step.

The human role changes as well. People used to control quality through line-by-line review. Their more important work may become designing the boundaries of change: what may be tried automatically, how failures are detected, how recovery works, which actions cannot be undone, and who is allowed to press the final button.

Reviewing every line of code can provide the reassuring feeling that the whole system remains under control. Yet the real danger is often not whether a particular line is elegantly written. It is whether the system can amplify an ordinary mistake into an unmanageable incident.

The new world still has gates. They just should not be placed mechanically in front of every merge.

They should stand wherever the blast radius suddenly expands.