Zombie UI: How to Stop AI From Building the Interface Everyone Else Ships

Teams of three can now do what once needed teams of 30. This article teaches the four moves that push back: a point of view, standards encoded into the machine, an editor who refuses to confuse done with good, and a budget for the strange.

The second building boom, and how a style turns into zombies

Right after World War II came a building boom, the largest in history by the talk's account. Its builders reached for the modernism of the 1920s: simple geometries, clean bare surfaces, monochromatic palettes, no adornment. With urgency to build and new construction methods, that style was copied again and again without intentionality. The talk's name for the result is zombie buildings, structures that stand and function while nothing differentiates them.

A style is a set of answers to specific problems, and copying it without the problems keeps only the surface. Copied that way, the patterns stopped fitting the places and people they were built for.

The most famous casualty of that era shows why the lesson needs care. Pruitt-Igoe in St Louis was heralded by Architectural Forum as the best high apartment of 1951, its demolition began in 1972, and it remains commonly cited for the failures of modernist design. Charles Jencks went further and dated the death of modern architecture to the dynamiting of its slab blocks on July 15, 1972. Historians have since argued that its construction and management were shaped by deeply embedded economic and political conditions, and that blaming the designers shifts attention away from those institutional causes.

The talk's central claim is that we are in another building boom now, the AI building boom. A company can now build 20 ideas in a week. Zombie UI is the digital twin of the zombie building: an interface assembled from the most probable patterns, competent on the surface and interchangeable with every other product built the same way. Research on AI-generated interfaces already shows its outline: tools that reach basic accessibility compliance while relying on homogenized design patterns.

The drift to the mean: language models are really good at telling you the most probable answer, and the most probable interface is the average one. The drift to done: AI makes things feel finished really fast, all too often prematurely. The drift to disposable: the work is so quick that it feels disposable and, worse, is treated that way.

Each drift needs its own counterweight, and the talk frames the outcome as a choice: this boom can skip the digital zombies and become a creative Renaissance.

Why AI output drifts to the average, and why better prompts will not fix it

Figure 1. The three structural drifts that push AI output toward zombie UI, each requiring its own counterweight.

A large language model, or LLM, is trained to predict what comes next, so it learns to assign high probability to the continuations it has seen most often. That is the precise sense in which LLMs are really good at telling you the most probable answer.

Researchers call the narrowing generative monoculture: a significant drop in output diversity relative to the training data, such as producing only positive reviews for books that had a mixed reception. Another line of research traces part of that cause to typicality bias: the people who rate model outputs systematically favour familiar text. Formatting templates add their own pressure, and one study found that the resulting diversity collapse persists even under high-temperature sampling. Across 14 language models, another team found probability mass overly concentrated on a few valid continuations.

A systematic review of LLMs in UI and UX design notes reliance on generic or conservative patterns and warns that designers may anchor on AI suggestions too early, narrowing their ideation. An evaluation of AI-made screens found attractive visual polish next to incorrect words, illegible labels and no interactive feedback. Practitioners testing a generative UI tool reported that it struggled to keep the connective tissue between screens: consistent styles, shared layout, a coherent flow.

The second mechanism is the gap between what you mean and what you type. Stripe's design team saw it directly: three different people could put in the same prompt and get three different results.

The third mechanism sits in the reviewer, not the model. The talk's image is a microwave burrito: 90 seconds from hungry to lunch, and the speed makes you willing to overlook that it is barely edible. That is the drift to done in miniature.

What works is structure at three points: a point of view upstream, standards encoded into the tools the model must go through, and an accountable editor downstream. The flow below maps the method the rest of this article teaches.

Step one: build a point of view by noticing

The first move happens before any model is opened: define your brand, what it is for you and what it is for your users.

Stripe's point of view is optimism, and the team puts it into all the details, big and small. In the talk, that value runs through colours, writing, subject matter and the products shipped to support entrepreneurs.

A point of view is not invented in a workshop; it is built by noticing. Notice what your users need and what they want, not just what they say. Notice the wider world too, since products, art and science all signal what reads as good, great or mediocre.

Figure 2. The three-layer token architecture that makes AI agents obey intent-based standards rather than guessing from appearance names.

Template to adapt: We are [what you are] for [who]. We believe [the belief]. So we always [visible behaviour] and never [the probable default we reject].

Step two: encode your standards into the machine

