Disposable Code: Building Software You Plan to Throw Away

The conventional wisdom on building software, learned painfully over decades, was that you should write code you can maintain for years. Pick patterns that age well. Avoid clever tricks. Document the surprising bits. Treat every line as a future liability that someone will have to read, understand, and modify long after you have moved on.

That advice was correct when writing code was expensive. It is becoming a load-bearing assumption that no longer holds.

When the cost of generating an implementation collapses by an order of magnitude, the right question is no longer “can we maintain this for ten years.” The right question is “do we need to?” For a growing class of software, the answer is no – and pretending otherwise produces over-engineered systems that cost more to build, more to operate, and more to retire than the value they ever delivered.

The Disposable-by-Default Category

We have started classifying software, at the spec stage, into three categories.

Load-bearing. Code that the business depends on running for years. Core transaction systems. Long-lived APIs. Compliance-critical workflows. Anything where downstream systems, customers, or audit trails will outlive the original developer by a decade. This code gets the full traditional treatment: documented, tested, hardened, observed, designed for evolution.

Operational. Code that exists to support a specific operational rhythm but is expected to be replaced within one to three years. Internal admin tools. Reporting pipelines. Vendor integrations. Glue code between systems that are themselves in motion. This code is built to be readable and tested, but with the explicit understanding that it will be rewritten or retired well within the decade.

Disposable. Code that exists to support a single workflow, project, or experiment and is expected to be thrown away within weeks or months. Internal scripts. Migration tooling. One-off data backfills. Bespoke automations for a specific client engagement. Glue that runs once a quarter, then never again.

The traditional industry instinct was to treat almost everything as load-bearing. Internal scripts grew comments. Migration tools acquired test suites. One-off automations got configuration systems “in case we need them again.” Every category leaked upward toward the most expensive treatment, and the codebase paid the cost.

Disposable code is the category most distorted by this leakage. It is also the category where agent-assisted development changes the economics most violently.

What Disposable Looks Like in Practice

A disposable script for us in 2026 is generated, run, and deleted in a single afternoon. The agent produces the implementation against a precise spec. A human reviews the output – carefully, because the run is real, not because the code will live – runs it, verifies the outcome, and removes the code. The artifact left behind is the spec, the run log, and the outcome. The code itself is not the artifact.

This is unrecognizable to most engineering teams. The standard reaction – “but what if you need to run it again?” – contains the wrong assumption. If you need to run it again, regenerate it. The spec is the durable thing. The implementation is the by-product. Regenerating from a spec is almost free; storing dead code is not.

We have measured this. Internal disposable scripts, treated as disposable from the spec stage, take roughly a third as long to produce as the same scripts treated as code-we-might-keep. The “might-keep” treatment adds configuration files, error handling for cases that will never happen in this one run, log formatting, parameterization, and a half-built abstraction that anticipates a second use case. The disposable treatment skips all of it. The work that actually delivers the outcome is small. The work that anticipates a future is most of the cost.

Why It Was Hard to Do This Before

In the era of expensive implementation, the temptation to keep disposable code was rational. Re-implementing a one-off script took most of a day. Modifying an existing one took an hour. The economic decision was almost always to preserve.

That economic decision drove cultural habits. Engineers learned that throwing code away was wasteful. They learned to parameterize, to abstract, to “leave it cleaner than you found it.” They learned that the right answer was always to build for reuse.

These habits are still correct for load-bearing code. They have become wasteful for disposable code, because the underlying cost ratios have inverted. Regenerating from a spec is faster than modifying an old implementation. Specifying once, regenerating on demand, and trusting the spec as the durable artifact is the cheaper path.

The hard part is the cultural retraining. Senior engineers, in particular, find it uncomfortable. They have spent twenty years internalizing “leave it cleaner than you found it.” Asking them to delete a working script feels wrong. The discomfort is real. It is also the right cost to pay.

The Disposable Spec

The artifact that survives a disposable run is the spec, not the code. Specs we keep look like:

• The precise problem the run was solving, written in plain language.
• The inputs: where the data came from, in what shape, with what constraints.
• The outputs: what was produced, where it landed, what verifications were run.
• The decisions: anything the implementer (human or agent) had to choose about behavior that was not implied by the inputs alone.
• The result: did the run produce the intended outcome, and how do we know.

This is shorter than a typical engineering README. It is also more valuable. If we need to run the same workflow again in six months, the spec gets regenerated into a new implementation, validated against the prior outcome, and run. The new code may not look like the old code. That is fine. The old code is gone.

We store these specs the way we used to store scripts. They are tagged, indexed, and searchable. They are reviewed when the workflow recurs. They have owners. They are the durable layer.

The Risk

The biggest risk in disposable code is misclassification. Code that should have been load-bearing gets built disposable, and the org finds out – months later, during an incident – that the workflow has become critical and no one can find the implementation anymore.

Two protections matter.

Classification is explicit at the spec stage. Every spec has a category. Disposable, operational, or load-bearing is a decision made before the work starts, not after. We do not allow the classification to be left blank. The default is operational; disposable requires a stated reason; load-bearing requires the same.

Promotion is a deliberate act. If a disposable workflow runs three times, we re-classify. The fourth run gets a proper implementation, treated as operational, with the appropriate investment. We do not let code drift upward in importance without drifting upward in treatment. The drift is the source of most of the eventual pain.

What This Does to the Codebase

The visible effect is a smaller codebase. We delete more than we keep. The repo does not grow linearly with the work we do; it grows linearly with the load-bearing work we do, which is a much smaller fraction of total work.

The less visible effect is faster engineering. The team is not maintaining things it does not need. The review queue is shorter. The cognitive load of the codebase is bounded. Onboarding a new senior engineer is faster because what survives in the repo is the work that matters, not the residue of every operational task ever performed.

The least visible effect, and the most important, is honesty about cost. We pay the maintenance cost on the code that earns it and refuse to pay it on the code that does not. The engineering org has a budget. It is not infinite. Disposable code is how we keep the budget honest.

The Honest Statement

Disposable code is not careless code. Disposable code is code that is specified well, generated cleanly, reviewed carefully, run successfully, and then – and this is the part that takes practice – deleted on purpose.

The instinct to keep everything was correct for the era of expensive writing. It is wasteful in the era of cheap regeneration. Update the instinct. Keep the discipline. Delete the rest.