Give Claude Eyes: A Screenshot Feedback Loop for Better AI UI

Why does Claude ship UI that looks broken when it says it is done?

A language model writing JSX is working blind. It predicts markup and class names, but it never sees the rendered result: the hero headline that wraps into four lines on a phone, the card grid that leaves an orphan, the grey-on-grey caption that fails contrast, the sticky header that hides the first heading. The Chrome team framed the problem exactly when it launched Chrome DevTools MCP: coding agents 'are not able to see what the code they generate actually does when it runs in the browser.' Anthropic's best practices page says Claude stops when the work looks done, and without a runnable check you become the verification loop, noticing every mistake yourself. Prompts and design rules (see our pillar post Why AI Websites Look the Same) set the direction; screenshots are how the model finds out whether it got there.

• •Text-only review catches syntax and logic, not overflow, collisions, cramped spacing or weak hierarchy.
• •Most layout bugs only appear at one breakpoint, so a single desktop check misses them.
• •A screenshot turns 'make it look better' into a concrete diff the model can list and fix.
• •Anthropic recommends asking Claude to show evidence, such as a screenshot, rather than asserting success.

What does Anthropic recommend for verifying UI changes visually?

The Claude Code best practices documentation lists 'Verify UI changes visually' as a core strategy. Its before example is the vague 'make the dashboard look better'. Its after example is: paste a screenshot, 'implement this design. take a screenshot of the result and compare it to the original. list differences and fix them.' The page names a browser screenshot compared against a design as one of the checks that closes the loop, alongside tests, build exit codes and linters, and suggests three ways to make the check stick: ask for it in the same prompt, set it as a /goal condition that a separate evaluator re-checks after every turn, or enforce it with a Stop hook that blocks the turn from ending until a script passes. It also recommends a second opinion: a verification subagent in a fresh context grades the work, so the agent that wrote the code is not the one marking it.

Playwright MCP vs Chrome DevTools MCP vs Claude in Chrome: which should you use?

Three tools give Claude a browser today, and they overlap more than they differ. Playwright MCP, from Microsoft, is the most common choice for local development and CI-like runs. Chrome DevTools MCP, from the Chrome team, adds DevTools depth: performance traces, CSS inspection and a Lighthouse audit tool. Claude in Chrome is Anthropic's browser extension, connected to Claude Code with the --chrome flag, and it drives your real, signed-in Chrome window. Microsoft also now points coding agents to playwright-cli, a command-line version exposed as skills, because CLI calls avoid loading large tool schemas and accessibility trees into context. Pick one primary tool per project and write its name into your CLAUDE.md so every session uses the same one.

Snapshot or screenshot: which one actually helps design quality?

This trips up most people setting up Playwright MCP. By default it works from Playwright's accessibility tree, not pixels; its README says it needs no vision model and operates on structured data. The browser_snapshot tool returns that tree and is what Claude uses to click and type. The tool description for browser_take_screenshot is explicit: you cannot perform actions based on the screenshot, use browser_snapshot for actions. So snapshots are for navigation and semantics, and screenshots are for judging how the page looks. For design review you need the screenshot, because spacing rhythm, alignment and contrast do not exist in an accessibility tree. Use both: the snapshot reveals a button with no accessible name, the screenshot reveals it sits off the grid. Chrome DevTools MCP mirrors the split with take_snapshot and take_screenshot. Coordinate-based clicking in Playwright MCP is an opt-in extra under --caps vision; you do not need it for visual review.

• •browser_snapshot: structure, roles, labels and element refs. Cheap, precise, blind to style.
• •browser_take_screenshot with fullPage true: the whole scrollable page, for hierarchy and rhythm.
• •scale 'css' keeps images small and consistent; 'device' gives high-resolution captures when you need to inspect type rendering.

How do you set up the screenshot, critique, fix loop step by step?

Here is the loop we run on landing pages and marketing sites, written so you can paste it into a project. It assumes a dev server on localhost:3000 and Playwright MCP, but the same steps work with Chrome DevTools MCP by swapping tool names (resize_page and take_screenshot). Keep the loop bounded, around three rounds, so old screenshots do not crowd the context; after two failed corrections on the same issue, Anthropic's advice is to clear context and restart with a sharper prompt.

