DEV Community: Amrutha Kollu

Why AI Keeps Generating the Wrong Design Tokens and How I Fixed It with Figma's API

Amrutha Kollu — Mon, 08 Jun 2026 18:18:46 +0000

AI design system output is approximate by default. Wrong border radii, raw hex values, inconsistent tokens across 60 components. The fix isn't better prompts. Here's the structural change that made it exact using Figma's REST API.

The fourth time I manually corrected the same border radius mistake in an AI-generated component, I stopped and asked why this kept happening.

Not "what prompt would fix this?" The deeper question: why does every AI tool I tried get the structure right and the values wrong?

The button was correct. The variants were there. The layout matched the Figma spec. But borderRadius: 8 when it should be borderRadius: '8px'. A spacing gap of 8 when the spec said 6. The color #3B82F6 sitting in the file where semantic.button.primary should be.

None of it wrong in a way that breaks the build. All of it wrong in a way that breaks the design system.

After hitting this wall enough times, I realized the problem wasn't the AI. It was the question I was asking it.

Why AI keeps generating the wrong Figma design tokens

When you give an AI tool a Figma screenshot and ask it to produce a component, it does something reasonable: it interprets what it sees.

The structure, the layout, the hierarchy - it gets most of that right. What it cannot get right is the token mapping.

The AI doesn't know your semantic token file. It doesn't know that #3B82F6 maps to semantic.button.primary in your codebase. It doesn't know that your MUI setup multiplies numeric border radii by 4, which means borderRadius: 8 renders at 32px instead of 8px.

So it approximates. Here's what that looks like in practice:

What AI produces	What the spec requires	Why it's wrong
`borderRadius: 8`	`borderRadius: '8px'`	MUI multiplies numeric values by 4
`gap: 8`	`gap: 6`	Spacing value not extracted from Figma
`color: '#3B82F6'`	`semantic.button.primary`	Raw hex instead of semantic token
`fontSize: 14`	`variant="MD_Medium"`	Typography token not resolved

Across one component, these deviations are small. Across 60 components, they mean your design system exists in two versions: what the designer built and what the code implements.

This isn't a prompt engineering problem. A better prompt doesn't tell the AI your semantic token file. The problem is structural, the input is wrong.

How to fix AI design token generation: read Figma's API, not a screenshot

The insight that fixed this for me: design system components have two completely different kinds of decisions.

Deterministic decisions have exact correct answers already defined somewhere like the token for this fill, the typography variant for this size/weight combination, the exact spacing value. These are not judgment calls. They have right answers that live in your Figma file and your token file.

Judgment decisions require actual design thinking where which variant is the default, how the component behaves in edge cases. These genuinely benefit from AI reasoning.

The mistake I kept making was asking AI to handle both at once. Once I separated them, everything changed.

Instead of giving the AI a screenshot to interpret, I started reading Figma's REST API directly. The API returns exact values, fills as precise hex codes, typography as specific size/weight/line-height combinations, spacing as pixel measurements. No interpretation. Exact data.

Here's what the fixed pipeline looks like:

# Step 1: Read exact values from Figma REST API (not a screenshot)
figment scan --node 87YQbb7f33GYUHSOogYGjH:397:23320

# Output: token patch with classified fills
✓  semantic.button.primary  #3B82F6  reachable
✓  semantic.surface.pressed  #1E3A5F  reachable
⚠  spacing.gap  8px  → resolves to tokens.space.2

# Step 2: Deterministic resolvers run before AI sees anything
# Typography: 14px/500 → MD_Medium
# Corner radius: 8 → '8px' (MUI string literal)
# Gap: 8px → tokens.space.2

# Step 3: AI generates from facts, not interpretations
figment generate --name Badge --node 87YQbb7f33GYUHSOogYGjH:397:23320

The prompt no longer says "generate a button component based on this design."

It says "generate a button component where the background is semantic.button.primary, the corner radius is '8px' as a string literal, the gap is tokens.space.2, and the typography variant is MD_Medium."

