Iterative Self-Repair: How to Ask AI to Fix Itself — and How Many Times

All steps happen in one chat, as consecutive messages:

STEP 1: Regular request → the model's first answer

STEP 2: Find a specific error in the answer
        → state exactly what's wrong (not "bad," but "here's where and why")

STEP 3: Repair prompt = {original task} + {previous answer} + {specific error}
        → add "first explain where you went wrong, then fix it"

STEP 4 (if needed): Repeat step 3 once more with the new error
        → STOP. After two fixes, further rounds are nearly useless.

Task: Daniel Brooks asked Claude to write a sales proposal for supplying medical equipment to a regional hospital. He got a text but noticed: the payment terms are wrong (he needs a 6-month installment plan, but it says lump sum), the warranty service section is missing, and sales tax is counted twice in the price calculation.

Prompt (STEP 3):

My task was: write a sales proposal for supplying 
MRI-1500 medical equipment to Riverside Community Hospital in Boise, 
with a budget of up to $500,000.

Your previous answer:
[paste the previous proposal text]

Here are the specific errors:
1. Payment terms: you wrote a lump-sum payment, but it needs to be 
   a 6-month installment plan in equal parts
2. The "Warranty Service" section is missing — it needs its own 
   block: 2-year warranty, technician on site within 48 hours
3. The 8% sales tax is counted twice: first in the equipment line, then 
   in the grand total — the total should be $498,000, not $537,840

First explain where exactly you made each of these errors. 
Then give the corrected version of the proposal.

Result: The model will first break down each of the three errors — why it showed up in the previous text. Then it will produce a corrected proposal with the right payment terms, a new warranty section and the correct total. The explanation block ("where I went wrong") isn't filler — it's a mechanism that makes the model aim more precisely before fixing.

Vague feedback is an empty signal. When you write "that's not it, redo it," the model doesn't know what to protect and what to change. It sees the task anew and may change everything, including what was right. Or the opposite — keep the error, because it doesn't understand where it is.

A specific error is a targeted signal. The model generates text from patterns in the context. When the context contains an exact description of the broken spot — the previous text + a description of the error — the model sees the gap between what was and what should be. The more precisely the gap is described, the more precise the fix.

Explaining before fixing is a built-in check. When you ask it to "first explain where you went wrong," the model has to state the problem in its own words before solving it. That removes ambiguity: if the explanation is right, the fix is almost certain to be accurate. This is CoT-repair (Chain-of-Thought repair — reasoning before acting).

Control levers: - Number of rounds → two max. More is a waste of time - The "first explain" block → drop it if you want a shorter answer without explanations - Error specificity → the more precise ("line 3, sales tax counted twice"), the better the result. The vaguer ("the logic is off"), the worse - Previous answer in the prompt → always include it, this is critical: without it the model starts from scratch

My task was: {original_task}

Your previous answer:
{previous_answer}

Here are the specific errors:
1. {error_1} — what it should be instead: {correct_version_1}
2. {error_2} — what it should be instead: {correct_version_2}
[add as many items as you found]

First explain where exactly you made each of these errors.
Then give the corrected version.

What to fill in: - {original_task} — copy your original request - {previous_answer} — the full text of what the model produced - {error_N} — specifically: what's wrong and exactly where - {correct_version_N} — what it should actually be

🚀 Quick start — paste into the chat:

Here's the Iterative Self-Repair template. Adapt it to my task: {your task}. 
Ask me questions to fill in the fields.

[paste the template above]

The LLM will ask what exactly went wrong in the previous answer and where precisely the error is — because without that it can't fill in the key fields {error_N} and {correct_version_N}, which are what make the fix precise.

⚠️ Logic errors are hard to fix: If the error is in the reasoning — "the conclusion seems wrong, but I can't explain why" — success is around 45%. Self-Repair barely helps here. You need either an external verifier (check the calculation yourself) or a different approach.

⚠️ Two rounds is a hard ceiling: After two fixes, further attempts are nearly useless. If it isn't fixed in two rounds, the problem is most likely your vague feedback, or an error so deep it can't be fixed without restating the task from scratch.