The talk's most consequential thesis is that the object of design is no longer the screen; it is the system itself. Hence the second move: encode your standards into the machine.

Theirs read the design documentation, and it was not specific enough: three people with the same prompt still got three different results. So the team built a CLI, a command-line tool, on top of its design system, and it works as a harness that makes the AI far more obedient.

One design-system governance guide states the principle bluntly: an agent cannot read a wiki page and decide to follow the naming convention, it needs rules expressed as structured data with explicit conditions, constraints and consequences.

Composition is exactly where generative tools are weakest, as practitioners found when a tool struggled to keep styles and flow consistent across screens.

Current guidance splits them into layers: primitives hold raw values, semantics hold meaning, and components consume the semantic layer. Name by intent, not appearance: color.blue.500 forces a guess between blues, while color.action.primary states the intent outright. In the W3C Design Tokens format, the $description field is what tells an agent when to use one token instead of a look-alike. One open-source agentic design system writes its absolute rule this way: primitives are never used directly in components.

If your design source is Figma, its own guidance says connecting components to code with Code Connect is the most effective way to get an agent to reuse your real components; without it, the agent has to guess. The same guidance asks for variables for spacing, colour, corner radius and typography, layer names that describe purpose, and auto layout instead of absolute positioning.

One exposes a compliance check that validates a code snippet against the design rules and returns violations. Another keeps a contract file beside each component and gates design-system drift in continuous integration. One builder's account of a design-system agent made the CLI the only entry point and wrote hard guardrails into it: a write allowlist, no shell commands, no new dependencies.

Encoding has a ceiling, and the talk names it with a line from Christopher Alexander: a system can satisfy every rule and still be dead. Research on design organisations shares the worry: leaders fear that systems structuring design as the assembly of predefined components may be narrowing the range of skills they see when hiring. Practitioners in another study judged such criticisms often lacking context, reaffirmed the value of design systems, and asked for better collaboration around them.

Step three: edit rigorously, and refuse to confuse done with good

The third move has a slogan worth pinning to the wall: refuse to confuse done with good. Behind it sit two habits every team has to unlearn: that built means done, and that done means good.

The role that replaces the old filter is the editor. An editor takes accountability for every decision, which in many ways means every pixel. The editor judges the end-to-end result the way a user meets it, not screen by screen as it was generated.

At Stripe, a crit on an AI-assisted ad ended with 17 bullet points of improvements.

Walk the flow as a user, from the first entry point to the last confirmation, and note where the journey breaks rather than where a screen merely looks off. Open every state models rarely draw well: empty, loading, error, partial data, the longest name, the smallest screen. Read every word, since evaluations of AI-made screens keep finding incorrect words and illegible labels behind attractive layouts. Then hold the result against the point of view: with the logo removed, would someone who knows the brand recognise it as yours?

Template to adapt: Where [location], I see [observation], which breaks [principle], so change it to [specific instruction].

Editing only works if the editor can stop work that is already built. Name one editor per surface, give that person an explicit right to block a release, and make blocking routine so it reads as practice rather than personal veto.

The step most teams skip is closing the loop between editing and encoding. Every note that shows up in two crits is a rule waiting to be written into the system, so the editor's judgement compounds instead of being spent again on each screen. Governance guidance makes the same move from the other side: inventory the rules that already live in contribution guidelines, linter configs, review checklists and decision records, then express each as a machine-checkable constraint. Over time the harness absorbs the routine judgements and frees the editor for the ones only taste can make.

🛠 How to — Build a design standard an AI agent obeys, and an edit gate that blocks done-but-not-good

1. Inventory the rules that already exist and where they live: contribution guidelines, linter configs, Figma naming conventions, token usage notes, pull-request checklists and decision records.
2. Restructure tokens into a primitive layer of raw values and a semantic layer named by intent, point every component at the semantic layer, and give each semantic token a one-sentence description of when to use it.
3. Connect your Figma components to code with Code Connect so the agent reuses real components instead of guessing.
4. If you adopt an off-the-shelf contract layer, initialise it in your repository; Fragments, for one, detects your framework and writes the contract in a single command. npx @usefragments/cli init
5. Gate design-system drift in continuous integration so off-system output fails before it reaches review. fragments check --changed --ci

Step four: spend the savings on the strange

As the talk puts it, AI can help us manufacture monotony, but it is also the greatest creative catalyst we've ever had. Its motto is protect the strange: AI lowers the cost to create, so part of what it saves should go to unusual work.

