You Can't Give an AI Agent a Talking-To — So Where Does the Correction Actually Go?

Why This Matters

Once agents are writing half your codebase, the bottleneck moves. It's no longer "can we produce code" — that part got easy. It's "can we correct it fast enough." Feedback is what closes that gap, and it always has been, for people. Now it has to work for machines too.

What Feedback Actually Is

Feedback is information about the gap between what someone — or something — produced and what was actually expected, specific enough that the next attempt is better. That's the whole definition. It's not praise. It's not criticism. It's definitely not a performance review. It's a correction signal, full stop. Engineering management lifted this straight from control systems: measure the output, compare it against the target, feed the delta back into the next iteration.

Every mature engineering org runs three feedback loops at three different speeds: code review (minutes to hours), 1:1s and PR retros (days to weeks), performance cycles (quarters). In the AI era a fourth loop showed up underneath all of them — the eval loop, which corrects the agent itself, often in seconds.

Why It Exists

• ▹You can't self-correct what you can't see — feedback is what makes blind spots visible, whether you're a person or a model
• ▹Silence reads as approval. Say nothing about a bad PR and you've just trained the author — or the agent's fine-tuning signal — to do it again
• ▹Fast, specific feedback compounds. One good review comment today can prevent the same mistake across dozens of future PRs, human-written or agent-written
• ▹It's the only way to calibrate trust. You can't know how much to delegate to a person or an agent without a track record of mistakes that got corrected

When to Use It — and When Not To

Give feedback when there's a real gap between what you expected and what showed up, and when whoever — or whatever — produced it can actually act on it. That second condition is the one people forget with AI. Leaving a review comment on a one-off, agent-generated PR that nobody will ever re-run is theater — the model doesn't learn from it. Put that same energy into the system prompt, the eval set, or the CLAUDE.md file instead. That's the real feedback channel for a stateless agent.

• ▹Give it immediately, while the context is fresh — for agents that means catching bad output at generation time, not three sprints later when nobody remembers the reasoning
• ▹Put it in writing if it should generalize — a line in the repo's guardrails outlives a Slack message by years
• ▹Skip it for one-off, non-repeating output with nowhere to store the correction — otherwise you're just venting
• ▹Skip vague feedback like "this feels off" on agent output — the model needs a concrete rule it can follow next time, same as a junior engineer would

Common Pitfalls

• ▹The feedback sandwich — burying the real point between two compliments. Do it enough and people stop trusting your compliments at all
• ▹Feedback with nowhere to live — telling an agent "don't do that" in a one-off chat that never makes it into CLAUDE.md or a system prompt. The exact same mistake ships again next session, guaranteed
• ▹Reviewing AI-generated code like it's human code — you start rubber-stamping because "the tests pass," while the actual failure mode of agent output is confident, plausible-looking wrong reasoning, not a typo
• ▹Confusing volume with quality — an agent will out-produce a human ten to one on PRs. If your review process doesn't scale to match, you're not reviewing anymore, you're skimming
• ▹Withholding feedback because "it's just an experiment" — experiments like evals, prompt tweaks, and agent configs are exactly where fast feedback pays off the most

The AI-Era Twist

The real shift is who — or what — is on the other end of the feedback. You're now giving it to three different recipients, and each one needs its own channel.

• ▹To a person → 1:1, PR comment, retro — same as it's always been, just at a faster cadence, because agents push more output through the pipe
• ▹To an agent's behavior → the system prompt, CLAUDE.md, or a skill file — that's the only memory a stateless model carries between sessions
• ▹To an agent's underlying capability → the eval set — if a mistake keeps recurring, turn it into a test case, so the next model version, or the next prompt tweak, has to clear that bar before it ships

That last branch, reinforcement, matters just as much as correction. If an agent — or a person — nails a hard refactor, say so out loud, and write the pattern down in a skill or a doc. That's feedback too. Most teams only ever build the correction half of this loop, then wonder why the good stuff never gets repeated.

Extend Your Knowledge

• ▹Read your team's CLAUDE.md or system prompt like it's a performance review — every rule in there is feedback someone gave an agent that didn't stick any other way
• ▹Pull your last ten PR reviews on agent-written code and count how many comments were about logic versus syntax — that ratio tells you whether you're actually reviewing or just skimming
• ▹Look at how your eval suite grew, if you have one — every test case added after a real failure is a feedback loop made permanent
• ▹In your next 1:1, split correction from reinforcement into two explicit halves and see if the conversation changes shape