Your design system documents appearance. It needs to document intent
I asked an assistant what was on my calendar that afternoon, and it told me. A meeting from two o'clock to two thirty, in a room on the fourth floor, with four people I work with, and a link to join if I was not going to be in the building. Every detail was correct.
It arrived as five lines of labeled text. When, and then the time. Where, and then the room. Who, and then the names.
That same meeting, inside the product those four people actually use every day, looks nothing like that. There is a component for it. It shows the time already converted into whatever zone you happen to be sitting in. It checks whether the room is genuinely free and says so when it is not. It has a button to accept. It went through an accessibility review, which is why a screen reader announces it as an invitation instead of reading out a run of field names. It took weeks to get right.
Both of those things came out of the same organization. The labeled text is what an assistant produced when it had that entire system available to it and had to decide what to show me.
Nothing broke here in the way broken things usually look. The assistant was perfectly capable of drawing the invitation. It did not know that it should.
The question every new standard answers, and the one none of them do
For most of the past few years, an AI assistant replied to you in words, and the only design question was how to format a paragraph. That is changing quickly. Assistants can now hand back an actual piece of working interface: a card with buttons on it, a map, a form you can fill in, rendered right there in the conversation. The industry calls this generative UI, and over the past year a set of standards has grown up around it in a hurry.
Read those standards next to each other and a pattern shows up. They are all careful, detailed answers to the question of how an assistant draws something. Almost none of them touch the question of which thing it should draw.
Start with the Model Context Protocol, the shared convention that lets an assistant talk to services it did not ship with, like your calendar or your company's own tools. Its Apps extension, specified in January 2026, defines how an assistant can return a piece of interface rather than a paragraph, and lets the surrounding application pass down its own colors, type and corner radius so the result does not look like a foreign object dropped into the page. What the specification deliberately declines to provide is a component library, and it says why: no single library works across every place these things get displayed. That is a defensible call. It also means the document has a great deal to say about how a returned interface should look and nothing whatsoever about what it should be.
OpenAI's Apps SDK went further and shipped actual components. There is a list, a map, an album, a carousel and a shop layout, along with three ways to present them: inline in the conversation, fullscreen, or tucked into a corner while something else runs. The planning guidance that comes with them asks builders genuinely useful questions. Is this something a person only reads, or something they edit? Should it remember where they left off when they come back? Those are the right questions to ask. Every one of them gets answered by a human being, in advance, before anyone has typed a request.
The half of a design system that nobody ever wrote down
A design system carries two kinds of agreement, and it has only ever published one of them.
The first is about rendering. What a component looks like, what states it has, how it behaves at small sizes, what it must do to satisfy an accessibility review, what you are not supposed to do with it. That agreement is documented exhaustively, in every mature system I have seen, often to the point of being more documentation than anyone reads.
The second one needs a name, so I will call it the selection contract: the rules that decide which content belongs in which component. Whether a set of facts becomes a card or a list row. Whether a status becomes a badge or a line of text. Whether four people and a time become an invitation or a table.
I have never seen that written down. Not in a system I have worked on, and not in a public one. It lives in designers' heads, and it comes out in critique, in the moment, in response to a specific screen someone is holding up.
There is a good reason it stayed there. Somebody was always in the room. For as long as design systems have existed, a person has sat between the information and the screen, every single time, and that person had context, judgment, and the ability to ask a question if they were unsure. You do not write down the part a person is reliably going to supply.
The size of that unwritten half is easy to underestimate. On a system serving a couple hundred internal products, the most expensive thing my team gave away was never help using a component. Teams could read. It was answering the question of which component something should be. Those conversations filled office hours week after week, they stretched design reviews, and almost none produced documentation, because every answer felt like it belonged to the one situation that prompted it.
What disappears when the designer leaves the room
Generative UI takes that person out of the room at the exact moment they were doing the most work.
The arrangement now gets decided per request, by a machine, against information nobody has previewed, for a person nobody has met. There is no critique. There is no one to ask. Whatever was tacit is not weakened or approximated in that moment. It is simply not present.
Which brings the meeting back around. The assistant that handed me five lines of labeled text was not weighing the invitation component against plain text and choosing plain text. The invitation was never in front of it as an option. The system it was drawing from had published, in great detail, what that component looks like, and had published nothing at all about when something is one.
The best case for doing nothing
The strongest argument against all of this is that it is a problem with an expiry date, and I want to put it as well as someone who believes it would.
Models are getting better at interface work quickly, and hand-written rules have lost to general capability before, in field after field. Writing down a system's current opinions in a form a machine follows means committing to this year's patterns and carrying them into next year's product, and those opinions will need governing, with the same drift, the same review burden and the same slow rot that every component library already suffers from. There is a sharper version of the worry too. A designer having a bad day produces one bad screen, and somebody catches it in critique. A bad selection rule produces ten thousand bad screens quietly, and nobody is looking at any of them.
I should also say plainly that I cannot point to a study measuring how often a model picks the component a design team would have picked, because nobody has defined what picking correctly means well enough to measure it. My case rests on the shape of the problem rather than on a number, and that is a weaker place to stand than I would like.
Here is why I think the objection still predicts the wrong failure.
Suppose a model chooses well nine times out of ten. On any individual screen that is a good result, and probably better than a rushed human would manage. But a person using a product does not experience one screen. They experience the same kind of information ten times across a week, and in those ten encounters they see something arranged ten slightly different ways, none of which is wrong. The thing a design system actually sells is that the eleventh visit feels like the tenth, and that promise does not survive being right ninety percent of the time.
Design systems did not come about because designers could not draw a button. They came about because forty designers each drawing a perfectly reasonable button produce forty perfectly reasonable buttons, and a product that feels like forty products. Every one of those decisions was defensible on its own. The author has changed, and the arithmetic has not.
What the rules would actually have to say
If a selection contract is going to be written down, two things have to be in it, and neither is a thing design systems document today.
It has to start from what the content contains, not from what the person was trying to do. Not "the user wants to schedule something" but "this has a start, an end, a place and a list of people." What something contains can be checked. What someone intended has to be guessed, and guessing is precisely the thing you were trying to take out of the process.
And it has to state the conditions in the open. A card earns its boundary when the content inside it is independently actionable. A list row is the right answer when the value of the content comes from comparing it against what sits above and below it. Those sentences get said out loud in critique constantly. They have never once been written into a documentation site.
Where the contract lives matters as much as what it says. A documentation page is built for a person reading at design time, with an afternoon to spend. Something assembling an interface at the moment a request arrives needs to be able to ask a direct question and get an answer with a reason attached. Part of this is already happening: shadcn's registry server lets an assistant search a component library, including a private company one, and pull a component in from a plain-language request. That solves the problem of finding a component. It does not touch the problem of choosing one, and choosing is the half that carries the design opinion.
There is a test for your own situation, and it takes about twenty minutes. Take three screens your team shipped recently and go block by block, asking why each one sits in the component it sits in. If you can answer in a sentence a stranger could act on without knowing your product, you have a selection contract already and it simply has not been typed up. If the honest answer is that this is how you do it, then whatever assembles your product next year will produce something defensible and unrecognizable, faster than any review process you currently run.
Conclusion
The standards that have arrived for AI-generated interfaces have settled how something gets drawn and left almost untouched the question of what to draw. That second question used to be answered by a designer at the moment of composition, which is exactly why no design system ever wrote it down: someone reliable was always going to supply it. Nobody supplies it now. A design system that publishes its components and its appearance rules while leaving its selection logic in people's heads will watch its own components get used correctly by coincidence. The work worth starting is unglamorous. Write down which content belongs in which component, with the conditions stated in the open, and put it where a screen actually gets assembled.
