For decades, a person with a need has had to find an application built for roughly that need. When the fit is poor, a team translates the requirement into screens, services, data models, code, tests, and a release. AI may change that sequence. My view is that computing will increasingly form the capability around the intent, at the moment it is needed.
From fixed applications to generated capabilities
I call this direction intent-native computing: an environment in which a person describes an outcome, and AI assembles an appropriate interface, workflow, and supporting logic from available data and services. The result might last for one question, become a repeatable process, or evolve into something shared by a team. It need not begin as a conventional application with a fixed set of screens.
Consider a clinical operations lead who asks, “Which sites have enrollment delays, what is causing them, and what should we review first?” Today that answer may require moving among reports, exports, dashboards, and messages. An intent-native environment could build a purpose-specific view, reconcile authorized sources, show its reasoning and provenance, and offer the next useful actions. In a regulated setting, permissions, traceability, review, and validation would remain essential.
Data remains; the layer above it changes
This is not a claim that databases disappear. Persistent data, identity, security rules, history, and dependable records remain fundamental. What changes is the development methodology on top of them. Instead of anticipating every user journey and hard-coding each form, query, and workflow in advance, we may increasingly describe the need and let the environment compose the capability.
Human involvement also remains central. People define the goal, the constraints, the meaning of a correct answer, and when a result is good enough to act on. The more capable the system becomes, the more important it is to make those judgments explicit and inspectable.
An evolution through today’s stack
I expect gradual replacement, not a sudden break. Existing software is the breeding ground: AI first helps create and modify familiar applications, automates repetitive CRUD work, and connects existing systems. As that approach matures, the pressure moves down into architecture itself. Interfaces, business logic, orchestration, and execution may become more adaptive, challenging the boundaries between layers built for a world of prewritten applications.
Those layers could eventually converge into a more unified environment for expressing intent, accessing durable data, generating behavior, and checking outcomes. This does not remove the need for reliability or accountability. It changes where the engineering effort sits: in the foundations, guardrails, evaluation, and stewardship that allow generated capabilities to be useful and trustworthy.
Competition will shape the transition
Early systems will likely compete as distinct models, agents, tools, and application platforms. Their different strengths will drive experiments in how well they interpret needs and deliver working results. Over time, successful patterns may become part of the computing environment itself, rather than features bolted onto individual products.
I do not know the final interface or the timetable. The direction I see is an evolution from software we must choose and operate toward capabilities that take shape around what we are trying to accomplish. The question for builders is how to make that transition practical, secure, and worthy of trust.