The history of generative UI

Most accounts of generative UI begin in late 2023, when Vercel launched v0, or in early 2024, when it open-sourced the technique as part of the AI SDK. A few reach back to Jakob Nielsen’s claim, in 2023, that AI was the first new interface paradigm in sixty years. None of these is wrong. They are just short.

The longer view is that generative UI, where a model composes an interface at request time from a catalog of parts, is not a new idea with new tooling. It is the latest round of an argument that has run since the 1960s: whether a designer’s job is to make the thing, or to make the system that makes the thing. That argument was had by typographers, by artists, by architects, and by mobile engineers, and most of what the current tools take for granted was worked out, often more carefully, by people who were not thinking about software at all.

The argument in one paragraph

A designer can author an artifact: this screen, this poster, this page. Or a designer can author a system: a set of rules, parts, and parameters from which many artifacts can be produced, by a machine or by chance. The first kind controls the output. The second controls the space of possible outputs and gives up control of any particular one. Generative UI is the second kind of design applied to interfaces, with a language model as the thing that runs the system. Every real question about it, what goes in the catalog, how much to let it vary, who is responsible for the result, how you measure something different every time, was asked first by people working on systems rather than single pieces.

Where the word comes from

The word generative did not arrive from machine learning. In 1965 the philosopher Max Bense published a short text, Projekte generativer Ästhetik, to accompany what is usually counted as the first exhibition of computer art: plotter drawings by Georg Nees in Stuttgart. Bense’s generative aesthetics was named directly after Chomsky’s generative grammar, the idea that a finite set of rules can produce an unbounded set of well-formed results. Nees took the word into his 1969 doctoral thesis, Generative Computergraphik, and from there it passed into generative art and, half a century later, into generative UI.

That lineage matters for more than trivia. A generative grammar is a lexicon plus a syntax: a catalog of parts plus rules for combining them, defining a space of valid sentences. That is exactly the shape of the declarative generative UI formats in use today, a catalog of components plus rules for composing them, defining a space of valid interfaces. The current tools are generative in Bense’s sense, not just in the marketing one.

The catalog

The first thread is the idea of designing the system rather than the output. The Swiss designer Karl Gerstner argued for it in Designing Programmes in 1964: a designer should define a rule set from which the decisions for a product follow. Fifteen years later Donald Knuth built a version a computer could run. Metafont, written between 1977 and 1979, described letterforms by their parameters rather than their outlines, so that one specification could yield an infinite variety of related letters. Christopher Alexander’s A Pattern Language, in 1977, was a catalog of 253 patterns meant to be used, in its own words, a million times over without ever doing it the same way twice, and its authors called the result something a computer scientist might call a generative grammar.

Knuth’s work also produced the first clear statement of the argument that still divides the field. Douglas Hofstadter replied to him in 1982 that there could be no single meta-font, because the space of letters cannot be captured in parameters set in advance. Knuth’s position is the schema-driven one: define the parameters and let the machine fill them. Hofstadter’s is the code-generation one: no catalog is rich enough, so generate the thing itself. That exchange is forty years old and the two camps have not moved.

The specification, separate from the thing

The second thread is the idea that a work can exist as an instruction that someone else carries out. The conceptual artists of the 1960s worked this out in public. Sol LeWitt wrote in 1967 that the idea becomes a machine that makes the art, and from 1968 his wall drawings existed as written instructions and a certificate. The drawing on the wall was made by assistants, could be remade elsewhere, and was painted over when the show closed. The instruction was the work.

This is the architecture of today’s app-in-assistant protocols with the roles renamed. The agent writes the instruction. The host executes it. The instruction is a specification, not a picture, and it can be rendered in different places with different results while authorship stays with whoever wrote it. LeWitt also named the thing the protocols are still working out, which is where latitude lives: his instructions left deliberate room for the person drawing them, because a specification with no slack is just a slow way of drawing the picture yourself.

The variation budget

The third thread is the number between the catalog and the specification: how much to vary. The clearest worker on it was Vera Molnár, who began making combinatorial art by hand in the 1950s and taught herself to program in 1968. Her method for the next fifty years was to take a strict structure, a grid, a set of lines, and introduce a small, controlled dose of disorder. She called it one per cent disorder. With her husband, a perception researcher, she built an interactive system in the mid-1970s that let her adjust parameters and see the result, a model-in-the-loop design tool decades before the phrase existed. She was treated as a footnote for most of her life and recognized as a pioneer only in her nineties, shortly before her death in 2023.

The mapping to generative UI is almost too neat. The structure is the catalog. The one per cent is the variation budget, the amount of latitude the system has to depart from the default. Too little and every interface is the same and the generation is for show. Too much and the interface cannot be learned from one visit to the next. Molnár named this parameter in 1976. Almost nobody in the current tooling has named it since.

The machine in the loop

