The Age of Disposable Software

This is part 3 of the series reflecting on software.

The first two essays are:

Claude Code and The Rise of CLI

How We Build Software in the Age of AI

Claude used to answer mostly with text. Recently, it starts to give visualizations.

A request that once ended as prose now often becomes something you can see, manipulate, and interact with: a diagram, an inline chart, a small SVG, a simulated dashboard, or a lightweight React component. The important change is not only on the screen. It is in the production process. Claude is quietly taking a series of steps to make this happen: interpret the request, choose a representation, generate code, render the result, and make it available for immediate iteration.

The user experiences this as better communication: the explanation becomes visual, the data becomes explorable, the abstraction becomes concrete. But underneath that improved experience, a small piece of software has been created for one moment, one question, and one context. It may never need a roadmap, a repository, a deployment pipeline, or a second user. It only needs to be useful now.

In May 2026, Thariq Shihipar, an engineering lead at Anthropic, published The Unreasonable Effectiveness of HTML. The argument is that HTML had replaced Markdown as the better default for AI output. The reasoning: context windows have grown to a million tokens, making the token-scarcity rationale for plain text obsolete. HTML carries embedded charts, SVG diagrams, color-coded diffs, and interactive widgets. Markdown carries text. When the constraint disappears, the richer format wins. Anthropic’s Claude Artifacts had already been doing exactly this, without a manifesto.

The most surprising truth about this shift is not that Claude is able to do this, but that the effort has become affordable. The artifacts are consumed on the spot, seldom revisited, let alone integrated into a workflow. The code is being generated as part of the answer itself: part answer, part code.

Software, Disposable?

This is a deeper change than people often realize.

Some software is no longer being built as a durable product. It becomes disposable.

It is generated for a particular context, solves a particular problem, and can be replaced when the context changes.

Consider a high school biology student studying for a unit test. She has just asked AI to explain the difference between mitosis and meiosis, why DNA replication happens before cell division, how dominant and recessive alleles show up in a Punnett square, and why photosynthesis and cellular respiration are almost mirror processes: one stores energy in glucose, the other releases it as ATP.

After the explanation, she asks for a quick quiz: ten questions, mixed difficulty, no hints. The AI generates questions like: In which phase do sister chromatids separate? If two heterozygous pea plants are crossed, what fraction of offspring are expected to show the recessive trait? Why do muscle cells produce lactic acid when oxygen is low? What is the role of chlorophyll in photosynthesis?

She scores 8/10. The two missed questions reveal weak spots: she confused anaphase I with anaphase II, and she remembered the Punnett square ratio but not why genotype and phenotype are different. So she asks AI to explain those two mistakes and generate another quiz focused only on meiosis and Mendelian genetics. This time she scores 10/10. The feeling is small but real: the loop closed. Confusion became feedback; feedback became practice; practice became confidence.

What happened to the quiz afterward? Nothing. Nobody will visit it again. It will not be shared, stored, polished, versioned, or made permanent. It was not a product. It was a temporary learning instrument, like scratch paper used to solve an algebra problem. Its value came from existing at the exact moment the student needed it. Once it helped her learn, it had served its purpose.

That sounds wasteful only if we still assume software must be permanent.

To call it software will make developers uneasy. Programmers have always written throwaway code: a bash one-liner, a regex, an Excel macro, a scratch script used once and never saved. Disposable code is not new.

What is new is who makes it and how. The throwaway script used to be a craft reserved for people who could already code. Now the high school student generates her quiz without writing a line. The artifact is conversational; it is born inside the answer itself and often rendered as something you can see and click rather than run from a terminal. The disposable script has escaped the developer’s machine and entered everyone’s hands.

It is still code, but not software in the traditional sense. Not something we deploy, run, or build a workflow around.

The IKEA Life Style

I have assembled enough IKEA furniture to develop real affection for its ethos. In different rental spaces, at different stages of life, I have repeatedly bought IKEA pieces not because I expected them to become family heirlooms, but because they fit the life I was actually living: temporary apartments, changing layouts, limited budgets, and the need to make a space functional quickly. Some people criticize IKEA furniture for not lasting forever, but many of the pieces I used lasted longer than my need for them. They survived the lease, the move, the short-term purpose. In that sense, they did exactly what they were supposed to do.

What is the value of a piece of furniture? You can ask, ‘does it last a century?’ or, ‘does it provide the life style support while you need it.’ A handcrafted oak table and an IKEA desk solve different problems. One is optimized for permanence. The other is optimized for adaptability. The IKEA desk is not a failed oak table. It belongs to a different philosophy of use.

A growing category of software is moving in the same direction. It is not built like heirloom furniture. It is closer to IKEA: functional, stylish, affordable, and flexible enough to be left behind when the environment changes.

