Software That Writes Itself: The Rise of Intent-Driven Apps

An investigation into what the browser can now do on its own, what it still cannot, and why every line of code you did not ship is a line no one has to pay for.

There is a particular kind of shame that comes from not knowing where a button lives. You want to dispute a charge, or move money to your sister before the school term starts, or find the setting that stops your phone screaming at 3 a.m. — and instead you are wandering a menu built by someone who has never met you, tapping through Settings > Account > Preferences > Notifications like a stranger feeling along a dark corridor for a light switch. For thirty years this has been the quiet tax of being alive with a computer: you did not just need to want something, you needed to learn the software's language for wanting it.

That tax is being repealed, in real time, by people who mostly do not say so out loud. Somewhere between 2024 and now, the software stopped waiting for us to find it and started trying to meet us where we stood. Ask, and something is built for you — on the spot, for that request only, then gone. This is the story of that shift: what it actually is, who is building it, what it has already broken, and what it still owes us.

From menus to meaning

The shift is real, but it is more gradual than claims that software is being rebuilt around intent alone suggest. Many products still depend on menus and conventional interfaces; some now add assistants that interpret a request, call a tool, or assemble a task-specific view. The useful question is not whether menus will disappear, but which parts of an interaction can be made simpler without giving up clarity or user control.

One approach is to let an AI choose among components designed and validated by the product team; another is to generate more of the interface at runtime. The first constrains what can appear, while the second offers more flexibility and requires stronger validation. These are design choices, not a single standardized definition of generative UI. For consequential tasks such as disputing a payment, the interface still needs to show what will happen and let the user review it before anything is submitted.

In practice, a product can keep its visual components fixed while allowing an assistant to select them and fill them with relevant information. A more open-ended system can adapt further, but also makes it harder to predict and test every result. The design challenge is deciding how much freedom to allow, and making the available actions and their consequences legible to the person using the product.

The plumbing nobody sees

Connecting an assistant to other tools requires a defined interface. The Model Context Protocol (MCP) is an open standard for connecting AI applications to external systems, including data sources and tools; it does not, by itself, make an agent safe or guarantee that a task will succeed. Separately, Chrome described WebMCP in February 2026 as an early-preview proposal for websites to expose structured actions to browser agents. Both efforts illustrate the work needed to make software usable by agents, but neither means every website or application now supports those workflows.

The browser becomes part of the interface

Browsers are one place where these ideas are being tested. Chrome's WebMCP proposal describes a way for a site to offer structured actions—such as creating a support ticket or searching a catalog—rather than relying solely on an agent interpreting page content and clicking controls. Chrome describes this as an early preview, so it should be understood as an experiment, not a generally available capability across the web.

These interfaces do not remove the need for conventional browser controls. An agent may misread a page, misunderstand an instruction, or take an action the user did not intend. A structured interface can make the available actions clearer, but it still needs appropriate permissions, confirmation for consequential actions, and a way for the user to stop or correct the process.

A benchmark score is not a guarantee of how an agent will perform in a particular person's workflow. Results depend on the tasks, tools, and test conditions, so evaluations should be read alongside the system's documented limits and tested behavior. For users, the relevant question is whether the product makes its plan and actions visible and gives them meaningful control.

The thing that has not been solved

Here is where the story stops being a product roundup and becomes something closer to an investigation.

Prompt injection is a documented risk for systems that process untrusted text, webpages, or files. Malicious or misleading content can influence a model's behavior, and current techniques do not guarantee prevention. The risk depends in part on what tools and permissions an application gives the model; it is therefore important to limit access and treat external content as untrusted. OWASP's guidance discusses the vulnerability and practical ways to reduce its impact.

A successful injection can lead to unintended outputs or actions, especially when an application grants broad access to data or external tools. That does not mean every agent is vulnerable in the same way, or that a model will always obey hostile content. The impact depends on the surrounding system: its permissions, the boundaries around untrusted inputs, and the checks applied before an action is taken.

No single safeguard is sufficient. OWASP recommends measures including least-privilege access, human approval for high-risk actions, and separating or clearly identifying external content. These controls do not eliminate prompt injection, but they can limit what a compromised agent is able to do. The practical goal is to reduce the potential impact while continuing to test the system as its tools and capabilities change.

What this costs, and who pays it

There is also a human question. When software automates parts of a workflow, people still have to decide what to delegate, review the result, and take responsibility for consequential choices. The tasks that can be automated vary by product and context; it is premature to claim that an agent replaces a whole profession simply because it can perform one step in that profession's work.

Trust is partly a design problem: users need to understand what an agent is about to do and how to intervene. Showing a concise plan, asking for confirmation before consequential actions, and making results easy to inspect are practical design choices—not guarantees that a system is correct or that a confidence indicator is calibrated.

The corridor, again

Picture the person from the beginning of this story, months from now, back at that same task — disputing the charge, moving the money before the school term starts. The menu is gone. In its place is a single sentence they typed the way they might say it to a person, and a screen that appeared to answer exactly that sentence and nothing else, built for the moment and already forgetting itself the instant the task is done. There is something almost generous in that, a kind of software that has finally learned to listen before it speaks.

But generosity of this kind is not the same as safety, and convenience has never once, in the history of technology, arrived without a bill attached. The systems now capable of understanding what we want are, by the same design, capable of being told what to want by someone else entirely — a stranger's sentence hidden in a document, mistaken for our own. The industry building this future has, by its own admission, not yet solved that problem, and may not for years. What it has built instead, alongside the convenience, is a new kind of trust: quieter than a password, harder to see, and, for now, resting on very little more than the hope that the voice giving the instructions is really yours.

The manual is disappearing. What replaces it is not silence, but a conversation — and like any conversation worth having, it will only be as safe as the character of whoever else is in the room.