Coding agents are the cleanest place to start

Coding agents are a good place to start because software delivery already has most of the pieces undo requires. An agent's change can sit in a branch, go through a pull request and a merge queue, and land in a lower environment before any customer sees it. It can ship behind a feature flag, and if it fails, someone can revert it or turn it off.

That structure doesn't make an agent safe by itself. When the structure is healthy, though, the way back is already built into the workflow instead of improvised during an incident.

This is one of the reasons trunk-based development matters. I've written about trunk-based workflows before¹, and they earn their keep here too, because a stable mainline with short-lived branches and releasable commits keeps every change small enough to back out. Long-running branches hide risk and turn integration into an event. By the time that work merges, nobody is quite sure what changed or what will break when it hits the shared system, and that's a bad place to put an AI agent.

A coding agent needs the same boring workflow human developers need, with small changes, automated checks, and a known way back.

When people talk about AI coding agents, they usually focus on generation, meaning how much code it writes and how many tickets it can chew through. I'd ask first how safely you can undo what it did. If the answer is "not very," fix the engineering discipline first, starting with how long it takes to revert a bad merge today.

Structural undo and runtime undo

There are at least two kinds of undo that matter in software delivery, and it helps to keep them separate.

The first is structural undo, which comes from the way the work is organized. Version control, reverts, and a release process that can redeploy a known good artifact all give you a way to move the system back to a safer state, because you know exactly what changed. Trunk-based development helps here as well. When your mainline is always close to production-ready and each change is small enough to understand, reverting a commit or redeploying the last good version is routine work rather than a terrifying one.

The second is runtime undo, which comes from changing behavior without changing the deployed code. Feature flags are the obvious example. The code ships disabled, you turn it on for internal users or a small customer group, and you turn it back off if it misbehaves.

Structural undo puts the system back, and runtime undo limits what the system is allowed to do. A rollback returns you to the previous artifact, a flag can stop the damage without deploying anything at all, and a dark launch or a staged rollout lets you find a problem while the blast radius is still small. Mechanisms like these let a team move a change forward because everyone knows where the exits are, and that's the part worth carrying into the AI conversation.

Undo works best before impact

Undo is most valuable before the damage happens. You can roll back a release after customers hit a bug, or turn off a flag after the support queue lights up, but by then the customer has already seen the broken behavior, and the data may already be wrong or the order already processed.

So validation belongs to undo, even though it usually gets filed under quality. It's the main way you avoid ever needing the expensive version. The cheapest undo is rejecting a bad suggestion before it becomes code, and from there the cost climbs one step at a time: rejecting the pull request before it merges, reverting before deploy, rolling back before release, and turning off the flag before broad exposure. Past that point you're into compensating actions, and things get messy.

With AI agents, the temptation is to optimize for speed and let the agent merge and deploy its own change while you watch what happens. Maybe that works someday, in systems where undo was designed into every step between the prompt and production.

The stages of undo

The stages of undo are different from the factors that make undo possible. The factors are what you put in place ahead of time, like version control, feature flags, and clear ownership, and the stages are how undo moves through time.

The first stage is design, where you ask what it will take to undo the work before it starts. If an AI coding agent is going to modify a service, what's the path back? Can the change be isolated and reverted cleanly, and will it touch data or behavior customers already depend on? If the only rollback plan is "we'll figure it out if something goes wrong," what you have is a future incident with better branding.

The second stage is validation, where you prove the change before impact. Tests run, reviews happen, and lower environments and dark launches do their job, so the change earns the right to move closer to the customer. With AI agents this stage matters even more, because an agent can generate plausible work very quickly, and plausible and correct are different things.

The third stage is controlled execution. You merge through a workflow, deploy through a pipeline, and release gradually, knowing before you start what "bad" looks like on the dashboard and who owns the call if things go sideways. A lot of organizations believe they're disciplined here because they bought the tools. A deployment pipeline is only worth something if it represents an actual agreement about how change moves through the system.

The fourth stage is reversal or containment, when you actually pull the lever. You roll back, disable the flag, or pause the agent so the damage doesn't spread. Good undo is boring at this stage. It shouldn't depend on the one person who remembers how the old deployment job works, or on a war room full of people guessing at which script to run. You cannot scale heroics, and you certainly can't scale AI-driven work on top of them.

The fifth stage is compensation, which people forget because it's less clean. Rollback doesn't erase what customers already experienced, and reverting the application doesn't necessarily repair the records it wrote. A sent email has no undo button at all. You may need to correct the data, issue credits, or apologize, and this is where accountability comes in, because undo gives responsible people a way to act quickly and honestly without taking the responsibility off them.

The final stage is learning. If the same kind of mistake can happen again, the undo isn't finished until the test gets added, the migration pattern gets written down, or the agent's permissions get tightened. Fix once, not many times.

Data is where undo gets hard

Code rollback is often the easy part. A bad code change can sometimes be reverted cleanly, but once a system writes the wrong value, deletes the wrong record, or migrates state in the wrong direction, reverting the code leaves the data exactly as broken as it was. Data changes need a different level of care.

