In September 2025 a research lab called Thinking Machines published a small experiment. They asked a language model the same question a thousand times. Not a thousand similar questions: the identical question, with the model's randomness setting turned all the way down to the position that is supposed to make it answer the same way every time.
Among those thousand responses were eighty different answers.
Most started identically. All thousand were word-for-word the same for roughly their first paragraph, and then they began to fork. The cause had nothing to do with the model being creative. It works a bit like adding a long column of numbers on a calculator that rounds at every step: add them in a different order and the total comes out slightly different. Servers add things in different orders depending on how busy they are, because requests get processed in batches and the batch size keeps changing.
So the answer you get depends, in a small but real way, on how many strangers happened to be typing at the same time you were.
Nobody designed that. It is noise from the plumbing. For the last two years that noise has only touched the words in an answer, which is survivable. It is about to start touching the layout.
An interface is two things, and only one of them has changed so far
It helps to split an interface into two parts that vary independently. The scaffolding is the structure: where the answer shows up, what container it sits in, what order things appear in, what actions sit underneath. The content is what fills that structure: words, numbers, images.
For most of software's history both were settled before a user arrived. Conversational products broke the content half of that: it now shows up per request, written on the spot, unpreviewed. Design system teams handled that with a familiar kind of engineering, meaning components that hold up whether the text is three words or three hundred, overflow rules, loading states, empty states.
You can see that thinking laid out publicly. OpenAI's design guidelines for the app interfaces inside ChatGPT read like any host system's rulebook. Use our type, not yours. No more than two primary actions on a card. No scrolling inside something that already scrolls.
Notice what those rules have in common. They all govern what goes inside a box, and they take for granted that the box exists, in a known place, at a known size. That is why the last two years were survivable: design systems absorbed generated content by getting better at filling a container that never moved.
The next change takes the container away
In November 2025 Google shipped the first serious version of the other thing. Its generative interfaces, in the Gemini app and in Search, do not pick a layout from a set of prepared ones. For each response the model writes the interface itself: structure, styling and interaction, produced fresh for that one answer.
Which brings the opening story back around. Writing an interface is the same kind of work as writing a paragraph, done by the same machinery, on the same servers, in the same shifting batches. The noise that today reshuffles a sentence will tomorrow reshuffle a layout, and for the same reason: not because anything decided your screen should differ, but because of who else was online.
If you own a design system, that is a different category of problem from the last one. Generated content was a stress test on your components. Generated structure removes the thing your components were pinned to. Almost everything a design system promises, it promises by knowing in advance where things will be.
Why a screen that stays put is worth money
Designers usually defend consistency on grounds of craft or brand coherence. The stronger argument is that consistency makes people faster, and it is not a matter of taste.
When you look at a menu you have never seen, you read from the top until you find what you want, so your time scales with the length of the list. When you have used it a hundred times you stop reading and start reaching, because you already know your item is fourth from the top, and now the length of the list barely matters. Cockburn, Gutwin and Greenberg modeled both states at CHI in 2007: a straight line for the first, a curve that flattens out for the second.
The difference is not a fraction of a second on one click. It is that one of those costs keeps growing as the screen gets denser and the other one stops growing. On a five-item menu nobody cares. On an enterprise screen with fifty places to look, it is the difference between a tool people get fast in and one they never get fast in.
What decides whether a person ever crosses from the first state to the second is a factor those researchers call learnability. It runs from zero to one, and it measures how reliably the interface stays where you left it. A fixed layout scores a one. Run their equations on an interface whose items land somewhere new every time you open it and the score is zero, which means nobody ever crosses. Every visit is a first visit, and everyone stays on the line that keeps growing.
Mitchell and Shneiderman found the human version of this in 1989. They built menus that quietly reordered themselves so your most-used options floated to the top, which sounds helpful. Sixty-three people tried them. On their first twelve tasks the reordering group took about three minutes longer than the group with fixed menus. By the second twelve the gap had closed, because everyone had adapted.
Adaptation is the catch. The cost lands entirely on people who have not adapted yet, and in a product that assembles a fresh arrangement every session, nobody ever gets to finish adapting. Even after the performance gap closed, 81% still said they preferred the fixed menus, which suggests the irritation outlives the measurable penalty.
The best argument against everything I just said
If the arrangement is genuinely right for this person and this task, then consistency was only ever a rough substitute for getting it right, and you can stop paying for the substitute.
When Krzysztof Gajos and colleagues studied adaptive toolbars in 2008, they separated how accurate an adaptation is from how predictable it is, and found accuracy did nearly all the work. Raising the hit rate from 50% to 70% measurably improved how fast people reached a button. Making the algorithm more predictable, on its own, did not. Google's results point the same way, with human raters preferring its generated interfaces to ordinary chatbot answers.
Two things in Google's own writeup complicate that. Interfaces built by human experts still rated highest, ahead of the generated ones, though the team does not publish the margin. And they note their implementation could be configured to give everyone a consistent visual style, which makes consistency an option somebody switches on rather than something generation includes.
Then there is the problem from the top of this article. An adaptation that is right seven times in ten is a design decision with a measurable success rate, and a bad one can be studied and improved. Variance that comes from server load is not a decision at all. Nobody chose it, so nobody can improve it, and from the user's side of the screen the two are indistinguishable.
Better instructions have never fixed this, in any field
A few years ago developers had a persistent complaint about language models. When you asked for an answer in a specific format you mostly got it, occasionally you did not, and the failures were expensive. OpenAI's first response was to train a better model, and it worked: the new one returned the correct format 93% of the time, against under 40% a year earlier.
Then they shipped something alongside it. Not clearer documentation and not a better prompt, but a mechanism that inspects each word as the answer is being produced and refuses to allow one that would break the required shape. A wrong answer stops being unlikely and becomes unavailable. With that in place, the same model went to 100%.
Training took them from 40 to 93. Making failure impossible got the last seven points, and for anyone building on top of it those seven were the only ones that mattered, because a format that breaks once in every fourteen calls is a format you cannot build on.
That distinction, between telling a system what you want and making the alternative unavailable, is the one design systems have not absorbed.
Here is what it looks like in our own field. A design system team made their whole system machine-readable and wired it up so coding agents could pull real components on demand. Thousands of prototypes came out of it. When someone audited a sample, the components were right and the foundations were wrong: type sizes that were not in the system's type scale, spacing that matched nothing, colors nobody had approved.
The cause is not what you would guess. Those foundation rules were in the system, machine-readable and accurate and sitting right there. But the request was for a card, so a card came back, and nothing in that exchange required anyone to go look up the typography. Nobody did, and the gap got filled with a guess.
The rules were available. They were not binding. Nearly every design system in existence is currently on the wrong side of that distinction, and reporting itself as healthy.
What constraint costs, and where it stops working
Constraint is expensive, and the expense is paid in expressiveness. To make that format guarantee keepable, its builders had to shrink the range of formats you were allowed to ask for; rules along the lines of "this part is required, but only when that other part is present" stopped being expressible at all. A design system that genuinely constrains generation ends up similarly reduced. The rules it can enforce will be blunter and fewer than the ones it publishes today.
Constraint also has a ceiling. Researchers at CHI this year examined 300 model-generated interfaces and found 541 places where the result passed every automated accessibility check and still told a screen reader user nothing: alternative text reading "image," links announcing themselves as "click here." Structure can be forced. Meaning cannot, so part of this job stays human no matter how good the constraints get.
So here is a test, and it takes an afternoon. Go through the rules your system holds and name who enforces each one when nobody chooses the layout. Wherever the honest answer is "a designer, at the moment they arrange the screen," your system is not enforcing that rule. A person is supplying it, unpaid and unrecorded, and that works perfectly right up until the person leaves the loop.
Conclusion
Design systems got through the first wave of AI by making components stretch and tightening the rules for what goes inside a container, which worked because the container never moved. Generated layout takes that fixed position away, and takes with it the thing design systems quietly deliver most of: the speed people gain from knowing where things are. Writing the rules down more clearly will not bring it back, because a rule an agent can look up has never been the same as a rule it has to obey. What brings it back is narrowing what can be produced at all, which turns the deliverable from a library of components into a short list of things that may not vary, enforced where the screen gets assembled. That list will be shorter and blunter than the system you have today, and it is the price of a promise you can actually keep.
Sources