When each attempt is expensive, teams rationally cut the odd idea first, because its payoff is uncertain and its cost is certain. When attempts become cheap, the same logic flips: variance is affordable, and the unusual option earns a place in every round.

The talk's own example is an event's opening animation.

The obstacle to strangeness is not only the model but fixation in the people using it, a phenomenon researchers describe as still underexplored in generative AI.

So ask the model for a spread, not an answer. Verbalized sampling, a training-free prompting strategy, asks the model for several responses with their probabilities, which relieves the pressure to produce one typical answer. In creative writing, it increased diversity by 1.6-2.1x compared to direct prompting.

Template to adapt: Give me five directions for this onboarding screen, each with how likely a typical product team would be to ship it, and make at least two of them directions a typical team would never pick.

Figure 3. Gutenberg's 290 type variants and Ruskin's non-repeating columns share the same principle: meaningful variation is engineered into the system, not left to chance.

The tension with step two is real: a harness built to make AI obedient pulls the opposite way from a lane built to make it strange. Let's call the resolution two lanes: a system lane where the harness rules navigation, forms, settings and every flow users need to be predictable, and an expression lane where the brand speaks, held to the point of view and the editor's bar rather than to the templates. One study of design systems notes that their limits on creativity may also be an asset, letting designers get more creative with the problems the system does not solve.

Craft lessons from Gutenberg and Ruskin: where variation lives

The printing press is usually told as a story of speed, but the more useful part for anyone building with AI is the system Gutenberg built around his machine. His scale engine was a hand-held mold that let hundreds or thousands of pieces of type be cast from a single matrix.

For his Bible, Gutenberg created 290 unique characters, including different widths, abbreviations and ligatures. Approximately 60 types would have been enough to compose the text if avoiding wide word spaces had not been the goal. The type designer Hermann Zapf later identified the secret as even grey columns, with no disturbingly wide holes between the words.

The detail matters: most of those extra sorts were ligatures and abbreviations, while the number of single characters with varying widths was small. Even for the same letter, he cast several pieces of type, each with a slightly different design.

John Ruskin approached the same problem from the opposite side, writing in 1850 about quality and craft and holding up gothic architecture as the epitome of great. He noticed that no gothic building was alike, and that not even one column matched another. Asked whether one could build Gothic by covering buildings with trefoils, he answered no, any more than a child can write Latin by copying words at random out of Cicero.

In The Nature of Gothic, Ruskin ranked the moral elements of the style as Savageness, Changefulness, Naturalism, Grotesqueness, Rigidity and Redundance. Seen from the builder's side, he restated them as Rudeness, Love of Change, Love of Nature, Disturbed Imagination, Obstinacy and Generosity.

Mistakes that turn a good system into a zombie factory

The first mistake is a separate, lower bar for AI work, the question a cross-functional partner keen to ship fast once put as: what is the quality standard for something made with AI? The answer that holds is that the output is what matters at the end of the day: users care whether it is good, and so should builders.

The second mistake is treating rule compliance as quality, which Christopher Alexander warned against when he said a system can satisfy every rule and still be dead. A study of ninety interfaces generated by two AI tools across three application domains shows the trap in practice. The tools consistently achieved basic accessibility compliance, yet they relied on homogenized design patterns that limited how well they served specialised user needs.

The researchers counted 178 instances of participants accepting requirements without question and 41 cases of pairs rejecting new ideas because they diverged from the initial ones.

Practitioners interviewed about that critique found it often misguided or lacking context, and reaffirmed the value of design systems. Another study notes that the limitation can be an asset, freeing designers to get more creative with problems the system does not solve. Design leaders still describe a real tension: they depend on people who work within system constraints, yet when hiring they value those who challenge assumptions and propose unexpected solutions.

Figure 4. The two available endings to the AI building boom, and the four visible habits that distinguish a Renaissance team from a zombie factory.

Pruitt-Igoe, the St. Louis housing project often cited as the failure of modernist design, was heralded by Architectural Forum as the best high apartment of 1951, and its demolition began in 1972. Historians argue it was not primarily a failure of design: economic and political conditions, public policy and the decline of the city shaped its fate.

Template to adapt: before anything ships, the editor answers three questions in writing: would a user prefer this to the best crafted alternative, what here could only come from us, and who owns it six months from now. If any answer is blank, the work is built, not done.

