Predictable → Uncertain Layout

Traditional layout is a contract between the designer and the content. The designer knows what’s going in the box — a product title (short), a description (medium), an image (fixed ratio). The layout system enforces that contract. Grid, flexbox, spacing tokens — all designed for content whose shape is known at design time.

AI output doesn’t honor that contract.

The Shift

You don’t know if the response will be ten words or a thousand. You don’t know if it’ll contain a code block, a table, a list, or just prose. You don’t know if there will be inline citations, embedded images, or suggested actions mixed into the text. You might not even know if a response is coming at all — the model might decide it needs to ask a clarifying question instead.

Layout has to negotiate with content it hasn’t met yet.

This isn’t just “make it responsive.” Responsive design adapts to viewport size — a known variable. Uncertain layout adapts to content shape — an unknown variable. The container doesn’t just resize; it restructures. A response that’s mostly code might need a different layout than one that’s mostly prose. A response with high confidence might be compact; one with low confidence might need room for caveats, citations, and alternative suggestions. The layout system needs to be comfortable saying “I don’t know what’s coming, and that’s fine.”

One practical approach emerging: instead of generating UI on the fly (which is still too slow — current models take 60+ seconds to produce a usable interface), teams are building large pattern libraries — hundreds or thousands of pre-built UI patterns, indexed and vectorized — and letting the AI select the right pattern for the context. Early research suggests that out of a thousand available patterns, users are successful and happy with about twelve. The layout isn’t generated. It’s curated by AI from a library designed for uncertainty. That’s a pragmatic middle ground while fully generative layout catches up.

Here’s another useful reality check: we still haven’t solved localization well. After decades of building for the web, most design systems struggle with text that doubles in length between English and German, or changes reading direction entirely in Arabic and Hebrew, or breaks in unexpected places in CJK languages. Line heights, text overflow, button widths, truncation — these are known variables in known languages, and they still cause layout bugs in production every day. If we can’t reliably handle a translated label, we’re a long way from handling an AI-generated UI block whose content, structure, and length are all unknown at design time. Uncertain layout isn’t a future problem. It’s a current problem we haven’t solved at a much simpler scale.

Where Systems Stand Today

Material has the strongest responsive story — window size classes, canonical layouts (Feed, List-Detail, Supporting Pane). Fluent’s slot system gives compositional flexibility. But neither has layout primitives that respond to content uncertainty. Both assume someone knows the shape of what’s being rendered before it renders. See the system pages for how this scores out.

What Pushes a Score Up

Fixed layouts for known content are a 3. Responsive containers that negotiate with content of unknown shape — ten words or five hundred, code or prose, with or without images — that’s a 7. The system has to be comfortable not knowing what’s coming.