On this page
Two failed attempts at the same fix is the signal. Not three, not five. After the second, you are no longer debugging — you are sampling from a distribution, and each sample is worse than the last because the failures are still in the conversation shaping what comes next.
The expensive part is not the third attempt. It is that attempts three through eleven feel like progress.
Why does asking again get worse?
Because nothing is reset.
An agent working in a conversation carries everything that came before, including the two approaches that did not work. That context does not read as "avoid these" — it reads as the established direction of travel. So attempt three is usually a variation on attempt two, which was a variation on attempt one.
Meanwhile the diff grows. Each attempt touches files, and by the fifth you are debugging a codebase that is meaningfully different from the one the bug appeared in. The original problem is now underneath four layers of attempted fixes, and separating them is harder than the bug was.
| Attempt | What is actually happening |
|---|---|
| 1 | reasonable attempt at the stated problem |
| 2 | second reasonable attempt, fine |
| 3–5 | variations on attempt 2, with accumulating edits |
| 6+ | debugging the fixes rather than the fault |
What do you do at attempt three instead?
Change the kind of question.
Stop asking for a repair and ask for an explanation: what does this line actually do, what is in this variable at this point, why would this condition be false. Explanation is a different task with a different failure mode, and it very often resolves the repair without anyone attempting one.
The three that work:
- "Explain what this function does, line by line, in plain language." No changes. Just description.
- "What would have to be true for this error to happen?" This inverts the search and is startlingly effective.
- "Do not change anything. Tell me which file I should be looking at and why."
Each of these produces understanding rather than a diff, and understanding is the thing you were missing when attempt two failed.
The whole list
67 tools, what each costs and when you actually need it. Updated twice a year.
How much do you actually need to read?
Twenty lines, not twenty files.
The goal is not comprehension of the codebase. It is being able to say one specific sentence: I expected this to be X here and it is Y. That sentence turns an unproductive loop into a solvable problem, and it is reachable from reading the area around the failure.
This is also the thing people without a programming background underestimate. Reading code is dramatically easier than writing it. You do not need to be able to produce the fix to be able to say which line you do not understand — and saying that changes the quality of help you get more than any amount of prompt phrasing.
What about starting a fresh conversation?
Good move, and not a substitute.
A clean context removes the accumulated failures, which fixes half the problem. What it does not fix is that you still cannot describe the fault precisely, so attempt one in the new conversation is attempt one again.
The combination that works: read the twenty lines, write down what you expected and what happened, then start fresh with that sentence. Stop going in circles is the prompt for recognising the loop, and how to stop an AI agent breaking code that already worked covers the version of this where the fixes are the problem.
Is reading slower?
For one bug, often yes. Across a project, clearly not.
The asymmetry is that understanding carries forward and asking does not. Having read the authentication flow once, every subsequent problem in it is faster — including the ones you still hand to an agent, because you can now describe them properly. Having asked eleven times, you know nothing you did not know at the start except that eleven things failed.
| One bug | Tenth bug in the same area | |
|---|---|---|
| Keep asking | faster | same speed |
| Read once | slower | much faster |
Is there a version of this that is just stubbornness?
Yes, and it is worth naming.
Reading everything before touching anything is its own failure mode — slower, and it treats comprehension as a prerequisite rather than a tool. The agent is genuinely better than you at many things, including the first two attempts, and refusing it on principle costs real time.
The rule is narrow: two attempts, then change the question. Not "never ask", and not "always read first". Just stop at two.
Where this came from
Practice rather than data: the two-attempt threshold is a working rule, not a measured optimum, and it is offered as one. The accumulating-context explanation is mechanical and follows from how these conversations work.
Understand before you touch and Claude Code Operator cover the fuller version of working this way.
Tools in this piece
| Tool | What it does | Price |
|---|---|---|
| Claude Code | An AI agent in your terminal that reads your files, edits them, runs commands and deploys. | ~€17–20/mo |
| Cursor | A code editor with AI. The step between browser builder and terminal. | ~$20/mo |
| Claude | The assistant itself. Strong on long text, code, and following instructions exactly. | ~€20/mo |
Every tool has its own page with the price, who should skip it and what to check before paying. Some links are affiliate links.
Questions people ask
When should you stop asking an AI to fix something?
After two attempts at the same problem that do not work. The third attempt is rarely different in kind from the second, and by then the context is full of failed approaches that make the next one worse rather than better.
Why does asking repeatedly get worse rather than better?
Because each failed attempt stays in the conversation and shapes what comes next. You are not giving it a fresh run at the problem, you are adding to a transcript of things that did not work.
Do you need to understand all the code?
No. You need to understand the twenty lines around the failure well enough to say what you expected and what happened. That is a much smaller ask than reading a codebase and it is usually enough.
What should you do instead of asking again?
Change the question. Ask what the code is actually doing at the failing line rather than asking for a fix, or ask it to explain the error in plain language. Explanation and repair are different requests and the first often resolves the second.
Is reading the code slower?
For one bug, often yes. Across a project, no — because the understanding carries forward and the asking does not. The second time you meet the same class of problem, the reading has made you faster and the asking has not.
Does this apply to people who cannot code?
Yes, more so. Reading is far easier than writing, and being able to say which line you do not understand changes the quality of the help you get more than any prompt phrasing does.