What if I get stuck in a coding loop?
A coding loop is when each attempted fix returns you to the same fault, creates a new one or reverses the last change. The answer is not a more forceful prompt. Stop changing the code, name what you can actually see, ask for a diagnosis, and test one explanation at a time.
A quick check, before we start
If the model has tried three fixes and the problem remains, I should keep asking it to try again in the same conversation.
Reveal the answer
False.
Repeating the same kind of request usually gives the model more of the same confused context. Pause the edits, return to the evidence and make it explain why the previous attempts failed before it changes anything else.
What is a coding loop?
A coding loop is not simply a difficult problem. It is a pattern: the model changes something, says the problem is fixed, you look and find that it is still there. It tries again and either nothing changes, the fault moves somewhere else, or the new fix restores a problem you rejected two turns ago.
The conversation can still sound productive. Files are being edited. Explanations are being offered. The model may be increasingly confident. But progress is not the amount of activity in the chat. Progress is a changed result that you can see and verify.
You do not need to understand the code to recognise the loop. You only need to notice that the observable result is not improving.
Why does the model get stuck?
Usually, because the conversation has begun treating a guess as a fact.
Perhaps everyone assumes the gap comes from the image when it is actually created by the container around it. Perhaps the model is editing the right-looking file but the page is using another component. Perhaps the change works at one screen width and fails at the one you are viewing. Each new prompt then builds on the same mistaken explanation.
Long conversations add another problem. The model has to recover the current task from a growing record of accepted ideas, rejected ideas, old screenshots and superseded instructions. A useful history can become a noisy one. More context is not always better context.
That is why a loop is rarely escaped by saying, “No, that still has not worked. Try again.” The instruction reports disappointment, but it gives the model no new evidence.
What should I do first?
Stop the model from editing and separate what you observed from what it inferred.
Write the visible facts as plainly as you can:
- What you expected to happen
- What happened instead
- Where and when it happens
- Whether it happens every time
- The last version that definitely worked
- What the previous attempts changed
Then ask for diagnosis rather than another fix:
Do not change any code yet. The last attempts have not changed the visible result. Summarise what we know from observation, separate that from your assumptions, explain what all the failed fixes may have had in common, and give me no more than three possible causes. For each cause, tell me the smallest check or measurement that would confirm or rule it out.
This changes the job. The model is no longer being rewarded for producing another edit. It has to show you how the next edit will teach you something.
What does “test one explanation at a time” mean?
It means making the next step capable of being wrong.
If the model proposes three causes and changes code for all three, a successful result will not tell you which explanation was right. A failed result will not tell you which one was wrong. You have exchanged one mystery for a larger one.
Instead, choose the smallest useful test. Ask the model to measure the element, inspect which rule is taking effect, confirm which file the page is actually using, or temporarily make one suspected cause unmistakably visible. Run the check, look at the result and record what it ruled in or out. Only then make the fix.
A measurement can be very simple: the width of a box, the name of the loaded file, the response from a link, or a screenshot at the exact screen size where the fault appears. The important thing is that the next move produces evidence, not merely motion.
When should I start a fresh conversation?
When the current conversation is carrying more confusion than useful history.
Do not simply open a blank chat and begin the whole project again. Ask the current model to prepare a short handover containing:
- The intended result
- The exact fault still visible
- The relevant files or component
- What has already been tried
- What each attempt proved or failed to prove
- The last known working version
- The next diagnostic check, not an assumed fix
Give that handover to a fresh session, or ask another model for a second opinion, and tell it to inspect before editing. A fresh conversation is useful because it removes the accumulated argument while preserving the evidence.
What if the attempts have made things worse?
Return to the last known working version. That is not giving up; it is removing unhelpful variables.
This is why small commits matter even before a site is live. A commit gives you a named checkpoint. If three speculative fixes have piled on top of one another, you can keep a record of them, restore the checkpoint and resume from a clean state with the new diagnosis.
Before restoring anything, ask the model to show exactly what would be reversed and confirm that no unrelated work will be lost. Undo should be deliberate too.
Where can I see this on the site?
The next rung, fixing a bug without reading the code, records two visible defects in the same component. One survived repeated attempted fixes until a measurement identified the mechanism that the prompts had been missing.
The lesson on what to do when the first version looks wrong shows the design bench, where alternatives and the reasons they were superseded are kept, and the Second opinion station, where the model is asked for a reasoned critique rather than another agreeable answer. Both make the same habit visible: when progress stalls, change the quality of the evidence before changing more of the work.
So, what if I get stuck in a coding loop?
Stop editing. Describe the result you can actually see, separate observation from assumption, and make the model explain why its previous fixes may have failed. Test one cause at a time. If the conversation has become part of the problem, carry a clean evidence-based handover into a fresh one. If the work has deteriorated, return deliberately to the last known good checkpoint.
The model can keep generating changes indefinitely. Knowing when to stop the changes and demand a diagnosis is part of the skill.