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
sxprops 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.
