# How to Give Feedback to Claude Code That Lands

> Feedback lands when it names the location, your expectation, and the gap between them. Reports that name only the gap force Claude Code to guess. A pasted 1080p screenshot adds 2,691 input tokens on Claude 4.7 and later, capped at 4,784, and still names none of the three.

Author: Roberto Ercole · Published: 2026-08-05 · Updated: 2026-08-16 · Canonical URL: https://usewalkie.com/blog/give-feedback-to-claude-code/

---

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.

**Updated August 2026.** This pattern holds regardless of which agent does the work, and it matters more to review quality than most advice about prompting technique. Anthropic's own guidance says the same thing in fewer words: "Claude can infer intent, but it can't read your mind. Reference specific files, mention constraints, and point to example patterns" ([Claude Code best practices](https://code.claude.com/docs/en/best-practices)).

Pasting an image does not substitute for naming those three things. A 1920×1080 screenshot costs Claude 2,691 input tokens to read on the high-resolution tier — Claude 4.7 and later, where the count is capped at 4,784 — calculated from the patch formula in [Anthropic's vision documentation](https://platform.claude.com/docs/en/build-with-claude/vision), and 1,560 on older standard-tier models after downscaling. Cheap or expensive, that image still cannot say which eight pixels you are looking at. The fix that misses is rarely a token problem or a model-capability problem. It is a naming problem.

## 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 are not jargon. They are the three questions an engineer silently answers before opening a file: where do I look, what should this do, and what is it doing instead? Skip one and the agent answers it by guessing — and every guess costs a turn.

## What does Claude Code need to act?

It 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 an assertion against, and a description of the actual observed behaviour. Any one missing turns the fix into a search.

- **Location** — the file, component, screen or state where the problem shows up. "The pricing page" is a location; "somewhere in checkout" is not.
- **Expectation** — what should happen there, stated as a fact the agent can check itself against, not a feeling.
- **Gap** — what is happening instead, described precisely enough that closing it has a clear finish line.

Anthropic's table of before-and-after prompts makes the same trade concrete: "fix the login bug" becomes "users report that login fails after session timeout. check the auth flow in src/auth/, especially token refresh. write a failing test that reproduces the issue, then fix it." Same bug, three added facts, and a verification step attached.

## 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, behavioural and state-dependent bugs — the three kinds that trip up an agent that cannot see its own output.

| Problem type | Vague version | What is missing |
|---|---|---|
| Visual | "The pricing cards look off." | Which card, which edge, how far off, which browser |
| Behavioural | "The submit button is buggy." | What triggers it, what should happen once, what happens instead |
| State-dependent | "Empty state is broken." | Which state, which screen, what renders instead |

**Visual — specific:** "On the pricing page, the middle card (the Pro 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."

**Behavioural — 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, and the button should disable while the request is in flight."

**State-dependent — specific:** "When the recordings list has zero items, 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 is just not wired up on the main list."

Each names a location the agent can open, a state it can reproduce, and a gap it can check itself against. For visual language specifically, see [how to describe a visual bug to an AI coding agent](/blog/describe-a-visual-bug-to-ai/).

## Should you say how to fix it?

Usually not. Describe the symptom and let the agent diagnose the cause. Naming a mechanism you are unsure of sends a confident agent down the wrong path when the real cause is something else — a missing debounce rather than a double-bound handler.

Take the double-POST example. "The onClick must be double-bound, fix the event listener" states a mechanism as if it were a fact. If the real cause is an undebounced request, the agent fixes an event binding that was never wrong, and the bug survives with a plausible diff to show for it. "Submit fires two POSTs 40ms apart, should fire once" names only what was observed.

If you have already traced the cause yourself, say so — a correct diagnosis saves a step. The caution is about guessing dressed up as diagnosis, not about withholding what you know.

## How do you report several problems at once?

List them separately, numbered, each with its own location, expectation and gap. A single sentence naming three unrelated issues usually gets one fixed and the other two silently dropped.

1. Pricing page — the middle card (the Pro tier) sits ~8px lower than the flanking cards, Safari only. Should be flush along the top edge.
2. Contact form — Submit fires two identical POST requests ~40ms apart. Should fire once and disable while in flight.
3. 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 treating the report as one problem with three symptoms, and it gives you a checklist to verify each item against afterwards.

## How do you stop repeating the same feedback?

Move the recurring parts out of chat and into files Claude Code loads for you. Anthropic's memory documentation gives a clear trigger for when: add to CLAUDE.md when "Claude makes the same mistake a second time," or when "you type the same correction or clarification into chat that you typed last session" ([Claude Code memory docs](https://code.claude.com/docs/en/memory)).

Three mechanisms, with different loading behaviour:

| Mechanism | Where it lives | When it loads |
|---|---|---|
| Project instructions | `./CLAUDE.md` or `./.claude/CLAUDE.md` | Every session, in full |
| Path-scoped rules | `.claude/rules/*.md` with a `paths:` field | Only when Claude reads a matching file |
| Skills | `.claude/skills/<name>/SKILL.md` | On demand, or when you type `/<name>` |

Keep CLAUDE.md short. Anthropic's stated target is "under 200 lines per CLAUDE.md file," because "longer files consume more context and reduce adherence." Procedures belong in a skill instead: Anthropic's skills documentation notes that "a skill's body loads only when it's used, so long reference material costs almost nothing until you need it" ([Claude Code skills docs](https://code.claude.com/docs/en/skills)). A review checklist you paste every session is exactly that shape.

One honest limit: none of these are enforcement. Anthropic states that Claude "treats them as context, not enforced configuration." For something that must happen every time, its guidance points to a hook, not a memory file.

## 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. The agent's own "should be fixed now" is not confirmation; matching the observed state against your written expectation is.

This is the verify step of the [plan → execute → verify loop](/blog/plan-execute-verify-loop/), and it is the step people skip because it feels redundant after watching the agent say it fixed the bug. It is not 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. For a fuller pass before shipping, the [12-point checklist for verifying AI-built UI](/blog/verifying-ai-built-ui-checklist/) covers the states most reports miss entirely.

## 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 is happening instead. That alone cuts most of the back-and-forth on a typical report.

If pointing at the screen is faster than writing the sentence, that is what [visual feedback tooling](/blog/what-is-visual-feedback-for-ai-coding-agents/) is for, and [how to run a visual review with Claude Code](/blog/how-to-run-a-visual-review-with-claude-code/) walks the setup. Before you reach for a screenshot, price it in the [screenshot token calculator](/calculator/) or read [what a screenshot actually costs](/blog/screenshot-token-cost-ai-coding-agent/) — an image is not free, and it is not a substitute for naming the three things.

---

Read the HTML version: https://usewalkie.com/blog/give-feedback-to-claude-code/