Not all software becomes disposable. Some software is still infrastructure. Banking systems, medical software, enterprise data pipelines, security infrastructure, and mission-critical workflows still require durability, governance, and reliability. But many lightweight software use cases are shifting from permanent products to temporary generated artifacts.

What divides the two is a simple test: disposable software makes sense when replacement is cheaper than maintenance. A chart you can regenerate in seconds never needs to be kept; a banking ledger does. The test sorts the IKEA desk from the oak table.

This is also where the obvious worry lives. Throwaway code is unaudited code. The quiz might contain a wrong answer; the inline chart might misread the CSV; the generated slides might quietly invent a number. Disposability and correctness pull against each other. What licenses the tradeoff is stakes and proximity: the student sees the quiz answer immediately and can challenge it, the analyst is looking at her own data, and the cost of being wrong is small and instantly visible. The moment stakes rise — money, health, legal exposure — the calculus flips back toward durable, governed, auditable software. Disposability is not a universal virtue. It is a privilege of low-stakes, self-verifying contexts.

If I only need to understand a CSV once, I may not need to subscribe to a dashboarding product such as Tableau. I may need an inline chart that exists long enough to answer my question. If I only occasionally make presentations, I don’t need to pay for Microsoft PowerPoint. Instead I may just ask AI to generate interactive HTML code that serves as my slides.

The Great Compression

How did software get cheap enough to throw away? Because AI compresses the distance between intention and implementation.

In the old software world, even a small feature carried organizational weight. Someone had to specify it, design it, implement it, test it, deploy it, and maintain it. A single visualization meant a data ingestion pipeline, a charting library, a UI surface of customizable components, and a steep learning curve to wire them together.

AI collapses that process. A feature that once took weeks appears in minutes; a prototype that once needed a team is built by one person over a weekend; a visualization that once required a dedicated tool is produced inline, as part of the answer.

This changes what users expect. Once you have experienced software generated at the moment of need, static output starts to feel unfinished: a summary you cannot interrogate, a table you cannot reshape, an interface that was never built for your question. Instead of routing every need into a permanent product surface, AI generates a temporary one. The boundary between “answer” and “application” begins to dissolve.

The clearest casualty is the lightweight tool. Enterprise software still has hard problems: permissions, governance, audit trails, compliance, reliability. Those are not dissolved by a single generated artifact. But the casual, exploratory, one-time use case no longer needs a full product. If a user only needs to cross a stream once, they do not build a bridge. They step on a stone. Disposable software creates stones on demand.

Consider what that compression means at the moment you decide whether to build something at all. Andrej Karpathy described a personal story about an app he tried to build. Imagine you want to help people understand restaurant menus in a foreign language or unfamiliar cuisine. A traditional software approach would require several components: OCR to read the menu, a parser to identify dishes and ingredients, image generation to visualize what dishes might look like, and an overlay system to place those images back on the page. That is a reasonable engineering plan. It is also a lot of software.

A model-native approach asks a different question: can a multimodal model collapse this entire pipeline? Instead of writing separate systems for OCR, dish understanding, image generation, and visual overlay, perhaps the model can simply look at the menu and produce an annotated version directly.

The lesson is not that one implementation is always better. The lesson is that the decision itself has become strategic. Before AI, the question was almost always “how do we build this?” The options were narrower. Now the question branches earlier: should this be code, a prompt, an agent workflow, a generated interface built once and discarded, or something that earns the cost of permanence?

A model-native path may be simpler and faster to reach, but it gives up determinism and fine-grained control. That trade-off is real. What has changed is that the trade-off is now worth examining for every small problem, not just the ones where you already know building is expensive.

Sometimes the best use of AI is not to help you write the code faster. Sometimes the best use of AI is to eliminate the code you were about to write.

Permanence Becomes a Choice

For most of software’s history, permanence was the default. You built a thing, deployed it, and maintained it. Building was so expensive that anything worth building was worth keeping. Disposability, the throwaway script, was the rare exception, and only people who could code were allowed it.

AI inverts this. When generation costs minutes instead of months, permanence stops being the default and becomes a deliberate, expensive choice. Building is cheap; owning is not. The moment software has users it accumulates obligations: uptime, bugs, support, security, migrations. Those obligations, not the code, are now the real cost. So the question shifts. It is no longer “can I build this?” Increasingly the answer is yes. It is “does this deserve to persist?”

Most of what we generate will not, and that is not a failure. Software becomes less like a building and more like spoken words: produced on demand, shaped by context, and left behind when the conversation moves on. We do not archive every sentence we speak, and we do not mourn the ones we forget.