Coding agents are the cleanest place to start

Coding agents are a useful starting point because the software world already has many of the pieces undo requires. A coding agent can generate a change, and that change can be reviewed, kept in a branch, tested, run through a pull request, passed through a merge queue, and deployed to a lower environment. It can be released behind a feature flag, and if it fails, it can be reverted, rolled back, or turned off.

That does not mean coding agents are automatically safe. It means code has structure around it, and when that structure is healthy, undo is not a vague hope. It is part of the workflow.

This is one of the reasons trunk-based development matters. I have written about trunk-based workflows before¹, and this is another place where they show their value, because a stable mainline, short-lived branches, frequent integration, automated validation, and releasable commits all make undo easier. Long-running branches do the opposite. They hide risk, they let changes pile up, and they turn integration into an event. By the time the work merges, nobody is quite sure what changed, what depends on what, or what will break when it hits the shared system. That is a bad place to put an AI agent.

A coding agent does not need a magical workflow. It needs a disciplined one, the same thing human developers need: small changes, clear ownership, automated checks, repeatable deployment, and a known way back.

When people talk about AI coding agents, they usually focus on generation. How much code can it write, how fast can it produce a feature, how many tickets can it chew through? That is the wrong first question. The first question should be how safely we can undo what it did. If the answer is "not very," you do not have an AI problem yet. You have an engineering discipline problem, and AI is about to amplify it.

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 gives you this, and so do pull requests, reverts, a clean mainline, and a release process that can redeploy a known good artifact. Structural undo says that we know what changed and we have a way to move the structure of the system back to a safer state. This is where trunk-based development helps. If your mainline is always close to production-ready, and if changes are small enough to understand, then reverting a commit or redeploying the last known good version is practical rather than terrifying.

The second is runtime undo, which comes from the ability to change behavior without changing the deployed code. Feature flags are the obvious example. A feature can exist in the codebase but stay disabled, so you can ship the code without exposing the behavior, enable it for internal users or a small customer group, and turn it back off if it misbehaves.

The difference is simple. Structural undo changes the system back, and runtime undo changes what the system is allowed to do. Both matter. A rollback might get you back to the previous deployed artifact, a feature flag might let you stop the damage without deploying anything at all, a dark launch might let you validate behavior before customers see it, and a staged rollout might let you find a problem while the blast radius is still small. These are not just technical tricks. They are trust mechanisms, because they let you say you are willing to let a change move forward since you know where the exits are. That is the part we need to carry into the AI conversation.

Undo works best before impact

There is a hard truth here, which is that undo is most valuable before the damage happens. Yes, you can roll back a release after customers hit a bug, revert a commit after production breaks, and turn off a feature flag after the support queue lights up. But the impact already happened. The customer already saw the broken behavior, the data may already be wrong, the email may already be sent, the order may already be processed, and the trust may already be damaged.

This is why validation is part of undo, even though validation usually gets filed under quality rather than recovery. In real systems, validation is one of the main ways you avoid ever needing the expensive version of undo. A good workflow tries to catch the problem while the cost of reversal is still low. The cheapest undo is rejecting a bad suggestion before it becomes code. The next cheapest is rejecting a bad pull request before it merges, then reverting before deploy, then rolling back before release, then turning off a feature before broad exposure. After that, you are usually in compensating-action territory, and that is where things get messier.

This matters with AI agents because the temptation is to optimize for speed. Let the agent do more, let it go further, let it make the change, open the PR, merge it, deploy it, and watch the result. Maybe one day that works well in certain systems, but it only works safely where undo has been designed into every stage. The discipline is not "trust the AI." The discipline is to build a system where trust is earned by containment, validation, and recovery.

The stages of undo

The stages of undo are different from the factors that make undo possible. The factors are the things you put in place, like version control, feature flags, automated tests, rollback paths, data migration patterns, approvals, audit logs, and clear ownership. The stages are how undo moves through time.

The first stage is design. Before the work starts, you ask what it will take to undo it. If an AI coding agent is going to modify a service, what is the path back? Can the change be isolated, tested, disabled, and reverted cleanly? Will it touch data, or change behavior customers already depend on? This is where you prevent a lot of pain, because if the only rollback plan is "we will figure it out if something goes wrong," you do not have a rollback plan. You have a future incident with better branding.

The second stage is validation, where you prove the change before impact. Tests run, reviews happen, lower environments do their job, and synthetic checks, dark launches, and feature flags all earn their keep. The point is not to create ceremony. The point is to make sure the change has earned the right to move closer to the customer. With AI agents this stage matters even more, because an agent can generate plausible work quickly, and plausible is not the same as correct. Validation is how you keep confidence from turning into wishful thinking.

