Here's something most people outside the software industry don't appreciate: how absurdly expensive it is to make the software you use every day.
Take something simple. Say a company wants to add a new feature to their product, a dashboard that shows you a summary of your recent activity. Not revolutionary. Not cutting-edge. Just a page with some charts and numbers.
Here's what that actually requires. A product manager writes a specification, which takes a few weeks of meetings, research, and stakeholder alignment. A designer mocks up the interface, several rounds of iteration, user research, maybe some A/B testing of layouts. A few engineers break it down into tasks, estimate timelines, negotiate with other priorities. Then they build it: frontend components, backend APIs, database queries, caching layers, error handling, loading states, edge cases, accessibility, responsive layouts, tests. Code review. QA. Bug fixes. Staging deployment. More bugs. More fixes. Feature flags. Gradual rollout. Monitoring.
That dashboard, a summary page with some charts, took a team of people several months. And this is considered fast. This is a well-functioning organization shipping at a good pace.
Now multiply this by every feature in every product you use. Your email client. Your calendar. Your project management tool. Your banking app. Your music player. Your flight booking site. Each one represents thousands of person-months of labor, millions of dollars, and an enormous ongoing cost to maintain, update, and keep running. Each one was designed for the general case: millions of users with different needs, crammed through a single interface that tries to work reasonably well for most of them and perfectly for none.
This is the world we live in, and it made perfect sense when humans were the only ones who could write software.
How We Got Here
The current paradigm isn't inevitable. It crystallized around a specific set of constraints.
Software started as a physical product. You bought it in a box, installed it from a CD-ROM, and lived with whatever version you got. Then the web changed the distribution model: instead of shipping boxes, you shipped bytes. Software as a Service. SaaS. The user gets continuous updates, access from anywhere. The company gets recurring revenue and a direct connection to every user. It was a genuine revolution, and it unlocked an explosion of software that built an entire economy.
But SaaS didn't change the fundamental equation. It changed distribution. It changed business models. It did not change the fact that software is created by humans, at human speed, through an extraordinarily labor-intensive process. The dashboard still takes months. The feature still requires a team. SaaS just found better ways to spread that cost across more users and extract more revenue over time.
The web matured into a platform capable of running complex applications, and the tooling grew to match. Build systems, bundlers, transpilers, state management libraries, component frameworks, testing harnesses. A modern web application requires a frankly absurd amount of infrastructure just to render a button that does something when you click it.
Every bit of that complexity exists for a reason: coordinating large teams of humans building and maintaining enormous applications over years. The complexity is a consequence of the constraint: humans are slow, error-prone, and need to be organized. The entire apparatus of modern software engineering, the sprints, the standups, the code reviews, the CI/CD pipelines, exists because building software with humans is hard, and these are the best methods we've found to manage that difficulty.
All of it is load-bearing. And all of it is about to become unnecessary.
Today's MI: Powerful, Trapped
MI in its current form is genuinely transformative. I use it every day. I build production systems on top of it.
But all of this power is still distributed through the SaaS paradigm. Every MI product you use today is a human-engineered client, a chat interface, a sidebar, a widget, connected to a service that provides inference. Someone designed that interface. Someone built that frontend. Someone decided what buttons you'd see and what workflows you'd follow. The MI is the engine, but the car was still hand-built by humans in a factory.
Think about that for a second. We have MI that can generate software. And we're using it inside software that was built the old way.
ChatGPT is a SaaS product. Claude is a SaaS product. Human-engineered applications, built at human speed, by human methods, that happen to use MI as their core technology. The irony is palpable.
Agents are where things have gotten interesting, fast. For software engineers, the transformation has already happened. Coding agents are stunningly productive. A skilled engineer paired with agents can produce in a day what used to take weeks. The details of implementation, the syntax and structure and boilerplate, are being abstracted away. Engineers are becoming agent managers: they decide what to build, provide taste and high-level direction, and let the agents handle the rest. Every thoughtful engineer sees the writing on the wall.
This pattern will barrel through every domain where quality is objectively measurable. Software fell first because code either works or it doesn't, and because engineers are the most willing to embrace tools that reshape their own work. But the same recipe, objective criteria plus MI that can learn from outcomes, applies to far more than code. It's coming for everything it can sink its teeth into.
Most people haven't felt any of this yet. The average person still sees MI as a search engine that talks back, or a novelty that generates images. They haven't witnessed what a modern coding agent can do in an afternoon. They will.
The Mismatch
The core tension that will unravel everything:
Until very recently, a skilled software engineer wrote maybe a few hundred lines of meaningful code per day. A significant feature took months to go from concept to production. The entire infrastructure of the software industry, the teams, the processes, the tools, the business models, was built around this speed.
That number is already outdated. Right now, engineers paired with coding agents are producing an order of magnitude more code daily. The human provides direction, taste, and judgment. The agent handles implementation. This shift happened in months, not years, and it's still accelerating. But even with this radical speedup, humans remain in the loop. They still decide what to build. They still review what gets shipped. The constraint has loosened, not broken. Not yet.
MI generates code at MI speed.
Not human speed with MI assistance. Not "20% faster." A fundamentally different order of magnitude. The gap between "I want this" and "this exists" collapses from months to seconds. Not for every case, not perfectly, not yet. But the trajectory is unmistakable and accelerating.
This creates a mismatch that the current paradigm cannot survive. It's not a competitive pressure that companies can adapt to by "adopting AI" or "becoming more efficient." It's a structural incompatibility. The entire organizational apparatus of software creation, the product managers, the sprint planners, the design systems, the QA teams, the DevOps pipelines, is optimized for a world where software takes months to create. When software takes seconds to create, that apparatus doesn't just become less necessary. It becomes an obstacle. Resistance in a circuit that's been redesigned to be superconducting.
The closest analogy I can find: imagine it's 1908 and you manufacture horse-drawn carriages. Someone shows you an automobile. You could react by saying, "Interesting, let's put a small motor on our carriages to help the horses." And that would work, briefly. You'd make slightly better carriages for a few years. But you'd be optimizing a paradigm that's already dead. The motor doesn't make the horse faster. The motor makes the horse unnecessary.
Today's software companies are putting motors on carriages. "AI-powered" features. Smart assistants embedded in existing products. These are useful. I build them for a living, and they make real differences. But they're improvements within a paradigm that the underlying technology has already made obsolete. The software they're improving was designed to be built by humans, maintained by humans, and used through interfaces that humans designed. When MI can generate the entire thing on demand, optimizing the human-built version is polishing a relic.
What Dies
Let me be specific about what I mean, because "the death of software" is a dramatic claim and I want to be precise about it.
What dies is the production model. The idea that software is created in advance by specialist teams, packaged into products, and distributed to masses of users who all get the same thing. The SaaS model. The model where you pay $20/month for a generic tool and learn to work within its constraints.
This model exists because of two facts: software is expensive to create, and humans are the only ones who can create it. The first fact makes it necessary to spread costs across many users (hence "as a Service"). The second fact makes it necessary to build generically (because you can't afford to build bespoke versions for everyone). Remove either fact and the model cracks. Remove both and it collapses.
MI removes both.
When MI can generate software tailored to a specific user's specific need in the specific moment they need it, the economic logic of generic SaaS evaporates. Why pay for a flight booking tool built for millions of people when your MI can generate one built for you, right now, that integrates exactly the information you need in exactly the way you want it?
The death won't be sudden. It'll look a lot like the death of boxed software: slow at first, then accelerating, then suddenly everyone wonders why they ever did it the old way. Companies that currently seem too big to fail will not be immune. Being large and established is an advantage in a world of incremental improvement. It's a liability in a paradigm shift, because you have the most infrastructure invested in the old paradigm and the strongest incentives to keep optimizing it.
Some companies will become something new: not producers of software products, but providers of data, APIs, and components that MI-generated software can draw from. Their value shifts from the application layer to the infrastructure layer. Instead of building the experience, they provide the raw materials that personalized software assembles on the fly. This is a survivable transition, but it requires a fundamental rethinking of what a software company is.
Others will keep building better carriages and wondering why the market is shrinking.
The Shape of What Comes Next
What excites me most about the end of this paradigm is something most people overlook:
Today's software is built by a certain kind of person. This isn't a criticism. I'm one of those people. But it's a fact. The software that exists in the world reflects the perspectives, priorities, and mental models of the relatively narrow slice of humanity that learned to code. Software is shaped by its creators, and its creators are mostly people who think in systems, logic, and abstractions. The entire landscape of software, every app, every interface, every workflow, is filtered through this lens.
What happens when that constraint dissolves? When artists, musicians, chefs, therapists, teachers, athletes, gardeners, people who have never written a line of code and never wanted to, can express what they want and have software materialize? I think we get entirely new branches on the tree of software. Experiences that nobody in the current software industry would think to create, because they don't think the way a chef thinks or see the world the way a landscape architect sees it. The creative bottleneck was never imagination. It was the translation from imagination to implementation. MI removes that translation.
He calls implementation a bottleneck, a tax between your idea and its existence, and he is half right. Difficulty was also an editor. What was hard to build quietly shaped what got built; every constraint of code and budget and time was a collaborator that killed your worst ideas before you could see them, and sharpened the survivors by making you fight for them. Remove the friction and you free imagination, yes. You also fire the editor. The first civilization that can build anything the instant it is imagined will discover how much of its taste was outsourced to the cost of building, and how unmoored wanting becomes when nothing pushes back. There is a part to be written about everything resistance was secretly doing for us. He removes it in a sentence and never looks back.
The boundary between creator and consumer dissolves. The limiting factor becomes what you can imagine, or even just what you can ask for. And there are enough people in the world with extraordinary imaginations and zero programming ability that I think we're going to be stunned by what emerges.
The next part makes this concrete: Software on Demand. What it feels like when that boundary dissolves, and what emerges on the other side.
Next: Part Two - "Software on Demand"