Stop eyeballing Figma: from design to verified code in 3 steps
Most UI is still built by looking at a design and copying it by eye. The result looks close, but small differences in spacing, color or font weight are easy to miss. AI agents make this faster, but if you give them only a screenshot, they guess too.
In this post, we show a simple workflow that avoids this in three steps: read the design as data, build from a written spec and verify the result in the browser. We tried it on a free
What is an MCP server?
With MCP, the agent does not need to guess from a screenshot or a description. It asks the tool and gets real data back. This workflow uses two MCP servers: one to read the design and one to check the result.
What you need
-
Claude Code -
A Figma MCP server, so the agent can read the design. With a paid Figma plan, use the official
Figma plugin for Claude Code Figma Linux Next -
The
Chrome DevTools MCP server -
Your app running locally, for example on
localhost:3000.
If you use Figma Linux Next, open Settings, go to the Integrations tab and turn on Figma MCP. It listens on port 3845 by default and reads the file in the active tab, so keep your design open in the app.
Connect the servers to Claude Code:
# Figma: official plugin...
claude plugin install figma@claude-plugins-official
# ...or the local server from Figma Linux Next
claude mcp add --scope user --transport http figma http://127.0.0.1:3845/mcp
# Chrome DevTools
claude plugin marketplace add ChromeDevTools/chrome-devtools-mcp
claude plugin install chrome-devtools-mcp@chrome-devtools-pluginsPlugins are installed for your user, so they work in every project. claude mcp add adds a server only to the current project by default. The --scope user flag makes it available in all your projects.
To check that everything is connected, run claude mcp list. With Figma Linux Next, you should see both servers as connected. Your list may also show other servers:
Checking MCP server health…
figma: http://127.0.0.1:3845/mcp (HTTP) - ✔ Connected
plugin:chrome-devtools-mcp:chrome-devtools: npx chrome-devtools-mcp@latest - ✔ Connected1. Read the design as data
The Figma MCP server lets the agent read the file directly: sizes, spacing, colors and fonts.
In Figma, right-click the layer, choose Copy/Paste as and then Copy link to selection. The link includes the node-id, so the agent knows exactly what to read.
Then give the link to the agent:
Read this node from Figma: <link to the "Earning" stats row>
Write the sizes, spacing, colors and typography into design-spec.md,
and save a PNG export of the node.
Report anything you could not read instead of estimating it.This is the export of the node the agent saved. Look closely: the avatars under "Active Now" are not there. We come back to this in step 3.
And this is a short excerpt of the design-spec.md it wrote:
The last line of the prompt is the important one. The agent listed four things it could not read. This matters because a missing value is easy to check later. A guessed value looks correct, so nobody reviews it.
2. Build from the spec
Next, ask the agent to write the code from design-spec.md only, not from Figma.
Implement the stats row from design-spec.md. Do not call Figma.
If a value is missing, choose one and mark it as an assumption in the code.Every value in the code is now a measurement or a marked assumption. For example, the spec had no CSS angle for the icon gradient, so the agent calculated one from the matrix and marked it:
{/* ASSUMPTION: 339deg derived from the gradientTransform recorded in design-spec.md. */}
<div className="flex size-[84px] items-center justify-center rounded-full
bg-linear-[339deg,var(--color-stat-icon-from),var(--color-stat-icon-to)]">The stats row had two of these comments: the gradient angle and the font weight of the trend text. Before the review, you can search the code for ASSUMPTION and see every guess in one place.
3. Verify in the browser
Last, ask the agent to open the app in Chrome, use the same screen size as the design and compare the two.
Open the app in Chrome at 1440x1198 and take a screenshot.
Compare it with an export of the whole Figma frame, not only the node.
Report the differences, then fix them.We compare against the whole frame on purpose. The node export only shows what the agent read in step 1, so it cannot show what is missing.
This is a short excerpt of the agent's report:
Compared at 1440x1198 against the export of the whole Figma frame.
Matches: card 968x151, radius 30, shadow, icon circles 84px,
labels 14px #acacac, values 32px #333333, dividers 87x1 #f0f0f0.
Differences:
1. The avatar stack under "Active Now" is missing (5 avatars, 26px).
It is outside the "Earning" group, so it is not in the spec.
2. The trend percentage is lighter than in the design
(code: Medium 500, design looks SemiBold).
3. The cards are about 1px narrower than in Figma (216.95 vs 218px),
because their width follows the text.
The first version looked right, but our check found two visible differences. Both are fixed in the last row above:
-
Missing avatars. In Figma they sit outside the layer we linked, so the agent never read them. Tip: link the whole area you want to build, not just one group.
-
Wrong font weight. The percentage weight was one of our assumptions. The comparison showed it was too light.
These problems were not visible in the spec. We only found them by comparing the result with the design.
This is the final result in the browser:
The result
-
One review round. The first comparison found the two visible differences. One fix solved both, and the second comparison found no visible differences.
-
Close to the design. After the fix, the card, icons, text and avatars match the design. The only differences left are about 1px: the card widths and the vertical position of the row. We accepted them.
-
Time. For a section like this, a developer usually needs about an hour: measuring the design in Figma, writing the code and comparing the result by eye. With this workflow, the agent does that work and the checks take minutes. In our run, the comparison took about one minute, and fixing both differences and checking again took about four.
-
A spec for later. The
design-spec.mdstays in the project. The next person can build the next part of the dashboard without reading Figma again.
Conclusion
This workflow works best when you need to match a design closely, for example for a design system or a client product. It is less useful for quick prototypes or for designs that still change every day.
It also has limits:
-
It depends on the Figma file. The agent reads layers as they are. Elements outside the linked group, mixed text styles or missing design tokens all leave gaps.
-
It still needs a human review. The agent marks its assumptions, but someone has to check them. The final comparison is a good place to start.
-
It checks one screen size. We only compared the desktop size. Mobile layouts, hover states and real data need their own checks.
The agent does the repetitive work: reading layers, writing CSS and taking screenshots. You review the spec, the assumptions and the final comparison.
