How to give your AI coding agent a feedback loop that catches its own bugs

When an AI coding agent writes code that looks right but quietly breaks something, the problem usually isn't the model — it's that the agent never saw the failure. It wrote the change, declared victory, and moved on, because nothing told it the test suite was now red. The fix is to close the loop: make the agent's own tools report back to it automatically.

This guide shows how to build that feedback loop so your agent catches its mistakes before you do.

The core idea: errors should flow back into context

A reliable agent workflow has four beats — explore, plan, build, verify. Most people stop at "build." The verify step is what separates an agent that produces working code from one that produces plausible-looking code.

Verification means running real checks after every change — your test runner, linter, and type-checker — and feeding the output back to the agent. When a check fails, the error message lands in the agent's context, and the model treats it like any other instruction: it reads the failure and fixes it. No human in the loop for the boring round-trips.

You can do this two ways: ask for it in your project instructions, or automate it so it can't be skipped.

Option 1: Just ask, in your project config

The lowest-effort version is a line in your CLAUDE.md or AGENTS.md (the plain-text instruction file most agents read on startup):

## Verification
After any code change, run `npm run typecheck && npm test`.
If either fails, fix the cause and re-run before reporting done.

This works surprisingly well — but it's advisory. A busy agent can forget, or decide a change is "too small" to verify. For anything you care about, make verification deterministic.

Option 2: Automate it with a hook

Claude Code hooks let you run a shell command in response to lifecycle events, independent of whether the model remembers to. The relevant one here is PostToolUse, which fires after the agent edits a file. As one practical hooks guide puts it, PostToolUse is built for reactions — formatting, logging, running tests — and its output is injected back into the agent's context to influence its next step.

Here's a minimal hook that runs your type-checker after any file edit and hands failures back to the agent. In .claude/settings.json:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "npm run typecheck"
          }
        ]
      }
    ]
  }
}

Now the cycle is automatic: the agent writes code → the hook runs tsc → if there's a type error, the message flows back as context → the agent fixes it → the hook runs again. The hooks reference documents how the non-zero exit code and output get surfaced to the model. This loop runs on every write, with no prompting.

Keep the loop fast and scoped

A feedback loop only helps if it's quick. A few rules of thumb:

• Run the cheap checks on every edit, the expensive ones less often. A type-check or linter on the changed file is fast. A full integration suite is not — gate that behind a Stop hook (when the agent finishes a turn) or a manual command, not every keystroke.
• Scope to what changed. Running your entire test suite after a one-line CSS tweak wastes time and floods the context. Where your tooling allows, target the affected files.
• Make failures legible. The agent only fixes what it can read. Linters and type-checkers with clear, located error messages (file:line: message) give the model exactly what it needs; a generic "build failed" does not.

A concrete before-and-after

Without a loop: you ask the agent to rename a function. It updates three call sites, misses a fourth in a file it didn't open, and reports done. You discover the broken import at runtime an hour later.

With the loop: the same rename triggers typecheck on save. tsc reports Cannot find name 'oldFn' at the missed call site. That error lands in context, the agent opens the fourth file, fixes the reference, and the next check passes — all before it tells you it's finished.

The takeaway

AI agents are good at producing code and bad at noticing when it's wrong. You close that gap by giving them the same signal you rely on: a red test, a type error, a failing lint rule — delivered automatically, right after the change. Start with one line in your project instructions, then promote your most important check to a hook so it runs whether the model remembers or not. The agents that feel "smart" are usually just the ones wired into a tight feedback loop.