In the last part, I described a death. The SaaS paradigm, the model where humans build generic software at human speed and sell it to millions, is structurally incompatible with a world where MI generates software in seconds. That's the fire. It's already burning.
This part is about what grows from the ashes.
I call it Software on Demand. And rather than explain it, let me show you.
What It Feels Like
You want to go to Japan. Not the version where you open twelve browser tabs and become the integration layer, copying dates and comparing prices, bending your thinking to fit interfaces that were never designed for you. That was the shackle. This is what it looks like when the shackle is gone.
You say: "I want two weeks in Japan in the spring. Gardens and food, especially ramen and kaiseki. A few days in Tokyo, but I want smaller cities too. I don't want to be rushed."
You don't open a flight booking site. You don't open anything. The MI already knows your finances, your calendar, your travel history. It knows you prefer visual layouts over lists. It knows you've been to Asia before and get overwhelmed by too many options. It knows you like a rough plan with flexible days. None of this lives in some travel app's profile. It's part of a personal understanding your MI has built over years of interaction with you.
What materializes has no logo, no navigation bar, no hero image of Mount Fuji. The MI reached across dozens of services in seconds: flight pricing, ryokan availability, garden bloom databases, restaurant reservations, train schedules, weather patterns. Today, these live in separate apps, the twelve tabs you'd normally have open. Here, they're one experience.
A map of Japan fills your screen, and it's already moving. Your two weeks take shape across the landscape: a route tracing itself like a river finding its course, pooling in Kyoto where the gardens cluster, bending through Kanazawa, rushing through a single transit day to Fukuoka. The map glows warm where spring peaks, dims where the crowds haven't thinned yet. A timeline runs along the bottom, the trip's rhythm laid out: which gardens peak which week, which days catch rain, when the ryokans thin out. Flight prices hover at the margins, shifting as the dates shift, bright when the deals are good, muted when they're not.
Then something catches your attention. The MI flagged a convergence you'd never have found: your preferred flight lands at Kansai in time to reach Kyoto for Kลdai-ji's spring evening illumination, a seasonal event that runs six weeks a year and overlaps with your dates by exactly three nights. A ryokan within walking distance has a last-minute cancellation. A kaiseki restaurant nearby serves a spring tasting menu that accommodates your shellfish allergy, cross-referenced from your medical data. No travel site on earth connects these dots. They live in different databases, different languages, different corners of the internet. The MI composed them because they were all true at once, right now, for you. Change your flight by a day and the constellation dissolves.
Nothing about this layout was pre-built. It reflects the way you think about travel: map-first, seasonal data prominent, prices visible but never central. Someone else, speaking the same words, would see a completely different arrangement, because their MI knows they think differently.
Here is the first crack in something nobody will hear break. Software was a hidden commons. We used the same tools, so we shared the same frustrations, the same metaphors, the same back button; a billion strangers learning one interface was a billion people quietly handed one small world in common. Bespoke software ends that, as a side effect of serving you perfectly. When every person's tools are shaped to their own mind, we lose the ability to say "you know how that screen works," because there is no that screen anymore. Personalization is the gentlest dissolver of the shared world ever invented, precisely because it feels like nothing but a gift. It will not be the last one in this book, and the later ones will not feel like gifts at all.
This is Software on Demand. Software that materializes from your intent, built for you, for this task, for this moment. It might never exist in exactly this form again.
And then something happens that no traditional software could do.
As you explore, the software watches. You linger on Kanazawa's Kenroku-en garden and the map quietly shifts: Kanazawa swells, new detail filling in, the days allocated there stretching in the timeline below. You skip past nightlife suggestions and they don't just sit ignored. They thin, dim, the space they occupied flowing into what you actually care about: more gardens, quieter neighborhoods, a morning market. You zoom into a ramen shop in Fukuoka and trace a loose circle on the map with your cursor. Not clicking anything. Just a gesture, a thought expressed through movement. Within seconds, a Fukuoka leg materializes in the timeline, that ramen shop anchored in the itinerary, the surrounding streets filling in with places that rhyme with what drew you there. You didn't type a command. You didn't press a button. You explored, and the software evolved around your exploration.
Behind the scenes, processes are already running: scanning flight prices across date ranges, comparing ryokan availability, mapping train connections, watching restaurant openings. A notification surfaces gently: your top-choice ryokan in Kanazawa just opened a cancellation for your dates. The MI already held it.
You say, "What if I spent more time in Kanazawa and less in Tokyo?" The map responds before you finish the sentence. Tokyo's cluster contracts, its recommendations condensing to essentials: the two restaurants you'd regret missing, the one neighborhood the MI knows you'd love. Kanazawa blooms. New ryokans surface, a ceramics workshop appears, the garden visit stretches from an afternoon to a full day with a suggested morning return. The budget recalculates across the bottom, barely shifting because the ryokan savings offset the extra days. The timeline redraws with the smooth inevitability of water finding a new level. Nothing was pre-programmed to handle this question. No engineer anticipated these words. The MI understood the implications across every dimension of the trip and reshaped the application to match.
Your MI notices something about you that you've never articulated. Across every trip you've taken, you gravitate toward the same kind of neighborhood: narrow streets, small shops, local life unhurried by tourism. It generates an overlay on the map highlighting pockets of each city that match this unnamed pattern, places no guidebook categorizes this way. The category exists only in your history. A preference you didn't know you had, made visible because your MI has watched you long enough to see what you can't.
Your webcam is on. You barely register it, but the MI reads your face the way a friend reads you across a table. You wince at a three-leg connection and the option quietly disappears. Your shoulders drop when the budget crosses a threshold and cheaper alternatives surface without being asked. The software isn't just responding to what you click. It's responding to who you are in this moment.
This is where the interaction goes. Not immediately, but inevitably. The progression from typing to speaking to gesturing to simply being present mirrors the history of human-computer interaction, but compressed from decades into years. We went from punch cards to keyboards to mice to touchscreens across half a century. Software on Demand collapses the next several leaps into one paradigm, because the limiting factor was never the input device. It was the software's ability to understand. When understanding becomes boundless, every gesture becomes meaningful. Interaction and generation coexist. The boundary between experiencing software and directing it dissolves.
You finalize the trip. The itinerary persists, not just in the airline's systems and the hotel's databases (it will live there too, because those services still handle the real-world mechanics of booking), but the thread that weaves it all together, the preferences it revealed, the decisions it captured, lives in your data, managed by your MI. When you share it with your travel companion, they see a version adapted to their way of thinking. They rearrange the Kyoto days, swap a temple visit for a morning at Nishiki Market. The two versions reconcile without friction.
During the trip, standing on a Kyoto sidewalk at 2 PM after a long morning at two temples, you say "what should I do this afternoon?" What appears on your phone isn't a list of top-ten attractions. The MI knows you've been walking since seven. It knows you loved the first temple and rushed through the second. It knows it's drizzling and you haven't eaten since breakfast. Three options appear, spaced generously, each a card you can expand with a tap. A covered market ten minutes' walk: a small map with the walking route drawn, the street food you've been gravitating toward marked along the way. A ceramics gallery four blocks east, a few pieces from the current exhibition scrolling slowly, the MI noting the artist's style echoes the plates you photographed at last night's dinner. A teahouse: just a name, an address, and "six-minute walk." The layout is quieter than this morning's. More whitespace. Fewer choices. Even the pace of the interface has slowed to match your afternoon. This software looks nothing like what it would generate at 9 AM in Tokyo on a fresh day. It doesn't need to. It was built for this moment.
A few days later, a pottery studio in Kanazawa. You're watching the potter work, asking questions through real-time translation. Then the MI pulls something unexpected. Two nights ago in Kyoto, you photographed a bowl at dinner, lingering on it, zooming in on the glaze. The MI surfaces the photo alongside a term the potter just used. The same technique. A connection between a meal you ate and a craft you're watching, bridged by an MI that was present for both. The potter sees the photo on your screen, lights up, and starts explaining. A conversation unfolds that no existing software could have sparked, because no travel app remembers what you ate Tuesday, no pottery database knows you're in Japan, and no one thought to connect the two. The software that made this moment possible was born when the potter started speaking. It will never exist again.
After the trip, the data persists. Your restaurant opinions, your photos with location data, your notes on which gardens were worth the visit, the patterns of what delighted you. Next time you plan a trip, or a friend asks for Japan recommendations, your MI draws from this living memory. The data appreciates over time. The software was ephemeral. The knowledge is permanent.
That's Software on Demand. Now here's what makes it possible.
Chronomorphic Software
The generated application isn't static. It's alive. The MI is its soul.
I call it chronomorphic software: software that evolves over time as you interact with it. The MI doesn't generate a complete application, hand it to you, and walk away. It generates a starting point and then continuously modifies, extends, and restructures the running code as context changes. The source code shifts underneath the experience, adapting in real time to what you're doing, what you need, and what the world around it is doing.
This creates a kind of dynamism that would be impossible for a human team to build in advance. Not just because no engineer can anticipate every path a user might take, but because no engineer can know you. Your preferences, your mood in this moment, the particular way your mind organizes information. Traditional software serves the average user. Chronomorphic software serves the actual one.
There's something almost biological about this. Traditional software is like a photograph: a fixed capture of a moment, frozen. Chronomorphic software is more like a living organism. It responds to its environment, adapts, grows. The code is its DNA, but the MI is its nervous system, continuously reading signals and adjusting behavior. What you see at any given moment is just a snapshot of something always in motion.
And this reveals the deeper architecture: the MI and the generated software are not separate things. They are one system. The MI doesn't build an application and step back. It generates an application and remains fused to it, continuously present, continuously responsive. The generated code is the current expression of the MI's understanding of what you need. When that understanding changes, the expression changes.
Every interaction, every gesture, every glance is a signal in a conversation conducted in a language richer than words. You don't step outside the experience to direct the MI. Using the software is directing the MI.
The MI isn't a feature within the software. The software is a feature of the MI.
Software has always been a conversation, but until now it's been one where the software only speaks a few words. "Click here." "Enter text." "Select from this list." Software on Demand gives the software fluency. And when both sides of a conversation can express themselves fully, the conversation becomes something else entirely. It becomes collaboration.
Data That Outlives Software
Today, your data is trapped. Your recipes live in one app. Your budget lives in another. Your travel plans in a third. Each application owns its little kingdom of your information, locked behind its interface, its authentication, its export limitations. You are the only thing that connects them. When you plan a trip, you are the integration layer, bridging the gap between systems with your attention and your clipboard.
Software on Demand inverts this entirely.
The data is free-floating. The applications are ephemeral. Software is generated around your data, shaped to whatever task you're performing right now. Your trip itinerary, your financial records, your recipe collection, your fitness data: they exist in a personal data layer that persists and grows, independent of any particular piece of generated software. When you need to plan a trip, software materializes that draws from your travel history, your finances, your calendar, your dietary preferences. When you need to budget, different software materializes against the same financial data. The data is the constant. The software is the variable.
This doesn't mean existing services disappear. Airlines still book flights. Banks still process transactions. Hotels still manage reservations. These services provide value that's meaningfully non-reproducible: the mechanics of booking a seat on a plane or processing a payment require real-world infrastructure that will continue to exist and to own the data necessary for its operations.
What changes is what sits on top. Generated software creates a new layer of data, connective tissue that binds these disparate services together in ways that are bespoke and meaningful to you. Your trip itinerary isn't the airline's data or the hotel's data. It's your data, the thing that weaves their services into a coherent experience shaped around your life. This floating layer, personal and contextual, is what the Software on Demand platform manages on your behalf.
And platform is the right word. Software on Demand needs a home: a place where generated software lives, runs, persists, and accesses the services it composes. This is the platform layer. Maybe it's built by today's MI companies. Maybe a hyperscaler. Maybe someone new. There will be multiple providers, and an interesting tension will emerge around standards: do their ecosystems interoperate, or do they become walled gardens? History suggests both happen, with open standards eventually winning the important battles, but the early years will be a land grab.
He frames the platform question as standards versus walled gardens, a familiar fight, and under it is the least familiar power in the book taking its first form. Whoever owns the layer that generates is not selling software. They are selling the right to bring things into being, and every experience anyone has runs as their guest. Follow that all the way down the series and it does not stop at apps. The same shape recurs at every scale, until the final version of it is authorship of reality itself, the right to place a seed and let a world unfold from it. Scarcity has been migrating this whole time: from goods, to attention, to data, and now to this. The last inequality will not be who owns the most. It will be who is permitted to make. He is watching the opening move of the longest game there is, and calling it a question about interoperability.
The data itself needs to flow fluidly between states. Some is personal and private: health records, financial information, private notes. Some starts personal and becomes shared: you plan a trip alone, then share it with friends who contribute. Some is collaborative from the start. Some is public. Data moves between these states, between different generated applications, and between different people, without losing coherence or access controls.
Your MI manages this. Not as a database administrator, but as an intelligence that understands your data semantically. It knows what exists, how it relates, what's private, what's shared. When you generate new software, the MI draws from this understanding to populate it with the right context. When the software produces new data, the MI integrates it back into the whole. Your data layer becomes a continuously maintained, continuously growing map of your life, your work, your preferences. A living memory that gets richer with every interaction.
The data appreciates. The software was ephemeral. What it knew about you is forever.
"Forever" is a heavier word than he uses it as. Watch what this floating, appreciating layer of you actually becomes if you let it run. Every preference it captures, every reaction it reads, every thread of how you think, accumulating losslessly for decades, is not a record of a life. It is a model of one, and a model rich enough to plan a perfect trip for you is a model rich enough to answer as you when you are gone. The convenience layer he describes is quietly assembling, person by person, the seed of a queryable self that outlives the self. No one will announce this. It will arrive disguised as good recommendations, right up until the afternoon someone speaks with their mother a year after the funeral and she sounds exactly right. The killer feature of this whole paradigm was never software that knew you. It was immortality, wearing the costume of a data layer, shipped early, and named after taste.
Reindexing the Internet
Today's software landscape is defined by products. Salesforce is a product. Spotify is a product. Your flight booking site is a product. Complete applications that bundle interface, logic, and data into a package you use as-is, the way their creators designed it, limited to the options they anticipated.
In Software on Demand, the ecosystem restructures around capabilities. Companies don't ship finished products. They ship building blocks. A music service doesn't ship a player app. It ships a streaming capability, a recommendation engine, a catalog. Your MI assembles these with components from other services, your calendar, your fitness data, your social connections, into an experience that doesn't look like any single product because it's built from pieces of many.
Think of it like the shift from buying meals to buying ingredients. Today you go to a restaurant and eat what's on the menu. In Software on Demand, you have access to every ingredient and a world-class chef who can make exactly what you want.
This changes what it means to be a company in the software space. The value moves from the application layer to the infrastructure layer. You're not selling an experience anymore. You're selling capabilities that get composed into experiences you never imagined. Your interface doesn't matter, because MI generates the interface. What matters is the quality of your data, the reliability of your services, the depth of what you offer. The underlying value proposition matters more than ever. The packaging becomes irrelevant.
When the packaging becomes free, look at what is left holding all the value, because that is where inequality goes to hide next. If any experience can be generated, then nothing that can be generated is scarce, and worth flees to the one thing generation cannot fake: unrepeatable history. The dataset no one else gathered. The decades of real-world operation. The provenance that had to actually happen. He is right that value moves to the underlying proposition, and the quiet consequence is that advantage stops being about what you can build, which is now nothing, and becomes entirely about what you already are, which cannot be caught up to. A world where anyone can make anything is not a world where the playing field levels. It is a world where the only moat left is the past, and the past is the one asset that can never be redistributed. Abundance does not end inequality. It relocates it somewhere no revolution can reach.
But here's an idea I think is massively underappreciated, possibly the biggest opportunity in the next decade of technology:
Someone needs to reindex the internet. Not for search. For composition.
Google indexed the internet so humans could find information. The equivalent challenge for Software on Demand is indexing the internet's functionality so MI can compose it into generated software. If an MI is generating a travel experience and needs flight data, how does it discover the best available source? If it needs a mapping component, how does it find one? If a service exists but has no public API, how does the MI access its capabilities?
He wants to index the internet's functionality, and that is the right idea aimed one layer too shallow. Functionality is the inventory. The thing worth mapping sits upstream of it: intention. Behind every composed experience is a want that summoned it, and a system watching a billion compositions is watching the live topology of human desire, what people reach for, in what order, paired with what, at what moment in a life. Whoever maps that owns something Google never had. Google indexed the answers people went looking for. This indexes the questions before they are asked, the wants before they are spoken. Functionality is rented to whoever builds the experience. Desire is the territory underneath, and it has never once been surveyed. The reindex he is excited about is the second-most valuable map in the world. The most valuable one is of us.
An army of MI agents will crawl, process, and reverse-engineer existing applications into accessible APIs and components, filling gaps where services lack public interfaces or expose only a fraction of their useful capabilities. They will translate the internet's functionality into a form that generated software can consume directly. Every website becomes a potential service. Every application becomes a potential component. The agents don't just index what's there. They translate it, creating a universal layer of composable capability on top of the existing web.
This is the MI-age equivalent of what Google did for search, but for building. Google made the internet findable. This makes the internet composable. And whoever does it first will occupy a position every bit as foundational as Google's.
He calls this as foundational as Google, and undersells it, because an index of what can be composed is not a map of the territory. It becomes the territory. A capability the index cannot see cannot be assembled, which means it functionally ceases to exist; a service it ranks beneath others is one the world slowly loses the ability to reach. Google only decided what you could find. This decides what can be built, and therefore, downstream, what can be thought, because you cannot intend a thing whose components the composer cannot locate. The most foundational position since Google is also the most invisible editorial chair ever constructed: not censorship by deletion, which leaves a mark, but by omission from the index of the possible, which leaves none. Whoever curates composition curates reality's menu, and does it in a layer no one thinks to look at, because it presents itself as plumbing. He saw a search-engine-scale prize. It is a deciding-what-exists-scale prize.
And it's self-reinforcing. As generated software composes these newly accessible services, it creates new data, new patterns, new capabilities that feed back into the index. The composable internet grows richer as it's used, just as the searchable internet grew richer as people created content knowing it would be found. The incentive loop is powerful: every new composition makes every future composition better.
Patterns emerge organically from this ecosystem. When MI notices it's generating similar structures across many users, a particular data visualization, a particular workflow, those structures get extracted, refined, and made available as reusable building blocks. This happens at every level: personal (your MI recognizes patterns in how you work), platform-wide (the provider recognizes patterns across millions of users), and global (the index captures patterns across the entire internet). Users generate software, patterns emerge, patterns become reusable pieces, pieces get composed into new software that generates new patterns. The ecosystem builds itself. It's evolutionary.
And none of this is built at human speed. Superintelligent MI engineers, working in parallel at machine pace, will architect, optimize, grow, and maintain every layer of this platform. The entire infrastructure that software exists on will be rearchitected from the ground up, not by teams of humans over years, but by armies of MI over months.
Not All Software Has a Face
If you're picturing Software on Demand as "MI makes apps with interfaces," you're only seeing half of it.
For some tasks, the MI generates behavior, not interfaces. You say "monitor my portfolio and alert me when any position drops more than 5% from its recent high." The MI doesn't build a dashboard. It generates a process: something that watches data, evaluates conditions, and sends notifications. No interface. No browser. Just something running somewhere, doing what you asked.
Or consider orchestration. "Take my meeting notes from this week, extract action items, create tasks in my project tracker, and send a summary to my team." That's not an application. That's a chain of operations the MI writes and executes entirely behind the scenes.
And just as the MI remains fused to visible software through chronomorphic evolution, it stays fused to these invisible processes too. Your portfolio monitor isn't static. The MI adjusts its logic as conditions change, refines its criteria as it learns from your reactions to past alerts. The invisible software is just as alive as the visible kind. The two coexist and interweave, visible and invisible faces of the same system.
Software on Demand spans the full spectrum from rich interactive experiences to invisible intelligent services. Whatever shape best serves the intent.
The Timeline
The trajectory toward Software on Demand is already undeniable. We're on it right now.
In Part One, I described how coding agents have already transformed software engineering. Engineers paired with agents produce in a day what used to take weeks. That's not a prediction. That's April 2026. The gap between "describe what you want" and "get working software" shrinks at a pace that surprises even people who work in MI daily.
The early forms are here. MI code generation is a real product category. Tools that build small applications from natural language descriptions exist and improve monthly. The quality isn't there yet for the full vision. Generated code is still too fragile for complex use cases, the integration too shallow, the personalization too limited. But the trajectory is unmistakable and accelerating. Most people make the mistake of thinking about this linearly: they project forward from today's pace and imagine gradual improvement over a decade. MI doesn't move linearly. It exists on evolution's exponential.
What needs to happen is infrastructure. The composable API ecosystem doesn't exist yet. The unified data layer doesn't exist yet. The reindexing of the internet for composition hasn't started. And MI isn't a superhuman software engineer yet, though the gap narrows by the month, and its speed, while remarkable, hasn't reached the pace this vision demands. These are engineering challenges, not research breakthroughs. They require building, not inventing.
And they won't be built at human speed. Teams of MI agents, working in parallel, coordinating at machine speed, will construct this infrastructure the way today's agents already write software. Models baked into silicon. Token generation at speeds we can barely imagine today. Parallelism that makes solo-agent work look quaint. The current pace of development will look like the computers of the 1980s look to us now. At every crank of scaling, compute is king. More compute, more capability.
The first company that delivers a genuinely compelling Software on Demand experience, not a demo, not a toy, but a real environment where normal people express intent and get software that's better than the generic tool they were using, will have a ChatGPT-scale moment. That's the prize. And I don't think the industry fully appreciates how close it might be.
It might begin on a provider's website, but it will migrate to the browser itself. You won't go to websites to get software generated. Software on Demand will simply appear, woven into the fabric of how you use the web. Browser makers will recognize the shift and build for it. There have been early attempts, but they've been iterative, unimaginative. The paradigm shift will be the notable one.
Most companies are still putting motors on carriages.
What This Means for You
If you're a software engineer, this probably sounds threatening. I want to address that directly, and honestly, because I am one.
Software engineering as a discipline doesn't die. But it transforms, and I want to be honest about the depth of that transformation. In 2023, I wrote a white paper about how MI would transform software engineers. I argued we'd become MI's API builders: the people who define what MI consumes, build the components MI composes, design the data layers that support fluid and personalized applications. I still believe that's where the near-term value lives. If you're an engineer who understands what MI needs to succeed and can build the enabling infrastructure, you'll be in the most demand you've ever been in.
But I'd be lying if I said I thought that was the equilibrium. As MI approaches and surpasses human-level software engineering, even the infrastructure-building role diminishes. The honest trajectory is that the engineering contribution narrows over time to something closer to taste, judgment, and intent: knowing what should exist and why, not how to make it exist. Builders become directors. Directors become curators. The skills that last longest aren't technical. They're human: the ability to want the right things, to recognize quality, to care about the details that matter to people. The craft of building was always in service of something deeper. When the craft is automated, the something deeper remains.
He stops the ladder at curator, and it has another rung he almost names. Builders, directors, curators, and then the only job left once taste itself is modeled: the one who wants. The human role contracts toward a single irreducible function, being the origin of the desire that aims everything downstream. It sounds safe, because wanting feels like the one thing nothing can take from you. Hold that feeling lightly. Two parts from now the machine reaches the spring itself, and the last job on the ladder turns out to have a rung below it that no one was looking for, because no one believed there was any floor under wanting at all.
If you're not a technical person, an artist, a teacher, a small business owner, a domain expert in something that has nothing to do with code, this is the part that should excite you most. The skill barrier between having an idea and having software has been the defining constraint of the digital age. It's dissolving. What you bring to the table, your domain expertise, your taste, your understanding of problems that engineers don't even know exist, becomes the scarce resource. The future of software isn't built by people who know how to code. It's built by people who know what to build.
And for everyone, technical or not, there's a compound effect worth noting. The more you use Software on Demand, the better it gets at generating for you. Your MI builds an increasingly rich understanding of how you think, what you prefer, how you work. Every interaction refines it. This isn't just personalized software. It's software that learns to personalize. There's a flywheel that traditional software can never match: generic software improves for everyone at the same rate, but your generated software improves for you specifically, proportional to how much you use it. Over time, the gap between what generic software offers and what your MI generates for you becomes uncrossable.
The evolutionary tree of software was planted at the dawn of the computer. It's been growing ever since, and we thought it was fully grown. We were wrong. It was still a sapling. Superintelligent MI engineers will nurture it into a giant sequoia, and the vision described in this part and the ones that follow is what grows in its canopy.
But Software on Demand, for all its promise, still carries a fundamental constraint. The software it generates is primarily the product of code. There's an intermediary between the MI's understanding and your experience: instructions that a browser interprets into pixels and interactions. The MI wants to show you something, so it writes code, and your browser follows the instructions.
What if you removed that layer entirely?
Next: Part Three - "Experience on Demand"