Feedback Loops That Let Coding Agents Learn From Failures

A coding agent that runs off a bare language model reads a prompt, spits out text, and stops. It cannot run the code it just wrote. It cannot open a file nobody handed it. It has no way to check if it got the answer right, per Mechtaev's software engineering course notes at Peking University. That's the whole problem in three sentences, and everything below is about the workarounds people have built to fix it.

Every session starts from zero, too. No memory of yesterday's codebase, no record of the fix a reviewer asked for last week, nothing carried over. So when a human catches a mistake in code review, the agent will happily make the exact same mistake next Tuesday, because nothing told it not to. That's not a reasoning problem. It's a visibility and memory problem, and mixing those two up is how teams end up blaming the model for something the model was never built to do.

Owain Lewis described a workflow trap in 2025 as: agent, then you, then terminal, then you again, then copy and paste, then back to the agent. Owain Lewis described it in 2025 as: agent, then you, then terminal, then you again, then copy and paste, then back to the agent. Each loop closes in minutes, but only because a human is standing there closing it manually. The developer becomes the slowest component in a system that's supposed to move fast. Left unfixed, this is the default state of things. Failure isn't the exception here, it's the operating mode.

How often agents fail in production, and what the failures look like

Start with the headline numbers, because they're rough. Industry analysis from bex.co put production failure rates for AI agents between 70% and 95%, and found that roughly 88% of agent projects never make it to production. Those numbers alone tell you almost nothing useful, though, because "failure" is a pile of different things wearing the same trench coat. It's a pile of different things wearing the same trench coat.

The MAST taxonomy (Cemri et al.) dug into 1,642 execution traces across five multi-agent frameworks and pulled out 14 distinct failure modes. Two dominate the count. Step repetition, the agent doing the same thing over and over without noticing, accounted for 17.14% of failures. Mismatches between what the agent reasoned it was doing and what the tool layer actually executed accounted for 13.98%. Those two alone cover almost a third of everything that goes wrong.

Then there's the tendency for fixes to introduce regressions, and this one's uglier than it sounds. The SWE-CI benchmark, covered by Engineers Codex, found that most models introduce regressions on more than 75% of tasks. The zero-regression rate (the share of tasks where the model didn't break something that was already working) sits below 0.25 for most models tested. Translation: fixing one thing while breaking another is a common event. It's closer to the norm.

Real-world data backs this up. Across 456,000 agent-authored pull requests spanning 61,000 repositories, actual acceptance rates are between 35% and 64%, according to research published on arxiv.org (2606.17799v2). That's a long way below the numbers you see on benchmark leaderboards. Speaking of which: a 2025 audit of the top 30 SWE-bench leaderboard entries found that 19.78% of "solved" cases were semantically wrong. They passed the unit tests by accident, or by gaming the eval harness, not by writing correct code. So even the scoreboard lies a bit.

One more data point, and it's a useful one. A study of 20,574 coding-agent sessions across 1,639 repositories found that 90.50% of misalignment episodes cost time and trust rather than causing real damage, no data got deleted, nothing caught fire. But 91.49% of visible fixes still needed a human to step in and correct the agent directly. The study grouped these misalignments into seven recurring buckets: how the agent reads a project, how it interprets what the developer actually wants, how well it follows stated rules, how it bounds its own actions, how it implements and runs code, and how it reports progress. Those seven categories are basically the job description for every feedback mechanism discussed below.

The observability gap that makes human-only feedback structurally insufficient

Bugs live inside code logic and execution state. Bugs live inside code logic and execution state. Humans, meanwhile, only see the output layer, the finished PR, the passing or failing build. Research into agent observability points out that the mapping from internal state to visible outcome is many-to-one: lots of different internal failures can produce the exact same symptom on the surface. So symptom-level feedback, which is basically all a human reviewer has to work with, can't reliably point back to the actual root cause.

What happens as a result is oscillation. It's oscillation. The agent keeps circling the same wrong answer, tweaking things at random, because nobody's told it which internal wire is crossed. Related research found that injecting even minimal code-level knowledge, giving the agent a sliver of insight into what's actually happening under the hood, restored convergence in experiments. That's a strong hint the bottleneck was never the agent's coding ability. It was never being shown the right information.

Practitioner data lines up with this almost exactly. LangChain's 2026 State of Agent Engineering report, which surveyed more than 1,300 people building agents for a living, found that 89% of production teams had set up observability. Only 52% had set up evaluations. That's a 37-point gap, and it's exactly where agent quality quietly rots. Teams can see what the agent did. They just have no structured way to judge whether it was any good, and no way to feed that judgment back into the next run.

Anthropic's 2026 Agentic Coding Trends Report adds a ceiling to the picture. Developers report being able to fully hand off only 0% to 20% of tasks, even in workflows where AI touches roughly 60% of the work. The rest still needs a human checking, steering, approving. Logging what an agent did is not the same as evaluating whether it should have done it. One's a security camera. The other's a judge. Production teams have plenty of the first and not nearly enough of the second.

Verbal self-critique as the simplest feedback loop: how Reflexion works and where it breaks down

Reflexion, presented at NeurIPS in 2023, skips the expensive route of retraining model weights. Instead it has the agent write its own postmortem in ordinary language after each failed attempt. A separate self-reflection model reads the attempt and the reward signal, drafts a short verbal critique, and drops it into a memory buffer. Next attempt, the agent reads its own past notes before it does anything.

The number that got people's attention: Reflexion hit 91% pass@1 accuracy on HumanEval, up from a prior best of 80%. That's a real jump, so consider what made it possible before getting excited. The trick is that HumanEval hands back a clean, binary signal, unit tests either pass or they don't. Verbal self-critique works beautifully when the feedback it's reacting to is crisp and unambiguous.

It falls apart the moment the problem is search. If an agent is lost somewhere in a massive search space, telling it "try different search terms next time" doesn't narrow anything down, per a research log from beancount.io. Verbal reflection is not a substitute for an actual exploration strategy. It's a note to self.

Owain Lewis's 2025 practitioner advice translates this into something usable today: put instructions in a CLAUDE.md file (or whatever your tool's equivalent is) that tell the agent to run its own tests, read the output itself, fix what's broken, and re-run before calling it done. That's the first rung of a closed loop, the agent checking its own work instead of shipping something and waiting for a human to relay the bad news. Reflexion works when the evaluator hands back a clean verdict. The next question is what happens when it doesn't.