Why test at 375, 768 and 1440 pixels?

These three widths cover a modern phone, a portrait tablet and a typical laptop or desktop canvas, and they straddle the breakpoints most Tailwind and CSS frameworks use, so a layout that survives all three rarely breaks badly in between. They are also what Patrick Ellis's open-source design-review agent for Claude Code (the OneRedOak claude-code-workflows repository) tests: a 1440 pixel desktop viewport with a screenshot, 768 for tablet layout adaptation, and 375 for touch optimisation, with an explicit check for no horizontal scrolling or element overlap. Do not skip 768: tablet is where two-column grids squeeze and navigation menus collapse awkwardly. The point is a fixed list that runs every time, and in Playwright Test you can encode it as projects using device presets such as devices['iPhone 13'] or a custom viewport object.

What should Claude check in each screenshot? A design critique rubric

A rubric turns taste into checks a model can apply consistently. Save this as docs/design-review.md, reference it from CLAUDE.md, and have the critique step cite rule names. It borrows from Nielsen Norman Group's definition of visual hierarchy (organising elements so the eye consumes them in order of importance, using color and contrast, scale and grouping) and from WCAG 2.2 for the measurable parts.

Which automated gates should back up the visual loop?

Model critique is good at hierarchy and rhythm and unreliable at exact measurements, so pair it with deterministic tools that return pass or fail. Each one below is something Claude can run and read in the conversation, which is the property Anthropic's guidance asks for. Wire them into a Stop hook or CI so a session cannot finish with them red.

• •Playwright visual regression: await expect(page).toHaveScreenshot() saves a baseline on the first run and fails on pixel drift afterwards; update intentionally with npx playwright test --update-snapshots, and set tolerance with maxDiffPixels. Generate baselines in the same environment you test in, since Playwright warns rendering varies with OS, browser version, hardware and headless mode.
• •Accessibility scans: @axe-core/playwright with new AxeBuilder({ page }).withTags(['wcag2a','wcag2aa','wcag21a','wcag21aa']).analyze(), asserting violations equal an empty array. Deque says axe-core finds on average 57 percent of WCAG issues automatically, and Playwright notes automated testing cannot detect every violation, so keep the human pass.
• •Lighthouse: Chrome DevTools MCP's lighthouse_audit tool scores accessibility, SEO and best practices from inside the session (performance needs performance_start_trace). For CI, Lighthouse CI (npm install -g @lhci/cli, then lhci autorun) can fail builds when scores regress.
• •Core Web Vitals budget: web.dev's good thresholds are LCP within 2.5 seconds, INP of 200 milliseconds or less and CLS of 0.1 or less, measured at the 75th percentile. Our post on Framer Motion and GSAP animations with Claude covers keeping CLS in check.
• •Console: fail the run on any console error or 404 asset.

What goes wrong with AI visual testing, and how do you avoid it?

The loop is simple, but a few failure patterns show up again and again when teams first switch it on.

How do you make the loop automatic in every Claude Code session?

Instructions only help if they run every time. Put a short Visual verification block in CLAUDE.md: after any front-end change, capture the changed routes at 375, 768 and 1440, critique against docs/design-review.md, fix Blockers and High items, and attach final screenshots. The OneRedOak repository ships a similar CLAUDE.md snippet (navigate to each changed view, compare against design principles and a style guide, take a full-page desktop screenshot, check console messages) plus a design-review subagent that triages findings as Blocker, High-Priority, Medium-Priority or Nitpick. R.A. Parks describes the same pattern on his blog, with a reviewer subagent that produces graded reports. For hard enforcement, Anthropic documents Stop hooks that block a turn from ending until your script passes, which is the right home for toHaveScreenshot and axe checks. At Tech Arion we keep the rubric and the viewport list in the repo next to the design tokens, so every session, human or agent, reviews against the same rules; if you want that setup on your own site, our vibe coding service at techarion.com/services/vibe-coding includes it.

Frequently asked questions

Short answers to the questions developers ask most when wiring screenshots into Claude.