Generative UI vs server-driven UI and A/B testing

Generative UI gets confused with two neighboring ideas: server-driven UI and A/B testing. All three move the layout decision off a single fixed page. They differ in what decides the layout, and how often it changes.

Generative UI vs server-driven UI

In a server-driven UI, the server returns a description of the screen and the client renders it from a component library it already ships. It decouples releases: you can change a screen without shipping a new app build. What the server returns is still usually the same for everyone in a given state.

Generative UI keeps that server-decides model and adds the input that makes it per-visit: data about who is looking and what they are doing. The server does not just pick a known screen. It composes one for the request from that data and a set of rules or a model.

So server-driven UI is the delivery mechanism, and generative UI is what you do with it once the decision is informed by live state. Most teams that want generative UI build it on top of server-driven UI.

Server-driven UI is older than generative UI, and it supplied most of the machinery. Microsoft’s Adaptive Cards in 2017 and Slack’s Block Kit in 2019 let a server describe a card in JSON that the client drew natively. Airbnb’s server-driven system, written up in 2021, sent whole screens this way to ship features across web, iOS, and Android without three separate releases. Swap the server’s fixed logic for a model and you have declarative generative UI: the schema becomes the catalog, and the renderer is unchanged. This is why the delivery side of generative UI arrived so fast. The hard part, drawing a described interface on the client, had been solved for years.

Generative UI vs static A/B testing

An A/B test ships two or more fixed variants and assigns each visitor to one, usually for the length of the test. It answers which variant performs better on average for the group. The experiences are built by hand, so the number of them is small.

Generative UI does not choose between pre-built pages. It assembles one from data about the visit. The result is closer to one experience per visitor than a handful of variants. You are tuning the rules and the data that drive generation, not maintaining a set of static pages.

They are not exclusive. Teams often A/B test the rules behind a generated interface: does composing from live intent beat composing from the segment. The test measures the approach. Generation produces what each visitor sees.

Generative UI vs AI UI generation

A third thing gets called generative UI: tools like v0, Lovable, and Bolt that turn a prompt into interface code. These generate at design time. A developer prompts, reviews the output, and ships it, and the result is code in a repository, the same for everyone who then uses the product. That is AI-assisted development. It is useful, but it is not what this guide means by generative UI.

The distinction is when the generation happens. Design-time tools generate the code once, before release. Generative UI generates the interface at runtime, for a visit, from data about that visit. The same word covers both because both use a model to produce UI, and search traffic mixes them freely. If the output is a pull request, it is design-time generation. If the output is the screen a particular person sees right now, it is generative UI.

Side by side

	Server-driven UI	Static A/B testing	Design-time AI UI generation	Generative UI
What decides the layout	The server, from app logic	A split assigned up front	A developer, at build time	Rules or a model, from live state
How many layouts	One per known state	A few fixed variants	One, shipped to everyone	Close to one per visitor
Changes within a visit	Rarely	No, fixed for the test	No	Yes, as the visit unfolds
Needs real-time state	No	No	No	Yes
Main cost	Building the server contract	Building and maintaining variants	Reviewing generated code	Fresh state and a decision layer

Which to reach for

Use server-driven UI when you want to change screens without app releases. Use A/B testing when you have a few clear variants and want a confident read on which wins. Reach for generative UI when the number of useful variants is larger than a team can build by hand, and you have state current enough to compose the interface per visit. In practice the three compose: generative UI delivered over server-driven UI, with A/B tests measuring the rules behind it.