A product manager at a professional services firm recently described a demo where a client asked their AI assistant a plain-language question about project status, and the assistant answered with a small interactive dashboard instead of a paragraph: a progress bar, a table of open items, a button to reassign a task. None of that dashboard existed as a page anywhere in the product. The model assembled it, on the spot, from components the engineering team had exposed for exactly this purpose. Nobody on the design team drew that screen. They designed the pieces it was built from.
That is the shift generative UI describes, and it is no longer a research demo. It shows up across every industry Aero works with: a biotech data platform where a scientist's query returns a custom chart instead of a static report, a fintech app where a spending question produces a one off comparison view, a media company's internal tool where an editor's request assembles a bespoke content queue. The common thread is not the industry. It is that the interface is no longer a fixed artifact a design team ships once. It is an output the model produces, screen by screen, using the product's design system, or not.
Generative UI is the practice of letting an AI model choose, assemble, and render interface components at the moment a user interacts with it, rather than routing that user to a pre built page. Three examples define where this stands today. OpenAI's Apps SDK lets third party products like Zillow, Canva, and Spotify render their own interactive interfaces directly inside a ChatGPT conversation, chosen and composed based on what the user is asking for, according to OpenAI's own announcement. Google has proposed A2UI, an open, framework agnostic protocol for AI agents to describe and render portable UI components across different front end stacks, according to the Google Developers Blog. And Vercel's AI SDK now ships built in support for generative UI, where a model selects which registered component to stream back instead of returning plain text, according to Vercel's own AI SDK documentation. None of these are the same product, but they converge on one idea: the component library is becoming something a model calls, not just a resource a designer drags from a panel.
We covered making a design system legible to coding agents building with it in is your design system agent ready. Generative UI is related but distinct: it is not about an agent writing code against your components at build time, it is about a model choosing and assembling those components live, in front of an end user, every time they ask a question.
Two SaaS analytics companies added generative response surfaces within months of each other, both letting a model answer natural language questions with a rendered chart or table instead of plain text. The first let the model generate raw HTML and inline styles for each response. Early demos looked impressive, but support tickets followed: charts with unlabeled axes, numbers formatted three different ways depending on the question asked, and a colorblind user who could not distinguish two categories the model had colored on the fly. Nothing was reused from the product's actual design system, because nothing forced it to be.
The second company took a narrower approach: a fixed, tested set of chart and table components from their existing design system as the model's only building blocks, plus a schema describing what each needed, so the model chose and populated components rather than generating markup. The responses were less flexible in theory. In practice, every generated screen matched the rest of the product, inherited its accessibility work automatically, and could be tested because the possible outputs were a known, finite set. The capability was identical. The outcome depended entirely on whether the model assembled from governed parts or generated freely.
The appeal of generative UI is real: interfaces that adapt to what a user asked instead of forcing them through a generic flow. But an interface regenerated at runtime carries risks a fixed page never had. Brand and accessibility consistency depend on what the model chooses each time, not on a design file. Reproducibility suffers, since a support agent trying to recreate what a customer saw may be looking at a screen that will not render the same way twice. And a generated interface that gets a number or layout wrong looks, to the user, exactly as authoritative as one that got it right.
This is Aero's own practical lens, not an established industry standard. Five questions worth asking before you ship an AI assembled surface:
A team answering "not sure" to two or more of these is shipping generative surfaces faster than it is governing them.
Generative UI raises the stakes on decisions Aero has written about before. A design system that is not agent ready cannot safely be handed to a model as a component library, a problem covered in is your design system agent ready. And when a generated screen goes wrong, which it eventually will, the product needs the disciplined fallback thinking described in designing for AI failure states. Generative UI does not replace either discipline. It makes both of them load bearing in a way they were not before.
Not quite. A rich response chatbot renders a fixed set of message types from a short menu. Generative UI is a model actively selecting and composing components, potentially assembling layouts nobody explicitly designed in advance.
No. A2UI and similar protocols mainly solve interoperability between different agents and front ends. A product team can start with a small, internal set of governed components and a model that selects among them.
Start narrow. Pick one surface where users ask open ended questions, expose a small set of existing, accessible components as the model's only options, and measure whether the generated screens hold up before expanding the list.
Wondering whether your product is ready to let a model assemble its own interface? Talk to Aero.
AI platforms are starting to assemble interfaces on the fly instead of shipping fixed screens. Here's what generative UI actually means for product teams, and Aero's framework for using it without losing brand and accessibility control.
Usage-based and hybrid pricing are becoming the default for AI-powered products, but most pricing pages still assume a simple per-seat world. Here is Aero's practical framework for pricing pages that build trust instead of anxiety.
AI design tools now touch most product teams' workflows, and that convenience carries a real risk: interfaces that quietly converge on the same patterns. Here is Aero's practical framework for using AI design tools without losing what makes a product recognizably yours.
