The situation
The gap between a design file and shipped code has never really closed. Designers hand off Figma files; developers rebuild them as components. Redlines, specs, and tools like Code Connect help, but parts of the translation still happen by hand: a state nobody specified, a token guessed by eye, a component rebuilt because finding the approved one took too long.
Then AI coding assistants entered the workflow.
They were fast, but they worked from whatever context happened to be nearby: the open files, the repository, and the model's general knowledge of how interfaces are usually built. BMW's design system, Density, was not part of that context.
So an assistant could produce a button. It compiled. It looked close. But it was not the approved component, it did not use the defined tokens, and nothing in the workflow would flag that anything had gone wrong.
That is a different failure mode from a developer knowingly taking a shortcut. A developer usually knows when they are deviating from the system. An assistant can improvise confidently, at speed, across every file it touches.
The knowledge that would prevent this already existed. It lived in four places: Figma libraries, implemented components in the codebase, partial design-to-code mappings through Code Connect, and written documentation in a separate web application. Someone experienced could navigate that. An assistant could not, and neither could someone new to the system.
Fragmentation was manageable while humans did the searching. It became a design-system risk once machines started generating interfaces at speed, across an estate where Density is the standard for an estimated two to three thousand applications.
The problem was not missing knowledge. It was that the knowledge had no route into the AI coding workflow.
Fig. 1: Density knowledge sat across fragmented sources: Figma libraries, codebase components, Code Connect links, and a documentation site. It was reachable if you already knew where to look, but not from the AI workflow itself.
A design system is published to be read. This one had to answer questions
A design system is usually built for people. You publish a documentation site, write usage guidance, maintain a component library, and expect designers and developers to look things up.
An AI assistant does not work that way. It does not browse your design-system site unless the workflow gives it a way to ask. It works from context. So there were three realistic options:
- Paste the documentation into the prompt. Fine for a demo, but useless at system scale and stale the moment guidance changes.
- Bake it into the model. Expensive, slow to update, and wrong as soon as tokens or components move.
- Let the assistant query the design system at runtime. Current by design, because the answer comes from the source when the assistant needs it.
The Model Context Protocol made the third option practical. It gave us a standard way for an AI client to call an external service for context during the task.
That changed the design-system question. The goal was no longer only “how do we publish guidance for humans?” It became “how do we expose Density so a workflow can ask a specific question and get back a usable answer?”
In late 2025, I could not find a major public design system exposing itself this way. I treated that as a signal, not a firstness claim: design systems were still mostly publishing for people, while the workflow was beginning to include machines.
I treated it as a retrieval problem, not a documentation problem
The obvious answer to “our design-system knowledge is scattered” is to consolidate the documentation. I argued against making that the first move.
The documentation was not the problem. Each source was useful in its own context, and each had an owner. The problem was that none of those sources were reachable from the place where implementation decisions were starting to happen.
So I framed the MCP as a retrieval layer with a defined product surface. It did not need to become a new documentation platform. It needed to answer the small set of questions that matter during implementation: search the documentation, retrieve component guidance, look up a token definition, and find an approved usage pattern.
This left the underlying fragmentation in place. Some people reasonably wanted the sources consolidated, and I chose to add a layer on top instead of fixing what sat underneath. I took that trade because a retrieval layer could ship in months, while a consolidation programme would have needed the roadmaps of four different teams.
Which component applies here?
COMPONENT GUIDANCE
What does the guidance say?
USAGE RULES
What is this token defined as?
TOKEN LOOKUP
What's an approved example?
USAGE PATTERN
The service had a defined retrieval surface, not an open-ended chatbot wrapped around documentation.
The product was the tool surface
The MCP was not the product because it used a new protocol. The product was the tool surface: what the assistant was allowed to ask, where the answer came from, and how a human could check it afterwards.
I kept that surface small on purpose. The service needed to answer the questions that actually show up during implementation:
- Find the right component — when a designer or developer describes a UI pattern, return the approved Density component that should be used.
- Retrieve component guidance — return usage rules, states, anatomy, and constraints for that component.
- Look up tokens — return the defined Density token instead of letting the assistant guess spacing, colour, typography, or elevation values.
- Find approved examples — return patterns that show how the component is used in context.
That boundary mattered. If the MCP tried to answer everything, it would become another vague AI layer. I wanted it to behave more like a design-system API: narrow, source-backed, and useful inside the moment where implementation decisions are made.
The output also had to be traceable. A useful answer was not just “use this button.” It needed to point back to the source: the component, the token, the rule, or the documented pattern. That is what makes the assistant's output reviewable by a human instead of merely plausible.
I built for any client, not for Copilot
GitHub Copilot inside an IDE was the workflow that made the idea concrete, and it would have been the fastest thing to build against.
I pushed for a tool-agnostic design instead, with MCP as the boundary, so any compatible client could call the same service. Enterprise AI tooling changes quickly. A knowledge layer welded to one assistant dies the day the approved assistant changes.
A Copilot-specific build would have demoed better and shipped sooner. Tool-agnostic meant a more abstract proof of concept and a harder pitch to people who wanted to see it working in the tool already installed on their machine.
Closing the design-to-code loop takes two sources, not one
Retrieval alone still leaves the practitioner doing the translation. You can get the right answer about a component and still have to connect it back to the screen you are building.
The useful workflow paired design context from Figma with design-system rules from Density, then kept human review in the loop.
The useful chain needs two sources arriving together:
- Figma MCP supplies the design context — what the frame is, which components it uses, and what state it is in.
- The design-system MCP supplies the rules — which approved Density component maps to it, how the tokens are defined, and what the usage guidance allows.
- The coding assistant implements against both sources in the product repository.
- A human reviews — the chain reduces translation loss, but it does not remove judgement.
What this replaces is a developer opening a Figma file, eyeballing the spacing, guessing the component, and writing something close enough. What it creates is an implementation path that can point back to approved sources.
I want to be precise about the ambition. This is not pixels-to-production. It is reducing translation loss. Code Connect had already mapped part of that path. The MCP made the rest of Density reachable inside the workflow where the implementation decision was happening.
The loop had more moving parts, and it depended on another MCP I did not control. I accepted that because one source alone would not solve the actual handoff problem.
The hard part: I had the idea and no engineering capacity
I was not the engineer on this. I had the product direction and no engineering capacity.
I found that BMW already had a team working on MCPs: the AI Delivery Factory. I networked into that team and first asked for pro bono help. They were interested, but they were also clear with me: goodwill would not survive capacity planning. If this was going to get real engineering time, it had to become official work.
So I pitched their manager and my Product Owner. My PO took it to their PO, and between them they made the work official. That is what unlocked three developers.
That was the real turning point. I did not need to own the engineering team. I needed to make the problem official enough that the right team could spend time on it.
Going through the partner team meant giving up direct control and accepting someone else's delivery cadence. It is also the reason there is a deployed service today instead of a prototype still waiting for time.
Working with a team I didn't manage
Three developers from the AI Delivery Factory built the server. My role during the build was to protect the user problem: define the retrieval use cases, answer context questions, bring design-system and workflow constraints into the room, and avoid making technical calls that belonged to the engineering team.
I did not write the server, and I would not describe myself as its engineer. What I can speak to is why it exists, what it needed to do, and how I set up the partnership so it could get built.
WHAT SHIPPED
- The concept, brief, workflow definition, and retrieval use cases
- Four retrieval capabilities: documentation search, component guidance, token lookup, and approved usage patterns
- A tool-agnostic MCP server, with proof of concept in January 2026
- A design-to-code workflow pairing the design-system MCP with Figma MCP inside an IDE
- Pilot in March 2026
- Deployment in April 2026
- First place in Mission Agentic, BMW's global competition for agentic AI tools and products, in August 2026
Four months from first pitch to deployment.
What it changed, and what I'd measure next
Density moved from static documentation into the workflow itself. Instead of relying on a human to find the right guidance and translate it into implementation decisions, an AI client could query the approved source at the moment the decision was being made.
The design system is the standard across an estimated two to three thousand BMW Group applications. That is the surface this was built for. It is not a usage count, and I will not present it as one.
What the work does show is that the problem was worth solving and the approach held up: it shipped, it deployed, and it took first place in an agentic-AI competition judged across BMW.
What I do not have yet is usage data: retrieval quality, time saved, support load moved, or implementation accuracy. If I picked this up again, I would define the evaluation set before the next pilot: retrieval relevance, source traceability, correct component selection, and time to a verified result.
That is not a footnote. It is part of the lesson. Deciding what counts as success after the fact is how teams end up with numbers nobody trusts.
What I'd bring to the next one
Two things, and they are connected.
The first is seeing when a discipline's infrastructure has to change. Design systems were built to be read by people. Once machines joined the workflow, that stopped being enough. The fix was not only better documentation. It was a protocol decision.
The second is getting work built without owning the engineers. I named a product where other people saw a documentation problem, then found the team that could make it real. My job was to hold the user problem steady and let the engineering team own the technical decisions.
I got that second part wrong at first. I asked for goodwill before I made the work official. The partner team told me plainly that goodwill would not survive their capacity planning, and they were right. That is the step I would take sooner next time.
I would rather ship something I don't own than own something that never ships.