What If Software as We Know It Is Already Becoming Obsolete?

I've been thinking quite a bit lately about where software development is headed, and the more I experiment with AI, the more I wonder whether we're looking at something much bigger than another productivity improvement. We're all talking about how much faster developers can write code, how many tasks AI agents can complete, and whether one model is better at programming than another. Those are interesting conversations, but I think we might be overlooking a much bigger possibility. What if the entire concept of building and maintaining software applications is about to change?

I'm starting to wonder whether software as we know it will even exist ten years from now. Even five years from now?

Before somebody points out that banks, hospitals, governments, and businesses aren't going to throw away their software tomorrow, I agree. I'm not suggesting that computers will stop executing code or that every enterprise system will suddenly disappear. I'm questioning whether the applications we spend months or years building today will continue to make sense when AI can generate software specifically for what somebody needs, exactly when they need it.

The Rise of Disposable Software

I came across an interesting prediction recently suggesting that software could eventually become disposable. An application might be created for a particular task, used for a few hours or a day, and then discarded. At first, that sounds completely ridiculous. We've spent decades building applications designed to last. We invest in architecture, maintainability, documentation, deployment pipelines, and entire teams responsible for keeping those applications running. The idea of intentionally throwing away working software seems almost irresponsible, but think about what happens when the cost of creating that software approaches the cost of simply describing what you need.

Imagine needing an application to reconcile two datasets, generate a report, or automate a specific business process. Today, depending on the complexity, that might involve requirements gathering, development, testing, deployment, and ongoing maintenance. In a different world, you might explain the task to an AI system, connect it to the appropriate data sources, define the expected results, and have a working application generated in minutes. Once the task is complete, there's no particular reason to keep the application around. The next time you need something similar, you simply generate it again.

Of course, there's a difference between generating code and trusting it. A temporary application handling financial information still needs appropriate permissions, validation, security, and accountability. Making software disposable doesn't magically eliminate those responsibilities, but perhaps those responsibilities increasingly belong to the platforms and systems orchestrating the applications rather than to every individual application itself. That's where I think things get particularly interesting.

The Platforms Survive, but the Applications Change

I don't believe companies like Microsoft and Google are going anywhere. If anything, the infrastructure and services they provide could become even more important. Businesses will still need identity management, databases, storage, communication systems, security boundaries, and reliable ways to access their information. Those foundational systems aren't necessarily becoming disposable just because the applications interacting with them might be. What could change is how we interact with those systems.

Today, we build applications with interfaces designed around the capabilities of individual platforms. We open a particular application, navigate through menus, enter information, and perform the workflows its developers anticipated. But what happens when an AI agent can interact directly with those underlying services through APIs, MCP servers, or whatever standardized interfaces become common in the future?

Instead of opening several applications to gather information, manipulate it, and produce an output, you might simply describe what you want accomplished. The agent could coordinate the necessary services, generate whatever temporary logic or interface is required, and return the result. You wouldn't necessarily care whether a dedicated application existed to perform the task. You'd care whether the task was completed correctly.

I think we'll still have permanent applications where consistency, performance, regulation, or user experience justify them, but I wonder how many smaller internal tools, administrative interfaces, reporting applications, and one-off business workflows will eventually become unnecessary as standalone products. If that happens, the value shifts away from the application itself and toward the data, the services, the permissions, and the ability to orchestrate them reliably.

Why We Created Programming Languages in the First Place

There's another part of this that I find just as fascinating, and it goes back to something I used to emphasize when teaching junior developers. I've always been a strong believer in writing clean, readable code. Computers don't need our well-named variables, carefully organized classes, or descriptive method names to execute instructions. At the lowest level, they're perfectly comfortable processing machine instructions. We created layers of abstraction because humans needed a practical way to express, understand, and maintain increasingly complicated systems.

Imagine trying to build and maintain a modern enterprise application entirely in ones and zeros. Technically, computers operate on binary representations, but that doesn't mean humans should be writing applications that way. Assembly language gave programmers a more manageable representation of machine instructions. Higher-level languages moved us further away from hardware details, and modern frameworks abstracted away even more of the repetitive work. Each step allowed developers to spend less time worrying about how the machine performed an operation and more time concentrating on what they wanted the software to accomplish.

One of the principles I've repeated over the years is that code is easy to read because it should be written for humans to read first and machines to execute second. Readability matters because software is rarely written once and never touched again. Somebody eventually needs to understand it, troubleshoot it, extend it, or explain why it behaves the way it does, but what happens when humans are no longer the primary authors or readers of much of that code? That's a question I never seriously expected to be asking.

Does the Programming Language Even Matter Anymore?

I've been thinking about this more as AI coding tools become increasingly capable. If an AI system can generate an implementation, run tests, diagnose failures, and modify the code without a human manually editing every function, does the underlying programming language carry the same importance it once did?

I'm not suggesting that all programming languages perform equally or that their technical differences disappear. They don't. Performance, memory safety, concurrency, ecosystem maturity, runtime requirements, and deployment constraints still matter. Choosing Rust over Python or C# over JavaScript can have real consequences depending on the problem you're solving, but those choices might become implementation decisions made by an intelligent system rather than decisions every developer needs to manage directly.

For years, we've spent considerable effort debating programming languages, frameworks, architectural patterns, and coding conventions. Some of those decisions have enormous consequences because humans are responsible for writing and maintaining the resulting code. If software can be generated and regenerated reliably, however, the economics of those decisions change.

