AI Design Tools vs Design Systems: The 15-Minute Floor
All three approaches produced UI. That is the low bar. The question I was actually testing: can any of them produce UI that uses my token names, my component names, my spacing scale, without me correcting it line by line afterward?
I ran three different setups against the same brief. Figma Make with my design system available via prompts. Claude + Figma MCP connected directly to my Figma file. And a custom multi-agent architecture I built with Sonnet and Haiku in parallel, with a local component library, an orchestration layer, and model-appropriate task routing. I spent real time trying to optimize that last one.
None of them broke 15 minutes for design-system-compliant, complex UI. But what I learned trying to break that floor is more useful than the benchmark itself.
The Brief I Tested Against
I needed something representative of real production complexity, not a landing page, not a hero section.
The brief:
- A data table with 4 sort states and a loading skeleton.
- A form with 12 field variants: text, select, checkbox, radio, date picker, error states, helper text, disabled states.
- A 4-level navigation pattern with active, hover, and collapsed states.
- A modal with two size variants and a confirmation variant.
The design system: a defined semantic token set (colors, spacing scale, border radius, typography), a component library with named components and documented variants, and a spacing scale in 4px increments.
My pass/fail criteria: correct token names, correct component names from the library, on-scale spacing values, semantic color system respected — error tokens for errors, warning tokens for warnings. Not visual resemblance. Implementation correctness.
Most comparisons stop at "does it look right." I checked whether the implementation was right.
Figma Make: Fast, But Not Reading the System
Figma Make got to wireframe-level output in about 5 minutes. Even with my design system provided via prompts, the compliance was poor.
The layouts were reasonable. The token names were wrong throughout. Component names did not map to the library. Spacing values fell between scale steps. It looked like UI. It did not look like my UI.
Figma's own launch announcement said design system support was coming: "soon the ability to apply third-party database integrations and design systems will give your explorations form as well as function" Figma blog, May 2025. My September 2026 test confirmed that behavior had not changed. Make approximates from visual inspection of prompts, it is not reading your component and token structure.
Where Figma Make is genuinely useful: concept exploration and stakeholder walkthroughs where token correctness does not matter yet. Five minutes to a credible wireframe in the Figma ecosystem is a real advantage in that context. The moment production handoff is the goal, the approximation becomes the problem.
Claude + Figma MCP: The Reference Approach, Bounded by MCP Speed
This is the one that actually reads my design system.
The GLips/Figma-Context-MCP server (~15.9k GitHub stars as of September 2026) connects Claude to my Figma file directly. It is not inferring what my components are called, it is looking at the file structure. Real component names, real token values, real spacing rules.
When connected and working, the output used the right tokens. Component references matched the library. Spacing values were on scale. It was the most design-system-accurate of the three approaches I tested.
The time: 15 to 17 minutes per screen, every time.
I tried to improve this. Parallel processes. Parallel subagents. Everything I could think of to bring that number down. It did not move.
The bottleneck is MCP connection speed, not AI reasoning speed. The operations that read from the Figma file (traversing the component tree, resolving token references) run through the MCP server. Adding more agents does not help if they are all blocked waiting on the same connection. You can route independent components to separate agents, but you cannot eliminate the per-operation overhead.
The other limitation I hit: context length. My component library is large. At a certain point, the MCP server was truncating it, and Claude started approximating the parts it could not see. This is solvable by chunking the library or scoping what you pass, but it is overhead that does not go away on large systems.
When it worked fully, it was accurate. When context ran out, it started guessing. And it always took 15 minutes.
The Multi-Agent Approach: Maximum Optimization, Same Floor
I built a more elaborate setup to see if I could beat the MCP bottleneck by removing the dependency on it entirely.
The architecture: built all components locally in React, created a structured reference guide so Claude could fetch components directly. Added an orchestration layer that split work by complexity. Sonnet handled requirements gathering and the decisions that needed reasoning. Haiku handled background tasks in parallel. When I was still talking with Sonnet about a component's behavior, Haiku was already working on simpler adjacent elements. I have written separately about this orchestration pattern in Babysitting AI.
This is the kind of setup that takes real effort to build. Token-level reference in the prompt instead of MCP calls to Figma. Parallel execution. Model-appropriate task routing.
The result: could not break 15 minutes.
And a new problem appeared that the Figma MCP approach does not have: consistency. The same prompt, run twice, produced different output. Different component choices. Different token interpretations. Different spacing decisions. This was not random variation in phrasing, it was functional variation in how the design system got applied.
This matters more than the time floor. Speed is theoretically improvable as inference gets faster. Consistency is a different kind of problem. If you cannot predict what you are going to get, you cannot build a reliable production workflow on it.
The token cost was also significant: 200,000 to 500,000 tokens per complex screen. At Claude API pricing, that is a real budget line if you are planning to run this at scale. It is not prohibitive for individual use, but it accumulates fast in a team context.
The 15-Minute Floor
Three architectures. Three different approaches to the same problem. Same result.
That convergence tells you something: the time is not in the generation. Generation is fast. The 15 minutes is in coordination and verification, making sure the output actually uses the right tokens, the right components, the right spacing. Even with the most optimized setup I could build, that verification overhead did not compress.
One practitioner reports that "what used to take 50+ hours to hand-code now scaffolds in 15 minutes" UXTools, October 2025. I think that is accurate for overall project scaffolding. What I found is that a single complex, design-system-compliant screen takes 15 minutes. Those are different claims, and the distinction matters when you are planning a workflow.
The Coinbase team reduced implementation time 22.3% and overall cost 22.5% by using Code Connect to give AI agents direct access to code-connected component definitions Figma blog, September 2026. That is the reference approach taken further than MCP, not just reading the Figma file, but mapping components to their code implementations. I have not tested that path yet. It is the most likely way to move the floor.
Approximation vs. Reference, Still the Dividing Line
Stepping back from the time data, there is a cleaner frame that explains most of what I found.
Approximation: the tool generates output from training data and whatever descriptions you provide. It produces something plausible, component names that follow patterns it has seen, token names that sound right, spacing that looks close. It is extrapolating from a general model of design systems, not from your system.
Reference: the tool reads the actual structure. Claude + Figma MCP reads the Figma file. The multi-agent approach with a local component library builds the reference directly into the prompt context. Both are working from your actual data rather than guessing at it.
The trap with approximation is that it looks identical to reference at the prototype stage. Both produce UI that renders. The errors live in the implementation layer, token names that do not exist in the codebase, component names that do not map to anything, spacing values that fail a design system audit.
46% of design system teams are now experimenting with AI, up from 36% in 2025 Zeroheight Design Systems Report 2026. But only 7% report full adoption across all teams, with 31% at wide adoption. AI approaches that introduce token and component drift make that adoption gap harder to close, and approximation does introduce drift, consistently.
The Failure Modes That Matter to Designers
These are the specific failure classes I documented. Approximation-based approaches produced them most consistently; the reference approaches hit them only when context ran out.
Invented Component Names
The tool generates PrimaryButton when the system uses Button/Primary. Different things in a codebase. Visually identical in a prototype.
Wrong Semantic Color Tokens
Warning colors applied to error states. Palette values nearby, implementation wrong.
Off-Scale Spacing
I saw 13px, 17px, and 19px values. My spacing scale runs in 4px increments. These fail a design system audit.
Hallucinated Icon Names
The Coinbase Code Connect case study specifically notes that AI agents were "hallucinating illustration and icon names," a problem that "disappeared overnight" after adopting Code Connect Figma blog, September 2026. I hit this with the approximation approach, icon names that looked valid but referenced icons that do not exist in the library.
These failures are invisible in demos. They show up in code review, in design system audits, and in the gap between what a designer expected and what shipped.
"Production has become cheaper than UX evaluation," NNG wrote in August 2026 NN/g. That describes exactly what I kept running into. Output generation is fast. Catching these failure modes is not.
When to Reach for Each Approach
Two variables determine the right tool: how much design-system fidelity the output needs, and whether you need a prototype or production code.
Stakeholder prototype (low fidelity, stays in Figma): Figma Make. About 5 minutes, credible visual output, no code. Good when you need to show a concept before you know whether the design direction is right.
Production code scaffold (high fidelity, code output): Claude + Figma MCP if your Figma library is well-organized and you can manage context length. More consistent output, better speed than the multi-agent approach. Multi-agent React if you want to build the reference into local files. Comparable quality and time, but consistency is an open problem and token cost adds up.
Fast concept with code (low fidelity, code): Claude standalone with a DESIGN.md file is the logical option here. I have not tested this in the same structured way, but it is in scope for a follow-up.
What Is Not Solved Yet
Context persistence is still a problem across all three approaches. Claude + Figma MCP requires the MCP server reconnected at the start of every session. The multi-agent setup requires the reference guide re-loaded. Nothing persists design system context automatically between sessions. Every session is a setup session.
The consistency problem is harder to solve than the speed problem. A 15-minute floor with consistent output is a workflow you can plan around. A 15-minute floor with variable output means you are reviewing and correcting after every run, and that review time is not free.
These are not complaints. They are the current state. The tools are improving fast. But knowing where the current state actually is, not where the marketing materials say it is, is what helps you plan the right workflow today.
Frequently Asked Questions
Why can't you speed up Claude + Figma MCP with parallel subagents?
I tried. The bottleneck is not AI reasoning speed, it is MCP connection speed. The operations that read from the Figma file run through the MCP server, and adding more agents does not eliminate the per-operation overhead. You can route independent screen sections to separate agents, but each one still blocks waiting on its MCP calls. The bottleneck is not where you would expect it to be.
Does Claude with Figma MCP produce design-system-compliant code?
More reliably than the alternatives, with caveats. It reads real component names and token values from the Figma file. The limitations I hit were context length (large libraries get truncated, approximation creeps back in at the edges) and session persistence (the MCP connection does not survive between sessions). Within those constraints, the output quality was the best of the three approaches I tested.
Is Figma Make useful for complex multi-state UI?
For exploration and stakeholder walkthroughs, yes. For design-system-compliant production handoff, currently limited. Figma's own documentation lists design system support as a future feature. My test confirmed it is still approximating from prompts rather than referencing your token and component structure. The output looks good; the implementation layer is not yours.
Is the consistency problem specific to multi-agent setups?
It was most visible there because more variables mean more variation. But it is a general property of stochastic models, the same prompt will not always produce the same output. The multi-agent approach amplified this because each layer of orchestration adds another source of variation. Claude + Figma MCP is more consistent within a single session, but sessions do not persist, so you are starting fresh each time anyway.
Conclusion
The 15-minute floor held across every approach I tried, simple, sophisticated, and everything in between. That consistency tells me the bottleneck is not the architecture. It is the verification layer. Getting complex, design-system-compliant UI right takes time, regardless of how cleverly you route the work.
Approximation vs. reference is still the clearest frame for evaluating these approaches. Reference approaches, Claude + Figma MCP, multi-agent with a local component library, produce more accurate output than approximation. They do not save time. They redirect where the time goes, from correcting token names afterward to managing context and consistency upfront.
Before picking a workflow for production use, two questions: is this approach working from a reference or a guess? And can I count on it to produce the same output twice?
I am still looking for something that answers yes to both. What are you running into?