Reviewing the visual fidelity of what AI generates
How to check that an agent's code looks like the design: a review checklist, screenshot comparison and visual regression with Playwright, Chromatic or Percy.
What does “looks the same” mean in a review?
“Looks the same” is too vague to review. An agent can get the overall structure right and miss the fine details, so the review should follow a checklist, not a general impression. This table is a starting point:
| What to compare | What to look at | How to check it |
|---|---|---|
| Typography | Family, size, weight and line height of each level | Inspect the element in the browser and compare with the design values |
| Spacing | Margins and paddings between elements | Measure with the browser tools and compare with the system’s scale |
| Color | Backgrounds, text and borders | Verify it uses the design variables or tokens and not approximate values |
| States | Default, hover, focus, disabled, error, empty and loading | Force each state and compare it with its version in the design |
| Responsive | Mobile, tablet and desktop widths | Resize and compare with the frames for each size |
| Content | Long text, images, icons | Test with content longer and shorter than the design’s |
For exact measurements, open the file in Figma Dev Mode. If the agent used the MCP server, review from Figma to code with MCP to know what data it received.
How do you run a review step by step?
- Define the reference. The approved design, the tokens and, if it exists, the screenshot of the frame. Without a reference there is no review, only opinion.
- Capture the result under the same conditions. Same width, same data and the same state as in the design.
- Compare side by side or overlaid. Look at the structure first and then at the details in the table above. Note each difference with its screenshot.
- Review the states, not only the ideal screen. The agent usually implements the default state well and forgets the error or empty one.
- Classify and send back. Separate what is an error from what is an engineering decision, and ask the agent to fix the former. The full review process is in design QA.
- Lock in what is approved. Once the component is right, turn it into an automated test.
Why does it matter to a designer?
Because visual fidelity is where your work becomes the product. A four-pixel spacing error on a button breaks nothing, but it adds up with twenty others and the result no longer looks like your design. Also, every change the agent makes can break something that was already right: refactoring the card component can move the text on a screen nobody reviewed.
You are the one who knows what “correct” is. The agent does not have that reference unless you give it one, in the form of designs, tokens or screenshots. To see changes before they are applied, read previewing changes.
How do you automate it?
When a component is already approved, you can lock its appearance with a visual regression test. Playwright implements it with toHaveScreenshot:
- On the first run there is no reference: Playwright reports that the snapshot does not exist and writes it. Review it and commit it to the repo.
- On later runs, it compares the new screenshot with the saved one.
- If the change is intentional, you update the reference with
npx playwright test --update-snapshots.
The main options are threshold, which sets the allowed color difference per pixel (from 0, strict, to 1, lax; default 0.2), maxDiffPixels and maxDiffPixelRatio, which set how many pixels may differ, and mask, which covers areas with variable content. Playwright disables animations by default while capturing. According to its documentation, rendering varies with the operating system, version, hardware and modes, and it advises running tests in the same environment where the references were generated.
If your team already uses Storybook, there are cloud alternatives. Storybook explains that visual tests take a snapshot of every story and compare it with a baseline (the last known good snapshot), and that they compare the pixels the user sees, not the HTML. Chromatic, made by the Storybook team, runs them in a cloud browser and asks you to confirm whether each change is intentional. Percy, from BrowserStack, captures the interface across browsers and widths, highlights the difference down to the pixel and lets reviewers approve or request changes; teams can make it a merge blocker in GitHub.
A useful flow with agents: the agent implements the component, runs the test and, if it fails, shows you the difference. You decide whether it is an error or an approved change.
When should you NOT use visual tests?
- When the component changes every week. Updating references all the time turns the test into noise.
- When the content is dynamic: dates, avatars or live data. Without fixed data, the test fails for no real reason, unless you cover those areas with
mask. - When there is no approved design yet. A reference taken from a draft locks in an error.
Example
Illustrative example: a team approves the Product card component in three states: default, with an offer and sold out. They write a visual test for each one with fixed data. One day an agent changes the card’s padding to “improve the spacing” during a task on another screen. The test fails with a difference along the right edge. The designer reviews the diff, sees that the change was not in the design and asks the agent to revert it.
Without the test, that change would have reached production unnoticed.
Common mistakes
- Relying on a general impression instead of the checklist.
- Updating references without reviewing the difference. It is like accepting changes without reading them.
- Using real or random data in visual tests.
- Generating references on your laptop and running tests in CI. The renderings will not match.
- Reviewing only the default state and forgetting error, empty and loading.
- Asking an AI whether it “looks similar” and treating that answer as a test. Use AI to point things out, and your eyes and the tests to decide.