Figma just shipped Check Designs. It scans your layers and flags anything that doesn't follow your design system, the hardcoded colors, wrong typography, incorrect spacing, components from the wrong library.

That's half the problem solved. The other half is harder.

What Check Designs doesn't cover

Check Designs catches drift in Figma before it reaches engineers. That's the right problem to tackle and Figma's approach — a machine learning model trained on your design system data, not generative AI guessing at tokens is exactly right.

But here's what happens after handoff.

A designer ships a perfectly validated Figma component. An engineer builds it correctly. Three weeks later, someone renames a token during a refactor. Another engineer adjusts a spacing value in a hurry. A border radius gets updated in Figma but nobody touches the component. A color reference gets hardcoded during a deadline crunch.

None of these changes are caught by Check Designs because they happen in code, not in Figma. The design system has two sources of truth now, Figma and the codebase, and they're slowly diverging. Nobody notices until a designer screenshots production and asks why it looks different.

This is code drift. And it has no equivalent to Check Designs.

The verification gap

The current options for catching code drift are:

Visual regression testing takes screenshots and compares them. Catches things that look different, misses things that look right but use the wrong token. A component can pass visual regression with borderRadius: 8 instead of borderRadius: '8px', raw hex instead of a semantic token, or spacing that's off by 2px. Close enough to pass a screenshot diff. Wrong enough to break the design system.

Manual design QA means a designer reviews production periodically. Expensive, infrequent, and happens long after the drift has already merged.

Code reviews require engineers to catch design system violations in PRs. Requires reviewers to know the design system deeply and remember to check. Doesn't scale.

None of these are systematic. All of them are approximate or intermittent. The problem compounds because each missed drift makes future drift harder to catch.

What systematic code verification looks like

The right approach is treating the Figma file as the source of truth for code, continuously not just at generation time.

Here's the architecture that works:

Step 1: Generate from exact data, not visual interpretation.
Instead of giving an AI a screenshot to interpret, read Figma's REST API directly. The node data gives you exact values, typography as specific size/weight/line-height combinations, spacing as pixel measurements, fills as precise hex codes. Resolve every deterministic value algorithmically before any AI sees the design. Inject those values as facts. The AI handles structure and judgment. It never has to guess at a token name because you already resolved all of them.

Step 2: Enforce output quality before writing any file.
Scan generated code for prohibited patterns before anything is written to disk. Raw hex values, bare border-radius numbers where string literals are required, missing token imports. If any are found, abort. Nothing approximate makes it into the codebase.

Step 3: Verify continuously in CI.
On every pull request, re-fetch the live Figma data for each component. Compare it against the current source. If anything has drifted, wrong token, changed spacing, updated radius. The check fails and the PR doesn't merge. The design system can't silently drift because the gate runs on every merge attempt.

Step 4: Close the loop back to Figma.
When a component fails verification, post the drift report as a comment directly on that component node in Figma, making it visible to the designer, anchored to the exact layer. When they resolve the comment, the next CI run re-enables detection. The designer finds out inside their tool, not in a meeting or a Slack message three weeks later.

What this produces

Components that stay honest over time, not just on day one.

I validated this approach in production before building Fixel. It shipped 60+ React components with 3,077 tests in 35 days. Zero raw hex values. Zero token hallucinations. Every component verified against the live Figma file on every PR, meaning the design system hasn't silently drifted once.

The result isn't just faster generation. It's a design system that the codebase is contractually obligated to follow.

Check Designs and code verification together

Check Designs validates that your Figma follows your design system.
Code verification validates that your code follows your Figma.

Together they form a complete loop:

Design system → Figma (Check Designs enforces this)
Figma → Code (CI verification enforces this)

Before today, only one half of that loop existed. Now both sides have tooling.

If you're shipping a design system in 2026 and only running Check Designs, you're catching drift on one side of the handoff. The other side is still drifting silently on every PR.

How does your team currently catch code drift after handoff? Are you relying on visual regression, manual QA, or something else entirely? I'd love to hear what's working and what isn't.

By Amrutha Kollu, Software Engineer at Socratics.ai.

Part 1: How I shipped 60 design system components in 5 weeks
Part 2: Why AI keeps generating the wrong design tokens