Agentic Figma-to-Code Visual QA With the SmartUI Skill

The Manual Review Problem

Design QA has stayed manual longer than most other testing disciplines. A developer opens the Figma frame in one tab and the deployed build in another, then scans for what changed: a border radius that's 2px off, a spacing token that got hardcoded wrong, a shadow with the wrong blur radius.

That gap rarely closes on its own. Only 43% of organizations are experimenting with generative AI in QA, and just 15% have scaled it enterprise-wide, according to the Capgemini World Quality Report 2025-26. Figma-to-code verification is one of the tasks stuck in that remaining majority, still running on someone remembering to check before a PR merges.

• Sub-pixel spacing drift - a 4px margin becomes 6px through a few rounds of "close enough" implementation, and no single PR looks wrong on its own.
• Shared-component regressions - a design system token change breaks a dozen screens that reuse the same button, but the reviewer only checked the one screen they were told to check.
• Reviewer fatigue - the fifth Figma-versus-build comparison of the sprint gets a faster, less careful pass than the first.

The Agentic Shift

AI coding agents are already doing some of this work, just not evenly. In the Stack Overflow Developer Survey 2025, 31% of developers say they use AI agents at work with some regularity, and among that group, 69% report a real productivity increase and 70% say agents cut the time spent on specific development tasks.

Figma-to-code comparison fits that pattern exactly: a specific, repetitive, rule-bound task that a person currently does by hand, one screen at a time. It sits next to the broader shift toward agentic testing, where an agent runs a defined task end to end instead of a human executing each step, and TestMu AI's SmartUI skill applies that same shift to design QA specifically.

• No context switch - the same agent that wrote or reviewed the component code also runs the visual check, in the same terminal session.
• No manual command lookup - the agent already knows the SmartUI CLI's Figma flags and environment variables, so you describe the outcome you want instead of looking up syntax.
• A read of the diff, not just a diff - paired with the SmartUI MCP server covered below, the agent can explain what changed instead of only flagging that something did.

What the SmartUI Skill Is

An agent skill is a folder of verified instructions that an AI coding agent reads before it acts, so it produces a correct SmartUI command on the first try instead of an outdated pattern it half-remembers. The SmartUI agent skill already covers installing the CLI and running visual regression tests against Playwright and Selenium suites; this walkthrough covers what that guide doesn't: pointing the same skill at a Figma file instead of a previous build.

SmartUI itself is TestMu AI's visual AI testing product. Its CLI can pull frames directly out of a Figma file and use them as the comparison baseline, so a screenshot of your live build gets measured against the actual design file, not a screenshot someone saved during the last release.

Walking Through a Real Check

Here's what asking an agent to run this looks like end to end, using the same commands documented in TestMu AI's SmartUI CLI Figma guide. Nothing here requires opening the SmartUI dashboard until the last step, where a human still makes the approve-or-reject call.

Setting Up the Comparison

The agent needs three environment variables before it can touch either side of the comparison, laid out in TestMu AI's SmartUI Figma CLI documentation: PROJECT_TOKEN from the SmartUI dashboard, FIGMA_TOKEN, a personal access token from Figma, and LT_USERNAME for TestMu AI account authentication. The docs page itself calls this out directly to agents, not just human readers.

export PROJECT_TOKEN="your-smartui-project-token"
export FIGMA_TOKEN="your-figma-personal-access-token"
export LT_USERNAME="your-username"

Point the agent at the Figma file and it generates the config itself: a designs.json naming the Figma file token from the URL and the specific frame IDs to pull as baselines, for example the node ID that follows node-id= in a Figma share link.

{
  "depth": 2,
  "figma_config": [
    {
      "figma_file_token": "abc12345",
      "figma_ids": ["2417-58969"]
    }
  ]
}

npx smartui upload-figma designs.json --markBaseline
npx smartui exec -- npx playwright test

Root Cause via SmartUI MCP

TestMu AI's SmartUI MCP server is what makes that conversation possible. It exposes tools that any MCP-connected agent can call by comparisonId, each one answering a narrower version of "what changed."

Ask "run a full SmartUI analysis on comparisonId <id>" or "what changed in the layout for comparisonId <id>" and the agent calls the matching tool and answers in the same terminal, without switching to the dashboard to interpret a colored overlay by eye.

Putting It in the Pipeline

A one-off agent conversation catches drift on the feature you're actively building. Wiring the same Figma comparison into CI catches it on every PR, including the ones nobody thought to ask about.

• Nightly, not per-commit - Figma frames don't change every commit, so running the design comparison nightly or on merge to a release branch catches drift without slowing down every push.
• Gate on rejection, not on every diff - block the merge only when a reviewer rejects a change in the SmartUI dashboard, not automatically on any detected difference, since some drift is an intentional last-minute design tweak.
• Component-level coverage too - pairing the Figma check with Storybook visual testing catches a shared-component regression from one story capture, instead of waiting for it to surface on every page that uses the component.

What the Agent Doesn't Decide

None of this replaces a human approving the baseline. The agent can report that a button moved 6px to the left and cite the layout diff behind it, but whether that 6px is an intentional design refinement or a regression is still a judgment call for whoever owns the design spec.

• Approval stays manual - every flagged change still goes through the SmartUI dashboard's approve-or-reject workflow, so a bad screenshot can't quietly become the new baseline just because an agent ran the comparison.
• The Figma file has to be current - if the design wasn't updated after a scope change, the agent will faithfully report a "regression" that's actually the design lagging the code.
• A vague summary is a tell - if the agent's answer doesn't cite a comparisonId or name a specific tool result, it's guessing instead of reading the actual diff data.

Getting Started

Add the SmartUI skill to your AI coding agent if it isn't there already, generate a Figma project token from the SmartUI dashboard, and try the walkthrough above against one screen you already suspect has drifted, before pointing it at a full feature.

The first Figma comparison has nothing to compare against on the code side until your test suite runs once, so that first run is really a baseline-setting pass. Every run after it is a real design-fidelity check, read back to you by the same agent that ran it.

Conclusion

The manual version of this task doesn't scale past a handful of screens a sprint. Handing the comparison to an agent that already knows the SmartUI CLI's Figma flags and can read the result back through the SmartUI MCP server turns a tab-switching chore into a request you make in the same session where you built the feature.

Pair it with KaneAI for the test generation side and the same agentic layer covers both what gets tested and whether it still matches the design. For the fundamentals of the comparison engine underneath all of this, see TestMu AI's visual regression testing guide.