How to give feedback that makes the next agent run better

When you review an agent's work and it's not quite right, you have a choice: silently fix it yourself, or turn the moment into feedback that makes every future run better. The second path compounds. Here's how to give feedback agents can actually act on.

Review is a conversation

It helps to treat review like mentoring a fast, literal junior engineer rather than grading a final exam. The output isn't a verdict; it's a turn in a conversation. Your feedback shapes the next attempt, and the next, until the work is right.

Be specific, point to the diff

"Make it better" gets you a different shade of not-quite-right. Instead, point at the change: which file, which behavior, which acceptance criterion it missed. "The coupon check should reject expired codes — see validateCoupon; add a test for the expired case" is something an agent can execute precisely.

Prefer re-dispatch over hand-fixing

It's tempting to just fix small misses yourself, and for a one-line judgment call that's fine. But for anything the agent could reasonably redo, send it back with feedback. Re-dispatching keeps you out of the weeds and produces a cleaner result than a patch grafted onto a draft you didn't fully read.

Switch agents when stuck

If an agent circles the same mistake twice, stop repeating yourself and re-dispatch the same task to a different agent. Because each run is isolated in its own worktree, trying Claude Code, Codex, or Gemini in turn costs you nothing but often breaks the logjam outright.

Capture feedback as criteria

The highest-leverage move is to stop giving the same feedback twice. When a correction recurs, bake it into the task as a constraint or acceptance criterion ("always add a test for error paths"). Now it's part of the spec, and the agent gets it right the first time from then on.

Don't just correct the diff in front of you — encode the correction so the next ten diffs don't need it.

Feedback templates that actually work

Good feedback to a coding agent has the same shape as a good task: specific, anchored, and checkable. A reliable template is "In [file/function], [the behavior that's wrong]; change it to [the behavior you want], and [add a test / preserve X]." For example: "In validateCoupon, expired codes are accepted; reject them and add a test for the expired case." Avoid the two failure modes — too vague ("make it better") gets you a different shade of wrong, and too prescriptive (dictating exact lines) wastes the agent's strength. Point at the diff, name the acceptance criterion it missed, and let the agent implement the fix. When a whole approach is off, say so at the approach level: "this should stream the data after first paint rather than block on it." Concrete feedback in, concrete fix out.

When to switch agents or escalate

Not every problem is solved by more feedback. If an agent circles the same mistake twice despite clear, specific feedback, stop repeating yourself — re-dispatch the same task to a different agent. Because each run is isolated in its own git worktree, trying Claude Code, then Codex, then Gemini costs you nothing but a click, and a fresh perspective often breaks a logjam outright. If all three struggle, that's usually a signal the task itself is underspecified or too large: break it into smaller pieces with clearer acceptance criteria, or do the tricky judgment call yourself and hand the agent the mechanical rest. Knowing when to give feedback, when to switch the model, and when to re-scope the task is the real skill of directing AI coding agents.

Building a feedback library that compounds

The highest-leverage move is to stop giving the same feedback twice. When a correction recurs — "always add a test for error paths," "match our existing naming," "don't introduce a new dependency without asking" — bake it into your task template or project conventions so it's part of every future task. Now the agent gets it right the first time, and your review gets faster because there's less to catch. Over weeks, these encoded corrections become a feedback library: the accumulated judgment of how your code should be written, applied automatically to every run. That's the compounding return on treating review as a conversation rather than a verdict — each lesson you encode is one you never have to teach again.

Key takeaways on feedback

• Review is a conversation, not a verdict — treat the output as a turn you can shape.
• Be specific and point to the diff — name the file, the behavior, and the criterion it missed.
• Prefer re-dispatch over hand-fixing for anything the agent can redo; it keeps you out of the weeds.
• Switch agents when one is stuck — a fresh model often clears a repeated mistake at no setup cost.
• Capture recurring feedback as criteria so the agent gets it right the first time on future tasks.

Done well, feedback compounds: each correction you encode is one you never have to give again, and review keeps getting faster. Command Fleet makes the loop frictionless — re-dispatch with feedback, switch agents in a click, and bake conventions into your task templates.

Frequently asked questions