Architecture · design systems

Code to design pipeline with AI agent teams

Almost every design-to-code tool runs one way. This one runs the other way. Point it at a coded component library and it builds the Figma library: components, variants, bound values, both themes. Nine agents, four human gates, $26 a component.

Published
28 July 2026
Read
23 min read
Discipline
Agentic pipeline design
Stack
Claude agents, Figma Plugin API
Build cost per component
$26
Agents in the team
9
Human decision gates
4
Cheaper than version one
51%

The job nobody wants

Most companies have a component library that is right in code and wrong in Figma. Engineers have the real thing. Designers have a copy someone drew by hand a year ago. Every screen designed against that copy earns a round of "that's not what the component does" in review.

The fix is obvious: rebuild the Figma library from the code. Nobody does it. It is weeks of a designer's time copying work that already exists — every component, every variant, every value bound to a variable, light and dark, documented. It is expensive and boring, and it never wins a sprint against shipping a feature.

So it waits, and the gap grows.

Two ways this is useful

I built a pipeline that does the copying. Give it a coded component library and a Figma file, and it builds the library in Figma: real components, bound values, documented. It solves the job above. It also solves a second one I did not expect.

  • Use case 01 — migration

    Your components already exist in code, and Figma has drifted.

    Rebuild the Figma library from the code that ships, so designers and engineers work from the same thing. It is a mechanical job with a checkable answer, which is exactly what agents are good at.

  • Use case 02 — a head start

    You want a library and a good open-source one already exists.

    Pull shadcn, or any library with published source, into Figma as proper components. Then restyle it there — by hand, or with agents. You start from a complete, correctly built library instead of drawing forty-eight components from scratch. That is what I was testing.

A component library is mostly structure: what nests inside what, which props become variants, which states exist. Structure is slow to draw and cheap to copy. Taste is the part worth your time. Get the structure for nothing and you start where the design work actually starts.

The direction matters. Nearly everything in this space runs Figma → code. This runs the other way. If your company already ships software, the truth lives in the code — so that is the side to build from.

What it costs, and what that is against

$25.78 per component in API tokens. Across a forty-eight component library, about $1,240.

That is pure model spend at published API rates — no tooling, no seats, no labour. It is also the most expensive way to read the number: the wave actually ran inside a monthly subscription, where the same work is a slice of a plan rather than a metered bill. I price it at API rates so it can be compared against the run before it, and against anything else you have measured. The breakdown is at the end of the article.

Either way, the number means nothing on its own. Building one of these by hand takes me a few hours: every variant, every value bound rather than typed, both themes, documented. The variants are quick. The binding and the documentation are not. After ten years of doing it, I am confident the comparison is hours of skilled time per component, not minutes.

So the model spend is not the expensive part. I am. The pipeline is built around that: four human gates, placed where my judgment is worth more than my typing.

Version one worked, and cost $52

I built it, ran it against nine components, and got a real library. Then I measured the run.

$52.34 per component. And 95% of every token went on agents re-reading their own context — not thinking, not building. Reading back what they had already been sent.

That is not a model problem. A cheaper model moves it maybe 30%. It was an architecture problem, and I had built every cause of it myself.

Measured in the version-one run — and what each one became
What the data showedThe fix
One agent planned and dispatched, and never ended. The orchestrator held a 349-turn context and re-read it 65 times — doing hard reasoning and simple routing in the same place.Split the two jobs. Reasoning goes to a bounded planner that runs once per component. Routing, bookkeeping and budgets go to deterministic code with no model in it at all.
The builder reasoned while it wrote — discovering platform limits and resolving ambiguity mid-build, on one context across ten dispatches. 222 turns, ~35,000 new tokens every turn.Move the thinking upstream. The planner resolves everything first and hands over a complete spec, so building becomes mechanical — which is what lets the builder drop to a cheaper model.
Agents re-read their own tool output every turn. A single Figma metadata call returns ~90,000 characters; a builder doing twenty reads re-paid for all twenty on every later turn.Never let a payload persist. Fat reads run in throwaway fetchers that return one distilled fact and then die. The planner works from ~200-token facts, not 30,000-character dumps.
Nothing capped an agent's lifetime. No budgets, no bail conditions — so one builder ran 222 turns on a single accumulating context and nothing stopped it.A hard budget and a bail condition per agent, enforced from outside the agent. One agent, one job, hand off through a written ledger.
Design tokens were passed by name, not value. Six components shipped light-mode-only because an agent bound a name and never checked what it resolved to in dark.Resolve tokens to values before the builder sees them — deterministic code, not an agent, emitting the exact light and dark value for every binding.

Five problems, one mistake: I let agents carry state they should have been reading.

Pipeline, or team?

The distinction shaped the redesign. A linear pipeline runs each agent once and passes the output on. It fails in one specific way: what an early agent learns is lost in the handoff. An agent team loops inside each phase, hands over structured files instead of prose, and puts a human at the phase boundaries.

Version one was already a team. It had roles, contracts and repair loops. It had none of the guardrails: no definition of done, no budget, no bail condition — and a chatty orchestrator doing a job that should have been code.