The fourth thread is the idea of a machine that designs with you rather than for you. From 1967, Nicholas Negroponte’s group at MIT set out to build exactly that, and the chapter titles of his 1970 book The Architecture Machine read like a roadmap for the agentic era. His claim was that the interesting machine was not one that drew what you told it, but one that proposed, argued back, and learned your preferences. That is the claim of today’s agent frameworks, made in 1970. Alan Kay’s 1972 Dynabook work asked for an interface a user could extend rather than one a vendor fixed. Muriel Cooper’s Visible Language Workshop at MIT, from 1974, built tools that took part in the act of design. This is the thread the current discourse most often forgets, and it is the direct ancestor of an agent composing an interface in conversation with you.

Server-driven UI, the recent prehistory

The fifth thread is the one that supplied the actual machinery, and it was built with no model in mind. To change a mobile app’s layout without waiting on an app-store release, companies moved the layout to the server. 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 from a shared schema, to ship across web, iOS, and Android without three releases.

Swap the server’s fixed logic for a model and you have declarative generative UI. The schema becomes the catalog. The renderer does not change. This is why the delivery side of generative UI could arrive so fast once models were good enough to author the specification: the hard part, drawing a described interface on the client, had been in production for years. What the model added was authorship. What it removed was the deterministic server logic that used to decide what to show, which is also the thing that used to make the result measurable.

The public learns to read a seed

The sixth thread is unfashionable and belongs here anyway. In 2021, platforms that minted each output of an algorithm to a collector changed the economics of generative art, and a large public learned to read a seed. People compared outputs of the same algorithm, argued about which parameters produced which traits, and valued variation within a distribution. Tyler Hobbs, whose Fidenza was the best-known work of the period, argued that the form demanded a different kind of algorithm, one interesting across hundreds of outputs rather than one or two.

Two things from that moment matter here. A public learned to see a generated result as one of a family rather than as a mistake, which is the literacy generative UI assumes when it shows each person a different screen. And the quality question Hobbs posed, how good is the whole space of outputs, is the right question for a catalog. A catalog that produces one layout is not generative. A catalog that produces ten thousand bad layouts is not generative in any useful sense either. The craft is in the distribution, and that cohort thought harder about distributions than interface design has since.

The name gets contested

By 2023 the pieces existed and only the name was unsettled. Nielsen framed AI as a new interface paradigm in 2023 without using the phrase. Vercel used it for v0, a design-time tool that turned prompts into code, then carried it over to a runtime technique in the 2024 AI SDK, which is the origin of the lasting confusion between generating code before release and composing an interface during use. Nielsen then used it in 2024 for an interface regenerated per person, and tied it to accessibility, which drew sharp replies from practitioners who pointed out that generated interfaces barely handle accessibility at all. Google Research used it in 2025 for a system that writes code for each prompt.

By 2026 the term covers at least four distinct things: generating interface code at design time, generating code at runtime in a sandbox, composing a screen at runtime from a catalog, and showing a third-party interface inside an assistant. The comparisons page separates the ones most often confused. The older vocabulary is more useful than any single definition: ask of any system whether it authors a picture or a program, and if a program, what its catalog is, how much it is allowed to vary, and who carries out the instruction.

The case against

An account with no counter-argument is marketing. Generative UI has three serious objections to answer, and all three are older than it.

People remember where things are. The steady finding in the research on interface layout is that interfaces which keep things in place are faster to use, because people learn them by location. An interface that is different every time cannot be learned that way. Molnár’s answer applies: keep the structure, vary the detail. Most demos do the opposite.

A catalog is hard to change. Once a model can only compose from the parts in the catalog, the interfaces it can imagine are the ones the catalog can express, and the catalog becomes harder to change the more systems depend on it. The security argument for catalogs, that no generated code can run, is also a lock-in argument, and it is more honest to state it as both.

A generated interface is hard to account for. Consistency underpins most usability guidance: the same situation should behave the same way. An interface regenerated per person cannot be documented, taught, or audited by a third party, because there is no single interface to point at. When something goes wrong, the question of what the person saw has no answer unless the system recorded it. That is a measurement problem as much as a design one, and measuring generative UI is where it gets picked up.

None of these is fatal. All of them are old. A generative UI practice that answered them would look a lot like Molnár’s: a fixed structure, a named variation budget, and a record of every seed.

Questions worth asking

The use of this history is a set of questions to put to any protocol, framework, or product, in place of whatever its makers call it.

• Is it a program or a picture? Does the system author a specification that something else renders, or does it author the artifact directly?
• What is the catalog? Who defines the parts, how rich are they, and how hard are they to change?
• What is the variation budget? How far may the result depart from the default, and is that number named anywhere?
• Who carries out the instruction, and with how much latitude?
• Is the machine in the loop or at the end of it? Does it propose and revise with the person, or deliver and stop?
• How is it measured? If every output is different, what is the unit of analysis?

Those questions, rather than any one definition, are the spine of this guide. They are also older than the field, which is the point.