Editorial note: Original analysis of the primary source below. No sponsor paid for or reviewed this story.

Figma’s September 2 account of Coinbase’s design system reports improved adherence to its components and an average 22.5% reduction in token costs in the team’s Code Connect experiment. The interesting point is not that a tool saved tokens in one test. It is that an agent with explicit links from design components to code has fewer opportunities to invent a parallel interface. This is a vendor-published case study, so treat the number as a reported result in that setting, not a universal benchmark for every team or model.

Where the ambiguity enters

A visual design gives an agent shape, spacing and labels but often hides the implementation contract. Which component is approved? What props are legal? Is the color token semantic or a literal value? Which interaction states exist off canvas? Without answers, the agent writes plausible code that looks right in a screenshot and drifts from the system in production. Human engineers can infer unwritten conventions from a repository; agents need those conventions made legible and retrievable.

Code Connect is one way to narrow that gap. The reported Coinbase setup links Figma components to their code siblings. That matters because the agent can work from a mapping rather than guessing a replacement. It does not automatically guarantee accessible states, correct behavior or a good product decision. It reduces one kind of uncertainty: where a component comes from and how the design language is represented in code.

Measure adherence separately from speed

A team tempted by the reported token reduction should first ask what changed in its own output. Did the agent use the approved component rather than a hand-rolled substitute? Did it preserve hover, keyboard focus, errors and loading? Did the resulting pull request require fewer rounds of correction? Token cost is useful, but it is only one cost in a delivery system. A cheaper wrong screen remains expensive after review and rework.

Create a small evaluation set of known interface tasks. Run it with and without component mappings, using the same repository, task descriptions and review criteria. Score implementation against actual component imports, semantic token use, accessibility checks and final diff size. Record how much human editing was needed. A narrow experiment can show whether the mapping helps your stack without pretending Coinbase’s conditions match yours.

The new maintenance work

A design-to-code contract becomes another artifact that can become stale. When the design library changes but production props do not, an agent can confidently follow the wrong mapping. Ownership matters: decide who updates links, who reviews mismatches and how a deprecated component is surfaced. A useful system should make the current component path visible inside the developer workflow, not demand that every engineer remember a separate design archive.

The team should also guard against a subtler failure: component obedience without product judgment. Agents can follow the library perfectly while implementing a confusing journey. A component contract answers how to build a known pattern; it does not answer whether that pattern is right for the user’s task. Keep product review and user research in the loop.

A practical rollout

Start with a handful of high-volume components: buttons, input fields, dialogs, navigation and status messages. Include examples for disabled, loading, validation and empty states; name the variants in terms a developer and an agent will encounter. Connect each design component to the real code implementation. Then ask an agent to assemble a modest flow, inspect the result and record every ambiguous instruction it encountered.

Treat those ambiguities as backlog items for the design system. If a model repeatedly builds a custom dialog, perhaps the approved dialog is poorly documented or difficult to discover. The same observation helps human engineers. The agent is a diagnostic probe, not the owner of the system. Coinbase’s report is compelling precisely because the design system is being tested as working infrastructure rather than admired as a static gallery.

What this signals for teams

Design systems now have at least two audiences: people who inspect examples and machines that need explicit, testable boundaries. Both benefit from precise names, supported variants and a reliable bridge into code. The business case is not ‘AI will design everything’; it is that fewer hidden assumptions mean less drift during implementation.

Read the Figma case study for its setup and reported result, then establish a baseline in your own repository. Keep the claim modest. A mapped library can improve consistency for the tasks it covers. It cannot replace evidence about comprehension, performance or accessibility in the finished experience. The most mature team will publish its own numbers alongside the conditions under which they were measured.

Questions to take into your next review

  • Can the agent find the production component for every common design element?
  • How often does it generate custom substitutes?
  • Which review failures remain even after mappings are supplied?

Primary sources and further reading

Continue reading