Apps Are Infinite. Human Context Is Finite.

If AI lets everyone make software, must developers keep making more of it while users keep evaluating more of it? That is a race nobody can finish. I think the opportunity is to change the premise: the easier software becomes to create, the more of it we can organize around a person's existing life.

REA, or Reverse Engineer Anything, gives coding agents tools to investigate existing software and reconstruct functionality. Brandon Thomas's PhotoCraft applies AI-assisted development to the familiar territory of Photoshop-style image editing. They make an increasingly tangible possibility visible: someone can study the software they need and build a version suited to their own purposes.

The examples keep coming. In the streams of work developers share online, I see people releasing new tools at a pace that would once have seemed implausible: almost another application every day, portfolios growing by dozens over a few months. Each has a recognizable interface and a particular problem it aims to solve. Then another developer does it, and another.

For a founder or engineer, this can produce a kind of panic. Should I be building more? Am I falling behind because I am still working on one product while someone else has launched ten? For the user, the abundance raises a different set of questions. Whose tool should I use? Who will look after it? Should I trust a stranger's application, ask an agent to make my own, or wait for something better next week?

Making more software is an understandable response. But I think there is a larger opportunity than multiplying the number of applications competing for the same person's attention and data. We can make it easier for that person to benefit from all this new capability without rebuilding a digital life around every tool that appears.

Software scarcity made applications the center

For most of the software industry's history, implementing a useful application took substantial effort. Teams had to work out the behavior, write the code, handle the edge cases and keep the result running. Even where competition was intense, the supply of credible alternatives was constrained by the work required to produce them.

Microsoft, Google and Adobe could each sustain large bodies of software because they had people and organizations capable of doing that work. A customer chose among a relatively limited set of environments, learned their conventions and invested time in them. Applications became places where work accumulated.

Even developers bought other people's software. Knowing how to write a program did not create enough hours to build and maintain every tool one needed. I might be capable of implementing a particular feature and still sensibly choose a service that already did it. Time was scarce on both sides: the producer's time limited supply, and the user's time made existing software valuable.

That arrangement gave application-centered computing an economic logic. A team built one system and asked many people to adapt to its structure. The application decided what a record looked like, how a workflow progressed, which account held the work and how it could be shared. Users learned the system and arranged their habits around it.

There were good reasons to standardize parts of this work. A shared accounting system needs consistent rules. A hospital needs dependable records. But the same organizing principle spread into almost everything. Each new service asked for another account, another explanation of my interests, another upload of information, another reconstruction of what I was doing. My context grew inside separate applications.

AI changes the production constraint. A person can now attempt many more useful tools, adaptations and experiments with the same amount of time. Software can be made for a narrower task or a smaller group of people. Something that was too specific to justify a conventional development project may become worth building for one person's use.

Security, reliable execution, compatibility and ongoing maintenance still take work. Those obligations explain why good software can deserve a long relationship with its users. Yet the growing supply of implementations changes the competitive environment even while those obligations remain. The ability to produce another interface or feature becomes less exclusive.

I would be wary of building a business on the assumption that a familiar application, recreated with AI, will hold users simply because it now exists. The same tools are available to the next builder and increasingly to the customer. A product needs a reason to remain useful after the novelty of its creation has passed.

The old constraints encouraged people to gather around a few applications that took substantial investment to build. The new opportunity is to let abundant software gather around a person.

Computing has already lived through repeated reorganizations. Mainframes, minicomputers and personal computers changed how computing power reached people, creating new uses and businesses while displacing established positions. I believe AI could open another transition of that kind.

When computing was expensive, people arranged work around access to a machine. Microprocessors and personal computers made it practical for a machine to serve one person's work. Compatible machines then proliferated; Compaq reverse-engineered IBM's BIOS to build its own compatible implementation. The Computer History Museum documents that history. Copying expanded the field in which software, peripherals and new uses could develop around a computer someone owned.

Better technology could also serve an attempt to preserve the old center of control. In 1987, IBM introduced the PS/2, using the more advanced proprietary Micro Channel Architecture in higher-end models. IBM's own history describes deterring clones as one goal. Competitors reproduced many improvements and introduced the rival EISA standard. The PS/2 fell short of IBM's expectations, although several of its innovations endured.

