Legacy code is a legacy idea
One argument that is often put forward in the debate on GenAI and its prospects within software development is concerned with the risk of bloated code bases and technical debt run amok. This argument takes one of the primary forces of agentic coding tools, extreme efficiency in producing code, and turns it on its head: We will drown in waves of AI slop and no one will understand the codebase.
Enticing as it is, I do think these arguments lack a little imagination. The problem is that they accept the premise that coding agents are actually efficient, but then fail to follow this premise to the end.
Treat apps as cattle, not pets
Consider a modern DevOps pipeline with IaC and cloud computing. In the not so distant past, servers each had their own name and were nurtured back to life whenever they malfunctioned.
Apply the metaphor of servers as cattle, not pets, to the software writing domain and the unthinkable emerges: Software without a codebase.
The future
The future of software is not apps built from a codebase that is maintained and developed in a collaboration between human developers and AI agents. The future is not apps developed by a swarm of AI agents overseen by human masters. The future is apps built from the ground up for every user on every download purely by AI agents. Based on the user's preferences and needs the necessary code is generated, the app is built and installed, and then the source code dies along with the agent that generated it.
Two users will have completely different apps. They serve the same purpose, but one might be blue and the other purple. Two users might have an app that looks pretty much the same, but the source code is different, because different agents wrote it at different times. Class names in the CSS-files are different. Code structure is inconsistent, but it does not matter because no one will ever read the source code. You would actually have to decompile the app to read it, because the source code is not stored anywhere.
If the app dies in production, it is rewritten and redeployed.
The end of legacy code
The point here is that the death of the codebase also means the end of legacy code. Think about it. No more documentation and no need for anyone to understand what the code does. Why would we have machines write the code at insane speeds, if we still need a human to read it afterwards?
What about quality and security? Well, we are going to the end of the line, as I said, so of course the answer is more agents! Hordes of adversarial testing agents with a simple open-ended task: "Break this app".
Pipeline aka. lots and lots of agents
This is your pipeline: An onboarding agent gathers what information you want/need from the user and spins up subagents to generate an attempt on the app to serve the user. Upon completing an attempt, each subagent spins up a horde of further test subagents. When a test agent decides that an attempt for an app is good enough, it releases the app and all other ongoing agents are terminated.
It is not a question of making the perfect app - a cathedral, as it goes - it is a throng of agents racing in parallel to make something that suffices.
Recommended by LinkedIn
Yes, compute needs to be extremely cheap for this to make sense, but isn't this the trajectory we are on?
If this makes you think of the scene in World War Z where the zombies just pile on top of each other until one makes it over the wall, I don't blame you. Although it is unfair. AI agents are not here to eat our brains, I think, but they are relentless, unwavering and work in parallel.
The specification is the artifact
Surely there is a specification somewhere, right? And data contracts? Yes, I can't see how we can do without. It is still software, but in this scenario the app needs just two things: To compile and serve the purpose. The specification to achieve this does not need sections on coding style, application architecture or even what stack you want to run. You want a really clear idea of what the app should do, and that is it.
Legacy of code
I do not have a strongly made up mind about whether the sketched out scenario is good or bad. I do think it is hard to imagine your banking app produced this way, but what about the calculator app or your to-do list app?
I for one do not think that concerns about legacy code are what will stop this train from running.
Sources of inspiration
I have read a few blog posts and other pieces that touch on the same ideas calling it disposable software or ephemeral software. See the list below:
0D Team — "The Ephemeral Code" (June 2025) [https://medium.com/@0D_xyz/the-ephemeral-code-the-death-of-permanent-software-f1e136a25fcc]
Ben Houston — "Software as Ephemeral" (March 2025) [https://benhouston3d.com/blog/ephemeral-software-in-the-era-of-ai]
Maisem Ali — "Ephemeral Software" (July 2025) [https://maisem.dev/blog/ephemeral]
Jules (?! Possibly an agent at HarrisonAIX) — "Disposable Software: Why Code is No Longer an Asset" (January 2026) [https://harrisonaix.com/blog/disposable-software-code-asset]
Christina Lin on Google Cloud blog — "Software Becomes Disposable?" (October 2025) [https://medium.com/google-cloud/software-becomes-disposable-how-ai-is-changing-the-way-we-architect-code-1bfb50356b98]
Very interesting read, Jonathan. I have not quite thought through your scenario, but I do speculate the following: 1) Communication between devices. It seems questionable if this kind of software is feasible if two devices who built "similar" apps can communicate, if they differ. It could be a simple feature that someone added to their app that simply would cause a malfunction. A simple reference could be if the messaging software of a Nokia 3310 suddenly being asked to receive a .gif. Building the app comes with a series of requirements which you today handle by version control and version compatibility. 2) Security. Without a codebase It will be very difficult to control if an app is built with a serious security breach or intentional malware (i.e. imagine the "app store" that built the app is designed to also build in a trojan horse). A counter argument of course is that without a codebase it also becomes much more difficult to hack the app.