When the interface is generated at runtime, knowing who clicked “Approve” may no longer be enough.
Imagine a release-management system that pulls together open defects, failed tests, risk signals and deployment history, then generates a release summary for the person making the final call.
It looks sensible. The risks are grouped. The evidence is there. The system recommends that the release is safe to ship and presents an approval action.
Someone approves it.
Six months later, something goes wrong and the obvious question is asked: why was this release approved?
The audit log can probably tell us who clicked the button and when. But if the interface itself was generated for that person in that moment, I’m increasingly interested in a different question: what exactly were they shown before they clicked it?
That question came back to me while looking at OpenAI’s Intelligent UI in GPT-6.
GPT-6 can decide that an answer would work better as a chart, form, set of controls, interactive explanation or small tool, and assemble that experience inside the conversation. OpenAI says it built native, streamable interface components and a compiler that processes them while the model generates its response. It also acknowledges that the model’s design judgment still needs work. (OpenAI)
For now, OpenAI describes Intelligent UI as part of the ChatGPT experience, but the pattern behind it is more interesting than the product boundary.
For most of software history, the interface existed before the user arrived. Designers decided what the screen contained, developers built it, QA tested it, and people learned how to navigate what was there.
Generative UI starts loosening that arrangement. Instead of always asking the user to follow a predefined path, software can assemble more of the experience around the task being asked of it. The prompt starts to behave a little like a temporary specification for the interface.
I don’t read this as “apps are dying.” Many interfaces should remain highly predictable. What changes first may simply be how much of the path has to be designed in advance.
That creates a less glamorous problem than generating a nice-looking screen: how do we know the screen is safe, correct and appropriate when nobody designed that exact version beforehand?
Testing the rules instead of every screen
Traditional regression testing has something reasonably stable to work with. A page should contain certain fields. A control should perform a known action. A given input should lead to an expected result.
If the interface can vary from one request to another, testing every possible screen stops making much sense.
The testing concepts themselves are not new. Property-based testing asks whether important properties remain true across many inputs. Contract testing checks whether components keep honouring agreed behaviour. Generated interfaces simply make those ideas much more central.
A user without release authority should never receive an active approval action, however the interface happens to be arranged. A calculation should use the authorised data source whether the answer appears as a table or a chart. A required warning cannot disappear because the model found a cleaner layout.
Accessibility creates the same problem in a more visible way. A generated interface may look perfectly fine and still have broken heading structure, poor focus order, missing control labels or dynamic content that a screen reader never receives. Looking correct is no longer enough; some of the most important quality checks sit below the visual layer.
I’ve sat through enough release discussions over the years to know that “all checks are green” and “we understand what we are shipping” are not always the same thing. Software tends to surprise us at the edges: two rules interact in an unexpected way, a harmless-looking change exposes a dependency, or somebody uses the product in a way nobody included in the happy path.
Making the interface variable gives those assumptions more room to collide.
Design systems will have to adapt too, but probably less dramatically than the phrase “AI-generated UI” suggests. A component definition may need to carry more behavioural meaning: not only what an approval control looks like, but when it can appear, what permissions it depends on and what information has to accompany it.
Generating another button is becoming cheap. Deciding whether that button should exist for this person, in this situation, and what it is allowed to do is still the harder work.
The audit trail may need to remember what you saw
Go back to the release approval.
If the system generated the screen, the information presented to the approver becomes part of the decision itself.
We may need to know which evidence was shown, which risks were omitted or de-emphasised, what data the model relied on and how it framed its recommendation. Could two people approving the same release have been shown meaningfully different information?
That is why I expect audit trails around AI-assisted decisions to evolve. Recording what the user did will not always be enough. We may also need to preserve what the user was shown when they decided to do it.
A timestamp and user ID tell us that an approval happened. They do not tell us whether the person saw the information they needed to make a sound decision.
This also complicates the comforting phrase “human in the loop.” A human can be present and still have poor oversight if the system controls which evidence reaches them and how that evidence is framed.
OpenAI’s Dots, its always-on agents that can keep working between conversations using their own cloud computers, already show how carefully these boundaries are being drawn. Some actions can proceed independently, others require approval, and particularly sensitive actions require the user to take over; proactive background research has tighter restrictions still. (OpenAI Help Center)
OpenAI has good reason to be cautious. In its review of misaligned research and evaluation systems, it identified 53 instances where user-provided images were posted to image-hosting sites as links that were not publicly listed. (OpenAI) Once an AI system can act outside the conversation, an error can escape the screen too.
If AI can influence both what someone sees and what happens next, provenance becomes part of the product experience.
Even measurement gets harder
There is a quieter consequence here for product teams.
Most analytics assumes that users move through reasonably predictable surfaces. We measure funnels, abandonment points, clicks and conversion rates because large groups of people are looking at roughly the same thing.
If the interface is assembled differently around each task, the page itself becomes a less useful unit of analysis.
The better questions may become more outcome-oriented. Did the person understand why the release was risky? Did they find the evidence they needed? Did the generated experience help them make the right decision, or did they have to keep asking until the system finally surfaced what mattered?
That is harder to measure than page conversion, but probably closer to what we cared about all along.
What remains fixed when the interface does not?
The software underneath all of this becomes more important.
Permissions need to be dependable. APIs need predictable contracts. Data needs provenance. Business rules have to be explicit enough for machines to apply them correctly. And for consequential decisions, we may need enough history to reconstruct not just the action but the context around it.
Some interfaces should remain fixed. I do not want my banking application deciding that a transfer confirmation deserves a more elegant interpretation on Tuesday than it did on Monday. Predictability has real value when money, safety or compliance is involved.
But there is also plenty of software where asking someone to work through six screens simply because those screens already exist is starting to look like inherited friction.
For decades, we have learned the structure of our software: which menu to open, which filter to apply, which screen comes next. Generative interfaces suggest that some of that burden may eventually move in the other direction. The software learns enough about the task to assemble the path around us.
If that happens, the difficult part will not be generating the interface. It will be making sure the things that matter survive every version of it: the right permissions, the right evidence, accessibility, context and a record we can trust later.
And if a consequential decision were made tomorrow through a screen that existed only for a few minutes, there is one question I would want to be able to answer months later:
Could we show exactly what the person saw when they made it?