I read that as a warning about direction. New technology can expand a person's choices or support an effort to retain control over them. Technical improvement cannot guarantee the success of the latter strategy. Using AI to produce more software suites or SaaS products, while expecting each to keep the user and their history inside its own container, risks carrying the old center of gravity forward with new machinery. Faster development solves the production problem.

A finite life cannot follow infinite apps

A passage from Zhuangzi, in the chapter Nourishing Life, keeps coming to mind:

吾生也有涯，而知也无涯。以有涯随无涯，殆已。

(My rendering: “Our lives are finite, but knowledge is boundless. To pursue the boundless with the finite is perilous.”)

Borrowing its rhythm, I would describe our software problem this way:

应用无涯，己数有涯。以有涯逐无涯，殆矣！

“Applications are boundless; one's own data is finite. To pursue the boundless with the finite is perilous.” 己数 is my newly coined shorthand for personal data. The classical passage concerns a finite life; that is also where the force of this adaptation comes from.

Storage can expand. Sensors can keep producing records. But the experiences, relationships and decisions that give those records meaning come from a person with a finite amount of time. Another application can be generated. The years that made a conversation, a photograph or a piece of work matter to someone cannot.

A few megabytes can connect a friendship, a place and a period of life that will never happen again. A short project note can explain why a decision was made and save someone from repeating a costly mistake. The significance belongs to the relationship between the information and the person's life. Counting bytes misses it.

Printing offers another way to see this. In manuscript-era Europe, reproducing a book required extensive labor. Printing, paper supplies and later industrial production gradually brought books to wider groups of readers. More people could build collections from different sources. A personal library could contain many authors and publishers without belonging to any one of them.

The growing supply also brought anxiety about having too much to read. Historian Ann Blair has studied how early scholars managed information overload through notes and reference works designed to help them find useful material. That research points toward another durable accumulation: what a person has selected, read and understood from a supply they can never exhaust.

Cheap publishing can spread careless work, rumors and repetition. It can also bring important work to more readers. Abundance leaves good research and expression valuable while giving them more competition for attention. I expect useful software to retain value too. Making something worth finding, trusting and continuing to use remains demanding work.

Cambridge University Library's exhibition on early printed books examines readers' annotations and traces of use. A mass-produced book, once part of a personal library, becomes connected to someone's understanding and work. I want a personal data space to offer that continuity: information from many sources, accumulated understanding and results, and the ability to carry on with another tool.

Every application that asks me to start again consumes some of that finite life. I have to explain the project, reconstruct the preferences, find the relevant records and teach another system what the previous one already knew. As applications multiply, asking people to repeat this process becomes harder to justify.

The anxiety about infinite apps often assumes that the individual must somehow keep up with them. I think that assumption is what needs to change. A person should be able to keep a continuous body of information and invite useful software to work with it. A new tool can learn the authorized context already there, do its job and leave a result that the person can continue to use.

This is a migration of scarcity. When useful software becomes more abundant, attention, trust and continuity of personal context become more important places to direct our effort. The question for a builder becomes: how much can this tool help someone accomplish with what they already know and own?

Abundance can also strengthen a platform that controls identity, storage or distribution. Cheap applications could surround a person while the platform gains more control over the only usable copy of their history. The opportunity needs a deliberate architecture and a choice about who has authority.

Abundance enables human-centric computing. Sovereignty makes it real.

Own the house. Invite the builders.

I have explored this through a simple image in “Builders Change. Your Property Stays.”: you own a house and invite different crews to improve it. One renovates the kitchen. Another repairs the wiring. A third comes later to do something the first two never anticipated.

When a crew finishes, the improvement stays with the house. Hiring a different crew next month should not require moving into a different home. The contractor's skill is valuable precisely because it improves something that continues to belong to you.

That is how I want to think about AI agents. A coding agent can build a tool. A research agent can organize information. Another agent can review the work or maintain it later. Their capabilities can come from different providers. The work needs a place to accumulate under the authority of the person who will live with its consequences.

The alternative is familiar: every provider supplies its own environment, and the person moves fragments of life into each one. Changing the helper then means reconstructing the home. We have already spent decades doing this with applications. AI gives us a chance to choose a different default.