Choosing a creative Renaissance over zombie UI

We are in another building boom, the AI building boom, and the choice in it is whether to make the digital equivalent of zombie buildings or a creative Renaissance. History offers both endings, which is what makes the choice real rather than rhetorical.

The object of design is no longer the screen but the system itself. That is why the choice is made upstream, in the point of view and the encoded standards, long before anyone reviews a single screen.

The guard at the other end is one sentence: refuse to confuse done with good. It works because it gives an editor permission to stop work that already looks finished, which is exactly the moment AI makes most tempting to skip.

A team that chooses the Renaissance has four visible habits: a written point of view, a system that ships templates and flows rather than parts, an editor with the authority to say not yet, and a protected budget for strange work. Gutenberg spent his savings on the sorts that made machine pages worthy of the hand, and Ruskin praised builders whose columns refused to repeat.

Key points

• The AI building boom repeats the postwar pattern: forms copied without intent produce zombie UI.
• Define a point of view, built by noticing behaviour, before any model touches the work.
• Design the system, not the screen: encode tokens, templates and flows into a harness the AI must go through.
• Built is not done and done is not good: one editor owns every decision, down to the pixel.
• Spend part of what AI saves on strange work, in its own lane, held to the same editorial bar.

Action plan

1. Run the consistency test: three people, one prompt, your current AI setup, then compare the outputs side by side.
2. Pick one written rule from your guidelines and encode it as a machine-checkable constraint your CI or agent runs.
3. Rename your semantic tokens by intent and give each a one-sentence description of when to use it.
4. Name one editor for your next AI-built release, give them the right to block it, and run a crit that ends in written instructions.

Test yourself

Q. Why can't you fix generic AI output just by raising the temperature or rewording the prompt?
A. Research finds diversity collapse persists even under high-temperature sampling and that simple sampling or prompting changes are insufficient, because the narrowing is likely rooted in alignment.

Q. What is the difference between documenting a design rule and encoding it?
A. Documentation explains the intent in words an agent may not follow; encoding expresses the rule as structured data with conditions, constraints and consequences that agents, linters and CI can check.

Q. Why name a token color.action.primary rather than color.blue.500?
A. An agent reads the name before it picks a token: an intent name states what the token is for, while an appearance name forces a guess between look-alikes.

Q. What does the history of Pruitt-Igoe warn product teams against?
A. Blaming the form alone: historians argue its failure was shaped by economic, political and institutional conditions, with the modernist design only one factor among several.

Open questions

• Who should hold the editor role in an organisation, and with what authority to stop work that is already built?
• How can teams of three find time for meticulous craft when speed is the reason they can compete?
• Who maintains the large volume of quickly built, AI-generated products over the long term?
• How can protecting the strange be squared with the brand consistency a design-system harness enforces?
• If the narrowing of model output is rooted in alignment, will fine-tuning methods that preserve diversity arrive, and what will they change for design work?
• Are design systems narrowing the creative skills the design profession develops, as some design leaders fear?

Go further

1. Good Accessibility, Handcuffed Creativity: AI-Generated UIs Between Accessibility Guidelines and Practitioners’ Expectations | Proceedings of the 2025 ACM Designing Interactive Systems Conference — A study of ninety AI-generated interfaces showing accessibility compliance alongside homogenized design patterns.
2. Verbalized Sampling: How to Mitigate Mode Collapse and Unlock LLM Diversity — The verbalized sampling paper: why aligned models collapse to typical answers, and a training-free prompt that restores diversity.
3. skills/governance-encoder/SKILL.md — A step-by-step skill for turning design-system governance rules into machine-checkable constraints for AI agents.
4. How to structure your design system for AI: tokens, naming, LLM-readable docs | DesignSystems.one — Concrete guidance on layering tokens, naming by intent and writing descriptions an agent can act on.
5. MCP server best practices – Figma Learn - Help Center — Figma's best practices for structuring files so an agent reuses your real components and variables.
6. InDesign, the hz-program and Gutenberg's secret — How Gutenberg used 290 types, mostly ligatures and abbreviations, to achieve his even justification.
7. The Nature of Gothic and Modern Oblivion | Church Life Journal | University of Notre Dame — Ruskin's own list of the characteristic elements of Gothic, from savageness to redundance.
8. Why Did Pruitt-Igoe Fail? — A short account of why Pruitt-Igoe failed, beyond the popular story that blames its modernist architecture.