Generative UI is a design problem

The biggest shift in interface design since responsive layouts is happening right now, and most design engineers are not ready for it. Generative UI — where a language model assembles interfaces at runtime instead of developers coding them at build time — is moving from experimental to production. I have been watching this pattern emerge across products I use and build, and it changes what "design" actually means. I wrote about taste tools as market signal a few weeks ago, and generative UI is the reason those tools exist.

On this page

• What is generative UI?
• Why generative UI is different from vibe coding
• What changes when the UI assembles itself
• How design engineers keep things from breaking

What is generative UI?

Generative UI is not another build-time tool like v0 or Figma Make. Those generate code at design time — you prompt, you review, you ship. Generative UI generates the interface at runtime, per user, per session. The same product, different UI depending on what the user is trying to do. Perplexity already works this way: ask for a comparison and you get a table, ask for a location and you get a map, ask for a timeline and you get sequential cards. The backend is the same. The interface adapts.

This is not a hypothetical future. Gartner predicts that by 2028, 80% of generative AI applications will be built on existing data management platforms, and the interface layer is where users will feel that shift most. If you build products, you will eventually need to think about how your UI behaves when it is no longer fixed.

Why generative UI is different from vibe coding

Vibe coding means you describe a screen and the model generates it. You review, you tweak, you ship. The output is static until you change the prompt and regenerate. Generative UI means the model decides which components to render at the moment the user asks for something. You never see the final layout during development because there is no single final layout.

That changes design from a specification activity to a constraint-definition activity. You stop designing screens and start designing the rules that govern how screens get assembled. Apple's Human Interface Guidelines have always emphasized principles over pixel specifications, but generative UI makes principles the only thing that travels. Your button color spec does not help when the model decides between rendering a button and rendering a card.

What changes when the UI assembles itself

Three things shift immediately.

First, your design system becomes an API. Every component needs defined inputs, output formats, and state behavior that a model can reason about. If your button component does not declare what intent it serves, the model has no basis to choose it over a link.

Second, quality assurance moves from visual review to constraint testing. You do not check whether the button looks right on the page. You check whether the model chose the right component for the user's intent. Did it render a chart when the user asked for a list? Did it show a comparison table when the user asked for a summary? These are not QA questions you can answer by looking at a mockup.

Third, brand consistency becomes a governance problem rather than a design problem. The Autodesk State of Design & Make: AI Pulse report surveyed 2,500 leaders and found that organizations turning AI into value are the ones investing in governance and standards — the unglamorous infrastructure work that makes adaptive systems predictable. Brand in a generative UI world is not a set of visual rules. It is a set of decision rules that constrain what the model can produce.

How design engineers keep things from breaking

The teams shipping generative UI today share a pattern. They define component envelopes — predictable surfaces that the model can fill but not modify. They build intent-to-component mappings that constrain what the model can render for each query type. They run automated audits that flag UI generation choices outside acceptable parameters. The work looks less like Figma and more like systems engineering.

That sounds like a loss of creative freedom, but it is the opposite. When you define the rules, you shape every possible output. The model becomes an execution layer for your design decisions rather than a replacement for them. The design engineer's job in 2026 is not to produce screens. It is to produce the intelligence that generates good screens at scale.