The pipeline

Four phases, left to right. The agents never talk to each other. They read and write typed artifacts, and a deterministic dispatcher decides what runs next.

One component's journey
Dispatcher — reads the ledger, decides what runs next, enforces budgets, bail conditions and the single write lane · deterministic code, no model

  1. 01 Understand

    • source library · pinned version
    • Contract ExtractorSonnet
    • ↓ draft contract
    • Mapping JudgeSonnet
    • contract · ratified
    • human gate 1ratify & escalate

  2. 02 Plan

    • PlannerOpus
    • ↓ spawns on demand
    • Context FetchersHaiku
    • build packet

  3. 03 Buildsingle write lane

    • BuilderSonnet
    • ⇄ repair loop
    • ValidatorOpus/Sonnet
    • validated
    • human gate 2visual review

  4. 04 Verify

    • Readback TesterSonnet · blind
    • ↓ readback
    • Readback GraderSonnet
    • Parity AuditorSonnet
    • human gate 3publish
    • published library
  • Verify → Build. A failed readback names the exact gap, routes it to the builder, and then a fresh tester re-verifies blind — never the tester that failed it. Two cycles, then it escalates to a human.
  • Drift → conventions, forward not backward. The parity audit runs at the close of a batch, so it cannot un-build a shipped component. It corrects the shared conventions, and the next component's planner reads the corrected version.

solid card = agentoutlined = typed handoffdashed = human gatefilled = output

Outlined blocks are typed handoffs — the only thing that crosses a phase boundary. Dashed blocks are human decisions. The dispatcher is code, so conducting the pipeline costs nothing.

Explore each agent

Plan is its own phase on purpose. Most designs fold it into understanding. Splitting it out is the whole move: resolve everything first, and building becomes mechanical enough for a cheap model. The builder is where the money went.

Open any agent to see what it takes in, what it hands on, and the two things version one lacked: a definition of done and a budget.

9 agents6 Sonnet1 Haiku1 Opus1 Opus/Sonnet

Understand

Plan

Build

Verify

Every run starts with fresh agents and a brief for that one component. The builder that made one component never touches the next. What carries over is files, not conversation: the token data, the shared conventions, and a ledger of what is built. A new agent reads them. It never inherits someone else's context.

Version one proved this by accident. A builder died mid-component, a fresh one picked up from the ledger, and nothing was lost.

The build packet

The planner's output, and the file the whole design turns on. It is what "resolve everything first" means in practice: it lets the builder be cheap, and gives the validator something objective to check.

target:   { file, page, staging }   # where to write
 
variants:                           # how code props become Figma properties
  - { prop: size,     kind: variant,       values: [sm, md, lg] }
  - { prop: disabled, kind: boolean }
  - { prop: icon,     kind: instance-swap }
  - { prop: onClick,  kind: ignored }      # behavioural — never drawn
 
nest:                               # primitives to instance, BY ID
  - { part: <name>, component_id: "…", props: { … } }
 
values:                             # tokens RESOLVED to values, never names
  - { role: surface, variable_id: "…", light: "#…", dark: "#…" }
 
steps: [ … ]                        # ordered, deterministic API operations
 
validity:                           # the contract the validator runs
  mandatory_bindings: [ … ]         # every fill, gap and radius that must bind
  must_disclose:      [ … ]         # Figma-only decisions → written to the description
  platform_limits:    [ 3, 7, 11 ]  # ONLY the three that apply here, not all sixteen
 
directive: >                        # the application contract — placed LAST
  Bind every value. Nest by ID, never by search. Emit each disclosure.
  Do not invent a token. On any gap, stop and report — do not guess.

Three details carry most of the weight. Values, not token names — the change that killed the light-mode-only bug outright. Nest by ID, not by search, because "find the button component" is a coin flip in a file with four Buttons. And the directive last, because the final instruction is the one a model applies.

Where the failures actually live

Before betting on the cheap builder, I tested it on one hard component: a hover card with ten exports, a nested panel, a progress indicator and a hand-drawn donut trigger.

The build was faithful. Sixty bindings, all confirmed by reading them back rather than by "no error thrown". The nested layout came out intact. Every API limit was reported instead of hidden.

Then I opened the file, and eleven of its twelve props were missing.

Not a rendering fault. One planning decision, three phases upstream. The plan built the card's parts inline instead of as their own components, and put content into a slot inside an already-published instance. A parent cannot bind properties into a node it does not own. So eleven props had nowhere to attach. The nested instance's padding bled through. And the card drew itself in its closed state, because visibility had been treated as styling rather than structure.

Every failure traced to the plan. None traced to the model doing the building. That is worth more than the cost work: the expensive layer is not the one doing the work, it is the one deciding what the work is.

Human gates

Four, all at phase boundaries. The pipeline surfaces decisions rather than guessing, and nothing reaches a published library without my hand on it.

  1. Setup — once per library

    I approve the config, the drafted token crosswalk, and the list of components to build. The only gate that runs at setup rather than per component.

  2. Ratify — before any write

    I approve the contracts and resolve anything escalated: a new token, a taste call. Batched and async. Deciding once, up front, is far cheaper than un-picking a wrong guess later.

  3. Visual review — after build and validation

    I look at each built component and approve it. The next build in the single lane waits for my go.

  4. Publish — after verification

    Publishing the library is my manual act, alone. Nothing auto-publishes, ever.

