Your AI agent is stuck in a loop: 12 prompts that break it

Your agent is not stuck on the bug. It is stuck on its own last answer.

Every reply it writes is built on the replies before it. So as long as the first wrong guess is still sitting in the chat, it keeps coming back, in slightly different code, under the same confident sentence: “I see the issue now.” New fix, same error. The problem is not the model. It is the conversation.

That means the way out is not a better description of the bug. It is changing what the model is building on. Below are twelve prompts that do exactly that, cheapest first. Start at the top. Do not jump to twelve.

Each prompt does two things a one-line prompt cannot. It forbids the next code change until you have read the answer, and it fences what the agent may touch: no revert without a backup branch, no new files it did not name, no “according to the docs” from memory. A stuck model is a confident model, and the fences are what make these safe to paste at one in the morning. Under each prompt is a Worked if line: something you can see in the reply or on screen, with no code to read.

Nothing here is tied to one tool. The wording works in any chat where you build.

Are you actually in a loop?

It is a loop if two or more of these are true:

• The same error came back after the agent said it was fixed, twice or more.
• The last few fixes change the same few lines, back and forth.
• Its explanation of the bug has not changed in three replies, or it changes every reply.
• You have stopped reading the diffs and started just pressing accept.

If none are true, you are not in a loop. You are debugging, and you should keep going. If you are in one, the sign you are seeing tells you where to start.

No sign fits? Go in order from 1.

The order, and three warnings

The ladder runs 1 to 12, cheapest first, and you stop at the first prompt that breaks the loop. Prompts 1 to 3 cost nothing: no code changes, no run, just a reply you read. Prompts 4 to 9 cost one run or one search, so something touches your project and the fences in each prompt matter. Prompts 10 to 12 change the road: you give up on the current approach, or the current chat.

Why not start at 12? A fresh session with no notes forgets everything the old chat disproved, and walks straight back into the same wrong idea. The early prompts are what make 12 work.

Three things are true and inconvenient before you start.

Prompt 5 can cost you work. “Revert to the last commit that worked” is how people lose an afternoon of changes that were fine. The prompt below makes the agent save everything to a backup branch first. Do not trim that line. And never let a stuck chat run a hard reset, a force push, a clean, or a branch delete. If you see one of those in a reply, say no and ask why.

Logs and pasted errors can leak secrets. Prompt 4 prints real values, and prompt 3 has you paste a full error. Both can contain keys, tokens, passwords, emails or a customer’s data. Before you paste an error into any chat, find the long random strings and replace them with [REDACTED]. Once the bug is fixed, ask the agent to remove every log it added: a debug log that prints a token is a leak you shipped yourself.

Prompt 12 throws away everything the chat learned. A new session is the strongest prompt here and the most expensive. It forgets what you tried and what you proved is not the cause, which is why prompt 12 has two parts, and the handoff note is written in the old chat before you close it. Skip the note and you get the same loop with a clean screen.

Group 1: no code, no run

These three cost nothing. They do not change a line. They make the agent look at what it has been doing instead of doing more of it.

1. Stop. List everything you have tried

The sign: “I see the issue now.” New fix, same error. The agent does not know it is repeating itself, because it has never seen its own attempts side by side.

Stop. Do not change any code in this reply. List every fix you have tried
for this bug so far, in order: what you changed, in which file, and what
happened after. Then tell me which of those attempts were really the same
idea written differently. After the list, name one thing you have not tried
yet, but do not try it.

Worked if: the list shows two or more attempts that are the same idea. That is the loop, now written down. If the “one thing not tried yet” is genuinely new, tell it to go ahead. If it is the old idea again, go to 2.

2. What are you assuming that you have not checked?

The sign: the agent talks about what a value is or what a function returns, and nobody has ever printed it. Under every loop is one wrong assumption, repeated.

Before any more fixes, list every assumption you are making about this bug
that you have not directly checked: what a variable contains, what a
function returns, which file actually runs, which version is installed,
what the environment has. Mark each one "checked" or "assumed". For each
"assumed", tell me the fastest way to check it. Do not change any code.

Worked if: the list has at least one “assumed” that surprises you. That is your next move: check it, with prompt 4 if it is a value.

3. Read the error word by word

The sign: a long error, and the agent keeps fixing based on the first line. It has been reacting to the error, not reading it. Often the answer is sitting further down the trace and nobody read that far.

Here is the full error, exactly as it appeared:
[paste the whole error and stack trace, with any keys or tokens
replaced by [REDACTED]]
Read it word by word. Explain what each part means: the error type, the
message, and every file and line in the trace. Tell me which lines are our
code and which are a library. Then say, in one sentence, what the error is
actually telling us. Do not propose a fix yet.

