Breaking out of prompt loops

Why this matters

A bad first answer costs you about thirty seconds. The real cost comes from attempts five, six and seven, when you're rewording the same request and hoping this version is the one that works. This lesson covers when to stop rephrasing and which of three things to change instead.

Minute 40, fourth 'no, that's still wrong'

At PhoenixDX we had a bug in a report export. Timestamps were stored correctly in UTC, but some rows came out a day off for users in Melbourne and looked fine for the team in Ho Chi Minh City. I asked Claude to fix it. Its first answer changed the date formatting in the UI. I said that wasn't it. The second fixed Melbourne and broke Ho Chi Minh City. The third put everything back the way it was. Forty minutes in, I was typing my fourth 'no, that's still wrong'.

I closed the tab and opened a new chat. I wrote a three-line brief covering the goal, what I'd already ruled out and what 'done' looked like. It was fixed on the first try with the same model, the same bug and the same afternoon. The only thing that changed was what the model could see.

What actually went wrong

Inside a chat, the model works from what's in the conversation, plus any memory feature you've switched on. Every time you hit send, it rereads the whole thing from the top: your first request, its first wrong answer, your correction, its second wrong answer, your increasingly annoyed reply. Your newest message is a small part of what it reads.

LLMs also learn heavily from examples in their context. That's why a few examples in a prompt work so well. It also means that by prompt three, the model's own wrong answers are the strongest examples in the chat. Three versions of the wrong approach steer it harder than one new sentence saying 'not like that'. Your corrections often repeat the wrong idea as well ('don't convert it in the UI'), which keeps that idea in front of the model.

Picture asking a colleague to forget the last hour while you keep pointing at the whiteboard they got wrong. If you want fresh thinking, wipe the whiteboard.

• Whatever goes into the chat stays there. Saying 'ignore that' doesn't remove it.
• Wrong answers become examples the model copies, even after you've called them wrong.
• Coding agents behave the same way. A long agent session full of failed edits and error logs gets worse with every attempt. That's why tools like Claude Code have a /clear command.

The rule

Three prompts is your limit. If three honest attempts haven't fixed it, a fourth rephrase won't either. Don't spend your fourth message on another prompt. Use it to decide what to change.

Read the failure before you react

How it keeps failing tells you what's actually wrong. Before you change anything, match what you're seeing to one of these three patterns:

WHAT YOU SEE                              WHAT IT MEANS            WHAT TO CHANGE
----------------------------------------  -----------------------  -------------------------------
Fixes A, breaks B, then back again        Task is too big          Split it (Move 2)

Confidently wrong the same way every      Missing context          Start fresh with a brief
time                                                               (Move 1)

Hedges, asks questions, or gives you      Request is ambiguous     Define what 'done' looks like
something generic                                                  (Move 3)

Change one thing at a time. If you open a new chat, split the task and rewrite the goal all in one go, you won't know which change worked, and next time you'll be guessing again.

Move 1: Change the context

Open a new chat and write a short brief of five lines or fewer. It should cover:

• Goal: what should be true when you're finished, in one sentence.
• Ruled out: what you've already checked, so the model doesn't send you back there.
• The one thing that matters: a single file, document or data sample, not the whole repo or folder.
• Constraints: what it must not touch.
• Done: a concrete example that proves it works.

Here's the brief that fixed the export bug. It's three lines because the goal and the constraint fit together:

Goal: the report export shows each event's date in the viewer's timezone. Stored values are UTC and correct, so don't touch the database or the API.
Ruled out: UI formatting. The date is already wrong when it leaves exportService.ts (attached).
Done: an event at 14:00 UTC on 3 March shows as 4 March in Melbourne and 3 March in Ho Chi Minh City, with a test covering both.

Don't paste the failed attempts into the new chat, not even under a 'here's what didn't work' heading. That gives the new chat the same mess you just left. Put what you've ruled out into one plain sentence. You opened a fresh chat so it would start clean, so keep it that way.

Move 2: Change the task size

When fixing A breaks B, the model is trying to satisfy two rules at once and keeps dropping one of them. Split the task at the part that keeps breaking. Then, before it touches anything, ask the model to state the rule it has to protect.

Step 1 only: convert the UTC timestamp to the viewer's timezone in exportService.ts.
Before you change anything, write down in one sentence the rule this change must not break.
Don't touch date formatting. We'll do that next.

Once the rule is written down, you can check the answer against it. Most of the time the model sticks to it, because the rule now sits in the context where the model can see it, not only in your head.

The same approach works outside code:

• Spreadsheet formula: your commission formula gets the tiered rate right and then ignores the monthly cap. Split it into two helper columns, one for the tiered amount and one that applies the cap. Combine them only after each is right on its own.
• Email: you need to turn down a vendor without hinting you'll reconsider next quarter. Ask for the rule first ('state what this email must never imply'), then the decline, then a check of the draft against the rule.

Move 3: Take the thinking back, not the typing

Here's the uncomfortable test. If you can't write down how you'd check the answer, the model can't hit it either. A hedging or generic answer often means you haven't decided what you want yet. Before your next prompt, write the check down. Any of these works:

• A test. An actual failing test, even a rough one.
• An example output: 'for this input, I expect exactly this'. If you're an analyst or PM, a small table with three input rows and the expected results does the same job.
• One sentence that starts with 'It must always...' or 'It must never...'.

// Write this BEFORE asking for the fix
test('export date respects viewer timezone', () => {
  const utc = '2026-03-03T14:00:00Z';
  expect(exportDate(utc, 'Australia/Melbourne')).toBe('2026-03-04');
  expect(exportDate(utc, 'Asia/Ho_Chi_Minh')).toBe('2026-03-03');
});

Sometimes writing the check shows you the fix and you don't need the model at all. Other times the fastest route is to write the ugly 20 lines yourself and hand them over: 'This works. Keep the behaviour exactly the same, clean it up, and don't add features.' Your ugly version becomes the spec. Models are very good at tidying working code and much less reliable at guessing what you meant.

A note for leads

When someone on your team is stuck in a prompt loop, it usually means the problem isn't understood well enough to hand off yet. You'd see the same thing if they were delegating to a person. Debugging their prompt rarely helps. Ask 'What would done look like?' before 'What prompt did you use?' If they can answer the first question clearly, the prompt usually sorts itself out. If they can't, the work left is thinking, not prompting.

Keep this beside your keyboard

BEFORE ANY FOURTH PROMPT

1. Is the chat poisoned?        -> New chat, five-line brief, no failed attempts
2. Is the task too big?         -> Split at what keeps breaking, state the rule first
3. Can I say what done is?      -> Write the test / example / 'it must always...' first

Tomorrow we build on the brief from Move 1 and look at how to keep a reusable version, so you're not writing it from scratch every time you open a fresh chat.

Extend your knowledge

• Read 'LLMs Get Lost In Multi-Turn Conversation' (Laban et al., 2025). It's research evidence that models struggle to recover once a multi-turn conversation goes off track.
• Read Anthropic's prompt engineering guide, especially the sections on being clear and direct and on using examples. They show how strongly examples in context shape the output.
• Kent Beck, 'Test-Driven Development: By Example'. It's the classic argument for writing the check before the code, and that matters even more now that a model writes the code.
• Practise this week. The next time you reach prompt three, stop, name the failure pattern out loud and change exactly one thing. Write down which move fixed it.