Tools that check the work

You tab through a signup page for the fourth time this week, counting where the focus lands, and lose count at nine. Somewhere a link jumps the queue. You'll find it eventually. You'll also do this again next week.

Code has checkers, design mostly doesn't

When you write code, a lot of mistakes get caught for free. Types catch the wrong kind of value, linters catch sloppy patterns, tests catch broken behaviour. Visual mistakes mostly still get caught by someone squinting at a screen.

But some visual mistakes follow a rule, and a rule can be a tool. An inspector is a small tool you drop into a page during development that checks one rule by eye and copies a report you can hand to the agent. Agents are good at building these, which is the nice twist: the agent builds the tool that checks the agent.

Example one: nested corners

A rounded image inside a rounded card looks right only when the corners run parallel. The rule, called nested radius, is that the inner radius is the outer radius minus the gap between them. A 20px card with 6px of padding wants a 14px image.

Nobody remembers to check that on every card. A drop-in inspector does: hover any rounded element inside another and it shows the actual and expected radius, scans the page for mismatches, and copies them as a report.

Build a drop-in inspector for nested border radii, mounted only in development.
Hovering a rounded element inside another rounded element shows each corner's actual radius and the expected one (outer radius minus the inset between them).
Add a "Scan page" button that lists every mismatch, and a "Copy report" button that copies them as markdown with selectors, so I can paste it to you.

Example two: the focus path

Keyboard users move through a page with Tab, and the order should follow the order you read in. One stray tabindex, the attribute that controls whether and when something takes focus, can send focus to the footer first and then back to the top. An overlay that numbers every focusable element and draws the path between them makes that jump visible at a glance.

Example three: motion

A still screen can be reviewed from one frame. Motion can't, because the bug often lives in a moment that's over in a tenth of a second. So first, slow it down until you can see it.

Then, instead of a screenshot, hand the agent the frame state: the exact values of everything animating at that moment, each property's curve, its duration and how far along it is. With a screenshot, the agent can only guess "make it shorter". With the numbers, it can see which curve is wrong.

t = 300ms, menu exit
transform  done (200ms ease-out)
opacity    0.88  480ms ease-in  62%

Emil Kowalski's inspector Lapse is built for exactly this: slow motion, recording, a frozen live page, notes pinned to an element at a moment, and the state copied as text for the agent. You can do the core of it for free with the Animations panel in Chrome DevTools, which slows animations down, scrubs through them and shows each one's timing and curve. Benji Taylor's Agentation is the same idea for still UI: you point at an element and the agent gets its selector instead of your description.

Example four: a critic that only sees the picture

Some checks don't follow a neat rule. "Does this landing page look as good as the references?" is a judgment, but you can still put it in a loop. Anshu Chimala describes a critic loop: after each pass the builder takes a screenshot, and a fresh reviewer that sees only that screenshot and your reference images scores it out of ten and names the biggest gap. The builder fixes that gap and goes again, until the score reaches nine.

Two details make it work. The critic is fresh, so it judges what's on screen rather than what the builder meant. And it's measured against your references, not taste in general. Add a cap on rounds so it can't run forever.

When a tool is worth it

If you check the same thing on every page or every pull request, build the inspector. If you'll check it once, keep it as one line on a checklist. Don't let tool-building become the job. The tool is there so you can spend your attention on the parts no tool can judge.

What to remember

• When a visual check follows a rule (corner radii, focus order), have the agent build a dev-only inspector that copies a report.
• For motion, slow it down and hand over the frame state, the numbers at one moment, not a screenshot.
• Build a tool only for checks you repeat; a judgment like "is this good" can still run as a critic loop with a fresh reviewer, a score and a cap.

Go deeper: Options and tools · Performance and review · Keyboard and touch