Worked if: its one sentence is different from the thing it has been fixing. If it is the same sentence, the error is not the problem, its picture of the code is. Go to 4.

Group 2: one run, or one search

These touch your project. Each prompt says exactly what the agent may change and what it may not. Keep those lines in.

4. Log before and after the failing line

The sign: the agent is guessing. Nobody knows what the value on the failing line actually is.

Do not fix anything yet. Add a log right before and right after the line
that fails, printing the value and type of every variable that line uses.
Do not print passwords, tokens or keys: print "[set]" or "[missing]" for
those instead. Tell me exactly how to trigger the bug so the logs run. I
will paste the output back. Do not change any other code, and do not guess
what the output will be.

Worked if: you paste the output back and one value is not what anyone expected: empty, undefined, null, the wrong type, an old value. Evidence replaced a guess. Once it is fixed, ask it to remove every log it added.

5. Back up, then find the last version that worked

The sign: ten fixes in, and nobody knows what state the code is in any more.

Before touching anything, commit everything as it is now to a new branch
called stuck-backup, so nothing is lost. Then find the last commit where
[the thing that broke] still worked, and list every change between that
commit and now, file by file, one line each. Tell me which change most
likely broke it. Do not revert, reset or delete anything yet. Show me the
list and wait.

Worked if: the backup branch exists (ask it to show you) and the change list is short enough to read. Then decide: revert just the suspect change, or go back to the working commit. If there is no working commit at all, this prompt cannot help, so skip to 6.

6. Reproduce it in the smallest possible example

The sign: the bug lives somewhere in forty files, and the agent is looking at all of them at once.

Build the smallest possible example that reproduces this bug, in one new
file, outside the app. No other files from the project, no real data, no
framework unless the bug needs it: just enough code to make this exact
error appear. Run it and show me it fails the same way. Do not edit any
existing file.

Worked if: the tiny file fails the same way. Now it is ten lines, and ten lines get fixed fast. If the tiny file does not fail, that is also an answer: the bug is in something you left out, so ask what is different.

7. Which line is the bug on? Prove it

The sign: fixes “land”, but nothing on screen changes. The agent may be fixing the wrong file, because the place an error shows up is not always the place the bug is.

Which exact file and line is the bug on? Prove it with evidence: a log
output, a line from the stack trace, or a failing test, not reasoning. If
you cannot show evidence, say "I do not know yet" and tell me what would
find out. Do not edit anything in this reply.

Worked if: you get a file, a line, and a piece of evidence you can point at. “I do not know yet” also counts. It is the first honest answer in an hour. No evidence, no line.

8. Find every place this is called

The sign: fixed on one page, still broken on another. The fix landed in one place, the bug lives in another.

Search the whole project for every place [function or component name] is
called, imported, or passed along. List each one with the file, the line,
and what gets passed in there. Then tell me which of those could produce
this error. Do not change anything until I have seen the list.

Worked if: the list has an entry you did not know about. That is usually where the bug is. Reading an unfamiliar call site is exactly what the code review guide is for.

9. Check the docs for this exact version

The sign: “is not a function”, “no exported member”, “deprecated”. The code is right, for last year’s version of the library. A good share of stuck loops are this.

Look in the manifest or lockfile and tell me the exact installed version of
[library]. Then check the official docs or changelog for that version, not
what you remember, for the function we are calling. If you cannot open the
docs, say so and I will paste them in. Tell me whether the way we are
calling it is correct for that version. Do not rewrite anything yet.

Worked if: it names the version number and shows where it read the docs: a link, or the text you pasted. “According to the docs” with neither is memory, not docs, and that is the one way this prompt fakes a pass.

Group 3: change the road

If you are here, the current approach is the problem. Stop trying to fix it and pick a different one.

10. Three different approaches, not the one you have been trying

The sign: every fix is a variation on one idea. The agent keeps walking back to the same road.

We have been trying [the current approach, in a few words]. That approach
is off the table from now on. Give me 3 genuinely different ways to achieve
[the actual goal: what should happen, not the bug]. Different in approach,
not different code for the same idea. For each: how it works in two lines,
what could go wrong, and how much existing code it touches. Do not write
any code. I will pick one.

Worked if: none of the three is the banned road in new clothes. If one is, say so and ask for a replacement. Then pick the one that touches the least code.

11. Explain the bug to a new developer

The sign: the agent’s explanation changes every reply. It does not understand the bug, and it will not say so unless you ask.

