Feedback Inversion: Why Quoting an Error Word for Word Makes the Model Repeat It

When a model makes a failed tool call or writes buggy code, the standard approach is to hand it back the exact text of that attempt plus the error message and ask it to fix things. The logic makes sense: the error is a fact, and the model should take it into account. In practice the opposite happens: the probability that the model repeats that very same failed version shoots up instead of going down.

In the experiments, the probability of repeating a failed action jumped from 6% to 54% after the model saw the record of its failure. The reason isn't that the model "didn't understand" the error message. 83% of the damage comes from the mere presence of the exact text of the failed attempt in the context: the model copies what's in front of it more strongly than it responds to the meaning of the error. It's like being shown a photo of the wrong answer and told "don't do this": your eye still latches onto the picture.

The fix: don't paste the failure back in verbatim. Instead, describe the gist of the problem in your own words, without quoting the original. That removes most of the effect at no extra cost. Meanwhile, the instruction "don't repeat this" doesn't work, and wiping the history for a "clean restart" doesn't work either; it actually turns out to be worse.

Method Blueprint

STEP 1: The model makes a failed attempt (code, call, text) → it gets recorded in the history
STEP 2: DON'T paste the verbatim text of the attempt back into the prompt
STEP 3: Describe the gist of the error in your own words → "the problem was that X"
STEP 4: Ask for a new version, explicitly requiring that it not repeat the old one's structure

All of this is a single prompt (the next turn in the conversation), with no API and no code.

Example in Action

Task: You ask Claude to write a Google Sheets formula or an SQL query to pull some data. The model gives you a version, you paste it in, and you get an error. The standard reflex is to copy the error and the code back into the chat.

Prompt (the usual approach, which hurts):

Here's your query:
SELECT name, revenue FROM sales JOIN clients ON sales.client=clients.id

Error: column "client" does not exist

Fix it.

Prompt (based on the study's finding):

The previous version of the query didn't work: you used a column name 
that doesn't exist when joining the sales and clients tables. 

Write a new query for the same task (pull the client name and revenue), 
but don't repeat the JOIN structure from the last attempt; first check 
what the columns linking the two tables are actually called.

Result: in the second case the model doesn't have the exact wrong query staring it in the face, so it doesn't "slide" into repeating it. It gets the diagnosis (what went wrong) without the temptation to copy the failed text itself. In practice this shows up as a more varied answer instead of one stuck on the previous mistake.

Why It Works

Models tend to copy what they've recently seen in the context. It's a fundamental mechanism of transformers (the model "gravitates" toward similar chunks of text that are already nearby). When the failed code or call stays in the history in full, that copying tendency outweighs the logical "don't do this," even when "error" is written clearly right next to it.

At the same time, the model responds well to rephrased descriptions of the problem: remove the trigger itself (the exact error text), and there's nothing for its "eye" to latch onto, so it freely generates a new version.

Control knobs: - Verbatim text vs. your own words: the main lever. Replacing the quote with a paraphrase removes most of the problem. - The "don't repeat" instruction: doesn't work, so don't waste words on it. To follow it, the model has to "keep in mind" a ban on a line that's sitting right in front of it, and models are bad at that. - "Let's start from scratch": a trap. If you just delete the error history but leave the task and prompt the same, the model will most likely give you the very same wrong answer again, because it sees the very same context that led to the error the first time.

Prompt Template

The previous attempt ({what the model was doing}) didn't work.

The problem (in my own words, without quoting the previous version): {gist of the error}

Requirements for the new version: {what should be different}

Write a new {content_type} without repeating the wording or structure 
of the previous attempt.

🚀 Quick start: paste this into the chat:

Here's a principle for giving an LLM corrective feedback: when fixing an error, don't 
quote the failed version verbatim; describe the problem in your own 
words. Adapt this template to my task: {your task}.
Ask me questions to fill in the fields.

[paste the template above]

The LLM will ask what exactly didn't work and what should change, because without that information it can't write an accurate "description of the problem in your own words" without losing the diagnosis.

Limitations

⚠️ Scope of testing: only small models were tested (135 million – 1.7 billion parameters), not top-tier GPT-4/Claude/Gemini. The mechanism (copying from context) is shared by all transformers, but how strong the effect is in large frontier models wasn't checked.

⚠️ Feedback isn't useless: the takeaway isn't "don't give the model information about the error"; it's "don't give it verbatim." If you strip out all diagnostics entirely, it won't help: the model simply won't understand what to fix.

⚠️ "A fresh chat from scratch" is no cure-all: if you just open a new chat and repeat the same prompt after a failure, without changing the wording, then per this finding the model may give you the same wrong result again. You need to change the context, not just delete it.

How They Studied It

The researchers took 6 small instruction-tuned models (135 million – 1.7 billion parameters, 4 different families) and ran them through two environments: a simulation of tool calls (office tasks like "find a contact," "create an event") and real Python code fixing with actual interpreter output. At each decision point they measured the probability the model assigns to repeating the failed action, before and after that failure was written into the history.

To separate "the model didn't understand the error" from "the model is just copying what it sees," they made control versions of the same failed action: with a success message, with a neutral acknowledgment and no verdict, and with no record of the attempt at all. It turned out that 83% of the damage comes from the mere presence of the exact text of the failed attempt, not from the fact that it says "failure."

The most unexpected result: the "obvious" fix, deleting the failed attempt and starting from a clean slate (as earlier literature on "context pollution" recommends), turned out to be the worst of all the options tested. The reason is simple: deleting restores the very same context that led to the error the first time, and in an identical context the model gives an identical answer.

Resources

Esmail Gumaan, University of Passau, Germany. Code, data, and every number in the paper: github.com/Esmail-ibraheem/feedback-that-backfires