Feedback lands when it names three things: the location of the problem, what you expected to find there, and the specific gap between the two. Most feedback handed to Claude Code names only the last one — "this is broken," "that doesn't look right" — and leaves the agent to guess the other two on its own.
Updated August 2026. This pattern holds regardless of which agent is doing the work, and it matters more to review quality than most advice about prompting technique. It's part of the wider picture of reviewing what your AI coding agent built — the agent can verify its own logic against its own tests, but it can't verify against your intent unless you hand that intent over in a form it can use.
A 1080p screenshot costs an agent about 2,691 tokens to read on Claude 4.7 and later, calculated from Anthropic's published vision token formula (full breakdown here; Source: Anthropic, 2026). On older, standard-tier models the same image is downscaled and costs 1,560 instead. Cheap or expensive, that image still can't tell the agent which eight pixels you're looking at, or why they're wrong. The fix that misses usually isn't a token problem or a model-capability problem — it's a naming problem. The report never said where to look or what "right" looks like.
Why do fixes miss?
Fixes miss because feedback names a feeling, not a target. "This is broken" or "the spacing is off" says something is wrong without saying where, what the correct state is, or how the current state differs from it. Without those three pieces, the agent guesses — and a guessed fix usually lands on the wrong line.
Location, expectation, and gap aren't jargon — they're the three questions an engineer silently answers before opening a file: where do I look, what should this do, and what's it doing instead? Skip any one of them in a report and the agent has to answer it by guessing, and every guess costs a turn: an attempt, a look, a "did that fix it?" that starts the loop over.
What does an agent need to act?
An agent needs enough to skip the guessing: a location specific enough to open the right file or reach the right screen, an expectation specific enough to write a test or assertion against, and a description of the actual, observed behavior. Any one of the three missing turns the fix into a search.
Broken into parts:
- Location — the file, component, screen, or state where the problem shows up. "The pricing page" is a location; "somewhere in checkout" isn't.
- Expectation — what should happen there, stated as a fact the agent could check itself against, not a feeling.
- Gap — what's actually happening instead, described precisely enough that closing it has a clear finish line.
If you're pointing at your screen while narrating this out loud, that spoken location plus a visual reference is exactly what a tool like Walkie hands the agent directly — the same workflow covered in giving your agent visual feedback without burning tokens. But the same three-part discipline works typed by hand, with nothing recording the click at all.
How specific is specific enough?
Specific enough means a second engineer, given no other context, could find the bug from your sentence alone: the file or screen, the exact state, and what deviates from the expected result. That bar holds across visual bugs, behavioral bugs, and state-dependent bugs — the three kinds that trip up an agent that can't see its own output.
The same underlying discipline, worked across three different kinds of problem:
| Problem type | Vague version | What's missing |
|---|---|---|
| Visual | "The pricing cards look off." | Which card, which edge, how far off, which browser |
| Behavioral | "The submit button is buggy." | What triggers it, what should happen once, what's happening instead |
| State-dependent | "Empty state is broken." | Which state (empty, loading, error), which screen, what renders instead |
Visual — vague: "The pricing cards look off." Visual — specific: "On the pricing page, the middle card ($39 tier) sits about 8px lower than the two beside it — they should be flush along the top edge, like the mockup. Only in Safari; Chrome renders it correctly."
Behavioral — vague: "The submit button is buggy."
Behavioral — specific: "On the contact form, clicking Submit fires the POST twice — two identical /api/contact calls, about 40ms apart, visible in the network tab. It should fire once per click; the button should disable while the request is in flight."
State-dependent — vague: "Empty state is broken." State-dependent — specific: "When the recordings list has zero items — first launch, before any recording exists — it renders a blank white panel instead of the 'No recordings yet' message. That empty-state component already exists and works on the Trash tab; it's just not wired up on the main list."
Each specific version names a location an agent can open, a state it can reproduce, and a gap it can check itself against — the same three pieces, applied to a pixel, a network call, and a data state. For more on translating vague visual language specifically, see how to describe a visual bug to an AI coding agent.
Should you say how to fix it?
Usually not — describe the symptom and let the agent diagnose the cause. Naming a mechanism you're not sure of can send a confident agent down the wrong path when the real cause is something else, like a missing debounce instead of a double-bound handler. State what you observed; flag a suspected cause only as a labeled guess.
Take the double-POST example above. "The onClick must be double-bound, fix the event listener" names a mechanism as if it were a fact. If the real cause is that the request itself isn't debounced, the agent "fixes" an event binding that was never wrong, and the bug survives with a plausible-looking diff to show for it. "Submit fires two POSTs 40ms apart, should fire once" names only what was observed — the agent is free to find whichever component actually owns the problem.
If you've already traced the cause in the code yourself, say so — a correct diagnosis saves a step, and there's no reason to withhold real information. The caution here is about guessing dressed up as a diagnosis, not about giving an agent everything you actually know.
How do you handle several problems at once?
List them separately. Give each problem its own location, expectation, and gap, numbered so the agent treats them as distinct, checkable items rather than one blurred paragraph. A single sentence naming three unrelated issues usually gets one of them fixed and the other two silently dropped.
Batched the right way, the three examples above become three checkable items instead of one vague paragraph:
- Pricing page — the middle card ($39 tier) sits ~8px lower than the flanking cards, Safari only. Should be flush along the top edge.
- Contact form — Submit fires two identical POST requests ~40ms apart. Should fire once and disable while in flight.
- Recordings list — empty state renders a blank panel instead of "No recordings yet." That component already works on the Trash tab.
Numbering does two things: it stops the agent from treating the report as one problem with three symptoms, and it gives you a checklist to verify each item against once the agent says it's done.
How do you confirm the fix?
Re-run the exact check that surfaced the bug — same screen, same input, same state — and confirm the specific expectation you named now holds. An agent's own "looks good" or "should be fixed now" isn't confirmation; matching the observed state against the expectation you wrote down is.
This is the verify step of the plan → execute → verify loop, and it's the step people skip because it feels redundant — you already watched the agent say it fixed the bug. It isn't redundant if the check is specific: reopen the pricing page in Safari and look at the card edge, click Submit once and count the network calls, load the app with zero recordings and look at the panel. If you want a fuller pass before shipping rather than checking one report at a time, the "The agent said it's done": 12-point checklist for verifying AI-built UI covers the states most reports miss entirely — empty, loading, error, and long text among them.
What to do next
Take whatever you were about to type — "the modal is buggy," "this doesn't work," "fix the spacing" — and add the three pieces before you send it: where, what should happen, and what's happening instead. That alone cuts most of the back-and-forth on a typical report, with or without anything recording the click.