The question might stop being which programming language a developer knows best and become which implementation best satisfies the requirements, constraints, and expected behavior. That doesn't make engineering knowledge worthless, it's quite the opposite. Understanding performance, security, distributed systems, failure modes, and software architecture may become even more important when you're responsible for evaluating what an AI system produces, but it could dramatically change how we apply that knowledge.

What If the Next Programming Language Is English?

I've seen people suggest that the next programming language might effectively be plain English written in Markdown. That sounds almost too simple, but I'm beginning to think there's something to the idea. I have a feeling there will be some kind of checks going forward for syntax like scope, outcome, guardrails, etc. If those aren't defined, some type of compile error, maybe?

Consider what a developer actually needs to communicate to an AI coding agent. We describe the problem, explain the expected behavior, define constraints, provide examples, and establish acceptance criteria. The clearer those instructions are, the better the system can understand what we're asking it to accomplish.

In some ways, that starts looking less like traditional programming and more like writing a specification.

Instead of writing every class, method, loop, and conditional statement ourselves, we could describe the behavior of the system and let an AI determine how to implement it. We would still need to validate the output, define what success looks like, and understand the consequences of incorrect behavior. But the primary artifact we maintain might eventually be the specification rather than the generated source code, and perhaps that specification is written in Markdown.

I don't think natural language alone is precise enough to replace every programming construct. Human language is ambiguous, and software often requires exact, deterministic behavior. More likely, we'd end up with a combination of natural language, structured requirements, executable tests, schema, and machine-verifiable constraints; the idea that English could become the primary interface for creating software isn't nearly as absurd to me as it would have sounded a few years ago.

We've spent decades creating abstractions that move programmers further away from machine instructions. Maybe describing desired behavior and allowing a system to generate the implementation is simply the next step.

The Part That Still Makes Me Skeptical

There's an obvious problem with this prediction, and I don't think we should ignore it: generating software isn't the same thing as operating software.

A system that handles financial transactions, medical records, or sensitive customer information can't simply be considered successful because an AI generated code that appears to work. It needs security controls, predictable behavior, auditing, monitoring, compliance, and a clear understanding of who is responsible when something goes wrong.

And even outside regulated industries, maintaining software isn't always the expensive part. Understanding the business problem, integrating with existing systems, dealing with unexpected conditions, and making sure the output is correct can be far more difficult than writing the code. AI doesn't eliminate those problems; in some cases, it might make them worse by allowing us to generate complicated systems faster than we can meaningfully validate them.

There's also the question of whether regenerating software is actually preferable to maintaining something that already works. A stable, well-tested application might be cheaper, safer, and more predictable than generating a replacement every time somebody needs it.

So in short, I don't think every application will become disposable. I don't think developers will stop needing to understand software, and I certainly don't think we'll reach a point where technical decisions no longer matter, but I do think the balance between permanent applications and software generated on demand could shift substantially.

What Happens to Software Engineers?

This might be the most interesting question of all.

If AI increasingly handles the mechanical work of producing code, what does that mean for the people who have spent their careers learning how to write it?

I don't believe the answer is that software engineers simply disappear. But I do think the profession could change dramatically. Developers may spend less time implementing individual features and more time defining problems, designing systems, establishing constraints, evaluating tradeoffs, and verifying results. In other words, the ability to understand what should be built and determine whether it works could become more valuable than the ability to manually produce the implementation.

That raises some uncomfortable questions about how we train new developers. If junior engineers aren't spending years writing and debugging code, how do they develop the intuition needed to recognize poor architecture, security vulnerabilities, or incorrect assumptions? How do we teach somebody to evaluate a system they might never have been required to build manually? I'm repeatedly asked why my prompts yield better results than others I know trying and spending a lot longer on the same types of tasks. A lot of this comes down to intuition I've gained through the years.

I don't have a good answer to where this goes - I don't think anyone has the faintest idea, but I think it's something our industry needs to take seriously.

I also wonder whether we'll eventually stop measuring engineering productivity in terms of code produced, features delivered, or even applications built. Maybe the more meaningful measurement becomes how effectively someone can turn a business problem into a reliable, secure, verifiable outcome; that's a very different way of thinking about software development.

Ten Years From Now

I could be completely wrong about all of this. Predicting technology ten years into the future is difficult enough under normal circumstances, and I don't think there's anything normal about the pace of change we're experiencing right now, but I keep coming back to the same thought. We spend an enormous amount of time discussing which AI coding tool is better, how much faster we can produce code, and whether AI will replace individual developers. Those conversations assume that the fundamental structure of software development remains relatively unchanged and that AI simply helps us do the same work faster. I'm not convinced that's the future we're heading toward.

Maybe the bigger transformation isn't that AI allows us to build applications ten times faster. Maybe it's that we stop needing to build so many permanent applications in the first place.

Maybe programming languages become implementation details that most people rarely think about. Maybe the specifications, tests, and constraints we give intelligent systems become more important than the source code those systems generate. Maybe software becomes something we request and consume rather than something we install, maintain, and replace every few years.

And maybe, ten years from now, we'll look back at the enormous amount of time we spent manually writing and maintaining application code and wonder why we ever needed to do so much of it ourselves.

We keep talking about AI making developers more productive. I'm starting to think that's the least interesting part of what's happening. I know many developers are having an identity crisis right now. Many saw their value in being a wizard that created runes from thin air that basically performed magic, but now, everyone has a wand. What do the wizards do? Is everyone a wizard now? I think developers need to abstract away from that level of thinking and think in much larger picture terms.