You have been going in circles with your agent on the same bug for an hour. It keeps trying, each attempt sounds just as confident as the last, and none of them work. The hard skill here is not another fix, it is knowing when to stop letting the agent try. This chapter gives you that judgment: when to take over, when to call a human, and when to accept the problem is beyond the tool for now.
7.7.1When to stop the agent
An agent has no sense that it is failing. It will cheerfully attempt the same broken idea a tenth time, because nothing in it tracks that the last nine did not work. That meta-judgment is yours, and noticing the point of diminishing returns is the whole job here.
Watch for three signals. It has looped over the same two or three fixes, its context is now full of dead ends so it contradicts itself, or it has stopped reasoning and started guessing. When you see them, stop. Another attempt only buries the real signal deeper.
7.7.2Step in yourself
Taking over does not mean writing the fix by hand. It means reading the actual code around the failure yourself, so you stop guessing along with the agent. A fresh hypothesis, a specific and testable guess at the cause, is usually the exact thing a stuck agent is missing.
Then hand it back a much smaller task. Not "fix the login," but "the token is null here, check whether it is set before this line runs." As the retry-loop chapter covered, starting the agent clean on that narrow task often breaks a loop nothing else could.
Rule of thumb: when you step in, your job is to narrow the problem, not to solve it. A smaller, precise task is usually all the agent needed.
7.7.3When to ask a human
Sometimes both of you are out of ideas, and the answer only lives in a person's head. Bring the specific error and what you already tried to where the experts are: the library's own issue tracker on GitHub, Stack Overflow, or a community for your stack.
Bring one more thing, or you will be ignored: a minimal reproduction, the smallest file or snippet that still shows the failure, with everything else stripped out. Have your agent do the stripping, cutting one piece at a time from the repro you already have and re-running until only the failure is left.
Do it even when you never post it. Minimizing finds the cause more often than the answer does, because the piece you remove that makes the bug disappear is the piece that caused it.
7.7.4Know when it's beyond the tool
A few problems are genuinely beyond what the tool does well right now, and saying so is judgment, not defeat. Sometimes the cost of getting it wrong is high: real money, user data, security, or work you cannot afford to lose. There, an hour of an actual professional is cheap insurance against a very expensive mistake.
Before you burn a day on any hard bug, roll back to the last working state, as the rollback chapter showed, so you are never both stuck and broken. Then, when you do take over, make the agent hand you a clean diagnosis instead of one more guess:
When the checklist trips, this prompt forces one clean theory instead of another guess:
Do this now: take the bug you are most stuck on and run the stop-and-take-over checklist against it. If it trips, paste the prompt above to get one clean theory instead of another guess, then carry the fix forward.
