The AI keeps saying it fixed it, and it did not. How to break the loop.
You report a bug. It says “You’re absolutely right! I’ve fixed the issue.” You check. Identical. You say it is still broken. It apologises, changes something, and says it is fixed. Identical.
Three hours later you are further from working than when you started, and the app has picked up four new problems along the way.
This is not you being bad at prompting. It is a specific, predictable failure, and once you can recognise it you can get out in minutes.
Why it happens
Your assistant cannot see your app. It cannot click the button, read the red text in your console, or watch the page stay blank. It has your description and the code, and from those it produces the most plausible-looking change.
When your description is “it’s still broken”, the most plausible change is often the same one it just made, because nothing in the new information ruled it out. So it makes it again, phrased differently.
Worse, it is agreeable by design. “You’re absolutely right” is not a considered judgement, it is a conversational reflex. It will apologise for a fix that was correct and defend one that was not, because it has no way to check.
You are the only part of this system that can actually observe reality. When you provide no observations, the loop is the inevitable result.
Five ways out, roughly in order
1. Give it the error, not your description of the error
This single change resolves most loops.
Press F12 in Chrome, open the Console tab, and look for red text. Copy the whole thing, including the file name and line numbers. Paste it in.
“It’s not working” gives it nothing to reason from. TypeError: Cannot read properties of undefined (reading 'email') at Profile.tsx:24 tells it what failed, on which line, in which file. That is often the entire difference between the fifth failed attempt and a correct one.
2. Make it explain before it edits
Try this exactly:
Do not change any code yet. Explain what you think is causing this, and tell me which specific line you believe is at fault.
If the explanation is vague — “there may be an issue with how the data is handled” — it does not know, and its next edit will be another guess. That is your cue to stop and get more information rather than accepting another round.
If the explanation is specific and names a line, you have something you can check.
3. Make it prove the cause first
Before fixing, add a line that prints the value of
userto the console right before it is used. I will tell you what appears.
This is the technique that separates people who debug from people who guess. You are no longer asking for a fix, you are asking for a measurement. Once you can both see the actual value — undefined, an empty list, an error object — the fix usually becomes obvious and singular.
It feels slower. It is dramatically faster.
4. Start a new conversation
Long threads work against you. Every failed attempt is still in the context, and the model treats its own earlier reasoning as established fact. It will defend the shape of a solution it committed to twenty messages ago.
Open a fresh chat. Describe only the current state and paste the current error. No history of what you tried. You will often get a correct answer immediately, on the same problem, from the same model.
5. Undo everything and go back
If you are five attempts deep, the original bug is no longer your only problem. You now have the original bug plus four speculative rewrites of unrelated code.
Restore the last version that worked. Yes, you lose the attempted fixes — that is the point, they did not work. Then approach the original bug once, with an actual error message in hand.
The rule that prevents most of this
Never accept a fix you cannot explain, even roughly.
Not because you need to understand the code, but because “I don’t know why that worked” and “I don’t know why it broke” are the same sentence six weeks apart. If you cannot say what was wrong and why the change addressed it, you have not fixed anything. You have shuffled it.
Ask: In one sentence, what was actually wrong? If the answer does not make sense to you, it is worth another minute.
When to stop and get help
A reasonable rule: three failed attempts on the same bug means stop.
Not because you cannot do it, but because the loop has a cost that compounds. Every extra round adds changes you did not ask for, to code you have not read, in an app you are now less able to reason about. The bug you started with is cheap. The mess accumulated while chasing it is not.
If you have been going more than an hour, undo back to working, then bring it to someone who can see what the AI cannot.
Stuck in one right now? The free setup session is often enough to break it. Bring the app mid-loop — do not clean it up first, the mess is the useful part.