The third stage is controlled execution, where the change moves forward but not blindly. You merge through a workflow, deploy through a pipeline, release gradually, and watch the right signals, knowing what "bad" looks like before you start and knowing who owns the decision if things go sideways. This is where a lot of organizations pretend they are disciplined because they have tools, but tools are not discipline. A deployment pipeline is only useful if it represents an actual agreement about how change moves through the system.

The fourth stage is reversal or containment, the point where you actually use the undo mechanism. You revert, roll back, disable the flag, stop the rollout, restore a previous configuration, or pause the agent so the damage does not spread. Good undo is boring at this stage. It should not require a hero, it should not depend on the one person who remembers how the old deployment job works, and it should not need a war room full of people guessing at which script to run. You cannot scale heroics, and you certainly cannot scale AI-driven work on top of heroics.

The fifth stage is compensation, which people often forget because it is less clean. Compensation is what you do when reversal is not enough. If bad code was deployed and customers were affected, rollback does not erase their experience. If bad data was written, reverting the application does not necessarily repair the records. If a bad email was sent, there is no real undo button. You may need to correct the data, notify customers, apologize, issue credits, restore access, resend information, or repair a relationship. This is where accountability enters the picture, because undo does not remove responsibility. It gives responsible people a way to act quickly and honestly.

The final stage is learning. If the same kind of mistake can happen again, the undo process is not finished. The system needs to improve: the test gets added, the flag strategy gets fixed, the migration pattern gets clarified, the agent gets tighter permissions, or the approval threshold changes. Fix once, not many times. That is how trust grows.

Data is where undo gets serious

Code rollback is often the easy part. Data is harder. A bad code change can sometimes be reverted cleanly, but a bad data change tends to leave a mark. Once a system writes the wrong value, deletes the wrong record, sends the wrong event, or migrates state in the wrong direction, undo gets more complicated. That is why data-impacting changes need a different level of discipline.

A useful pattern is the three-stage rollout. In the first stage you introduce the new data structure or new data path while keeping the old one in place, so you do not rip out the old behavior immediately and you create room to compare, validate, and observe. In the second stage, after validation, you cut the system behavior over to the new data path while the old path still exists as a safety net, so you are using the new approach without burning the bridge behind you. In the third stage, after the new approach has proven itself, you retire the old data path, clean up the old structure, and simplify the system.

This pattern is not glamorous, and it can feel slower and like extra work. It is also how grown-up systems survive change. It works because it respects reality: data changes are not the same as code changes, state matters, side effects matter, and customers may already be relying on what the system has done. If you pretend data undo is as simple as a code revert, production will eventually teach you otherwise.

AI agents make this even more important. If an agent proposes a data migration, writes a script, updates records, or changes a workflow that affects state, the question cannot be whether the script looks right. The question has to be what happens if it is wrong. Can we run it in read-only mode first? Can we preview the affected records, stage the change, and keep the old data long enough to compare? Can we replay the operation safely, produce a compensating change, and prove the result before committing to it? If those questions feel heavy, good. They should, because state is where confidence needs evidence.

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 the agent sends a bad one. Maybe the tone is wrong, maybe the facts are wrong, maybe it sounds careless, and maybe it goes to your boss, your bank, a customer, a vendor, your spouse, or someone else whose trust matters in your life. You cannot revert that email. You can send a follow-up, apologize, clarify, and own the mistake, but those are compensating actions, not undo. The impact already happened.

The same discipline applies outside of code. If an action has real-world consequences, the agent should not get full authority without the right controls. Maybe it can draft the email but not send it, maybe it can suggest a response but require approval, maybe it can send routine messages but escalate sensitive ones, maybe it can operate only inside a narrow template, or maybe it can summarize the action it is about to take before it takes it. The point is not to make AI useless. The point is to match autonomy to reversibility. Low-impact, reversible actions can be automated more aggressively, while high-impact, hard-to-reverse actions need more validation, more human judgment, and clearer compensating plans. That is not fear. That is discipline.

Trust is not blind confidence

A lot of AI conversations get trust backward. People talk as if trust means believing the agent will get it right, but that is not trust. That is hope. Real trust comes from knowing what happens when it gets something wrong.

I trust a deployment pipeline more when I know it can roll back. I trust a feature release more when I know it can be disabled. I trust a data migration more when I know the old path still exists. I trust an AI coding agent more when I know it works through the same review, test, and release discipline as everyone else, and I trust an AI assistant sending messages more when I know sensitive communication requires approval. The trust does not come from pretending the system is perfect. It comes from knowing the system is recoverable.

