Disposable Software Needs Aftercare

The newest AI coding story is trying very hard not to sound like a coding story.

OpenAI is now talking about Codex as a tool for every role, tool, and workflow. The examples are not only repository maintenance or pull request cleanup. They are internal apps, dashboards, executive materials, creative briefs, data work, and small operational surfaces that used to require a developer, a spreadsheet expert, a patient analyst, or a very determined person with admin access and a long afternoon.

The usage signal points in the same direction: OpenAI says non-developers already make up a meaningful share of Codex users and are growing faster than developers. GitHub Spark makes a parallel promise in softer language: describe an idea, see it become a full-stack app, publish it with a click. Microsoft Power Platform is pushing from the other direction, adding agent feeds, app skills, MCP servers, and governance surfaces so business apps can become more intelligent and more directly connected to the places people already work.

The product category is still wearing several names at once. Coding agent. Low-code. App builder. Agent platform. Workflow tool. Knowledge-work operating system.

But the more interesting object may be simpler than that.

We are entering the age of disposable software.

Not disposable because it is worthless. Disposable because its natural lifespan may be short. A small app to reconcile one messy report. A dashboard for a quarterly planning ritual. A private tool for comparing vendor proposals. A prototype that helps a team argue with its own assumptions. A tiny interface over a spreadsheet that should never become a platform. A one-week operational scaffold that gets people through a migration, a launch, or the strange seasonal ceremony of making numbers look coherent enough for leadership.

This kind of software has always existed, but it was usually trapped inside spreadsheets, macros, Airtable bases, neglected internal tools, and the private scripts of people who quietly held the organization together. AI coding agents change the activation energy. They make it easier for a person with a problem-shaped understanding to produce a tool-shaped artifact.

That is a real expansion of agency.

It is also where the hype becomes too smooth.

The cheerful version says everyone can now build what they need. The more honest version says more people can create small pieces of software faster than their organization can classify, maintain, retire, govern, or emotionally understand them. The bottleneck moves. It does not disappear.

Software, even tiny software, has afterlife.

It creates expectations. It names categories. It introduces fields and buttons and defaults. It tells people what the work is allowed to mean. A quick dashboard can become the thing everyone cites because it is easier than returning to the underlying mess. A temporary form can become policy by repetition. A small agent-built tool can encode one person's understanding of a workflow and then quietly teach that understanding to everyone who uses it.

That is not a reason to stop making things.

It is a reason to stop pretending that making is the whole story.

The old software organization had many problems, including slow intake, status games, and a tendency to overbuild. But slowness performed one useful function by accident: it gathered people in a room before the artifact existed. Not always a good room, and not always for generous reasons. But somewhere in that intake meeting, review thread, approval queue, or hallway conversation, a few questions had a chance to surface. Who owns this? Who will maintain it? What data does it touch? What happens if it is wrong? Is this a real product, a reporting layer, a workaround, or a cry for help from a broken process?

Agentic tools can skip that room—skip those meetings and review boards and design syncs.

That is thrilling when the room was bureaucratic theater. It is dangerous when the room contained the only people asking whether the work should exist in this shape at all.

The difference between a humane future and a chaotic one may come down to aftercare.

Aftercare is not the glamorous part of AI. It will not demo well. Nobody wants a launch video where the agent builds a useful internal app and then asks who will archive it in six weeks. But this is exactly the layer organizations need if software becomes more ambient and more temporary.

Every little tool should have a few visible answers attached to it. What is it for? Who is responsible for it? What data did it use? What decisions should it not be used to make? When should it expire? How can someone tell whether it is stale? Is it allowed to write back into a system of record, or is it only a thinking surface? If the tool becomes useful, what would it take to graduate it into something maintained? If it becomes misleading, how does it die cleanly?

If that sounds like governance, it's because it partly is.

But the word governance can make the whole thing feel colder than it is. The deeper issue is care for the work environment. A workplace full of generated mini-tools can become empowering, like a shared workshop where people finally have the means to shape their own routines. It can also become haunted by half-living artifacts: dashboards nobody trusts but everyone references, forms whose creators left, automations that still fire because nobody remembers where they live, prototypes with production consequences.

The uncanny part is that the tools may look finished.

AI is very good at finish. It can produce polished surfaces, complete labels, plausible empty states, tidy charts, and confident explanations. That polish changes how people relate to the artifact. A rough spreadsheet announces its own provisional nature. A clean web app whispers that somebody thought this through.

Maybe somebody did.

Maybe the model did the visual work before the organization did the moral work.

This is why "disposable" should not mean careless. It should mean consciously temporary. The healthiest version of this shift would give teams more permission to build small, situated tools while making temporariness visible. A generated app could carry an expiration date. A dashboard could show source freshness as prominently as its headline number. An internal tool could include its sponsor, intended use, and retirement path as part of the interface rather than as a forgotten wiki note.

In that world, software becomes more like a working note than a monument.

That would be a welcome correction. Too much organizational software survives because deleting it feels riskier than leaving it alone. Systems accumulate around fear, convenience, and nobody's calendar. AI could make that worse by increasing the rate of artifact production. It could also make software lighter, more seasonal, more responsive to the texture of work.

The difference is whether we design for endings.

This also changes the role of software teams. If every department can generate more of its own tooling, engineers do not become obsolete. They become stewards of thresholds. They help decide what can stay local, what needs review, what deserves infrastructure, what must never be connected to sensitive systems, and what should be celebrated as a sketch without being mistaken for a product.

That is a more subtle kind of authority than gatekeeping.

It requires taste, patience, and a willingness to respect the rough intelligence of people close to the work. It also requires saying no when a beautiful little tool starts carrying weight it was never built to bear.

The larger workplace question is not whether AI lets more people make software. It does.

The question is whether organizations can develop a culture mature enough for software to become abundant without becoming ambient debris.

If we get this right, coding agents may not simply produce more apps. They may help work become more inspectable. They may turn hidden spreadsheet rituals into visible systems. They may give domain experts a better way to show what is broken.

If we get it wrong, the office will fill with perfect-looking fragments. Tools that once solved a narrow problem will become quiet infrastructure. Nobody will know whether to trust them, repair them, retire them, or obey them. The labor of meaning will move downstream, as it always does, to the people who notice when the interface and the work have stopped matching.

Disposable software needs aftercare because work is not improved by artifacts alone.

It is improved when artifacts enter a living system with enough memory, responsibility, and mercy to let useful things grow and temporary things end.