A useful pattern is the three-stage rollout. First you introduce the new data structure or path while the old one stays in place, which gives you room to compare and validate. Once that checks out, you cut the system's behavior over to the new path, and the old path sticks around as a safety net so you aren't burning the bridge behind you. Only after the new approach has proven itself do you retire the old path and simplify.

It feels slower, and it is more work. It's also how grown-up systems survive change, because state and side effects don't revert the way code does, and customers may already be relying on what the system has done. Pretend data undo is as simple as a code revert and production will eventually teach you otherwise.

AI agents raise the stakes. If an agent proposes a migration script or a bulk record update, whether the script looks right matters much less than what happens if it's wrong. Can you run it read-only first and preview the affected records? Can you keep the old data long enough to compare, and is the compensating script written before the real one runs?

The email example

Not every AI mistake is a production incident. Some are more personal.

Imagine you give an AI agent poor instructions and ask it to send an email, and it sends a bad one. The tone is off or a fact is wrong, and it went to your boss, a customer, or your spouse.

You can't revert that email.

You can send a follow-up and own the mistake, but that's compensation, and the impact already happened. The same discipline applies outside of code, too. When an action has consequences out in the world, the agent shouldn't get full authority without controls. Maybe it drafts the email and you send it, or it handles routine messages and escalates the sensitive ones, or it tells you exactly what it's about to do before it does it. The goal is to match autonomy to reversibility. Low-impact, reversible actions can be automated aggressively, and high-impact, hard-to-reverse ones need human judgment and a plan for repairing the damage.

Trust is not blind confidence

A lot of AI conversations get trust backward. People talk as if trusting the agent means believing it will get things right, which is closer to hope. Trust comes from knowing what happens when it gets something wrong.

I trust a deployment pipeline more when I know it can roll back, and a data migration more when I know the old path still exists. I trust a coding agent more when its work goes through the same review, test, and release discipline as everyone else's, and an assistant that sends messages more when anything sensitive waits for my approval. None of that requires pretending the system is perfect, only knowing it's recoverable.

Organizations need to understand that before they hand agents more responsibility. AI raises the need for clear accountability, because it moves faster than the old process did, and most of its failures will be ordinary process failures wearing new clothes. If an agent breaks production, the people who gave it access are accountable, along with the workflow that let the change through without validation or a way back.

The factors that make undo possible

The discipline of undo depends on a few practical factors, and none of them are exciting.

Ownership comes first. Someone has to be responsible for the change and for the recovery, because when ownership is vague undo gets slower, and during an incident ambiguity is expensive. Versioning is next, since you can't undo what you can't identify, and that goes for prompts and agent instructions as much as for code and schemas.

Isolation makes changes easier to reason about. Small changes, narrow permissions, and limited rollouts are all safer than their opposites, and an agent with scoped authority is easier to trust than one with access to everything. Validation before impact, through tests, dry runs, and approval gates, catches mistakes while they're still cheap.

Runtime control lets you stop behavior without a full rebuild, which is what feature flags, kill switches, and circuit breakers are for. Rollback paths have to be practiced, because a rollback nobody has ever run is a theory, and if the process matters you prove it before the emergency.

Compensating actions cover what can't be undone cleanly, which means knowing ahead of time how you'll correct the data or talk to the customer. Accountability ties the rest together. Somebody owns the result, especially when AI was involved, and "the agent did it" won't mean much to the customer whose order went through twice.

AI needs more discipline

The mistake would be treating AI as an exception to normal engineering discipline. Because the agent is fast, we let it bypass review. Because the demo worked, we assume the workflow is safe. That's backwards.

AI-generated work needs the same discipline as human-generated work, and sometimes more, because it can produce a lot of plausible output very quickly and speed without undo is just a faster way to create cleanup work. Coding agents are valuable inside a workflow that already knows how to absorb change. Drop one into a fragile system held together by tribal knowledge and manual release rituals and it gets dangerous fast.

If your deployment process already scares people, adding an AI agent won't make it trustworthy, and if nobody owns the system after the code ships, an agent won't solve the ownership problem either. AI will expose whatever system you already have, and asking how you would undo its work is a quick way to find out what that system looks like.

The better mental model

The question I'd put in front of any team is how much the AI can do safely, given your ability to catch its mistakes and recover from them. That question changes the design.

For code, it pushes you toward trunk-based workflows, small pull requests, and progressive delivery. For data, it means staged migrations with a validation window and a compensating script ready to go. Operations get scoped permissions, audit logs, and kill switches, and communication gets drafts and human approval for anything sensitive. In your personal life, it means not letting an agent take actions that can damage trust until you've thought through the consequence.

None of this is anti-AI. The more powerful the tool, the more the discipline around it matters. A table saw is useful because it's powerful, and nobody sensible responds to that by removing the guard and closing their eyes.

The takeaway

Outside the text editor, undo is never just a keystroke. It starts before the work begins and shapes the design, the release, and the recovery plan, and it accepts that mistakes will happen while refusing to let every one of them become a crisis.

Trusting an agent means building the system so that when it's wrong, people can catch it, reverse what they can, and take responsibility for the rest. The teams that do well with AI won't be the ones that let agents do the most. They'll be the ones who built the undo before they needed it.