A design system that an AI can read

A design system tends to exist three times. Once as a Figma library, once as the code that implements it, once as documentation describing both. Each copy has a different owner and a different update cadence, so they drift. Add an AI assistant to the workflow and there is a fourth copy, because the model needs an instruction set and somebody writes it by hand.

MDS 2.0 was an attempt to collapse that into one thing. A token architecture in Figma, bound to the Flutter codebase through Code Connect, with component rules written in a form a model could read directly. Not a library plus docs plus prompts. One artifact with several outputs.

I owned the color foundation, the component-state variable matrices, and the Code Connect mapping for the button set. Most of my time went to the seam between those, which is also where all of the arguments were.

A component library, its documentation, and a model's instruction set are one artifact rendered three ways. Most teams maintain three.

Seven named tonal ramps at thirteen stops each. Nothing consumes a raw palette value. Semantic theme roles alias into the ramps, and every role carries an explicit light assignment and an explicit dark one, so a theme swap is a lookup rather than a redesign. Elevation is authored twice for the same reason.

Material 3 gives you primary, secondary, tertiary and error. It does not give you success, warning, danger and info as themed roles, so teams invent them per screen and the greens stop matching. We promoted all four to first-class themes with full light and dark pairs, in design and in code. That means leaving the spec, and every future Material upgrade now needs a reconciliation pass. It was still cheaper than the alternative, which was status color as folklore.

About 1,830 variables across nine collections. The split matters more than the count: primitives separated from semantics, semantics separated from component-state matrices, and one collection built purely to serve the codebase rather than the canvas. Component interaction state runs off variable modes instead of hand-built variants. A text input resolves fifteen bound properties across five modes, so the stroke walks from outline to primary to danger by state and the floating label is a boolean, with no duplicated variant holding either.

Code Connect maps one Figma button set to five Flutter symbols, including a named constructor. The mapping targets Flutter's `ThemeExtension` classes rather than bespoke wrapper widgets.

That choice has a visible cost. The snippet Dev Mode hands an engineer is a plain `FilledButton(...)`. Nothing in it names the design system, which makes the handoff demo look like nothing happened, and it means adoption cannot be audited by reading a screen. It is also correct: theming belongs in the theme, not in a parallel widget layer somebody has to keep in step with the framework.

The spec board and the sandbox are deliberately separate objects. The master variant set is locked. Next to it sits a playground of roughly sixty rendered permutations including a disabled state for every style, because the question a developer actually has is not what the spec says, it is what this looks like when it is off.

FORGE is the pipeline built on top. Three ingest paths converge on one representation: analysis of legacy screens, the proven path from Figma files already built out of MDS components, and an R&D path starting from prompt-generated HTML. All three produce the same enriched JSON. Per-component skill files are what the model reads, and those files are treated as source of truth rather than as prompt scaffolding.

The enrichment step is what made it work. Raw Figma JSON is mostly noise for this purpose. Enriching and reducing it cut the parse payload from roughly ten thousand lines to roughly one thousand, which is the difference between a model holding context for a screen and a model holding context for a button.

Which model runs is a controlled variable in the design rather than an implementation detail, so output can be compared across models instead of argued about.

Code Connect was wired and reporting connected. The artifact I can show is the panel rather than the `figma.connect()` source file, so that is the limit of the public evidence.

FORGE's enrichment step reduced the raw parse payload from roughly ten thousand lines to roughly one thousand. End-to-end Flutter generation was not feasible when I last worked on it, output quality had not been benchmarked, and adoption was not instrumented.

If I returned to it, I would instrument adoption first. A design system cannot improve a workflow if nobody can answer whether it is being used.