The AI received facts. It produced code from them. It never had to guess at a token name because I had already resolved every single one before the model saw anything.

The problem generation doesn't solve: design system drift in CI

Getting values correct at generation time is necessary. I learned it's not sufficient.

One month in, a developer renamed a token in a PR that looked completely unrelated. The rename was correct and it was a necessary cleanup. What nobody checked, including me, was which components used the old name. During the design review, the designer flagged that three buttons in production no longer matched the Figma spec. Not dramatically. Just slightly off.

That's the thing about design system drift. It's invisible until someone looks closely enough to notice.

The fix I landed on: a verification script that runs on every pull request. It fetches the live Figma data for each component, re-runs the same deterministic extractors I used at generation time, and compares the results against the current component source.

# Runs on every pull request automatically
npm run verify-figma -- --component Badge --node 87YQbb7f33GYUHSOogYGjH:397:23320

✓  Typography    variant="MD_Medium"         PASS
✓  Spacing       gap: tokens.space.2         PASS  
✓  Colors        no raw hex values           PASS
✓  Border-radius '8px' string literal        PASS
Exit code: 0 — no drift detected

If anything has drifted from the Figma spec, the script fails. The pull request doesn't merge.

The design system no longer depends on the memory of whoever is reviewing the PR. It depends on the Figma file, verified continuously on every merge.

What production-ready AI-generated components actually look like

When you put these two things together - deterministic pre-resolution and CI drift detection, the output is structurally different from what most AI tools produce.

Every generated component includes:

✅ Zero raw hex values — every color is a semantic token
✅ Correct border radii — string literals where MUI requires them
✅ A .figment.json spec file recording exact Figma values at generation time
✅ A spec-lock test suite running against the current source on every CI build
✅ An overrides file documenting every intentional deviation with written justification

This approach shipped more than 60 components with 3,077 tests in 35 business days against an original estimate of 120 engineer-days. The reason cleanup time dropped to near zero was the pre-resolution step. There was nothing to fix because the values had never been wrong.

Why the constraint-first pattern works for any AI code generation

AI output is approximate by default. Making it exact requires constraining what AI is allowed to decide.

I've come to think of this as a general principle, not just a design system trick. Any workflow where AI generates code that needs to be production-correct, not just production-close, benefits from the same structure.

Resolve the deterministic parts upstream. Delegate the judgment parts to the model. Scan the output for violations before writing any file. Verify against the source of truth on every pull request.

Most teams skip the constraints because they seem like overhead. Then they wonder why every AI-generated component needs a round of manual cleanup before it's usable.

That cleanup is the cost of asking AI to make decisions it was never designed to make well. Once I stopped asking AI those questions, it stopped giving me wrong answers.

By Amrutha Kollu, Software Engineer.

Part 1: How I Shipped 60 Design System Components in 5 Weeks Using Figma as the Single Source of Truth

How I Shipped more than 60 Design System Components in 5 Weeks Using Figma as the Single Source of Truth

Amrutha Kollu — Tue, 26 May 2026 23:26:59 +0000

We estimated 120 engineer-days. We shipped in 35 days with 3,077 tests and zero raw hex values. Here's the pipeline I built to make Figma the literal source of truth for our codebase.

All front-end developers are familiar with that pain.

A designer drops a Figma file. It is pixel-perfect. All interaction states are included. Next, you launch your editor and the translation process starts.

You squint at 2 screens. What's the gray color of that? Which is 8 pixels and which is 12? What is the font weight for this font? MD_Medium, MD_SemiBold?

The questions are brief. The answers are extremely important. The farther away you are from the Figma file, the more the component deviates from the original idea.

This is not something resulting from carelessness. It's a structural issue; Figma and code are two very distinct ways of representing the same truth, and every time a new engineer has to re-translate the specification by eye.

The cost in real numbers

Our design system had more than 60 components to implement. The effort estimate was conservatively estimated at 4-5 engineer days per component.

That's about 120 engineer-days including design drift at each turn.

The typical failure pattern:

Day 1: engineer reads the Figma spec, guesses what names to give the tokens.
Day 2-3: component is written by hand
Day 3: QA feedback and it is noted that it is the incorrect color or spacing.
Day 4: fixes and review
Day 5: tests (if time permits)

After one week, the component continues to drift. The source of truth was a Figma file that was not programmed into the engineer, but looked at.

Why I built Figment

The insight was simple: It was not that engineers failed to be good at reading Figma files. The issue was that they had to read them all.

If it was possible for Figma to talk directly to the codebase, without a human being being an error-prone layer in between?

That became Figment.

The aim was to never take away the human judgment. It does not need to be automated for designers to make decisions regarding hierarchy, intent and emphasis. But the mechanical aspects of the translation, like the exact hex value of a token, the exact measurement of a gap, what font variant equals a particular weight — those answers are there in the Figma file already.

It didn't make any sense for a human to be making the sixty re-answers to the fiftieth time for sixty components.

One of the initial limitations

Every generated component had to use:

Semantic design tokens (not raw hex values)
MUI sx props (not external stylesheets)
TypeScript strict mode
A Storybook story for every meaningful Figma variant
Spec-lock tests capable of catching drift in CI

Figment was not built to produce a starting point for an engineer to clean up. It was built to produce code ready for review and ready to ship on the same day.

How Figment works: a three-stage pipeline

Stage 1: Token reconnaissance

Design tokens that are used by the component must exist in the codebase before the component generates them. Stage 1 retrieves the Figma fills for the target node, compares them to the existing token file, and prints a patch that can be pasted to the token file to include the missing tokens.
One Figma API call. Thirty seconds. No room for ambiguity.

Stage 2: Token authoring (where all that is necessary is a human touch)

The engineer checks the proposed additions of tokens and adds them to the appropriate semantic group. This is a deliberate manual step as there are design intentions and intents to the token that cannot be captured by automation.
The system's state is indicated by a color called surface.pressed, which the hex value doesn't convey.

Stage 3: Deterministic component generation

This is where Figment differs from having an AI create a component from a Figma screenshot. Figment uses Claude via the Anthropic API for the generation step, but the key is what happens before Claude ever sees the data.

All values that can be exactly determined are fixed in advance of any data reaching the Claude (via the Anthropic API):

The typography is solved by the algorithm: 12px + weight 500 = MD_Medium, line-height 16px. Injected as facts, not suggestions.
The spacing and icon sizes are directly retrieved from Figma's bounding box data. Exact pixels (not rounded up).
If all variant dimensions are parsed, then a required coverage block is appended to the input coverage to ensure no interaction state is lost, otherwise the variant coverage is determined.

The output is scanned for forbidden patterns after generating and before writing to disk.

Raw hex values → rejected
Numeric border radius with no other modifiers (such as blur or drop shadow) → accepted, but multiplied by 4 (MUI)
Missing token imports → rejected There is a problem with the order of the focus rings' shadows.

A file is written only if it passes all the checks. No silent failures.

What a single run produces

Figment creates 3 files when it is called. Not a scaffold. Not at the beginning. A full, reviewed, PR ready package:

The component file containing semantic tokens, MUI sx props and type strict mode
A Storybook story for each meaningful Figma variant.
A spec-lock test to store all the tokens and spacing values for CI checking

All three products are produced simultaneously, all are checked simultaneously and all are sent simultaneously. An engineer's task is to check that it is correct and not rewrite.

Handling intentional deviations from Figma

Not all of a specification should be taken verbatim and pasted into the code. In some cases, the designer may define typography that is applicable to a child component. A spacing value sometimes is more a layout frame artefact than it is a rule for the component itself.

Figment does this using a file called figment.overrides.json that is located with each component. Any deliberate deviation from Figma is documented on a written basis with a justification. Nothing is undocumented. An exact Figma value that is used as a basis for the generated code is recorded in a separate figment.spec.json.

This means that each part has its own origin: what it was said in the Figma file, what it will do differently, and why. A response of 6 months later to "why doesn't this meet the Figma spec?" should not be based on someone's memory, but rather the file.

