Software Is Becoming Disposable. Trust Isn't.
Imagine an application built on Monday, deployed on Tuesday, used for a business process on Wednesday, and deliberately retired on Friday.
No technical failure. No abandoned project. The application simply completed the work it was designed to perform.
For decades, software engineering has operated on a fundamental assumption: building software is expensive, so we should design it to last.
We invested heavily in architecture, development, testing, deployment and maintenance. We created reusable components, frameworks, platforms and entire ecosystems to extend the useful life of applications.
AI is beginning to challenge that assumption.
We are entering a period where generating software may become significantly cheaper than understanding, verifying and maintaining it.
And that raises two interesting questions.
If software becomes inexpensive to create, should every application still be designed to last? And if generating software becomes cheap, what happens when verifying it remains expensive?
The Economics of Software Are Changing
Traditionally, the economics of software favoured reuse and longevity. Once an application was built, organisations wanted to maximise its useful life and recover the investment over time.
AI coding agents are beginning to change the cost of initial creation.
An application that previously required weeks of development may now be generated in hours for certain well-defined use cases. AI agents can generate interfaces, business logic, tests, configurations and deployment artefacts.
But the economics of verification are not necessarily changing at the same rate.
An AI agent may generate an application in minutes, but how do we establish that its calculations are correct, its dependencies are secure, its permissions are appropriate, and its behaviour matches business expectations?
Generating ten applications does not automatically make verifying ten applications inexpensive.
In fact, if we generate software faster than we can establish confidence in it, we may create a new bottleneck in software engineering.
The constraint shifts from how quickly we can create software to how quickly we can establish trust in what we create.
And this has implications far beyond developer productivity.
What If Applications Had an Expiry Date?
Consider a business team preparing for a three-day conference.
Today, the team might use spreadsheets, dashboards, registration platforms and project management tools to coordinate participants, logistics, resources and reporting.
Imagine an AI agent assembling a purpose-built application that brings these capabilities together for the event.
The application exists for a few weeks, supports the event, generates the necessary reports and is retired when its purpose is fulfilled.
Its business records and required audit information remain available, but the application itself no longer needs to exist.
This is the idea of disposable software.
Applications are created for a defined purpose, operate within a defined scope and are deliberately retired when their usefulness ends.
However, disposable software is not simply about generating applications quickly and deleting them afterwards.
It challenges a deeper assumption in software architecture: must the application itself be the permanent asset?
Perhaps the enduring value is not the application, but the business capabilities, data, rules and knowledge that the application consumes.
The interface could be temporary. The business capability could be permanent.
This is where things become interesting.
Software Can Be Disposable. Trust Cannot.
Imagine two applications generated by AI.
The first displays event schedules and publicly available information. It has read-only access to approved data and will exist for five days.
The second calculates employee payroll adjustments. It also exists for five days.
Both applications are temporary, but they cannot be treated equally.
The payroll application must satisfy much stronger requirements around correctness, privacy, authorisation and accountability.
Its short lifespan does not make incorrect calculations or security failures any less consequential.
This exposes a potential weakness in disposable software: if we make applications disposable without rethinking verification, we could end up generating and testing the same capabilities repeatedly.
The problem is not the lifetime of an application. It is the responsibility associated with what that application does.
This suggests an alternative architectural approach.
Instead of allowing every generated application to recreate business logic, permissions, data access and validation processes, we could establish a foundation of trusted, reusable capabilities.
These capabilities would expose clearly defined contracts, rules, permissions and verification mechanisms.
AI agents could then generate temporary applications that assemble and consume these capabilities without repeatedly implementing them.
An application might be created for a day, a week or a month, while the trusted foundation behind it continues to operate.
The application becomes disposable, but the trust established in its underlying capabilities becomes reusable.
From Reusable Code to Reusable Verification
For decades, software engineering has focused on code reuse.
We built libraries, frameworks, APIs and services to avoid solving the same technical problems repeatedly.
But AI-generated software creates an opportunity to rethink what we should reuse.
What if, instead of simply reusing code, we could reuse the evidence that certain capabilities behave correctly under defined conditions?
Consider an AI-generated application that calculates shipping charges.
If the underlying calculation capability has already been independently validated against approved business rules, every application consuming it should not need to recreate the same calculations and repeat the entire validation process.
The generated application would still need verification of its integration, inputs, permissions and overall behaviour, but some of the assurance about the underlying capability could be carried forward.
This is where harness engineering becomes important.
An agent harness can provide constraints, execution environments, approved tools, tests, monitoring and feedback loops that guide how AI agents generate and validate software.
The objective is not to trust AI-generated code simply because another AI agent has tested it.
It is to establish independent verification mechanisms, enforce approved contracts and preserve evidence of what has been validated.
Over time, the reusable asset may extend beyond code to include business contracts, validation rules, test evidence, security policies and operational constraints.
Of course, trust is never universal or permanent. A capability validated under one set of conditions may require reassessment when its dependencies, business rules or operating context change.
But we would no longer need to start every verification exercise from zero.
Perhaps the next major abstraction in software engineering is not another framework for generating code, but an architecture for reusing verified behaviour.
Could Disposable Software Also Be More Sustainable?
There is another dimension to this shift.
Today, organisations maintain applications that may have outlived their original business purpose. These applications continue to require infrastructure, patches, dependencies, monitoring and operational support.
Disposable software could potentially reduce some of this overhead.
But there is an important trade-off.
If AI agents continuously regenerate applications, repeatedly invoke models, reproduce business logic and execute extensive verification processes, we may simply exchange maintenance overhead for generation and verification overhead.
Even temporary applications can leave behind persistent data, unused cloud resources, credentials and dependencies.
From a sustainability perspective, we need to evaluate the entire lifecycle.
The resources consumed during generation, verification, deployment, operation and retirement all matter.
So do the energy, carbon, water, hardware and waste impacts associated with those activities.
Imagine two approaches to solving the same business problem.
One maintains a lightweight application for a year. The other generates a new application every week and retires it afterwards.
Which approach is more efficient?
There is no universal answer. It depends on the resources required to generate and verify the applications, their operating characteristics, how often requirements change, and whether trusted capabilities can be reused.
This introduces a useful architectural principle:
Software should exist for as long as it delivers value, but generating it again should not automatically become the default.
Sometimes permanent software will be the better choice. Sometimes temporary software will be more appropriate. And sometimes an existing capability can deliver the outcome without creating another application.
The objective is not to maximise the number of applications we can generate, but to minimise the lifecycle cost and resource consumption required to deliver useful business outcomes.
The Next Measure of Software Productivity
We have spent decades improving the speed at which we develop, test and deploy software.
AI may dramatically accelerate the creation part of this lifecycle.
But if generating applications becomes nearly effortless, the number of applications produced or the amount of code generated becomes a less meaningful measure of productivity.
The more interesting questions are how confidently those applications can be operated, how much verification can be reused, how efficiently they deliver their intended outcomes and whether they should continue to exist.
This changes the way we think about software ownership.
Instead of treating every application as a permanent asset requiring indefinite maintenance, we could begin designing applications with an explicit purpose, a defined lifetime, an appropriate level of assurance and a retirement strategy.
Durable business capabilities would provide continuity. Temporary applications would provide flexibility. Reusable verification would help establish trust across both.
The future of software engineering may not be about writing more code or even generating code faster.
It may be about knowing which software deserves to exist, how long it should live, and how much trust we can carry forward when we build the next application.
Because when generating software becomes cheaper than verifying it, the most valuable engineering asset may no longer be the software we create.
It may be the confidence we can reuse without having to recreate it.
What do you think?
If generating an application becomes trivial, what should decide whether it deserves to exist at all — and how much of your verification could you realistically carry forward today? I’d love to hear your perspective in the comments.
Thank you for reading Technology Bytes.
Subscribe to stay updated with future insights on the intersection of AI, software architecture, sustainability and emerging technologies.