Trust and quality notes
- Last updated
- September 30, 2026
More software does not automatically mean more control. If every need produces another app, people inherit more accounts, more data silos, and more decisions about which tool knows what. Alex Komoroske argues that AI could either intensify that fragmentation or help create a different relationship between people, software, and personal data.[1]
His vision of humanity after automation is not mainly about removing work. It is about agency. Software becomes abundant and adaptable, but the crucial design question is whether it serves the person using it or extracts value through centralized control.
The source's central argument
Komoroske expects AI to create what he calls “infinite software,” an enormous variety of tools tailored to particular needs. Yet he warns that distributing that abundance through today's app-store model would amplify existing problems. Each new app can become another silo, another place where data is trapped, and another fragment the user must coordinate.[1]
He uses trip planning to show the burden. Flight information may be in email, hotel details in another app, recommendations in a document, and commitments in a calendar. The easiest way to reduce friction is often to give a single large service access to everything. That convenience has a cost: intimate data becomes concentrated inside a megacorporation.[1]
His argument is that AI is subject to the same forces that consolidated social media into a few dominant platforms. But he does not treat that outcome as inevitable. Agentic coding, combined with stronger guarantees around data policies and verifiable software behavior, may make another model possible. In that model, tools adapt to individual needs while remaining private by default.
Abundance can make coordination worse
The promise of generated software sounds straightforward. If creating an application becomes easier, everyone can have tools fitted to their exact situation. Komoroske asks us to notice the hidden cost: a tool is not useful in isolation. It needs context, permissions, data, and a place within the rest of a person's life.
A thousand narrow tools can produce a thousand seams. A user may spend less time performing each task but more time moving information, reconciling conflicting records, and deciding which service deserves access. Automation at the feature level can therefore increase work at the system level.
This is why his argument reaches beyond user-interface preference. The architecture of data access determines who holds power. If reducing friction requires placing everything inside one company's boundary, convenience and dependence grow together. Infinite software delivered through centralized platforms could make services feel personalized while leaving people with even less practical control.
Trust must become a property of the system
Komoroske points toward technical guarantees rather than promises alone. He asks what would become possible if data policies were always respected, if software could operate on sensitive information without its creator seeing that information, and if an app could be remotely attested as trustworthy.[1]
The source presents these as emerging possibilities, not as a finished consumer system. That distinction matters. It would be inaccurate to say the privacy problem has already been solved. His claim is that the technical pieces are appearing and that builders now have a chance to reconsider the basic rules of software and data.
In his preferred future, trust does not depend only on a brand's reputation or a lengthy policy. It can be supported by verifiable properties of how code runs and what it can access. The person should not have to trade all privacy for a useful assistant that understands context.
From using apps to expressing intent
The phrase “software that works for you, not on you” captures Komoroske's human outcome.[1] Today, people often adapt themselves to a product's categories, screens, and business model. Personalized software could reverse that relationship. A person states a need, and tools assemble around that need rather than forcing the person through a fixed process.
My interpretation is that this changes the central unit of software from the app to the person's intent. The source does not use that exact formulation, but it follows from its contrast between fragmented platforms and adaptive, private tools. Instead of deciding which application owns a task, a person could decide what result they want and what information may be used to achieve it.
That interpretation also exposes a governance requirement. An adaptive system needs boundaries that remain understandable as the tool changes. People need to know what data is available, for which purpose, under whose authority, and how access can be withdrawn. Personalization without legible control would reproduce the problem in a smoother form.
What is argument and what is interpretation
Komoroske explicitly argues that AI will multiply software, that today's distribution model will deepen silos, and that privacy-preserving, attestable systems could offer a different path. He also argues that society can choose to build better systems rather than accept consolidation as a law of nature.[1]
My practical interpretation is that teams evaluating automation should ask two sets of questions. The first concerns capability: can the tool complete the task? The second concerns power: where does the data live, who can inspect it, what permissions are required, and can the user move away? A capable tool can still weaken the person using it if its convenience depends on irreversible concentration.
Another interpretation is that interoperability becomes a human concern, not merely a technical one. When data and tools can work together without surrendering everything to one intermediary, people have more freedom to change their minds. The source supports the direction of that idea, though it does not provide a detailed standard or migration plan.
A useful standard for software after automation
For readers considering an AI-assisted workflow now, Komoroske's thesis suggests a simple review. Map every piece of information the workflow touches. Identify where it is stored, which service can see it, and whether access is broader than the task requires. Check whether the person can export the data, replace a component, and understand what the system did.
Then distinguish convenience from alignment. A tool may remove clicks while increasing lock-in. Another may require a little setup but preserve meaningful choice. The right balance will vary, but the tradeoff should be visible rather than hidden behind effortless automation.
Komoroske's future is hopeful because it treats software's current structure as designed, not natural. Humans made the platforms, policies, and incentives that shape digital life. Abundant software gives us a reason to revisit those choices before abundance hardens into deeper dependence.
If you want help designing automation around your needs and boundaries, Agentic Workers can help you shape a workflow that remains accountable to you.