TL;DR
General-purpose software was an economic compromise: expensive implementation forced one product to serve many; AI can make tailored software economical.
Malleability moves beyond the product: the underlying capability persists while each implementation becomes one possible form.
The user-facing layer becomes individual, while shared foundations and common seams remain essential.
Chat remains an entry point, but as human understanding becomes the bottleneck, interfaces become more important.
A feed can become an app store: software can travel as content.
Software makers can enter the creator economy, monetizing patterns, taste, trust, and audience.
Value may shift toward what agents cannot rebuild: models, infrastructure, data, networks, reputation, and proprietary services.
Default implementations remain, but become starting points that can bend around individual needs.
1. When Rebuilding Gets Cheap, Software Loses Its Final Form
Building software used to be expensive. To justify that cost, companies generally built one product for many people and spread the cost across them. Custom software existed, but for most individuals and organizations it was too costly to build and maintain.
General-purpose software therefore became the norm. You learned the interface, accepted the feature set, and bent your workflow around the product. The gap between what the product offered and what you actually needed was paid on every use in lost time and productivity: a misfit charge.
AI agents are changing that economic equation. Creating and modifying software is becoming faster and cheaper. Increasingly, working software can be built almost on demand.
Software can therefore become more individual: built for you, your team, or your company. But that does not mean regenerating everything from scratch. Hardened components, infrastructure, and shared standards will remain essential. But the parts closest to the user—the interface, workflow, and glue between systems—can increasingly be reshaped around the situation.
This points toward malleable software: software that bends around people instead of requiring people to bend around it.
Malleable software is often discussed as a quality designed into particular products. I want to push the idea further. As implementation becomes cheaper, the product no longer has to be the boundary of malleability.
In this broader sense, malleability no longer describes only how far one product can bend, but whether its underlying capability can be realized in another form. Software’s identity begins to separate from any one implementation: what it does can persist while the interface, workflow, and code that realize it change.
Andrej Karpathy’s “idea file” is an early example of this separation. Instead of distributing a finished application, he distributes a document that communicates the underlying pattern and leaves each person’s agent to work out an implementation suited to them. What travels is the software’s organizing idea: the pattern to preserve, not the finished form in which it happened to be implemented.
Software is shifting from a finished artifact that many people use unchanged to something that can be repeatedly reconstructed around different people, contexts, and needs. A particular implementation becomes one possible version, rather than the final form.
The finished application is not just a technical artifact. It is the unit around which software is distributed, purchased, and controlled, and the software industry has largely organized itself around it. As that unit becomes less fixed, interfaces, practices, standards, ownership, and business models may change with it.
2. The Closer Software Gets to the User, the More It Should Bend
The finished application may lose its fixed form, but software artifacts will not disappear. We will still rely on operating systems, databases, browser engines, encryption libraries, runtimes, models, and other people’s code. What changes is where the durable artifact ends. It retreats toward the shared substrate, while the application layer above it—the interface, workflow, business rules, and glue between systems—becomes easier to rebuild around a particular situation.
Not every part of software should become equally malleable. The closer software gets to a particular person, team, or company, the more its value depends on fit. The deeper it sits in the stack, the more its value depends on reliability, reuse, and coordination.
Where individuality pays
A general product is built for a category of users. An individual tool can be built around an actual workflow. The difference matters most at the surface: which information is visible, which actions take one step instead of five, which rules reflect how a company really works, and which features disappear because nobody needs them.
These mismatches can look small, but repeated every day they become the misfit charge general software imposes. The user-facing layer is therefore where I expect malleability to create the most value. It can absorb local context, the very thing a general product is forced to average away.
This is also the layer that much of the software industry currently packages and sells as a finished application. The effects are therefore likely to differ across the stack.
What should remain shared
Lower in the stack, the economics reverse. A database, browser engine, encryption library, or operating system becomes valuable through years of testing, maintenance, and use. Reliability accumulates through reuse. Regenerating these foundations for every application would usually be slower, riskier, and worse.
Malleable software therefore does not mean replacing shared technology with isolated generated code. It means building individual forms on top of shared foundations. The fixed artifact becomes smaller and moves further down the stack.
A small core, a malleable edge
Pi, Mario Zechner’s minimal agent harness, offers an early picture of this architecture. Its stable core is deliberately tiny, while new capabilities can be written around it as they are needed. Rather than treating every capability as another finished extension that users must install unchanged, an agent can create a local implementation from instructions, examples, or reference code.
This is a shift in what travels. The shared artifact supplies dependable primitives and constraints; the final capability is assembled closer to the user. We still use other people’s code, but the most context-dependent layer no longer has to arrive as one finished application.
Malleability itself is not new. Spreadsheets, HyperCard, Smalltalk, Emacs, and recent work from Ink & Switch all treat software as something users can reshape. What changes now is who performs the modification and where it can happen: agents lower the skill barrier, while cheap reconstruction lets malleability escape the boundary of the original product. Customizing an open base and rebuilding from shared material are two points on the same spectrum.
Individual forms need shared seams
There is a cost to giving up sameness. Today, compatibility often comes free because everyone uses the same product. Two people collaborating in Slack or Excel do not need to negotiate a protocol; the product itself provides the common environment.
When applications become individual, compatibility can no longer depend on identical forms. It has to move into the seams: APIs, file formats, schemas, permissions, and shared data models. The more individual the forms become, the more weight those standards must carry.
The seams themselves may become one of the most active areas of software innovation over the next few years. New formats, protocols, and conventions will emerge, compete, and spread; some will become standards because enough adopt them.
Malleable software is not software in which everything changes. The central question is what must remain shared and what can be regenerated.
A useful division of labor would be to share the foundations, standardize the seams, and regenerate the layer closest to the user.
3. Interfaces Become More Important, Not Less
At first, this sounds backwards. AI is currently collapsing many interfaces into chat: one text box replaces menus, forms, and dashboards. But chat is powerful because it can handle almost anything, not because it is the best way to understand or control everything. It may become a universal entry point without becoming the final interface for every task.
Human understanding becomes the bottleneck
As agents become more capable, producing information and taking action gets easier. Human attention does not scale with them. The interface is where machine output becomes something a person can grasp, judge, and act on. I expect this translation layer to become more important as the systems behind it improve.
Thariq Shihipar, on Anthropic’s Claude Code team, describes preferring HTML to Markdown because visual structure, diagrams, and interaction make complex outputs easier to read and keep him more aligned with the agent’s choices.
Interaction becomes hybrid
Interfaces also make it easier to communicate intent back to the agent. Selecting, dragging, filtering, or adjusting a control can be faster and more precise than explaining the same operation in prose.
MCP Apps are an early example of this hybrid pattern: tools can provide interactive forms, dashboards, and visualizations inside an agent environment, while the model reads and updates the same interface. This points toward a shared workspace in which language and direct manipulation coexist.
The right interface depends on the task and the person
What the right interface looks like depends first on the task, and then on the person. Two people using the same service may need different information, different actions, and a different sequence of decisions. A useful interface is individual not merely because people prefer different styles, but because they pursue different goals, know different things, and organize their work differently. The relevant information and controls can move forward; the rest can disappear.
An interface also encodes an objective. A provider’s default has to balance the needs of an average user with support costs, conversion, retention, margin, and product strategy. That does not imply bad intent; it simply means the provider’s objective is not identical to yours. A personal interface can optimize more directly for the work you are trying to do, and expose costs, alternatives, or information the default has little reason to foreground.
The client becomes one possible view
This is where the application begins to unbundle. The service, models, account, and data may remain shared, while the client becomes a replaceable or generated view over them. The interface no longer has to be the permanent face of the service; it can be a form produced for a particular person, task, and moment.
4. Software Will Travel Wherever Ideas Travel
An app store distributes implementations. A malleable software ecosystem can distribute intent.
From implementations to intent
Once the context-sensitive layer can be reconstructed from information, it no longer has to travel as a finished package. A written description, screenshot, video, demo, conversation, specification, or reference repository may communicate enough for an agent to build a local version. Karpathy’s “idea file” is a deliberately structured example: it preserves the software’s organizing idea while leaving the particular implementation open.
Code will still travel wherever shared foundations or complex behavior must be maintained. But at the malleable edge, the reusable object can move upstream; from an implementation to the intent behind it: what the tool should accomplish, which constraints matter, and which pattern should survive.
A feed can become an app store
That changes where software can be discovered. A post can introduce a workflow, a video can demonstrate an interaction, an article can describe a tool, and a screenshot can communicate an interface. Instead of installing the same artifact, a person can ask an agent to reconstruct the idea around their own data, services, and habits.
Software distribution therefore starts to merge with content distribution. A feed can function like an app store without containing an app. The content carries the pattern; the implementation is produced at the destination.
Product judgment gains leverage
When implementation was expensive, having a good idea was still far from having software. It had to be designed, engineered, packaged, distributed, and maintained before anyone could use it. As more of that work becomes cheap at the application layer, greater leverage moves toward identifying a useful problem, imagining a better workflow, deciding what should remain invariant, and communicating it clearly.
Engineering does not disappear. It remains essential for the shared foundations, for security and reliability, and wherever behavior is difficult to specify or verify. But at the malleable edge, product judgment, taste, and communication become more powerful. Someone can shape how software is built without operating one canonical implementation of it.
Software begins to travel less like a package and more like a pattern.
5. Value Moves to What an Agent Cannot Rebuild
I’m more confident about the direction of this pressure than about who the eventual winners will be. A useful test is: what can an agent reconstruct for its user, and what must the reconstructed software still obtain from someone else?
The application layer comes under pressure
Many business applications package a database, permissions, workflow rules, and an interface into one finished product sold per employee. As agents make it cheaper to reconstruct forms, dashboards, approvals, and integrations around an organization’s actual workflow, the fixed application becomes less defensible, especially when most of its differentiation sits in a thin layer of interface and business logic over data.
This shift is already showing up in build-versus-buy decisions. Klarna became a prominent example when it stopped using Salesforce and Workday and shifted toward a mix of internally built systems, AI, and other services. By early 2026, the software selloff described as the “SaaSpocalypse” suggested that investors had begun pricing the same risk. The reality is less clean than the original headlines suggested, but the economic signal remains: recurring per-seat software now has to compete with tools a company can increasingly assemble around its own processes.
Satya Nadella has described business applications as databases wrapped in business logic and argued that more of this logic may move into agents operating across multiple backends. The data and governance remain; the conventional application above them comes under pressure. This does not mean all SaaS disappears: reliability, compliance, support, integrations, and responsibility when things break remain valuable. But the application itself is no longer automatically the strongest place to capture that value.
More value moves toward the substrate
Every reconstructed application still needs things it cannot simply generate into existence, like models, compute, chips, data centers, energy, hosting, authentication, storage, synchronization, external services, or persistent state.
More malleable software may increase demand for these layers rather than reduce it. A million individual applications would still make model calls, store information, authenticate users, and communicate with other systems. The application shell becomes cheaper while the resources underneath it become more heavily used.
Pricing may follow the same movement. When the client is generated locally and agents perform work across several systems, the human seat becomes a less natural unit of value. Providers can instead charge for what the application consumes or accomplishes: model calls, transactions, stored state, synchronized accounts, agent actions, or successful outcomes.
Data becomes the control point
A replaceable interface is only truly replaceable if the user can bring their accumulated state with it. Otherwise, the client may be malleable while its history, files, permissions, relationships, and memory remain trapped inside one service. The more replaceable the client becomes, the more strategic the data layer becomes: you may own the interface without owning the system it reveals.
One possible consequence is a reversal of today’s default. Instead of moving your data into every new application, you could maintain a personal or organizational data layer and grant different applications access to it. A client could then be replaced or regenerated without abandoning the history and state accumulated behind it. Whether this architecture becomes common is uncertain, but malleability makes owning and controlling the data beneath your tools much more valuable.
Providers will not necessarily resist malleability at the surface. They may instead move their advantage beneath it: into the model, account, memory, tool permissions, proprietary data, compliance layer, or agent harness. As the interface becomes easier to reproduce, lock-in retreats to whatever the replacement still cannot take with it.
What remains difficult to reproduce
Not every durable advantage sits in infrastructure. An agent cannot instantly regenerate trusted relationships, proprietary data, network effects, regulatory approval, accountability, or a reputation earned over years.
It may also be unable to reproduce a service whose internal process remains hidden. A specialized agent can combine private data, models, prompts, evaluations, tools, and human judgment. The customer sees the result, but not enough of the recipe to reconstruct it.
Software enters the creator economy
If software can be reconstructed from information, software makers can use the same networks as creators to distribute what they make. Instead of packaging every idea into one canonical product, they can publish a workflow, interface, demo, or idea file and let other people’s agents turn it into local software.
This could create a new economic role between developer and creator. The asset is not only code, but a continuing stream of useful ideas, product judgment, taste, trust, and an audience. Income can come through sponsorship, patronage, consulting, employment, paid implementations, or specialized agents and services.
Karpathy is an early example of the role: his explanations, experiments, demos, and idea files influence what others build without each one becoming a conventional product or company. What used to be packaged and sold as software can increasingly be distributed as content.
I expect cheaper implementation to change where value is captured in software. More of it may move away from the finished application as a fixed package and toward the intelligence, infrastructure, state, trust, and services that each new implementation still needs.
6. Defaults, Not Final Forms
Most people will not spend their days designing and maintaining their own software. Defaults remain powerful because people generally want to complete the work, not operate a private software stack. The likely future is therefore not one in which everyone builds everything from scratch. It is one in which software arrives as a useful default that can be bent when the mismatch becomes important.
Omarchy offers an early example of this balance. It provides a curated Linux environment while equipping agents with instructions to help users create apps, plugins, and themes. Built-in desktop components can be copied and modified locally without changing the shared originals. Users start with someone else’s choices, but they do not have to keep all of them. A strong default reduces the work of getting started without determining the final form.
Sometimes a person will ask an agent to change the tool directly. Sometimes the interface will adapt around the task without the person thinking of it as software development. Sometimes one builder in a team, family, or community will shape a tool for everyone else. The important shift is not that every user becomes a programmer, but that implementation labor becomes less of a barrier between a need and a better-fitting form.
The most durable products may be those that provide the best shared material rather than prescribing one complete final experience.
The deeper change is that an implementation no longer has to be the only thing that carries software from one place to another. An idea, example, specification, or interaction can carry enough information for the software to be realized again at the destination. Code remains essential in the shared foundations, but at the malleable edge software increasingly travels as information.
For seventy years, the cost of building software has often meant that people had to adapt to what was available. Shared systems and useful defaults will remain, but the layer closest to the user no longer has to be accepted as given.
I’m very grateful for any questions and comments :) Talk to me on x.