Automated drift detection in CI with verify-figma

Generating a correct component is one problem. Keeping it correct as the codebase evolves is a separate problem.

A token renamed by a future engineer. A spacing value adjusted without checking Figma. A color swapped in a hurry. These changes silently erode a design system until the code no longer matches the spec.

Figment addresses this with verify-figma, a script that runs on every pull request:

npm run verify-figma -- --component Badge --live --figma-node 397:23320

Typography    12px / weight 500  variant="MD_Medium"  PASS
Spacing       gap in "Icon + Label"  6px              PASS
Colors        raw hex  No raw hex values               PASS
Border-radius 6 checks  PASS | 6 passed, 0 warnings, 0 errors

Six checks. Zero warnings. Zero errors. Verified live against the Figma file in thirty seconds.

Pull requests that introduce drift do not merge.

The design system does not rely on the memory or diligence of the people maintaining it. It relies on the Figma file, verified continuously by the pipeline that created it.

The parallel review workflow that made 5 weeks possible

The pipeline was only half of what made this work. The other half was the process design.

Building a design system means satisfying two reviewers: a designer checking visuals and an engineer checking code. Most teams run these sequentially. Three sequential waits per component.

We collapsed them into one:

Run the Figment pipeline for the target component
Deploy to Storybook via Chromatic and send the designer a link
Simultaneously, raise a PR for engineer code review
While both reviews are in flight, start the next component
When feedback arrives from both, address it completely

Designer review and engineer review happen concurrently, not consecutively.

We shipped 7 components in a single day using this workflow.

The bottleneck stopped being the build. It became the review queue trying to keep up.

The bottleneck nobody expected

It was not all smooth. Early in the implementation, pull request reviews from the engineer arrived slowly. Components were being generated and deployed. The pipeline was working. But the reviews were not keeping pace with the output.

This is a well-known failure mode on small teams: one person's output rate exceeds another's review rate, and work accumulates in the queue. Components that sit in review for two weeks get feedback in a different mental context than when they were built. Addressing that feedback takes more effort than it should.

Then something shifted. When the engineer's review cadence aligned with the generation rate, the entire dynamic changed. Two people in synchrony: one generating components and running visual review, one reviewing code, both running at the same pace. Components that had been stacking up began shipping daily.

That is the part no tooling can automate. The pipeline can generate at any speed. The workflow can parallelize reviews. But the human rhythm of a team working in sync is what turned a good system into a fast one.

The results

Metric	Before Figment	After Figment
Time per component	4-5 engineer-days	Less than 1 day
Total for 60 components	~120 engineer-days (est.)	35 business days
Tests	Written if time allowed	3,077 (every component)
Raw hex values	Common	Zero
Design drift	Discovered weeks later	Caught on every PR

Every component has a matching Figma node ID recorded in its source. Every token choice is auditable back to the Figma file. Every intentional deviation from the spec is documented with a written justification in figment.overrides.json.

Why AI alone doesn't solve this problem

I tried using AI tools to generate components from Figma before building Figment. The output was always close but never exact.

The reason: AI tools interpret Figma like a screenshot. They see the design visually and approximate what they see. A 12px font becomes 14px. A 6px gap becomes 8px. A border radius of 6 becomes 8 because MUI multiplies by 4 and the AI doesn't know that.

Figment reads Figma like a database. It uses node IDs to extract exact values from the Figma API. No interpretation. No approximation. Then it resolves every deterministic value algorithmically before claude sees any data.

That is the difference between "close enough" and "correct."

What this changed

Before Figment, implementing a component took 4-5 engineer-days. After, the same work took less than a day, with tests included.

The human effort shifted from production to judgment which is precisely where human effort belongs.

A human translating a specification at four in the afternoon makes different choices than the same human on a Tuesday morning. Figment makes the same choices every time.

60 components. 3,077 tests. Zero raw hex values. 5 weeks. One source of truth.

Built by Amrutha Kollu, Software Engineer.