This is why I am more interested in inviting agents into a space we control than in putting a separate model subscription inside every application. If an application's central proposition is access to a general-purpose model through another chat interface, the model provider is a formidable competitor. It can improve the underlying capability and deliver it directly to people already using its service.

The more interesting work is around the person: making their information usable, giving agents a place to work, and letting the results survive changes of model or provider. A specialist tool can earn its place by doing a task well. It need not become the permanent container for the person's entire relationship with that task.

This is the architectural reason I keep returning to DID and DID Space, and to the personal-space direction of Arc Space. A DID provides a persistent identity that applications can recognize. A data space tied to that identity gives us a basis for organizing records and access around the person. The design goal is for applications and agents to work under authority granted by that person, with the information remaining useful as tools change.

The practical questions are quite ordinary. Can a new agent find the relevant records? Can it understand their meaning? Can I give it access to one project without handing over everything? Where will its result go? If I replace it, can the next helper continue the work?

Portable formats, understandable permissions, recovery and usable migration paths have to answer those questions. A DID alone cannot do all of that. Neither can a download button that produces a file no other tool understands. Ownership becomes useful when a person can continue working after changing the company supplying the help.

The house analogy also reminds me that ownership must be convenient. People hire contractors because they want help. A personal space that turns its owner into a full-time system administrator will serve a narrow audience. Services can host and maintain it; agents can help operate it. Control and the ability to replace those services need to remain practical, as I argued in my essay on sovereignty without self-hosting.

The opportunity is to leave the person more capable

For someone building software now, I think this changes the ambition worth pursuing. Building another application can still be valuable. The stronger question is what becomes possible for its user, and what remains with that user afterward.

Consider an agent that helps prepare a proposal. It should be able to use the relevant project history with permission, produce work where the person can keep using it, and preserve the important decisions. Next week, a different agent might review the proposal or adapt it for another audience. The person's project should get richer through those interactions. It should not restart with each helper.

Or consider a specialist assistant handling a refund. The receipts, outstanding claim, deadline and prior correspondence should remain available to the person. Replacing the assistant should preserve the work already done. That is the kind of continuity I described in my essay on personal agents that protect our attention.

These are product opportunities as much as infrastructure questions. Someone has to make the records legible to different tools, explain what an agent is asking to access, show what changed and make a handover work. A product that saves people from repeatedly rebuilding their context can become more useful as the surrounding supply of applications grows.

Trust belongs here too. A person needs to know which agent is acting, whose interests it serves, what it can read and what it can change. Important actions need understandable approval and a record. Revoking permission can stop future access; data already copied makes care before sharing essential. Giving every new tool the whole house would defeat the purpose of having a boundary.

The person's judgment also needs room to persist. An agent can suggest a course of action, explain the evidence and perform delegated work. The person should be able to disagree, change the rules or bring in another helper. A highly personalized service that quietly makes those choices for its own benefit leaves the central problem unresolved.

Some applications will remain durable because their reliability, expertise, integrations or communities are difficult to replace. Good services will continue to deserve customers. What becomes a weaker foundation is dependence created mainly by keeping the user's history inside the application. I want people to stay because the service continues to help them.

Return to the opening question. If everyone can make software, must we keep competing over who produces more and who keeps up? Personal computing put computing capability into individuals' hands. Printing helped more people build libraries of their own. We can choose to use today's new productive capacity to give people a working space in which their lives and efforts continue to accumulate.

Apps are infinite. Human context is finite.

Excellent software remains worth building. It can help people do something previously out of reach, or make better use of information they already have. But I want each new tool to leave its user with more capability, rather than another fragment of life to explain and migrate. Applications and agents can keep changing. A person's identity, work, relationships and authority over what happens next should stay with them.

Keep the context. Replace the apps.

Sources

morluto, REA project documentation. Brandon Thomas / Storytold, PhotoCraft project documentation. Zhuangzi, “Nourishing Life”, opening passage; English rendering and modern adaptation are mine.

Historical sources: Computer History Museum, Personal Computers and the Compaq Portable collection record; IBM, The PS/2; Sarah Sweeney, “Ye olde information overload”, Harvard Gazette, December 16, 2010, reporting on Ann Blair’s research; Cambridge University Library, Private Lives of Print.