Explain this bug to a developer who has never seen this project: what is
supposed to happen, what actually happens, and why. Plain words, no code.
If there is any part you cannot explain, name exactly which part and say "I
do not understand this part yet." Do not guess to fill the gap, and do not
propose a fix.

Worked if: you understand the explanation yourself, or it names the part it does not understand. That named gap is what you check next, usually with 2 or 4. If it cannot explain the bug, it cannot fix it.

12. Handoff note, then a fresh session

The sign: the chat is long, and the agent contradicts itself or forgets things you said. The chat is poisoned, and no prompt fixes it from inside.

First, in the old chat, before you close it:

Write a handoff note for a fresh session. Include: the goal, the exact
error, the files involved, every approach we tried and why it failed, and
anything we proved is NOT the cause. Under 200 words, no code. Save it as
docs/handoff.md. Do not change any other file.

Then close that chat, open a new one, and start it with this:

New session. Read the project instruction file, docs/handoff.md, and only
these files: [file 1], [file 2]. Here is the error:
[paste the error, keys replaced with [REDACTED]]
Do not open any other file without telling me why first. Do not retry any
approach the handoff lists as failed. Start by telling me what you think
the bug is, before you change anything.

Worked if: the new session’s first guess is not on the handoff’s failed list. Memory lives in files, not in the chat, which is the whole idea behind the 5-file starter pack.

Two more prompts

Two that did not make the twelve.

Is it even the code? Sometimes the fix is right, the code looks right, and nothing changes because the bug is outside the code entirely.

Before touching the code again, could this be outside the code? Go through
this list and give me one step to rule out each: an environment variable
missing or different from what the code expects, a stale build or cache,
the dev server still running old code, the wrong port or URL, a different
runtime version than expected, a browser cache or service worker. Do not
change any code, and do not print the values of any secrets: just whether
they are set.

If one of the checks fails, that was it. Restart the server and hard-refresh before you believe any fix, ever again. Several of these are the same traps as the deploy guide.

Ask me first. Sometimes the agent is filling gaps with guesses about things only you know: what you clicked, what you expected, what changed today.

Before your next attempt, ask me up to 3 questions about this bug that you
would need answered to be sure: things only I know, like what I clicked,
what I expected to see, or what I changed today. Wait for my answers. Do
not change anything in this reply.

It worked if one of its questions makes you say “oh, actually”. That was the missing fact.

Make it stick

Put this in your tool’s project instruction file, such as CLAUDE.md, AGENTS.md or your editor’s rules file, so the next loop gets caught at round two instead of round ten.

DEBUGGING RULES FOR THIS PROJECT
- If the same error comes back twice, stop fixing. List what you have
  tried and what you are assuming.
- Never say "I see the issue" without evidence: a log output, a stack
  trace line, or a failing test.
- After two failed attempts at one approach, offer a different approach
  instead of a third attempt.
- Before any revert or reset, commit the current state to a backup branch.
  Never force-push, never clean, never delete uncommitted work.
- Check the installed version before using a library's API. Say so when
  you are going from memory.
- Never print or log passwords, tokens or API keys. Print "[set]" or
  "[missing]" instead.
- Only touch files related to the bug. Tell me before opening more than 3
  new files.
- When the bug is fixed, remove every debug log you added.

To confirm it is being read, open a new chat and ask: “What are your debugging rules in this project? List them from memory before you do anything.” A vague or generic answer means the file is not being picked up, so check its name and that it sits in the project root.

What this is, and what it is not

Twelve prompts are not a debugger. They break the loop, which means they get the agent to stop repeating itself and look at evidence. They do not replace reading the error yourself, and they cannot fix a bug nobody can reproduce.

The model is marking its own homework. Every prompt here ends with “do not change anything yet” for one reason: a stuck model is a confident model, and the next confident fix is how the loop continues. The Worked if lines are the only part of this that does not take its word for it. “It says it is fixed” is not a Worked if. “The error is gone after a restart and a hard refresh” is. If the loop is really about the bill rather than the bug, AI cost control is the one to read next, and if it keeps coming back after each fix, the answer is a test, which is prompt 7 of the senior-engineer set.

Three things that are true and inconvenient. A revert without a backup branch is a gamble. A debug log left in production is a leak. And a fresh session without a handoff note is the same loop with a clean screen.

When to stop: if you have run all twelve and it is still broken, it is no longer a prompting problem. Take the tiny example from prompt 6 and the handoff note from prompt 12 to a person, a friend, a forum, or the library’s issue tracker. Those two files are exactly what someone needs to help you in five minutes, which is the other reason to write them.

The one line to keep, if you forget the rest: your agent is not stuck on the bug, it is stuck on its own last answer, so change the answer it is building on.