An AI coding agent can't see what it built because its entire working world is text. It writes code, reads file contents, and reads command output — but the actual rendering, the pixels a browser or OS draws from that code, happens somewhere it has no access to. Nothing shows it the result unless a separate tool captures it and hands it back as an image.
Updated August 2026. This gap is architectural, not a bug that better prompting fixes. It explains why an agent can be completely right about what code should render and completely wrong about what it does render — and why verifying the visible result still needs someone who can actually look.
What does an agent actually perceive?
An agent's perception is limited to text: the source code it writes, the contents of files it reads, and the terminal output of commands it runs. It has no display, no camera, and no default channel back from a rendered page or app. It can reason accurately about what code should produce without ever perceiving what actually appears on screen.
This is part of the wider picture of reviewing AI-generated code: every large language model, including the ones behind coding agents like Claude Code, works as a next-token predictor over text. Feed it a file and it reads tokens. Ask it to run a test suite and it reads the text the test runner prints. Ask it to write a component and it writes text that becomes a file.
None of that loop includes a rendered page. A browser interprets HTML, CSS and JavaScript into pixels on screen — a process with no text representation the agent automatically receives. The agent can describe what the CSS implies ("padding: 24px reads as generous spacing") because that's inference from source, not observation of a result. Those two things look similar in a transcript and are not the same operation.
Can't it just take a screenshot?
Only if a connected tool captures one and hands it back as input — nothing about an agent's default loop prompts it to check. Some coding agents can run a screenshot command or a browser-automation tool mid-task, but the tool must be wired up, and someone still has to point it at the right moment.
This capability is real. Tools built on the Model Context Protocol (MCP), an open standard for connecting an agent to external systems, can give an agent the ability to open a page and capture what's on it (Source: Model Context Protocol, 2026). Microsoft's Playwright MCP server is a working example: it lets an agent drive a browser and pull back either a screenshot or a structured snapshot of the page.
What that doesn't solve is initiative and intent. Most agents finish a task, run their checks, and report done — they don't reflexively stop to look at what rendered unless a workflow explicitly tells them to. And a screenshot captured without direction just shows a state of the page, not necessarily the one you're worried about. A full 1080p screenshot costs about 2,691 tokens on Claude 4.7 and later to read, calculated from Anthropic's published token formula — the full breakdown is here — and that buys the agent pixels, not judgment about which pixels matter.
What about vision models?
Claude's vision-capable models can genuinely read an image handed to them — accurately describing layout, colour, text, and whether an element is present. What they can't do is decide on their own to go look, know which of several similar elements you mean without being told, or infer motion and state changes from a single still frame.
This is the nuance worth getting right, because it's easy to overstate the limitation in either direction. The perception itself works: give Claude a screenshot and ask what's wrong with the header, and it will read padding, alignment, colour and text correctly. That's a real, current capability (Source: Anthropic, 2026), not a future promise.
What vision doesn't supply is agency or disambiguation. An agent won't interrupt a task to go capture a screenshot unless something in its instructions or tools makes that the obvious next step. And "the button" means nothing precise when six buttons are visible — a person pointing at one, or narrating "the save button, top right, it's the wrong colour," resolves in a sentence what a static image leaves ambiguous. Static also means static: a single frame can't show a hover state, a loading spinner that never resolves, or an animation that stutters partway through. Those are exactly the kind of visual bugs worth learning how to describe precisely rather than leaving to inference.
Why doesn't more pixels solve it?
Resolution isn't the constraint, meaning is. A higher-resolution screenshot gives the vision system more image patches to encode, which raises token cost without adding information about intent. The model can already see fine detail; what's missing is which detail matters and why, and no amount of extra pixels supplies that.
Anthropic's published formula prices an image by patches, not by file size, on Claude 4.7 and later's high-resolution tier: tokens = min(4784, ceil(width / 28) × ceil(height / 28)) (Source: Anthropic, 2026). A 1920×1080 screenshot lands at 2,691 tokens under that tier's cap — exact, not estimated. Older, standard-tier models use a lower cap and downscale first, landing at 1,560 tokens for the same image. Push resolution higher and the token count climbs toward the 4,784-token ceiling per image; it doesn't unlock new understanding, because the model was already reading the pixels that existed.
The same math gets worse fast if you skip screenshots and hand over a recording instead. A full-quality screen recording, frame-dumped at one frame per second, costs the full 4,784 tokens per frame, because a full-resolution frame exceeds the patch cap — the mechanics of why an agent ends up in this position at all are covered in why your agent can't watch a screen recording. Thirty seconds of that is 80,730 tokens (calculated) — close to 40% of a 200k context window gone before any actual fix starts.
| Fact | Value |
|---|---|
| One 1080p screenshot (Claude 4.7+) | 2,691 tokens |
| A 30-second recording, frame-dumped at 1 fps | 80,730 tokens |
| Share of a 200k context window spent before the fix begins | ~40% |
What closes the gap?
Two things together: something that captures the actual render as pixels, and something that carries your intent about what's wrong and where. A screenshot supplies the first alone. Pointing at the screen while describing the problem supplies the second. Neither one by itself gets an agent to correct judgment about what it built.
Line up what each option actually hands the agent:
| Method | Tokens | Pixels included | Intent included |
|---|---|---|---|
| No image, code only | 0 | No | No |
| One pasted screenshot | ~2,691 on Claude 4.7+ (calculated) | Yes, one moment | No |
| 30s recording, frame-dumped | ~80,730 (calculated) | Yes, redundant | No |
| Narrated, pointed review | ~3,500 (measured typical) | Yes, selected | Yes |
The pattern: pixels alone, at any quantity, don't carry a reason. A narrated, pointed review — speaking while pointing at the specific spot that's wrong — adds a transcript that typically runs about 150 tokens (measured, range 100–200) on top of the selected frames, and that transcript is what tells the agent why a frame matters, not just that it exists. That approach is worked through in giving your agent visual feedback without burning tokens, and it's the same idea behind a REVIEW.md bundle: pair the capture with the reason.
Closing the gap in practice usually means:
- Capture the actual render — a screenshot, a recording, or a live browser tool.
- Select the moment that matters — a person doing this beats a script guessing.
- Attach the reason — what's wrong, where, and often what right looks like instead.
A tool that does all three in one pass — record, point, narrate, hand the agent a short bundle instead of a raw video — is the idea behind Walkie itself. It's one way to close the gap; a screenshot with a clear, specific caption, done by hand, closes the same gap for free.
Whose job is this?
Verification of what AI-built code looks like is a human job, for now. An agent can confirm what it can observe: that code compiles, tests pass, and logic holds. It can't confirm the layout reads correctly, an empty state doesn't break, or an animation feels right, because none of that is visible to it by default.
This isn't a complaint about current models; it's a description of where the responsibility sits until tooling changes. Treat it as a division of labour: let the agent verify what's checkable in text — types, tests, logic, error handling — and keep visual verification as a step a person still owns. A structured pass through what AI-built UI reliably gets wrong is a faster way to run that step than eyeballing the whole page from scratch.
Better browser tools and better vision models are narrowing this gap, not closing it. An agent with a wired-up screenshot tool and a vision model can now do more of the loop than it could two years ago. What it still can't do on its own is decide, mid-task, that something looks wrong — that judgment call is still the human half of the loop, and probably will be for a while yet.
What to do about it
Next time an agent reports a UI task done, don't take its word for the part it structurally can't see. Open the app yourself, or hand it a screenshot with a specific caption — either closes more of the gap than trusting a passing test suite alone. If you're doing this often enough that typing out captions is the slow part, a narrated pass over the screen carries the same information for less typing. How you capture it matters less than making sure the agent actually receives both the render and the reason, not just one or the other.