Twelve states account for most of what an AI coding agent ships broken without knowing it: empty data, loading, errors, long text, dark mode, keyboard focus, mobile width, disabled buttons, first-run versus returning, slow network, list counts, and reduced motion. Checking all twelve after the agent says "done" is the fastest way to catch what it couldn't see itself.
Updated August 2026. This list is the practical half of the wider question of how to review what your AI coding agent built: the agent can tell you its tests pass, but it can't tell you what a screen looks like once a real person opens it. Below is exactly what to look at for each of the twelve, why it's easy for an agent to miss, and the fastest way to force the state to appear.
Why does "done" not mean done?
An agent's "done" means the code compiled, the tests passed, and the happy path worked when it checked. It says nothing about the states nobody prompted it to hit: empty data, a slow connection, dark mode, or a name twice as long as the one in its own test fixture.
That gap isn't sloppiness, it's architectural. Your agent can't see what it built the way you can: its world is the code, and, if it bothers to check, one static screenshot of one moment. Checking its own work costs tokens too. On Claude 4.7 and later, a real 1080p screenshot runs 2,691 tokens, calculated from Anthropic's published vision formula — the full token math is here; older standard-tier models downscale the same image and pay 1,560 instead (Source: Anthropic, 2026). So agents that do check tend to check once, not once per state below.
2,691 tokens — the cost for one 1080p screenshot on Claude 4.7 and later: the single frame an agent could take to check its own work.
The twelve checks
These twelve states cover most of what ships visually broken: no data, a pending request, a failed one, text that runs long, dark mode, keyboard-only navigation, a phone-width screen, a mid-action button, a second visit, a slow connection, the edges of a list, and motion turned off.
Each one below gets what to look at, why it's easy for an agent to miss, and the fastest way to force it to happen right now, without writing a single test.
| # | Check | Fastest trigger |
|---|---|---|
| 1 | Empty states | Wipe the data, load on a fresh account |
| 2 | Loading states | Throttle the network to Slow 3G |
| 3 | Error states | Kill the API mid-request |
| 4 | Long text & overflow | Paste a 50+ character name into every field |
| 5 | Dark mode | Toggle the theme switch |
| 6 | Focus rings & keyboard nav | Tab through with the mouse down |
| 7 | Mobile width | Load the page at 375×667 |
| 8 | Disabled states | Submit before the form is valid |
| 9 | First-run vs. returning | Reload after completing the flow once |
| 10 | Slow network | Throttle, then interact mid-request |
| 11 | Zero / one / many | Go to 0 rows, then 1, then 50 |
| 12 | Reduced motion | Turn on Reduce Motion, then retrigger |
1. Empty states
What to look at: the very first screen a brand-new user or an empty list sees, before any data exists. Why agents miss it: agents build and test against a database that already has rows in it, so a genuinely empty state only appears if someone deliberately clears the data first. Fastest trigger: wipe the table (or local storage) and reload on a brand-new account.
2. Loading states
What to look at: what renders between the request firing and the response landing — a spinner, a skeleton, or nothing at all. Why agents miss it: on a local dev machine most responses resolve in milliseconds, so the loading state exists in the code but is rarely actually seen. Fastest trigger: throttle the network to Slow 3G and watch the first render.
3. Error states
What to look at: what a user sees when the request fails — a timeout, a 500, a rejected form. Why agents miss it: the agent's own check runs against a working backend, so it has no reason to make anything fail. Fastest trigger: stop the API server, disconnect the network mid-request, or force a 500 from devtools' network overrides.
4. Long text and overflow
What to look at: names, titles, and labels at their real maximum length, not the short placeholder the agent typed. Why agents miss it: a fixture an agent writes for itself is almost always short, and it has no reason to generate a name longer than the one it typed. Fastest trigger: paste a 50-character name into every text field on the screen.
5. Dark mode
What to look at: text contrast, icon visibility, and any image or gradient with a background color baked in. Why agents miss it: most local dev environments default to one theme, so a CSS variable can exist in the code without ever being checked against a dark background. Fastest trigger: toggle the theme switch and step through every screen just built.
6. Focus rings and keyboard nav
What to look at: whether tabbing through the screen moves focus in a sane order, and whether focus is ever visible.
Why agents miss it: agents interact with a page through the DOM or a mouse-click simulator, not a keyboard, so a missing :focus-visible style never registers as a failure.
Fastest trigger: put the mouse down and tab through the entire screen from the top.
7. Mobile width
What to look at: the layout at real phone width, not a desktop browser window resized smaller. Why agents miss it: a component can pass every check at desktop width while silently overflowing at phone width, and agents rarely open a device emulator unprompted. Fastest trigger: open devtools' device toolbar and load the page at 375×667.
8. Disabled states
What to look at: buttons and inputs mid-action or pre-condition — a submit button before the form is valid, a button while a request is in flight. Why agents miss it: a happy-path check clicks the button once, when it's already enabled, and never tries it a moment too early. Fastest trigger: try to submit before filling in the form, then double-click submit to see if it fires twice.
9. First-run vs. returning
What to look at: whether onboarding, tooltips, and empty-state prompts reappear for someone who's already seen them. Why agents miss it: every test run starts from a clean slate, so first-run and returning look identical to an agent with no session history to compare against. Fastest trigger: complete the flow once, reload, and confirm the welcome tour doesn't play again.
10. Slow network
What to look at: whether the interface stays usable, not just whether it eventually loads, when a request takes several seconds. Why agents miss it: the same root cause as loading states, but compounding — a slow request also lets a user click twice or navigate away mid-request, which an instant response never exposes. Fastest trigger: throttle to Slow 3G and try to interact with the page while a request is still pending.
11. Zero / one / many list counts
What to look at: a list with zero items, exactly one, and enough to force scrolling or pagination — three different layouts, not one. Why agents miss it: seed data is usually three to five tidy rows, which happens to be the one count that never breaks a grid, a plural label, or a "showing X of Y" string. Fastest trigger: delete down to zero rows, then to exactly one, then paste in fifty.
12. Reduced motion
What to look at: whether animations respect a user's reduced-motion setting instead of running regardless. Why agents miss it: the setting lives in OS accessibility preferences that an agent's environment doesn't have and wouldn't think to set, so the code path exists but is never exercised. Fastest trigger: turn on Reduce Motion in system accessibility settings and retrigger the same animation.
Which fail most often?
The checks that need no user interaction to surface fail most: empty states, dark mode, and long text, because an agent's own test run never needs a genuinely empty database, a dark theme, or a name longer than the one it typed. Transient states — loading, error, slow network — fail almost as often, for the same root cause.
None of this means the agent did a bad job on the states it did check. The happy path, correctly implemented, is real work. The gap is specifically in the states a normal build-and-verify loop never has a reason to visit on its own.
How long should this take?
A full pass through the checklist is quick once you know the triggers, because most are a single devtools toggle, a pasted string, or a flipped OS setting, not a rebuild. The first pass on a new feature takes longer while you locate each toggle; after that it's a habit built into how you already look at a screen.
Run the full twelve on a new screen or a substantial feature. On a smaller change, spot-check whichever checks that change actually touches — a copy edit doesn't need a dark-mode pass, but any new list view needs the zero/one/many check every time, because that's exactly where seed data lies to you.
How do you report what you find?
Report each failing check by name, not a vague description — "the loading state has no spinner" beats "it looks broken while it loads." Screenshotting every failure adds up: four screenshots to cover one page already run 10,764 tokens with zero narration attached (Source: Anthropic, 2026). Narrating it in place, the approach covered in giving your agent visual feedback without burning tokens, costs a fraction of that.
The same principle applies as giving feedback that actually lands: name the location, state the expectation, state what actually happened. That's also most of what it takes to describe a visual bug precisely instead of vaguely. A short, repeatable report format beats a running back-and-forth:
- Name the check that failed, using the table above.
- State what you expected at that check.
- State what actually happened instead.
- Note whether it's every case or one edge case.
- Send it as one message, not a stream of commentary.
Narrating the twelve checks as you trigger them, instead of screenshotting each one after the fact, is the job Walkie is built around: record once, point at what's wrong, and hand the agent a bundle instead of a pile of images.
Bookmark the table above and run it once against whatever an agent just told you was done. Twelve checks, a few minutes, no new tooling required — just the OS settings and devtools panels already open on your machine.