Build the design, then go and look

The failure this is for

The agent writes the component. It reads its own source back, confirms the class names say what it intended, and reports that the header is blue with the logo centred. The header renders red and left-aligned, because a parent rule won and nothing in this loop ever displayed a pixel.

This is not carelessness. The agent is generating a visual artifact while reasoning entirely in text, and the only feedback available to it is the text it just wrote. Of course it agrees with itself.

The failure	What it looks like	What answers it
Measuring the design by eye	12px read as "about 14", a shade off	the design as data
Screenshotting too early	compares against a loading skeleton	wait for the network to settle
Reasoning about pixels in prose	"I have implemented the blue header"	an actual render
The match rots	a refactor removes a label, silently	an assertion that re-runs

The pair that looks redundant

Chrome DevTools and Playwright are the two items anybody would suspect of being the same item twice. They are not, and the distinction is worth having because it generalises past this stack.

Chrome DevTools is for looking. It drives a live browser inside the build loop and hands back a picture, a DOM, and a console, right now, interactively. Playwright's own README brags about needing no vision model, which sounds like a weakness in a stack about pixels and is exactly the point: an assertion over an accessibility tree is deterministic, cheap, and can be written to a file. One proves the match happened. The other stops it from silently un-happening.

The second one is the one people leave out. Everybody remembers to look at the screenshot once. Almost nobody turns that look into something the next refactor has to get past.

There is no visual diff tool here, on purpose

The obvious fifth item is a pixel-diff: something to compare the render against the design and return a similarity score. Its absence is the sort of thing a catalog papers over, so here is the actual reason.

Nothing first-party exists for it. Searching this catalog for pixelmatch, odiff, resemble, percy, backstop and visual regression returns single-digit-star personal forks and enormous skill-dump repositories that bundle thousands of unrelated files. Recommending one of those would be inventing rigour.

The better reason is that the job does not need a tool. The model already has vision. Putting the render next to the design and asking is the entire mechanism, and a similarity score would mostly launder that judgment into a number that looks more objective than it is. What the stack has to guarantee is that the agent looks at all, which is what the other four items are for.

Where the design lives

This reads the design through a community server rather than Figma's own Dev Mode MCP, and that is a deliberate trade rather than an oversight.

Figma's official server does something this one cannot: Code Connect, which maps the design's components onto the ones already in your codebase, so generated code reuses your button instead of inventing a second one. That is genuinely better output. It also assumes you have already done the Code Connect mapping, and it puts the richer tools behind a beta endpoint limited to an approved client list.

The item here needs a personal access token and nothing else. If your team has Code Connect set up, use theirs; the rest of this stack is unchanged either way.

claude mcp add figma-context -- npx -y figma-developer-mcp
npx -y skills add anthropics/skills --skill webapp-testing
claude mcp add chrome-devtools -- npx -y chrome-devtools-mcp
claude mcp add playwright -- npx -y @playwright/mcp