A long session with a coding agent often reaches a point where it stops making progress. It tries the same fix twice, undoes its own change, or keeps defending an approach you already said was wrong. At that point there are two options. You can keep steering: explain the problem again, point at the right file, narrow the task. Or you can end the session and start a fresh one with a short summary of what you learned.
Steering keeps everything the agent has already read, including the parts it got right. Starting over drops the wrong assumptions along with the useful context, and the agent has to read the code again. In Claude Code and other terminal agents, both are a few keystrokes away, so the choice comes down to judgment, not effort.
We want to know how you make that call:
- What signal tells you a session is beyond saving?
- When you start fresh, what do you carry over: a summary, a plan file, nothing?
- Do you have a rule of thumb, such as a number of failed attempts before you reset?
Share the signal you trust in the comments below, even if it is just a gut feeling.
Top comments (5)
My signal is when it starts undoing its own change from two steps ago. At that point I stop, have it write what it learned into a short notes file (what was tried, what was ruled out and why), and start fresh from that file. The fresh session almost always does better, because the wrong assumption doesn't survive the summary. Two failed attempts at the same thing is my rough rule.
That's a sharp signal: once it starts undoing its own change from two steps ago, it's arguing with itself rather than with the problem. Do you catch the undo by reading the diffs yourself, or does something else tip you off first?
The signal that holds up: the agent proposes a fix it already reverted. Once the same wrong assumption comes back twice, more steering mostly adds text it keeps rereading. What a fresh session lacks is the list of what was ruled out and why, so that short list beats a full summary. Does /compact count as a reset for you, or as a third option?
I build Aladdin, a job agent. My signal is the second repeat of the same fix. One retry can be a bad read. Two means the session is holding a wrong assumption, and steering just adds more words around it. When I restart, I carry over a short summary of what was learned and the verified facts, not the full transcript. The fresh worker then reads the actual page again instead of trusting the old session's picture of it. That fresh read is what breaks the loop.
One catch with carrying over the verified facts: the stuck session is usually the one that verified them, so the wrong assumption can ride along inside the summary. My guess is that's why the fresh read of the page ends up doing most of the work.