Reviewing AI-generated code means checking two different things: whether the logic is correct, which the agent already verified with its own tests, types and linters, and whether the result actually works and looks the way you meant it to, which nothing but a human eye can confirm. The agent's blind spot here is structural, not a discipline problem — it never once saw its own output rendered.
Updated August 2026. As more of the code you ship comes from Claude Code, Cursor, Codex and similar agents, the review step hasn't gotten smaller. It's moved. The agent runs its own test suite, resolves its own type errors, and reports "done" with real confidence, because by every check it's able to run, it is done. What it hasn't done is look at the page it just built. Even the fallback most people reach for, pasting a screenshot back in, costs the agent about 2,691 tokens to read on Claude 4.7 and later — calculated from Anthropic's published vision token formula, broken down in full here — and still doesn't tell it which part you're pointing at or why (Source: Anthropic, 2026). Closing that gap reliably comes down to two habits covered in full below: running a plan, then execute, then verify loop instead of stopping at execute, and reading a generated diff in a specific order instead of top to bottom.
- 2,691 tokens — what it costs an agent to read one 1080p screenshot (Claude 4.7 and later)
- 0 — how many of those tokens tell it what's wrong, or what you meant instead
Why does AI-generated code need a different review?
AI-generated code needs a different review because its author never experienced its own output. A human writes with a mental picture of the running app in mind; an agent writes code, runs automated checks, and reports success without ever seeing a rendered pixel or an actual click. Review has to cover exactly what it structurally cannot.
There's also a volume-and-fluency problem that reviewing human code doesn't have in the same way. Generated code tends to be syntactically clean and confidently structured even when it's wrong, because the model is optimizing for plausibility as much as correctness. A junior developer's mistake often looks like a mistake — a weird variable name, an obviously missing case. An agent's mistake usually looks exactly like correct code, because it was trained on correct code. That makes a fast skim less reliable on generated diffs than on human ones, even though generated diffs are often easier to read line by line.
Take a common example: an agent asked to add a loading spinner while search results fetch will confidently generate a spinner component, wire it to the fetch call, and report the task complete once its type checker and test suite are satisfied. It has no way to notice that the spinner doesn't match the page's design language, that it flashes for a few milliseconds on a fast connection and looks like a rendering bug, or that it never appears at all on a slow connection because the component unmounts before the network call resolves. None of that is a logic error. All of it is real.
The other difference is memory. When you review a colleague's pull request, you can ask them why they made a decision, and the answer carries context from before the diff and after it. An agent's context resets with the session. It doesn't remember why it chose one approach over another last week, and it won't have an opinion about the tradeoff unless you ask it to justify the change while it's still in front of it. That pushes more of the "why" burden onto the review itself — if you don't capture the reasoning during review, nobody will have it later, including the agent.
What can the agent check itself?
The agent can reliably verify anything it can run and compare against a rule: does the code compile, do tests pass, are types correct, does lint pass, did the expected files change. These are closed-loop, textual checks. It cannot verify anything that needs the running result — layout, real content, or whether the fix matches what you meant.
| What gets reviewed | Can the agent verify it? | Why |
|---|---|---|
| Type errors | Yes | Static analysis reads source text, no rendering required |
| Unit test pass/fail | Yes | Tests are just more code the agent wrote and ran |
| Lint and style rules | Yes | Pattern matching against the source |
| Whether the build compiles | Yes | Deterministic pass/fail from the toolchain |
| Whether the requested files changed | Yes | A diff is text, easy to check |
| Whether the page renders as intended | No | Requires seeing actual rendered pixels |
| Whether the layout survives real content | No | Requires real data and real screen widths |
| Whether the fix matches your actual intent | No | Requires knowing what you meant, not just what you typed |
| Whether it feels right (slow, jarring, confusing) | No | Requires a human experiencing the running app |
The agent's self-checks are genuinely valuable — they eliminate a whole category of trivial regressions before you ever look at the change, and they're cheap to run on every attempt. The mistake is treating them as a proxy for the review, rather than as the first half of it. A green test suite is evidence the code does what a test asserts. It is not evidence the feature is right, because nobody has yet compared the running result to what you actually wanted.
Consider two runs of the same task. In the first, the agent adds a field to a form, updates the type, writes a test asserting the field renders, and every check passes. In the second, the field renders, but its label overlaps the field above it on anything narrower than 380 pixels — something no test in the suite happens to check, and nothing in the agent's toolchain would think to look for unless a rendering check was explicitly wired in as one more textual comparison.
What can only you check?
Only you can check whether the output matches your actual intent, whether it looks right on a real screen with real content, whether an edge case with messy data breaks it, and whether the experience feels right rather than merely functions. These require a human perspective the agent's toolchain has no route to.
In practice this usually breaks into four categories. Intent match: does the change solve the problem you actually had, not just the literal words of the request — an agent can build exactly what you asked for and still miss what you needed. Real-content behavior: does a 40-character company name, an empty search result, or a price with four decimal places break a layout that looked fine with placeholder data. Felt experience: does a transition feel slow, does a form feel fussy to fill out, does an error message read as hostile — none of that shows up in a passing test. And cross-context rendering: dark mode, a narrow viewport, a focus ring after a keyboard tab, a slow connection.
A concrete version of this: an agent building an onboarding flow will happily generate a form, validate the fields, and pass its own tests using "Jane Doe" and "test@example.com" as sample data. It has no occasion to try a 40-character company name, a name with an apostrophe, or a screen reader tabbing through the fields in the wrong order — not because it's careless, but because nothing in its checklist asks it to.
This isn't a gap the next model release closes on its own — it's architectural, not a training limitation. Why your AI agent can't see what it built goes into why more pixels or a vision-capable model call doesn't solve it by default.
A vision-capable model can describe a screenshot once you hand it one. What it won't do unprompted is decide to open the app, click through the real flow, and check its own work — someone still has to point the camera and ask.
How do you review what you didn't write?
Reading AI-generated code top to bottom the way you'd read your own fails, because there's no narrative already in your head to follow. Start with the data shape moving through the change, then the boundaries — inputs, outputs, error paths — then the logic in between. That order surfaces the failure modes generated code produces most often, first.
Generated code fails in specific, recognizable ways once you know to look for them: an error path that catches an exception and silently does nothing instead of surfacing it, a defensive null check added on a value that can never actually be null there, a test that asserts against the function's own implementation instead of its behavior, so it stays green even when the behavior is wrong. None of those jump out on a top-to-bottom read, because that reading style assumes you'd notice if the general shape were off — and generated code's general shape is almost always fine.
Not everything needs the same scrutiny. Boilerplate and mechanical, repetitive diffs can be skimmed. Anything touching money, authentication, a data mutation, or a public API deserves the full pass — those are the places where a plausible-looking mistake does the most damage before anyone notices. How to review AI-generated code you didn't write covers that reading order and the specific failure patterns in more depth.
How do you communicate a fix so it lands?
A fix lands when your report gives the agent a precise location and a precise expectation, closing the gap between what it sees and what you mean. "The spacing looks off" gives it nothing to act on. "The card padding is 8px; it should be 16px" gives it a fact to check and a target to hit.
The difference between a report that lands and one that doesn't is rarely length. "The button looks wrong" is six words and useless. "The Save button on the settings page is filled teal — it should be outlined, like the Cancel button next to it" is barely longer, and an agent can act on it without asking a single follow-up question. The second version names the exact element, the exact deviation, and the exact target.
Visual bugs are the hardest category to put into words, because "off" is a feeling, not a fact, and translating a feeling into a coordinate takes effort most people skip under time pressure. How to describe a visual bug to an AI coding agent has a translation table from vague phrases to ones an agent can actually act on. How to give feedback to Claude Code so the fix actually lands breaks the anatomy down further, with the same bug reported badly and well side by side.
Pointing at the exact spot on screen while saying what's wrong compresses that gap further than a written report usually can, which is the premise behind Walkie: a spoken, pointed-at walkthrough turned into a review bundle the agent can read in about 3,500 tokens (measured typical), instead of a video it can't open or a stack of screenshots that cost more tokens and still leave it guessing — the same tradeoff worked through in giving your agent visual feedback without burning tokens.
What does a good review loop look like?
A good review loop runs plan, then execute, then verify, treating verify as its own step rather than something the agent's "done" message already satisfies. Planning sets the acceptance criteria before code is written; execution is the agent doing the work; verification is a human looking at the running result against those criteria, not reading a summary of it.
A workable version of that loop looks like this:
- Write the acceptance criteria before the agent starts, in plain language it can check itself against.
- Let the agent execute, and let it run its own automated checks — types, tests, lint, build.
- Stop before merging and actually open what it built.
- Compare the running result against the criteria from step one, not against the agent's own summary of what it did.
- Report back with a location and an expectation for anything that doesn't match.
- Re-verify the fix the same way. Don't take "fixed" as an answer either.
None of this has to be slow. For a typical UI change, planning is a sentence or two of acceptance criteria, execution is the agent's normal turnaround, and verification is the two or three minutes it takes to open the page and click through it. The loop breaks down not because verification is expensive, but because it's the step with no automatic prompt — nothing forces you to do it, so under deadline pressure it's the one that gets skipped.
The plan → execute → verify loop, explained covers each stage in more depth, including why verify is the step almost everyone skips — it's the only one that can't be automated away, because it requires eyes.
How do you know when it's actually done?
Code is actually done when a human has checked it against the original acceptance criteria on the real, rendered output, not when the agent's automated checks pass and it says so. "Done" from an agent means its own checks are green. It says nothing about empty states, dark mode, or whether the change solved the problem you actually had.
Treat "done" as a two-part bar: the automated checks pass, and a human confirmed the rendered result against intent. If either half is missing, what you have is "the agent believes it's done," which is a different and much weaker claim. In practice the mismatch follows a specific pattern: the agent reports the feature works, the human skims the summary instead of opening the page, and the gap between "the tests are green" and "the thing does what I needed" ships to production unnoticed until a user hits it. Closing that gap costs minutes when it's caught in review and hours when it's caught after release.
"The agent said it's done": a 12-point checklist for verifying AI-built UI lists the specific states agents most reliably miss when nobody looks — empty states, error states, focus rings and mobile width among them.
What to do next
The next time an agent tells you something is done, treat that as a claim, not a fact. Open what it actually built. Run the real command, load the real page, click through with real data instead of the happy path it tested against. If something's off, name the exact location and the exact expectation rather than the general feeling — that single habit saves more back-and-forth than anything else in this article.
None of it requires a specific tool. A notepad and two minutes of actually looking will catch most of what matters. What it requires is treating verification as a distinct step you do on purpose, with the same seriousness as writing the acceptance criteria in the first place, rather than a step the agent's own summary quietly does for you.