That is the part organizations need to understand before they hand more responsibility to agents. AI does not remove accountability. It increases the need for clear accountability, because it can move faster than the old process. If an AI agent breaks production, the agent is not accountable. The people who gave it access are, and so is the workflow that allowed the damage, the missing validation, and the lack of rollback discipline. Most failures will not come from AI being strange or magical. They will come from ordinary process failures wearing new clothes.

The factors that make undo possible

The discipline of undo depends on a few practical factors.

You need ownership. Someone has to know who is responsible for the change, the system, the release, and the recovery, because when ownership is vague, undo gets slower, and during an incident ambiguity is expensive.

You need versioning. Code, configuration, prompts, data schemas, agent instructions, and workflows all need some form of history, because you cannot undo what you cannot identify.

You need isolation. Small changes are easier to reason about, narrow permissions are safer than broad ones, and limited rollouts are safer than global launches. An agent with scoped authority is easier to trust than an agent with access to everything.

You need validation before impact. Tests, previews, dry runs, reviews, simulations, lower environments, and approval gates all exist to catch mistakes while they are still cheap.

You need runtime control. Feature flags, kill switches, throttles, circuit breakers, and permission controls let you stop behavior without waiting for a full rebuild of the system.

You need rollback paths. A rollback that has never been practiced is not a rollback plan. It is a theory, and if the process matters, you prove it before the emergency.

You need compensating actions. Some things cannot be undone cleanly, and for those you need to know how you will repair the damage, whether that means data correction, customer communication, credits, apologies, audits, or manual review.

You need accountability. Not blame, accountability. Someone has to own the result, especially when AI was involved, because "the agent did it" is not an acceptable operating model.

These factors are not exciting, but they are what make the exciting parts safe.

AI needs more discipline, not less

The mistake would be to treat AI as an exception to normal engineering discipline. Because the agent is fast, we let it bypass review. Because it is impressive, we let it skip validation. Because it can explain itself, we stop demanding evidence. Because the demo worked, we assume the workflow is safe. That is backwards.

AI-generated work needs the same discipline as human-generated work, and in some cases it needs more. Not because AI is useless, but 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 when they operate inside a workflow that already knows how to absorb change, and they are dangerous when they are dropped into a fragile system that depends on tribal knowledge, manual release rituals, and hero engineers.

If your deployment process already scares people, adding an AI agent will not make it trustworthy. If your rollback process is unclear, adding an AI agent will not make it safer. If nobody owns the system after the code ships, adding an AI agent will not solve the ownership problem. AI will expose the system you already have. That is why undo is such a useful lens. It makes the hidden system visible.

The better mental model

The right mental model is not "how much can the AI do?" It is "how much can the AI do safely, given our ability to validate, contain, reverse, and compensate?" That question changes the design.

For code, it pushes you toward trunk-based workflows, small pull requests, automated tests, merge queues, feature flags, progressive delivery, and clean rollback. For data, it pushes you toward staged migrations, parallel paths, validation windows, previews, backups, and compensating scripts. For operations, it pushes you toward scoped permissions, approval gates, audit logs, dry runs, and kill switches. For communication, it pushes you toward drafts, review steps, templates, escalation rules, and human approval for sensitive messages. For personal life, it pushes you toward not letting an agent take actions that can damage trust unless you have thought through the consequence.

This is not anti-AI. It is the opposite. The more powerful the tool, the more important the discipline around it. A table saw is useful because it is powerful, and that does not mean you remove the guard, close your eyes, and trust the blade.

The takeaway

Undo is not a feature. It is a discipline. It starts before the work begins, and it shapes the design, the workflow, the validation, the release, the permissions, and the recovery plan. It accepts that mistakes will happen, and it refuses to let every mistake become a crisis.

Coding agents give us a clear model because software delivery already has many of the right patterns. Structural undo gives us a way back through versioning, clean mainlines, and rollback. Runtime undo gives us a way to control behavior through flags, kill switches, and staged release. Data changes remind us that state makes undo harder, and human communication reminds us that some actions cannot be reversed, only repaired. That is where trust and accountability meet.

Trust does not mean the AI will always be right. It means the system is designed so that when the AI is wrong, people can catch it, contain it, reverse it where possible, and take responsibility for the rest. The standard is not perfect agents. It is recoverable systems.

The future of AI work will not belong to the teams that let agents do the most. It will belong to the teams that build the strongest discipline around what agents are allowed to do, how their work is validated, and how the system recovers when something goes wrong. The system is what happens after the agent acts. Build the undo before you need it.