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

> Generative UI, server-driven UI, and static A/B testing are often confused. Server-driven UI is the delivery mechanism, A/B testing picks between a few fixed variants, design-time AI tools generate code before release, and generative UI composes the interface per visit from live data.

_Last updated 2026-10-24. From The Generative UI Guide, https://generativeui.guide_

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.