$ Disposable Software: When Code Becomes a Temporary Medium
Software used to be expensive enough that we assumed every serious effort should last. AI weakens that assumption. Some software now only needs to exist long enough to solve one problem, communicate an idea, or feed the real build. Disposable software is its own category — not a lower one.
For most of computing history, software was treated as something expensive to create — and therefore something worth preserving.
That single assumption shaped almost everything around it: engineering organizations, product management, roadmaps, QA, release cycles, support models, procurement, SaaS pricing, and the corporate machinery that decides what gets built in the first place. Software was scarce, so we built processes around the scarcity.
But that scarcity is weakening.
With AI agents, coding tools, research tools, and design-to-code workflows, software is becoming easier to generate, easier to explore, and easier to throw away. Not all software needs to become a product. Not all software needs a roadmap. Not all software needs to survive.
Some software only needs to exist long enough to solve a specific problem.
That is disposable software.
Software was always a tool
Software exists because humans need help doing things.
Before computers, we extended ourselves with mechanical systems, animals, paper processes, and physical tools. Computers changed the medium, not the purpose. A computer is a machine that follows instructions. Software is the instruction layer that turns general-purpose hardware into a useful tool.
For decades, writing those instructions was hard. Storage was limited. Compute was limited. Hardware was expensive. Programming required deep specialization. From punch cards and tapes, through assembly, compilers, operating systems, graphical interfaces, cloud platforms, and SaaS, every generation made software more powerful — but also more central to modern work.
As software became more important, it also became more institutional.
Because building software was expensive, companies built layers around it: product managers, project managers, designers, analysts, executives, roadmaps, tickets, requirements, ceremonies, reviews, QA cycles, and release processes. These layers were not accidental. They existed because engineering time was scarce, coordination was costly, and mistakes were expensive.
When software is expensive, you need strong filters before deciding what deserves to be built.
But what happens when the cost of building small software drops dramatically?
The economics are changing
AI does not eliminate software engineering. It does not remove quality concerns. It does not magically produce reliable systems.
But it changes the cost curve.
Research that previously took weeks can now take hours. Prototypes that previously required days can now be generated in an afternoon. A person with a specific pain point can describe the problem, explore existing options, generate a tool, iterate on it, and use it — without waiting for a company to decide whether that problem is worth solving at scale.
This matters, because many genuinely useful software ideas never became products.
Not because they were bad ideas, but because the market was too small. The business case was not strong enough. The audience was too niche. The workflow was too specific. The value was real, but not large enough to justify a software company, a SaaS subscription, a procurement process, or a dedicated engineering team.
AI agents change that math.
A person may not need to buy software. They may not need to wait for someone to build it. They may not even need to care which framework or language is used. They can spend some tokens, describe their need, and generate something good enough for the task.
That is a fundamentally different relationship with software.
What is disposable software?
Disposable software is software built for a narrow purpose, used for a specific need, and then discarded, rebuilt, repurposed, or kept as context for something more permanent.
It does not need to be elegant. It does not need to scale. It does not need to become a platform. It only needs to serve the job it was created for.
A disposable tool might reconcile a spreadsheet, generate a report, visualize an idea, test a workflow, explore an API, compare options, or demonstrate a concept to a team. It may be used once. It may be used for a week. It may be rebuilt the next time the same problem appears, because rebuilding it is cheaper than maintaining it.
This is uncomfortable for traditional software thinking, because we tend to equate software value with durability. We ask whether something is maintainable, extensible, production-ready, tested, documented, and scalable.
Those questions still matter — but not for everything.
For disposable software, the better question is simpler:
Did it help someone move forward?
Disposable software for users
The most obvious case is the end user.
A person with a specific need can now build software around their own workflow, instead of bending their workflow to fit whatever software happens to exist. They can explain the pain point directly to an agent. They can research existing tools. They can generate a small app, script, dashboard, calculator, workflow, or interactive artifact.
For many people, that is enough.
The result may not be beautiful. It may not be engineered the way a professional team would engineer it. It may have rough edges. But if it solves the problem, the software has done its job.
This is where “vibe coding” gets both interesting and dangerous.
Yes, it introduces low-effort software. Yes, it creates quality risks. Yes, it can produce fragile systems that people do not fully understand. I have written before about the mess this style of work leaves behind, and I stand by it.
But that criticism misses part of the point.
Not every generated tool is trying to become infrastructure. Some of it is closer to a spreadsheet, a temporary notebook, a one-off automation, or a whiteboard sketch that happens to execute. The mistake is not creating disposable software.
The mistake is confusing disposable software with production software.
Disposable software for engineers
Disposable software is not only useful for non-engineers. It may be even more powerful in the hands of experienced ones.
Proofs of concept, spikes, technical explorations, and design branches used to take real time. Today, several of them can be explored in parallel. An engineer can generate prototypes to test assumptions, compare approaches, visualize tradeoffs, or create working context for a larger system.
This changes collaboration.
In the past, turning an idea into shared understanding often required meetings, diagrams, written proposals, whiteboarding sessions, and repeated explanation. Now an engineer can use agents to research, prototype, and produce something interactive enough for others to respond to.
The prototype does not need to be the final implementation. It can be a conversation object.
It can help a team see what is being proposed. It can expose missing requirements. It can reveal UX issues. It can pull feedback forward in time. It can hand another agent the context it needs to build the real system.
In this sense, disposable software becomes part of the design process. It is not the destination. It is a means to an end.
Imagine the older path: a series of meetings and processes to flesh an idea into a design — whiteboarding, diagrams, documents — all to earn buy-in from your team. Today you can research alongside your agents and produce something visual and tangible that earns that same buy-in far faster. It does not mean the prototype is something you have to keep. It means you have a thing to point at, and the choice to toss it, reuse it, or feed it into the real build with production constraints.
Disposable software as context
One of the most important shifts is that disposable software can become context for non-disposable software.
A prototype encodes decisions that are hard to explain in prose: layout, flow, tone, interaction model, information hierarchy, edge cases, and user intent. This is especially clear in design-oriented tools that produce interactive artifacts. A generated prototype can act like a living specification.
It is similar to Figma — but with behavior.
A design artifact can show not only what a screen looks like, but how it responds. It can carry style tokens, layout structure, content decisions, media references, and interaction patterns. An agent can inspect it and infer far more than it could from a paragraph of requirements. It is already answering questions before they are asked.
This is why tools like Claude Artifacts, Claude Design, “show me” experiences, Codex web previews, and similar agent-generated interfaces matter. They are not only producing software. They are producing shared context.
Think of one of these as a full export of a Figma file that happens to be a working website — the HTML and the styling are just the technical details behind an interactive prototype. An agent can go in and read the style tokens, the layout, the content, the media: all the things that are really design choices dressed up as front-end code. That does not make the artifact production-ready. It will have gaps. But it makes the target concrete in a way prose never does.
Sometimes the artifact is good enough to use as-is. Sometimes it should be thrown away. Sometimes it becomes the clearest possible input for building the real thing.
The new boundary: disposable vs. durable
The important skill is learning where the boundary is.
Disposable software is appropriate when the cost of correctness is low, the scope is narrow, the lifetime is short, and the purpose is exploration, communication, or personal utility.
Durable software is needed when reliability, security, maintainability, compliance, scale, shared ownership, or long-term evolution matter.
The future is not that everything becomes disposable. The future is that software splits more clearly into categories:
- Some software should be treated like infrastructure.
- Some software should be treated like a product.
- Some software should be treated like a prototype.
- Some software should be treated like a temporary tool.
- And some software should be generated, used, and thrown away.
The problem is that our organizations, engineering habits, and product processes were mostly built for the first two categories. We are still learning how to work with the last three.
The practice of using disposable software well
Disposable software still requires judgment.
There is a balance between token cost, time saved, risk, and usefulness. There is a skill in knowing when to generate, when to refine, when to stop, and when to rebuild properly. There is also a skill in knowing when a prototype has served its purpose and should not be promoted into production.
The danger is not that disposable software exists.
The danger is laundering disposable software into durable systems without doing the engineering work.
A prototype can inspire the real system. It can inform the real system. It can provide context for the real system. But production software still needs production constraints: architecture, security, tests, observability, deployment discipline, maintainability, ownership, and clear failure modes. Disposable software should accelerate that path, not bypass it.
The pull request is the same shift, one scale down
There is a smaller version of this story happening inside our daily workflow, and it is worth making the connection explicit.
The pull request used to be finished code waiting to be merged. It is quietly becoming something more: a compressed software object that is generated, reviewed, tested, learned from, and — sometimes — discarded on purpose. I argue that case in detail in Reusing the Pull Request: From Code Contribution to Research Artifact.
Disposable software is that same pattern applied to the whole artifact rather than a single change. A PR is a microcosm; software as a whole is the macrocosm. In both, the scarce resource stopped being the code. As I have argued before, generation got cheap and judgment did not. What you spend your attention on is no longer typing the thing — it is deciding which generated thing is worth keeping, and which one has already done its job and can go.
Conclusion
Software is entering a new era.
For decades, software was expensive enough that every serious effort carried an assumption of permanence. AI weakens that assumption. It lets software be generated for smaller needs, shorter lifetimes, narrower audiences, and more experimental purposes.
That does not make engineering less important. It makes judgment more important.
The question is no longer only: what software should we build?
It is also: what software should we generate temporarily, so we can think, decide, communicate, or act faster?
Disposable software is not a lower form of software. It is a different category of software.
It is software as a sketch. Software as a conversation. Software as a prototype. Software as a single-use tool. Software as context.
And in a world where agents can produce software on demand, learning when to throw software away may become just as important as learning how to build it.
Written and developed with Claude. The arguments are mine; the drafting was collaborative.