Execution feedback as a training signal: reinforcement learning from test results

RLEF, published at ICML 2025 as a spotlight paper by Gehring, Zheng, Copet, Mella, Cohen, and Synnaeve, takes the idea a step further. The model writes a solution, the solution gets checked against public tests, failures generate feedback, and the model tries again. The full trajectory, every attempt and every piece of feedback along the way, gets fed into a reinforcement learning process aimed at producing correct final code as judged by a separate, private set of tests.

The loop in practice: the model writes code, a sandbox runs the tests, and the pass/fail result along with specific error messages and runtime numbers becomes the reward. RLEF produced large gains across models of different scales, beating prior approaches while needing roughly an order of magnitude fewer samples to get there.

The difference from Reflexion matters. Reflexion's feedback is text that gets read again within the same session. RLEF's feedback reshapes the model's actual policy through training, so the improvement sticks around across sessions instead of resetting every time. That durability comes at a cost, though: RLEF needs a sandboxed execution environment, a test suite whose results can be trusted, and real compute to run the RL training. A team plans this deliberately as part of a training pipeline decision. It's a training pipeline decision, made deliberately.

Compiler and language server feedback as a dense, intermediate signal

Test results tell you the final answer was wrong. They don't tell you where, or why. That's the gap compilers and language servers fill, and it's a gap agents fall into constantly: they hallucinate APIs that don't exist, drift onto the wrong symbol, and apply edits with no evidence the surrounding code still compiles, according to research on the RLCSF paper. Text-level guessing outruns what's actually true about the program.

The frustrating part is that compilers, type checkers, and language servers already compute all of this. Diagnostics, symbol resolution, type info, references, safe-refactor checks, it's all sitting right there. It's just packaged for a human clicking around an IDE, not for a learning loop consuming it automatically.

RLCSF treats every tool interaction, looking up a symbol, requesting a diagnostic, previewing a rename, applying an edit under a safety check, as one step in a chain, and builds a reward out of how diagnostics, symbol confidence, and edit safety actually change from step to step. A companion piece, Lanser-CLI, takes what would normally be a throwaway language-server session and turns it into a replayable bundle with pinned environment details and stable content hashes, so that compiler feedback becomes something a learning system can reuse.

