Almost to the T

Almost to the T

Why this matters

A design lead pointed an AI model at a Figma file over MCP. It built the concepts almost exactly, and that was the easy part.

Almost to the T A design lead on our team pointed an AI model at a Figma file over MCP. What it built, what it cost, and why the list of misses is the real deliverable. A design lead pointed an AI model at a Figma file over MCP. It built the concepts almost exactly, and that was the easy part. Figma-to-code over MCP works well enough to change how designers work. The real findings are the token bill, the adoption gap, and the list of what it got wrong. That list is your design system backlog.

A design lead on our team pointed an AI model at a Figma file over MCP. What it built, what it cost, and why the list of misses is the real deliverable.

One of our design leads spent part of last Friday doing something I’d been hoping someone on the team would try. Another designer had a set of concepts for a custom report builder sitting in Figma. The lead pasted the Figma link into Claude with the Figma MCP connected and asked it to build the thing.

It built it almost to the T.

That’s their phrase, and they’re careful with phrases. The layouts, the hierarchy, the component choices, the states. It produced the design itself, in code, close enough that the gap was the kind you’d fix in a review rather than a rebuild. The next week they showed another designer on the team how to do it in their 1:1, which is my favorite kind of knowledge transfer: somebody sees something work, and the first thing they do is hand it to a peer.

It built the concepts almost to the T. The bill and the adoption are the rest of the story.

Here’s the rest of the story, because the demo alone would be misleading.

The token bill was real. They were running the most capable model and used a significant chunk of a monthly budget in one Friday session. We’ve since set up an overage process (more on that in this issue’s toolbox piece), and our finance partner is tuning limits per person every month until usage settles, higher for the power users and lower for the rest. All of that argues for planning the heavy sessions instead of stumbling into them.

Adoption is still a handful of people. Two designers have tried it beyond the original experiment. Most of the team doesn’t have the MCP connected even though they have access to the model, which tells me the gap is more of a setup-and-confidence gap than an access gap. The plan that came out of our design leadership meeting: the lead posts the experiment to the design hangout channel, shows exactly what got built from their colleague’s concepts, asks who else is experimenting, and invites the people who know this best to weigh in. A couple of us follow with nudges so the post doesn’t sink. It’s low ceremony on purpose.

The design system is the real finding. It worked as well as it did because the file was well structured and our system is in decent shape, and where it missed, that’s probably the same story told from the other side. Our design systems partner offered real-time education to anyone who wants it, and the leadership team left with the question I think becomes the workstream: is the system actually giving the MCP what it needs? Where a human reader fills a gap with judgment, an agent fills it with a guess.

What I’d tell anyone trying this for the first time: pick a real file rather than a toy, budget the session like a workshop, and write down what it got wrong, because that list is the design system’s backlog. The concepts getting built almost to the T is the headline, and the list of “almost” is the work.

The teachable part

Figma-to-code over MCP works well enough to change how designers work. The real findings are the token bill, the adoption gap, and the list of what it got wrong. That list is your design system backlog.

Filed under ML Maker's Log — Process, visible.