⚠️ Doesn't work without the previous answer in context: If you just write "fix the sales tax error" without pasting the previous text, the model doesn't know what to fix. Always paste the full previous answer.

⚠️ Simple tasks aren't worth the effort: If the task is small, rewrite the request from scratch — it's faster than building a repair prompt.

The researcher took 7 different models — from the small Llama 8B to the flagship Gemini 2.5 Pro — and ran each through the same coding tasks. Each model got a task and wrote a solution, and the code ran automatically: it either works or it doesn't. If it didn't, the model got the error text and was asked to fix it. Up to five attempts.

An interesting design detail: errors were classified by type — a typo in a variable name, a syntax error, or "the code ran but produced the wrong result." The last type — the "logic error" — turned out to be fundamentally different in nature. When the error was specific ("you used variable X, which doesn't exist"), the model fixed it in ~77% of cases. When the error was logical ("the code ran but the answer is wrong") — only in ~45%. This confirmed earlier theoretical observations: AI can't reliably fix its own reasoning without a clear signal of what exactly is wrong.

A surprising result: even the smallest modern models (8B parameters) benefited from self-repair — whereas it used to be believed that weak models only degrade from it. But the biggest surprise came from Gemini 2.5 Flash: it started poorly (63.8% correct solutions on the first try) but, thanks to repairs, shot up to 93.8% — the largest gain in the study (+30 pp). This shows that the ability to fix yourself and the ability to get it right the first time are different skills, and they don't always correlate.

Repair prompt (minimal version from the study):

The following Python function has a bug. Here is the function:

{previous_code}

When run, it produced the following error:

{error_message}

Please fix the bug and return only the corrected function.

CoT repair prompt (enhanced version, +5.5pp quality):

The following Python function has a bug. Here is the function:

{previous_code}

When run, it produced the following error:

{error_message}

First, explain what is wrong with the code and why the error occurred.
Then, provide the corrected function.

Context: The researchers compared three versions of the repair prompt — minimal ("fix it"), explain-then-fix, and a Chain-of-Thought version. CoT gave a +5.5 pp gain over the minimal prompt on strong models.

💡 Adaptation: Self-Repair for text tasks (not code)

The principle works anywhere the result is verifiable — text with facts, calculations, structured documents. The key: you have to be able to find the specific error yourself.

Strong zone: contracts with wrong terms, financial calculations with a mistake, texts with factual inaccuracies, résumés with a broken structure.

Weak zone: "the text isn't persuasive enough," "the tone is off" — too vague, the result will be worse.

🔧 Technique: graded feedback → precise fixes

Instead of one vague comment, break the errors down by type:

FACTUAL ERRORS (fix exactly):
- The sales tax rate should be 8%, not 6%
- Contract date: March 15, 2025, not February 15

STRUCTURAL ISSUES (add/remove):
- Add a section on warranty obligations
- Remove the intro paragraph — it's not needed

TONE EDITS (direction):
- The "Price" section — make it softer, less blunt

This structure gives the model a clear hierarchy: what to change word for word, what to restructure, what to adjust in spirit.

🔧 Extrapolation: Self-Repair + a verifier

The technique's weak spot is logic errors (~45% success). The upgrade: add a second step before the repair prompt.

Step 1: Ask the model to explain its logic
"Explain step by step how you arrived at this conclusion/calculation"

Step 2: Find exactly where the logic breaks

Step 3: A repair prompt pointing to the exact step with the error
"In step 3 you assumed X, but the correct assumption is Y. Fix it."

This converts a "vague logic error" (45% success) into a "specific point of failure" (closer to 77%). It takes an extra round but pays off on complex tasks.

How Many Tries Does It Take? Iterative Self-Repair in LLM Code Generation Across Model Scales and Benchmarks

Author: Johin Johny Arimbur (Independent Researcher)

Code and data: github.com/Johin2/iterative-code-repair

Related work: Self-Refine (Madaan et al.), Reflexion (Shinn et al.), Self-Debug (Chen et al.), Olausson et al. "Is Self-Repair a Silver Bullet?"