A developer opens their code editor, asks an AI assistant to build a settings page, and gets one in about thirty seconds. It compiles. It looks reasonable. The quieter problem is that none of it uses the design system the organisation has already invested in.
That is the problem I started working on at BMW in December 2025. The work became a Density MCP, Density being BMW’s design system, and moved from an idea to a deployed service in four months. It later won first place in Mission Agentic, BMW’s internal competition for agentic AI tools. This post stays mostly with the problem, because many design-system teams are about to meet the same one.
What is actually happening
The assistant works with whatever context is nearby. It does not understand your organisation by default. It sees open files, repository patterns, and general UI conventions. If system guidance is not in that context, it fills the gap with something that feels standard to the model rather than standard to your product.
The failure is easy to miss. When a developer hand-builds a button instead of importing the system component, the choice is visible. When an assistant generates a plausible substitute, it can look close enough to pass: spacing roughly right, colour nearly right, component shape familiar. Nothing in the workflow necessarily tells the team that the system was bypassed.
At enterprise scale, that quiet drift compounds. Density is used across an estimated two to three thousand BMW applications. A small generated default does not stay small if assistants repeat it hundreds of times a week across teams.
Why a documentation site does not fix this
Most design systems already contain the knowledge an assistant would need. Density had Figma libraries, code components, Code Connect links between design and implementation, and written guidance in a separate documentation app. Each source was useful. A person who knew the system could move between them.
The issue was reach. An assistant does not pause mid-generation, open the documentation site, compare it with Figma, and check the component package unless the workflow gives it a way to do that. The knowledge was not missing. It was outside the place where the work had moved.
The system knowledge existed in trusted sources, but the AI workflow had no reliable route to ask for it.
FIG. 1 - KNOWLEDGE GAP
What “queryable” means
We looked at three ways to put design-system knowledge in front of an assistant. The useful distinction was freshness: does the workflow answer from the source, or from a copy that starts drifting the moment the system changes?
Paste the documentation into the prompt. Fine for a demo. It stops working once the system has more than a handful of components, and it is stale the moment the guidance changes.
Train it into the model. Expensive, slow to update, and wrong the day your tokens or components change. It creates a second version of the design system that has to be maintained beside the real one.
Let the assistant ask the design system while it works. This is the one that holds up, because the answer comes from the source. It changes the design system from something people only read into something a workflow can ask questions of.
The shift is simple: the design system becomes something a workflow can ask, not only something a person can read.
PASTE INTO PROMPT
Useful for demos; breaks down as soon as the system grows
TRAIN INTO MODEL
Slow to update; becomes a second design system that drifts
ASK AT RUNTIME
Answers from current sources while the work is happening
What to make queryable
We did not try to expose the whole system at once. We started with questions teams already ask when they are building.
Which component fits this situation? Given a described UI problem, return the component options, when each one applies, and why.
What does the guidance say? Usage rules, edge cases, and when not to use the component.
Which token should this use? The value, its purpose, and the kind of decision it supports.
What does an approved pattern look like? A known implementation example for a common composition.
We also paired this with Figma’s MCP so the workflow could read design context and system rules together. That did not make the assistant magically correct. It gave it a reliable place to ask before inventing, which is the gap that matters between a design file and the code.
What we were careful about
Five decisions mattered because a service like this can create false confidence if it is too eager to answer.
Not claiming more than we had built. The MCP improved the conditions for a better answer. It did not, on its own, guarantee governed output. That only comes from designing and testing the workflow around it.
Making sources visible. If an answer cannot show which guidance or component it came from, people stop trusting it the first time it is wrong.
Deciding which source wins. Documentation, design libraries, and code packages disagree more often than teams like to admit. The service needed clear rules for which source should win.
Being able to say there is nothing for this. Sometimes the right response is that the system has no approved pattern. A tool that always produces something teaches people to doubt everything.
Not tying it to one assistant. The approved assistant will change. The design-system service needed to be useful beyond one vendor or one interface.
Where to start
Ask an approved assistant to build something real in a real repository. Anything it invents instead of using is your first priority list.
Map where the design-system knowledge actually lives. It is usually spread across more places than the team remembers.
Start with the two or three questions people ask most, answered well, rather than trying to expose the whole system at once.
Where this leaves design system teams
For a long time, design-system work has meant publishing good material and helping people find it: documentation, libraries, launch comms, training, office hours, and channels for questions. That work still matters.
Now there is another audience in the workflow. It does not read docs or attend training, but it may generate interface code all day. Reaching that audience is becoming part of the job of running a design system, because AI-assisted delivery still needs governed design-system context.