Most enterprise software ships one interface and asks every team to bend to it. The fit is never quite right, so you pay for customization, a months-long project to reshape a fixed product around how your team actually works.
The interface is treated as expensive and permanent, because for decades it was. That assumption is the thing that just changed.
The right interface is usually small and specific
For most tasks, the ideal interface is not a big general application. It is a small, purpose-built surface: the three fields this review needs, the one table this approval reads, the two buttons this workflow actually uses.
Those interfaces rarely get built, not because they are hard to imagine, but because building UI has always been expensive enough that only the general case was worth it. So teams make do with a general tool that fits no one perfectly, and call the gap configuration. The mismatch is not a failure of the software; it is the economics of building interfaces, showing up as friction.
Picture a claims-review applet. On one screen: the three fields the reviewer fills, the relevant policy excerpt pulled in, the customer's recent history, an approve and an escalate button, and the agent's draft recommendation with its reasoning. Nobody would build that as a product, because the market for exactly-this-screen is one team. Generated for that team, in an afternoon, it is the obvious right interface for the job.
If an agent can write code, it can write the interface
Here is what changed. The same capability that lets an agent do real work, writing and running code, also lets it produce an interface. An applet is exactly that: a per-use-case interface, generated for a specific team and a specific task, in hours instead of months.
Not chosen from a library of templates. Generated, the way the agent would write any other code, against this team's actual workflow. When the cost of an interface drops from a quarter to an afternoon, the calculus that made only the general case worth building no longer holds, and the specific interface becomes worth building too.
It keeps the work in view
There is a failure mode this avoids. When a tool fixes a single form factor, a chat window, a spreadsheet grid, the work that does not fit that shape gets done somewhere else, and the tool sees less and less of it.
A generated interface bends to the work instead, so the work stays on the surface where the agent can act in it and the trace can capture it. The form factor following the work is not only convenient. It is what keeps the work in view, which is the thing everything else depends on.
Humans and agents share the surface
An applet is not a dashboard the agent hands a person and walks away from. It is a surface they co-inhabit. The agent works in it, the person works in it, and they hand off across the same interface: the agent drafting in a field the human then edits, the human approving a step the agent then continues.
The interface is where the human-in-the-loop actually lives, and because it was generated for this workflow, the loop fits the work instead of the work bending to a generic form. The handoff stops being a context switch between a person's tools and an agent's, because it is one surface, built for both.
The interface stops being the bottleneck
The shift is not that the UI is prettier. It is that the interface stops being the expensive, permanent thing it used to be. When an interface can be generated in hours, you build the one the task actually needs, and you change it when the task changes, instead of filing a feature request and waiting two quarters.
The form factor follows the work. For years it was the other way around, the work bent to fit the form factor, and we mistook that for the natural order of things. It was just a constraint, and it has loosened.
Because an applet is cheap, it is also disposable, which is a feature. When the workflow changes, you regenerate the interface instead of customizing the old one and carrying that customization forever. Applets do not accrete the legacy a configured product does, because there is nothing precious to preserve. The cheapest interface to maintain is the one you can always rebuild.
Why this is sticky, honestly
There is a second-order effect worth naming plainly. When the interfaces a team depends on every day are generated against your agents, your data, and your identities, wired into how the work runs, they become part of the company's fabric in a way a bolted-on tool never does.
That is stickiness, and it is worth being honest that it cuts both ways. It is hard to rip out precisely because it fits, which is the same reason it was worth adopting. The lock-in, if you want to call it that, is just the interface having become the workflow rather than sitting beside it.
What the work actually needs
Hard-coded interfaces made the surface the slowest, most expensive part of fitting software to a team. Generated interfaces invert that: the surface becomes cheap, specific, and disposable enough to match the task instead of constraining it. Agents do the work, people steer it, and the place they meet is built for the work in front of them, not chosen from a catalog. When the interface is no longer the bottleneck, the question stops being what does the tool let us do and becomes what does the work actually need, which is the question that should have been driving it all along.