I. Solid Software
One of the first computer programs I wrote when I was a kid was a BASIC program to add 2 numbers that worked on the command line. You ran the program, and it would print: “Enter numbers to add:”. You’d type in the first number, hit enter. Second number, enter. It would print out: “The total is: …”
It was such a delight to write these programs, and I was hooked!
But this program was the definition of rigid: its functionality and interface were fixed. You couldn’t ask it to multiply or divide. You couldn’t provide more than two numbers. You had to have a new line between the inputs. If you faltered with a space or a comma, it would unceremoniously error out.
Software has evolved a lot since then. We moved to graphical interfaces, the web, mobile apps, and SaaS. The functionality and range of options have exploded. Yet, the general rigidity of software has persisted.
For the last 30 years, software has behaved exactly how its creators asked it to. Developers decided that this button does that action. Developers decided the data schema, the business logic, and the workflows. Developers built for the “average user”, and decided what is configurable and to what degree. Developers decided whether to offer accessible APIs or to integrate third-party extensions and data.
For the most part, thoughtful and creative decisions are a service to the user. But if a user wanted to do something that the developers didn’t foresee or deemed unimportant or out of distribution, they were stuck. They had to beg for a feature request, switch to a different rigid tool, or expensively hack a solution on their own.
And as a software tries to accommodate more users and needs, its interfaces, code, and data become increasingly complex.
We have been building Solid Software: reliable structures built to endure, but unable to adapt, restricted to their containers, and hard to update.
II. Intelligence as the Solvent
In May 2023, after experimenting with several prototypes using GPT-3 as both an application interface and a coding assistant, I wrote a blog titled “The New Approach to Building Software with AI.”, predicting that the new block of Intelligence will dissolve the hard boundaries of rigid applications.
When you have a processor that can understand natural language intent, and write code or use tools to execute tasks on the fly, you no longer need to pre-compile every possible user interaction or build complex interfaces. You don’t need a developer to translate requirements of users into rigid code. The forced explicitness of Solid software cramps the potential of these systems, and any rigidly architected software will likely end up as technical debt.
Pure run-time generation with fuzzy AI would be unpredictable, buggy, slow, and wasteful. So I proposed that the future lies in loosely coupling the magic of AI with the reliability, statefulness, and efficiency of traditional software tools. While that may appear like a step back into Solid software land, the key differences now are that the AI would dynamically orchestrate the use of these tools, and that these tools themselves would be built by AI based on instructions from humans; writing and managing instructions in natural language offers significantly better ease, flexibility, and access to both developers and end users.
Most of these predictions have turned out correct sooner and better than I imagined (Alas I didn’t buy even more NVDA!). The stock market is already spooked and the multiples of legacy Solid software companies are collapsing, while the companies providing the infrastructure of fluid generation are rising. We are witnessing a phase change from Solid to Fluid software.
III. The Architecture of Fluid software
The main property of Fluid software is that they take the shape of the user’s intent and the need of the moment. The software adapts to the user, rather than the other way around.
How would you architect such software? I’m no Linus Trovalds, but this is what I imagine it could be.
1. The Interaction Layer: Headless-first, with Customizable UI. Historically, software applications were synonymous with the UI. In the near future, people will just ask their agent to “book me a massage when I’m free tomorrow”, and the agent works across different MCPs and APIs to get it done. GUI will continue to be important because they are generally more pleasing and higher dimensional, and let users see and do more than a linear chat or CLI. Agents can conjure richer UI on the fly or stream them via MCP. Software developers would probably continue to offer a pre-generated, default UI, but one that can be modified or replaced by users and their agents.
2. The Backend: English as Code This is the most disruptive shift. Instead of hard-coded logic (e.g., if x > 10 return true), we can move toward logic written in English that can be compiled into Code. If a user has a unique constraint—“Don’t approve expenses on Fridays”, they can just say so and the AI compiles that English instruction into a rule or script. The software re-architects itself to match the user’s specific business reality.
3. The Data: Concrete to Clay The hardest part of software to change has always been the database. Large data models and datasets are difficult and risky to update. But even that may be melting. We might be approaching a world where the schema itself can be maintained in natural language and evolve as the user’s mental model changes. The AI can propose and safely write state-preserving migrations to update tables and refactor relationships instantly.
4. Opinionated Defaults Lastly, Fluid software will continue to have opinionated defaults across the stack. Most people don’t want to define UI, business logic, and data models from scratch. They want something that’s thoughtfully designed that they can use flexibly out of the box and modify as needed.
The current models and harnesses may fall short of the needs of this architecture, but given the pace of progress, I’d be surprised if it won’t be possible in the next couple of years.
IV. The Danger of the Gas Phase
While the promise of Fluid software is immense, the physics of this metaphor suggests a danger: If you apply too much heat, liquid turns to gas.
“Gaseous Software” is volatile and unpredictable.
Ambiguity: Natural language is inherently imprecise. A user asking to “fix the data” might inadvertently trigger a destructive update because the AI misinterpreted the intent. Fluid software requires robust “Clarification Loops” to stabilize the user’s request before it hardens into code (also why “chat“ has turned out to be the default form factor for AI) and sandboxes to test safely before deploy.
Governance and Maintenance: If every user can define their own custom logic and data models, you risk creating a chaotic fragmentation where no two users are running the same software. I suspect the answer to this is again…agents.
Latency: Compiling English to code in real-time is computationally expensive. There is a trade-off between the fluidity of the experience and the speed of execution. For this, I think we’ll see new caching techniques to reuse parts or all of agent-generated solutions.
V. The New Role of the Builder
The main change is we need to stop building cages and start building blocks. See your users as not just mere consumers, but as co-creators.
In a Fluid software world, the role of the builder shifts from defining features for a human to defining capabilities and constraints for a human’s AI assistant or coding agent. We provide a reliable foundation— the default UI and data model, APIs and MCPs, sandboxes, and compute infrastructure. But we allow the user and their AI to assemble and extend it.
Building Solid software was an exercise in foresight and control. We predicted the workflow, locked down the database, and forced the user to adapt to the machine.
Fluid software is an exercise in flexibility and trust. We are stepping back from defining the exact shape of the application, and instead providing the elemental physics that allow the application to shape itself. *
* Final Note: If models don’t hit a wall and AGI is achieved, all bets are off. There may not be a need for builders, building blocks, instructions, and this architecture. We can’t really plan or write a memo for that. This presupposes there’s a period of time where models continue to improve to be capable of this fluid architecture, but incapable of total autonomy.