Most engineers worry about the quality of code agents produce. They worry about technical debt and standards. But quality is not the main bottleneck. The real problem is volume. Agents produce code at a scale our current workflows cannot handle.
Generating code faster does not increase velocity if integration stays the same. It just creates a coordination tax. Pull request queues fill up. Senior engineers lose track of the system architecture. When four different agents open PRs touching the same core library, you spend the afternoon resolving merge conflicts instead of shipping. This is why agent output cannot be treated as a permanent part of the codebase. It has to be disposable.
Our inherited mental model#
Our workflows are built for human constraints. Human labor is slow and expensive. Since it takes a developer days to make a change, we build systems to protect that work.
Our model is based on permanence. We use shared branches and long-lived environments. We assume the author understands the whole system. In this model, code is an asset as soon as it is written. We treat the repository as a permanent record where every line is meant to stay.
This works for humans. We are good at maintaining context. We understand why a change happens. The overhead of reviews and pipelines is a fair tax on slow human thought.
The failure mode is predictable#
The system breaks when you put agents into this model. The economics are different. An agent generates hundreds of lines in seconds, but it lacks human intent.
The problem is that agent output feels permanent too soon. When an agent pushes code to a branch, it interacts with everyone else’s work. Our model assumes the author was careful. Engineers end up trusting the code more than they should.
Review costs explode as volume grows. If a human spends thirty minutes reviewing what an agent wrote in thirty seconds, the bottleneck just moved. An agent might refactor a module and pass every unit test, only for the team to find a subtle database locking issue an hour after the merge. You end up manually untangling a thousand-line diff just to get the system stable again. The problem is not bad code. It is permanence without verification.
The core invariant#
To solve this, we need a structural requirement for any system involving AI agents:
Agent work must be cheap to create, cheap to discard, and impossible to accidentally trust.
Why humans tolerate mess and agents cannot#
Humans adapt to fuzzy requirements. We can work in a messy codebase because we can infer meaning. We fix things as we go.
Agents cannot do this. They amplify ambiguity. If a codebase has bad patterns, the agent replicates them at scale. A human sees an outdated utility function and ignores it, but an agent uses it in fifty new places before the first review.
If agent work isn’t disposable, bad attempts pile up. This residue becomes part of the permanent state. Over time, the agent’s future work gets worse because it builds on its own mistakes. Humans tolerate mess. Agents need a clean slate.
What disposability means in practice#
In practice, disposability has four properties: isolation, reversibility, zero residue, and safe deletion.
Isolation keeps agent work in a sandbox until it is validated. This means more than just git branches. It requires temporary environments where the agent can run code and fail without breaking the main build. Some teams use isolated Git worktrees to ensure each agent task begins on a truly throwaway branch.
Reversibility means undoing an agent’s work costs almost nothing. If the solution is flawed, you must be able to remove it completely. No configuration changes or extra files should stay behind.
Zero residue means the environment returns to a clean state after a task. No side effects should influence the next job. Sandboxed or containerized environments ensure that agent failures or side effects cannot pollute the host system.
Safe deletion is the acceptance that throwing away 100% of an agent’s work is a good outcome. If an agent fails to solve a migration, you delete the entire branch and start over. There is no hunting for orphaned tables or leftover config files. This is not a failure. It is how the system stays safe.
Why disposability restores speed#
Discarding work sounds like it would slow things down. It doesn’t. When work is disposable, parallel attempts are safe. You can try multiple approaches to the same problem at the same time. A system can try three different ways to optimize a query at once. You keep the fastest one and discard the other two without any cleanup cost.
When failure is cheap, you can experiment more. We move from pre-verification to post-verification. You let the agent run, then use code to check the results.
Trust moves from the author to the process. If you know agent work can’t leak into the main system without passing a gate, you spend less time reading every line. You spend more time defining success. Velocity comes from the ability to safely reject bad work.
What this does not solve#
Disposability is a requirement, but it does not replace fundamentals.
It does not replace the need for clear specs. If the input is bad, the agent produces disposable garbage. It also does not replace human judgment. Automation can reject broken code, but humans must decide if the solution actually works for the business.
Disposability does not make agents autonomous. They still need clear boundaries. It provides a safety net, but it does not provide the direction.
Closing reframing#
The goal is not more code. The goal is making it cheaper to be wrong. High mistake costs force you to move slowly. When agent work is disposable, you can move faster because you are not afraid of errors.
Modern engineering systems should make permanence something earned, not the default.