When software lasts as long as the problem

Most of the software that could be useful is never built.

Not because it is technically impossible, but because the problem is too small. A tool for organising migration data, reviewing a batch of contracts or coordinating an operation that will last two weeks may save many hours and still not justify a software project. Designing, developing, deploying and maintaining it costs more than living with several spreadsheets.

Code generation is shifting that boundary. When obtaining a functional interface no longer takes weeks, applications can appear without having to become products. They are created for one objective, live for as long as that objective exists and are then abandoned.

They are beginning to be called single-use apps, disposable apps or ephemeral software. The name has not yet settled. The question they raise is more interesting: if creating software is no longer the expensive part, which software still deserves to be permanent?

Software was expected to last

Traditional development starts from a reasonable expectation: an application should be used enough times to recoup the effort of building it.

That is why products try to cover many use cases. They add configuration, permissions, importers, tutorials and screens for different audiences. This generality spreads the cost across thousands of people and several years, but it also forces each user to adapt their problem to the tool.

A one-off need sits outside that economy. If a team needs a very specific view during a migration, it normally has to force it into Excel, combine several tools or request an internal development that will probably never become a priority.

Single-use applications reverse the calculation. They do not ask how many years the software will live, but whether the value of solving the task exceeds the cost of generating it now. Throwing away the result is no longer wasteful when rebuilding it costs less than learning, configuring and maintaining a generic tool.

In August 2025, Anish Acharya used the term disposable software to describe small personal applications that would previously have made no economic sense. He was not talking about particularly novel code. The novelty was that a tool could be valuable without aspiring to scale, make money or survive.

One name, three different ideas

Some of the confusion comes from calling systems that work in very different ways a generated app.

The most direct version is to generate a conventional application and discard it afterwards. A model writes the initial HTML, JavaScript or backend. The result can be run, inspected and modified like any other software. Its life is short by choice, not because it has no code.

One step further is the generative interface. Instead of always responding with text or displaying a screen designed in advance, the system builds a visualisation suited to the request: a table, a simulator, a chart or a combination of controls. Google presented this direction as generative UI and began testing it in Gemini and Search’s AI Mode through dynamic view in late 2025.

Here, the system is not necessarily generating a product that someone will keep. It is generating the best way to interact with an answer.

The third version is far more radical: the model represents the application’s behaviour while the person is using it.

Anthropic explored this idea with Imagine with Claude. In that experiment, there was no complete feature set prepared before the interaction began. Claude built the software in real time and adapted it as new interactions arrived. Part of that work later reappeared in a more contained format: charts and interactive visualisations created inside a conversation.

Mirage, a prototype by Daniel Mewes, removes almost the entire application. The model generates the HTML for a screen and, when someone clicks a button, receives the interaction and produces the next screen. There is no persistent business logic determining the transition. The model imagines what should happen.

All three approaches can look identical in a demo. Technically, they are not. In the first, software is generated. In the second, an interface is generated on top of certain capabilities. In the third, the model attempts to be the software.

A case where the idea does make sense

Consider an infrastructure migration. For a few days, the team needs to cross-reference a cloud inventory, a cost export and a list of owners. It must find orphaned resources, group dependencies and produce an action plan.

A permanent application for that process would have to support future providers, different data schemas and countless exceptions. It would be a substantial product. But the current operation is bounded: three known sources, a small team and a clear deliverable.

A single-use app could create a review workspace for that dataset, offer purpose-built filters and export the final plan. Once the migration is complete, the interface is no longer useful. The corrected inventory, the decisions and the change log still are.

That distinction is the key. The application can be temporary; the truth it handles should not be.

The pattern fits when the task has a beginning and an end, the data is controlled, errors can be detected and there is an outcome that can be kept outside the tool. It is a poorer fit when the program itself must be the system of record, coordinate hundreds of users or execute actions that are difficult to reverse.

The most plausible architecture is not a hallucinated app

The soundest version of this idea separates a durable layer from a temporary one:

objective + context
        ↓
interface generated for the task
        ↓
permitted actions and components
        ↓
durable APIs, rules and data

The model decides which information is useful to display and which controls help at that moment. It does not decide by itself how an invoice is calculated, who can approve a payment or where history is stored. Those responsibilities remain in conventional services.

We might call it a stable core with a disposable interface.

This separation solves several problems at once. Data survives the session. Permissions do not depend on the prompt. Important actions can be validated and logged. The interface can change without regenerating the system that contains the truth.

It also explains the growing interest in declarative approaches. A2UI, introduced by Google as an open project in December 2025, allows an agent to describe an interface using structured data. The host application translates that description into components it already knows.

The model can request a table, selector or form without having to send arbitrary JavaScript. The product retains control over design, accessibility and the available actions. It is less free than generating any code at all, but that constraint is precisely what makes it more reasonable for production.

Drawing the screen is not the hard problem

A generative-interface demo usually focuses on the moment something visual appears. It is the easiest part to show and the one that creates the strongest sense of novelty. But it is not where the risk accumulates.

The significant cost begins when the interface must do something real:

• preserve state across sessions;
• distinguish users and permissions;
• produce the same calculation from the same data;
• survive a model failure;
• explain which action was executed and why;
• allow information to be undone or recovered;
• remain accessible and understandable even as it changes.

A conversation context is not a database. A plausible prediction is not a state transition. A convincing screen does not prove that the displayed data came from the correct source.

Mirage makes these limitations visible because it does not try to hide them. The prototype itself loses its data when the session closes, can change information unexpectedly and eventually fails when the context fills up. As an experiment, it is useful: it shows how far a model can simulate software. As an architecture, it also shows why simulation is not enough.

Generation reduces the cost of the first version. Trust, integration and operations still have a different cost.

What we are likely to see first

The nearest change will not be the disappearance of applications. It will be the disappearance of some of their fixed screens.

Products with valuable data and APIs will be able to build different views for different tasks. A financial system can keep its ledger and permissions intact while generating a purpose-built surface to investigate a discrepancy. An operations platform can gather the controls needed to resolve a particular incident into one view, then remove that view when the incident closes.

Software for the internal long tail will grow too: reconciliations, migrations, reviews and temporary processes that never justified a place on the roadmap. These tools will not replace core systems. They will build on them to solve the specific stretch that currently ends in a spreadsheet.

Some of these tools will be born with an explicit expiry date. At the end of the project, their credentials will be revoked, the outcome archived and the deployment deleted. For software to be temporary, its infrastructure and access must be temporary too—not just an abandoned repository.

Product work will also move. Instead of designing screens alone, teams will have to design the space in which a model can compose them: which components exist, which actions are permitted, which data is trustworthy and which states must never be generated.

Permanence will remain valuable

A stable interface creates memory. After using it several times, we know where each feature is, what will happen when we click it and how to explain the process to someone else. That predictability matters in frequent and critical tasks.

Generating a different experience for every session also has costs. It introduces latency, complicates support and multiplies the combinations that would need testing. Sometimes the best form is the same old form, because millions of people already understand how it works.

Single-use apps do not signal the end of maintained software. They expand the territory in which building something is worthwhile. They give a dedicated interface to problems too small, brief or specific to become a product.

The web organised much of software around pages. Mobile organised it around applications. The generative interface proposes organising part of it around intentions: the need appears first, then the way of interacting with it.

Underneath, we will still need systems that do not improvise. The question is not whether to choose permanent or disposable software, but to decide precisely what the system must remember once the interface no longer exists.

Sources

• Anish Acharya: Disposable Software
• Anthropic: introducing Imagine with Claude
• Anthropic: interactive visualisations inside Claude
• Google Research: Generative UI
• Google Developers: introducing the A2UI project
• Google Cloud: approaches to building generative interfaces
• Daniel Mewes: Mirage, a hallucinated application one screen at a time