The value here is density. Instead of one verdict at the very end (pass or fail), the agent gets dozens of small verdicts along the way: did this edit stay safe, did this symbol resolve, did the diagnostics get better or worse. RLEF scores the finish line. RLCSF scores every step leading up to it. Put together, they cover both ends of the race.

Cross-session learning: accumulating behavioral rules from review feedback

Reflexion, RLEF, and RLCSF all operate within a session or a bounded training run. Carrying improvements forward into future sessions still requires either retraining the model or manually updating the prompt.

A closed-loop framework described in a July 2026 paper takes a more direct route. Every review comment a human accepts gets written down as a permanent rule. Over time, the set of error types the agent can catch on its own, before it even submits code, keeps growing. Three pieces make this work: a rule list kept in a version-controlled file, a self-review checklist the agent runs through before submitting anything, and automated checks that validate the rule set as it grows.

Real deployment data shows this: across 11 recorded sessions on a system with more than 35 microservices, the rule set grew from 5 rules to 18. Across 11 recorded sessions on a system with more than 35 microservices, the rule set grew from 5 rules to 18, plus more than 15 language-specific standards and a 15-item self-review checklist, all pulled straight from actual review comments (arxiv.org/html/2607.13091v1).

A per-project notes file that the agent reads and edits on its own can quietly go stale. Code moves on, the notes don't, and the agent ends up reintroducing bugs that were already fixed. Rule accumulation isn't free maintenance. It needs its own upkeep. And the whole mechanism is only as strong as the review process behind it. The whole mechanism is only as strong as the review process behind it.

Evolutionary and hierarchical approaches for long-horizon improvement

AlphaEvolve, which Google DeepMind unveiled in May 2025, takes a completely different shape. It's an evolutionary coding agent that runs an ensemble of models, Gemini 2.0 Flash for churning out a high volume of candidate solutions fast, Gemini 2.0 Pro for occasional higher-quality suggestions, and improves algorithms through repeated evaluator scoring.

The loop, in this case, is the evolution itself. Every candidate gets scored, and that score decides what the next generation of mutations looks like. There's no finish line. The agent just keeps improving, generation after generation. AlphaEvolve is closed-source and depends on proprietary models, which makes it hard to reproduce, according to a paper on arxiv.org (2510.14150v4). Teams that need to audit the system or swap in a different model are out of luck here.

A separate approach, PARC (Orimo et al., December 2025), builds self-assessment into a hierarchical structure designed to handle situations where errors pile up over very long computation horizons, and one bad early decision can quietly poison everything downstream.

There's also a design pattern: the self-healing agent. It's built from an error-trace analyzer that hunts down root causes, a self-repair module that generates a better reasoning path once the cause is found, and an episodic memory patch store that keeps good fixes around for reuse later. What ties all of these together is a shift in how feedback gets treated. It's not a one-time correction anymore. It's a continuous score that drives ongoing search, and that shift means the evaluator, the thing doing the scoring, becomes the actual engineering challenge, not the model generating candidates.

Loop engineering as the discipline that ties the mechanisms together

All of this adds up to a discipline, and it has a name now: loop engineering. Boris Cherny of Claude Code and Andrew Ng, in his June 2026 Batch letter (both cited via AI Builder Club, June 2026), describe it as designing the loop an agent runs inside: what happens between tool calls, when the agent checks its own work, how it decides it's actually finished. Where prompt engineering was about wording the ask correctly, loop engineering is about designing the whole system the ask lives inside.

The core insight is blunt: the generator isn't the bottleneck anymore. Models are good at writing code now. The scarce skill is defining what "good" and "done" actually mean, and building a system that can check for those things without a human hovering over every step.

Andrew Ng's June 2026 letter lays out three nested loops, running at three different speeds. The agentic coding loop runs every few minutes: the agent writes, tests, and iterates against a spec, and it can verify its own work because the test suite gives it a clean answer. The developer feedback loop runs over tens of minutes to hours: a person reviews what came out, steers the agent, and updates the spec, because this is the part that actually needs human judgment. And the external feedback loop runs over days or weeks: alpha testers, A/B tests, real production data slowly feed back into what the spec should have said. It's the slowest loop of the three, and also the one that catches everything the other two were never built to see.