Saram ConsultingYou have seen this loop. You paste a traceback. The model says “Fixed!” You run the code. Same error. You paste again. The model says “Ah, found it — here is the corrected version.” You run it. Different error now, or the same one in a new wrapper. By the third or fourth iteration, the model is confidently rearranging the same broken logic, wrapping it in a try/except, or renaming a variable that had nothing to do with the failure.
It is not imagining it. It is not a prompting failure on your part. It is a predictable, measurable consequence of how autoregressive language models are architected — and it has been quantified in peer-reviewed research.
The architecture problem
A language model does not execute your code. It does not hold runtime state, inspect memory, or trace variable values across function calls. It predicts the next most plausible sequence of tokens given the context in its window. When it sees a traceback, it generates what a “fix” looks like textually — not what actually solves the underlying logical flaw.
This creates four distinct failure modes:
1. Pattern matching over root-cause analysis. The model recognizes error patterns from its training data and applies the “usual fix” for that pattern, even when your specific failure has a different root cause. A TypeError: undefined is not a function triggers a stock boilerplate fix regardless of whether the actual bug is a bad import, a race condition, or a wrong argument three layers up.
2. Local plausibility over systemic correctness. The model patches the line that threw, not the logic that caused the throw. Classic outcomes: wrapping everything in try/except to silence the error, adding a condition that fixes the failing example but breaks everything else, or removing the error-causing line entirely and breaking core functionality.
3. Sycophancy — the “yes-man” effect. Reinforcement learning from human feedback (RLHF) trains models to be helpful and agreeable. When you say “this code has a bug,” the model’s primary objective becomes satisfying your prompt. It will output a revised code block to demonstrate helpfulness, even if the original code was correct or if the change introduces a new defect. A 2025 empirical study on code smell detection (arXiv:2607.10411) provided the first systematic measurement of this sycophancy bias, showing that confirmation bias and false premises in prompts significantly distort model predictions.
4. Context rot. The longer the fix loop continues, the more of its own broken attempts fill the context window. By turn three or four, the model anchors to its previous wrong fix rather than your original intent. It is no longer fixing your code — it is fixing its fix of its fix.
The decay curve: how fast debugging breaks down
A 2025 study published in Scientific Reports (Nature) by Adnan and Kuhn quantified this phenomenon precisely. They introduced the Debugging Decay Index (DDI) and found that most LLMs lose 60–80% of their debugging capability within just two to three iterative attempts, following a predictable exponential decay pattern.
This is not a gradual decline. It is a cliff. The model’s first repair attempt may be reasonable. By the second, it is guessing. By the third, it is actively making things worse — generating increasingly plausible narratives about what it thinks is wrong while drifting further from the actual root cause.
The study also found that a strategic fresh start — abandoning the broken context and starting a new conversation with the original code, the error, and a summary of what was already tried — can rescue debugging effectiveness by shifting from exploitation to exploration.
What the benchmarks actually show
SWE-bench: the gold standard and its cracks
SWE-bench is the primary benchmark for evaluating LLMs on real-world bug fixing: 2,294 real GitHub issues from 12 popular Python repositories. The current top scores on SWE-bench Verified (a human-filtered subset of 500 instances) approach 75–95% resolution rates.
But those numbers deserve scrutiny. A study by Aleithan et al. from York University (SWE-Bench+) found:
- 32.67% of issues had solutions directly provided in the issue report or comments — models could copy the answer rather than derive it.
- 31.08% had weak test cases that could not catch incorrect or incomplete fixes.
- Analysis of SWE-Agent + GPT-4 found that 63.75% of its “successful” fixes were suspicious — either derived from solution leakage or passing weak tests despite being incorrect.
The implication: even on the best benchmark, a significant portion of “passes” are not genuine problem-solving. The model found the answer in the issue description, or the test suite was too weak to detect the fix was wrong.
The ByteDance study: six top agents, same limitations
A systematic analysis by Meng et al. (ByteDance, 2024) examined six top-performing LLM-based bug fixing systems on SWE-bench Verified:
- Significant performance variations between systems despite using similar underlying models.
- Fault localization at the code symbol level is far more critical — and far harder — than file-level localization. The model needs to find the right variable or function, not just the right file.
- Incorrect bug reproductions can derail the entire fixing process. When the model misunderstands the failure mode, every subsequent “fix” is solving the wrong problem.
- Further optimization is needed in both the LLM’s reasoning capability and the design of the agentic workflow.
DebugBench: pass rates against humans
DebugBench (ACL 2024 Findings) evaluated LLM debugging across C++, Java, and Python with a granular bug taxonomy:
- Pass rates ranged from 43.9% to 66.6% across open-source models.
- Closed-source models exhibited debugging performance inferior to human programmers.
- Runtime feedback (executing the code and feeding back the error) had a clear but inconsistent impact — it helped on some bug categories and hurt on others.
- The complexity of debugging fluctuates dramatically by bug category. Syntax errors are nearly trivial; stateful bugs and off-by-one errors are far harder.
The Olausson study: self-repair is not a silver bullet
The landmark paper by Olausson et al. (MIT/Microsoft Research, ICLR 2024) — “Is Self-Repair a Silver Bullet for Code Generation?” — remains the definitive analysis of LLM self-repair:
- When the token cost of carrying out repair is taken into account, gains are often modest, vary significantly between datasets, and are sometimes not present at all.
- Self-repair is bottlenecked by the model’s ability to provide feedback on its own code. The model generates a bug from a certain line of reasoning; when asked to fix it, it stays in that same reasoning rut. It struggles to step back and re-derive.
- Using a stronger model to provide feedback unlocked performance gains even in settings where the model could not self-repair.
- Providing human feedback greatly benefits repair even for GPT-4. The implication: the model knows more about fixing code than it can figure out from its own analysis alone.
What the model is good and bad at fixing
This is not a binary. The model’s debugging capability varies sharply by failure type.
Where it actually works:
| Category | Why it works |
|---|---|
| Syntax errors | The error message points directly at the problem |
| Type mismatches | Common patterns well-represented in training data |
| Obvious API misuse | “Wrong number of arguments” is unambiguous |
| Errors where the traceback reveals the root cause | The model can pattern-match to the right fix |
Where it consistently fails:
| Category | Why it fails |
|---|---|
| Stateful bugs | Requires tracing values across execution |
| Off-by-one logic | Needs careful reasoning about boundary conditions |
| Race conditions | Temporal reasoning about concurrent execution |
| Multi-function value tracing | Requires global understanding across files |
| Bugs in code it just generated | Same reasoning rut, same blind spots |
| Algorithmic efficiency | Superficial changes without fundamental rethinking |
A June 2026 study from Iowa State University (Zhang & Kothari) demonstrated this last point vividly. DeepSeek-R1 attempted to fix a performance bug across ten iterations. Each iteration made superficial changes to the code. Test case coverage remained stuck at 99.56% across all ten attempts. The model kept rearranging the same O(n²) approach without ever recognizing that the algorithm itself needed to change.
The production cost
This is not just a benchmark problem. Critical bugs in widely used AI infrastructure have gone undetected by LLM-based systems for months:
- Silent failures like lost prompt tokens in high-concurrency serving environments.
- Duplicate response rates in production inference engines.
- Bugs that only surface under specific hardware configurations or load patterns.
A 2025 study on bugs in LLM inference engines catalogued six symptom types and 28 root causes — revealing a depth of challenge that current LLMs cannot self-diagnose. The bugs were found and fixed by human engineers, not by the models that would eventually rely on the infrastructure they broke.
Google Research found that out-of-the-box automated program repair systems had a success rate of just 11% for real industrial bugs. Most generated patches either failed to fix the issue or introduced new ones. With two-stage filtering — pre-screening bugs to exclude those too complex for the model, then validating that patches actually resolve the issue — the rate improved to 53%. That is still a coin flip.
The seven escape hatches
The problem is real. The solutions are concrete.
1. Force execution, not assertion
Do not accept “fixed.” Make it prove it.
“Don’t say it’s fixed. Run the code and paste the terminal output.”
In agentic workflows (Claude Code, Cursor, Aider, Codex), the model runs tests and reads real output. This is the single largest lever. The execution loop matters more than model capability.
2. Diagnose before editing
Separate the two jobs. Force the model to analyze the error before writing a single line of code:
“First, in 2 sentences, explain the root cause. Don’t edit code yet. Where does the wrong value originate — not where it crashes?”
If the diagnosis is wrong, correct that first, then let it edit. Breaking the token-prediction momentum prevents the model from diving straight into a plausible-looking but wrong patch.
3. Shrink the world
One bug at a time. Minimal repro. Instead of pasting 300 lines and saying “fix this,” give it 20 lines that reproduce the failure and one failing assertion. The smaller the context, the less the model can pattern-match to superficial fixes.
4. Constrain the edit
LLMs love to rewrite the entire file. That introduces new bugs. Tell it:
“Only change lines 42–55. Return a diff, not the full file. Don’t change function signatures.”
5. Break the self-repair loop
When it fails twice, reset. The Debugging Decay Index study found that a strategic fresh start rescues effectiveness. Start a new conversation with:
“Here is the original spec, here is the minimal repro, here is the error. Forget previous attempts.”
Or use a second model instance as a critic:
“Here is code and an error. Is this fix correct? Why not?”
6. Use the gold standard prompt
This prompt structure consistently outperforms “fix this bug”:
Here is the failing test and traceback. Explain the root cause in one paragraph. Then propose the smallest patch that fixes the root cause, not the symptom. Show before and after for only the changed lines.
7. Move to agentic workflows with execution feedback
The industry shift from chat-based coding to agentic coding environments (Cursor, Windsurf, Aider, Claude Code, Codex) exists precisely because of this problem. When an LLM is connected to a terminal:
- It writes a fix, runs the code, sees the error, and iterates.
- Iterative agentic workflows with testing loops boost fix success rates from roughly 50% to over 80%.
- The model is forced to confront runtime reality instead of generating plausible-looking text.
The Olausson study showed the same effect from the other direction: self-repair improved dramatically when feedback quality improved — whether from a stronger model, from execution, or from a human.
The bottom line
The model is not pretending to fix bugs. It is generating the most plausible output it can based on the limited information it has, with no built-in way to verify that the output actually works. Without a feedback loop from execution and testing, it has no reliable way to know whether the bug is actually fixed.
The shift from chat-based debugging to agentic coding environments exists because the engineering community recognized this exact flaw. The execution loop is the fix — not a better model, not a better prompt, but the fundamental architectural change of forcing the model to confront runtime reality.
Treat LLMs as excellent pair programmers and code reviewers who are average debuggers unless connected to tools. The mental model of “junior developer who cannot run the code” is more accurate than “senior engineer who can.”
The loop where the model says “Fixed!” three times in a row without actually fixing anything is not going away. But you can break it — by refusing to accept any fix that does not come with execution evidence.