Turning an existing design system into something an AI agent can read and build from — accurately, and without babysitting every output.
This case study is shared privately. Message me for the password, or enter it below if you already have one.
Incorrect password. Try again.
Token usage to generate a full page dropped from over 50% of a session budget to under 10% once structured specs were in place. Roughly 50 components converted into matched machine specs, human docs, and live demos — following a single repeatable process that the team now uses to extend the system independently.
I started this project to find out whether AI could be meaningfully integrated into our design workflow, and if so, how. As AI tooling started appearing across product teams, including Figma-to-code generation using Claude skills and MCP connections, I saw an open question no one had answered yet: could our existing design system actually support it?
Lunar, our existing design system, was built the way most are: a React component library, styled through a bespoke CSS bundler, documented in Storybook, with Figma as the source of truth for high-fidelity design. That structure works well for human designers and engineers, but not for an AI agent.
Early tests made the gap obvious. Without deliberate structure, an agent generating UI from Lunar would burn over 50% of a session’s token budget just inferring what the design system allowed, and the output was inconsistent from one generation to the next — sometimes correct, sometimes quietly wrong in ways a human reviewer had to catch by eye.
I defined an agentic design system as one where tokens, components, and layout patterns are structured for an AI agent to read and build from reliably. Lunar’s existing documentation was written for human designers and engineers; this needed to be built for a reader that couldn’t infer intent.
In practice that meant two layers: a set of AI-readable markdown files encoding Lunar’s components, tokens, spacing, typography, interaction rules, and constraints (written to minimize token usage and set clear boundaries on agent behavior), and a set of Claude skills that reference those files to generate, check, and refine UI output, whether that output was a Figma design or production-ready React code.
I led the conversion of Lunar’s Figma component library into the new spec format — eventually covering roughly 50 components, from Button and Badge through Dialog, Datatable, and the full menu family. Each component went through the same five-step pipeline: pull the Figma variant matrix and variable definitions, map Figma variables to semantic CSS tokens, write a machine-readable JS spec (frozen exports for meta, anatomy, variants, color/sizing/typography/motion tokens, and accessibility rules), write a matching human-readable doc, and add a live CSS demo. A strict rule ran through all of it: semantic tokens only, never a hardcoded hex value or raw pixel — if a value had no token, that was a signal to raise it, not work around it.
One of the largest sources of token waste in early tests wasn’t component lookup — it was structure. An agent rebuilding a full responsive page layout from scratch on every generation consumed a significant portion of the session budget before a single component was placed.
The CAP Shell templates addressed this directly: pre-built HTML files with pre-defined responsive rules, structured so an agent could duplicate one and fill in the content body without reconstructing or re-deriving the surrounding layout. Rather than generating page structure from scratch each time, the agent works within a known, stable scaffold — which is what moved token usage from over 50% of a session to under 10%.
The responsive rules also gave designers something they didn’t have before: a way to preview and verify layout behaviour across breakpoints before anything went to development. Because the shell encoded the layout constraints explicitly, designers could spot responsive issues early and catch inconsistencies in how content sat within the grid — without waiting for a dev build. The CAP Shell became the consistency layer between AI-generated content and the final handoff, making sure layout decisions stayed aligned with Lunar’s standards from the first draft through to development.
I ran the whole initiative through a repeatable loop — Scope & identify, Setup & experiment, Test & refine, Document & share — with a check-in at every step and an explicit path to flag blockers early rather than let them surface at review. Progress was logged weekly from late April through July: tokens and component conversion in May, skills integration and a CAP Shell prototyping system in June, and a pilot rollout with a UI-prototyping guidebook in July.
Token usage to generate a page dropped from over 50% of a session to under 10% once real structure was in place — markdown-based token references, component-build rules, and reusable layout templates. Roughly 50 components now exist as a matched set of machine spec, human doc, and live demo, following one documented, repeatable conversion process rather than one-off effort per component.
The exploration proved the approach was viable. That process, along with the risk register, the CAP Shell templates, and the execution framework, was handed over to the design system team as the foundation to build on and maintain. The goal was to answer the question clearly enough that the right team could take it forward.
The goal was to prove that AI could work within an existing design system and leave a clear enough path for another team to maintain and extend it. Speed and automation were side effects. The real value was a shared vocabulary between the system and the AI, precise enough that correctness becomes testable: when an agent generates something, a reviewer can tell in seconds if it followed the spec.