Pointing it at a different library

The pipeline is general. The library I tested against is a config, not the design — three fields, and the same agents, conventions and gates rebuild whichever library you name.

source:  <package or repo>        # the code library to build from
figma:   <library file URL>       # variables + existing primitives + build target
intent:  "match structure; bind our token values"

The one knob that matters is the token crosswalk — a fifteen-to-twenty row map from the source's token names to yours, written once. Map it one to one and you clone the source's look. Point it at your tokens and you get the source's structure in your brand, which is where restyling begins.

If the source uses a token you do not have, nothing is guessed. It comes to me as a decision. "Looks different from the source" is expected. "Invented a token" never happens.

What the rebuild measured out at

Same method as version one, same model rates on both sides. The difference is process, not a cheaper price list.

Measured — version one against the first wave on the redesigned engine. Build cost per component; one-time setup for a new source library is separate and does not repeat.
v1After the rebuild
Components in sample94
Build cost per component$52.34$25.78
Tokens billed per component~62M~24M
Turns, whole wave2,341396

Where the $26 actually goes

Both runs are priced at the same published rates — Claude Opus 4.8: $5 per million input tokens, $6.25 per million written to cache, $0.50 per million read back from cache, $25 per million out. Version one ran on that model. Split the per-component cost by what it was spent on and the shape of the problem is obvious:

Approximate, from the run's token mix — one component at Opus 4.8 rates
What the tokens wereShareCost
Cache reads — context the agent had already been sent~90%$10.80
Cache writes — putting that context there in the first place~5%$7.50
Fresh input — genuinely new material~5%$6.00
Output — the work the model actually produced~0.3%$1.80

The thing you are buying costs $1.80. The other $24 is the cost of the model being reminded what it was doing. That is the whole thesis in one table, and it is why the redesign targeted agent lifetime rather than model choice.

Three things worth reading off the number

What you would actually pay is lower. Both columns are priced at Opus 4.8 rates so the comparison is like-for-like — version one ran on that model. The wave after the rebuild ran on a cheaper one, and at its published rates the same work comes to about $19 a component. Run inside a subscription, which is how most people will run it, a library of this size sits comfortably inside a monthly plan — Claude's own are $20 for Pro and from $100 for Max — rather than arriving as a four-figure API bill.

Tokens are billed, not written. 24M tokens per component sounds enormous until you account for how agent turns are charged: every turn re-bills the whole context, so this is roughly 240,000 tokens of actual material charged across a hundred turns. Cache reads are still ~90% of the total, down from ~95%. Shorter agent lifetimes cut tokens per component by about 60%, which is where the saving came from.

The spread is the real signal. Components in the wave ran from $11.78 to $41.73. The cheap ones are what the engine does when the plan is right; the expensive one cycled through three gates on a composition the planner had got wrong. In a pipeline like this, cost tracks planning quality — which is why the next thing worth improving is the planner, not the model.

What transfers

Little of this is Figma-specific. If you are building any pipeline where agents produce work to a standard, these are the parts worth taking.

  • 01

    Instrument before you optimise.

    I would have guessed "use a cheaper model". The data said 95% of the spend was re-reading context, which no model swap fixes. One run's worth of per-agent token data reframed the entire redesign.

  • 02

    Separate deciding from doing.

    The most expensive agent was the one doing hard reasoning and simple routing in the same context. Routing is deterministic work; it belongs in code, where it costs nothing and never forgets.

  • 03

    Give every agent a definition of done and a budget.

    Enforced from outside, with a bail condition. Without one an agent will run 222 turns and still hand you something that needs repair.

  • 04

    Spend on planning, not on building.

    Every failure worth fixing traced to the plan. A complete specification lets the build step be mechanical, cheap and checkable — and makes the human review short, which is the cost that actually matters.

  • 05

    Put the human at phase boundaries.

    Not on every turn, and not absent. Four gates: ratify the plan, review the build, approve the publish. Deciding once up front is far cheaper than un-picking a wrong guess later.

Notes on the numbers

Two measurements, taken the same way: per-agent token usage across version one's fifty-six agent runs, and the same reconstruction across the first wave on the new engine. Both priced at the same published model rates.

Both are rebuilt from run transcripts rather than read off an invoice, because the tooling does not store tool results — their sizes are calibrated estimates. The direction is solid, the second decimal place is not. Neither figure includes my own review time.

The architecture leans on published work rather than my own assertion — Anthropic on multi-agent research systems and effective context engineering, Cognition on single-threaded writes, Manus on cache hit rate as a cost lever, and Kaelig Deloumeau-Prigent's design system components with AI agent teams, which runs the opposite direction to this one and is where the exit-criteria and budget model comes from.

If you are moving a component library into Figma, or building something like this and want a second pair of eyes on it, get in touch.