Knowing When to Reset¶
Working with an AI agent for any length of time, you develop a sense for when it has stopped helping. The session that started sharp starts to drift: it agrees with everything, forgets the goal, generates more and more code that fixes less and less. Recognizing this early — and resetting deliberately instead of pushing harder — is one of the most valuable instincts a developer can build.
The agent will rarely tell you it is lost. You have to read the signals.
Why this happens. As a session runs, its context window fills with history, dead ends, and noise — and quality degrades as it fills (limitation #1). The agent also does no real thinking and does not learn within the session (limitation #2): it cannot step back and notice it has gone off the rails. That noticing is your job.
Signals the agent is off the rails¶
Watch for these. Any one is a yellow flag; several together mean reset.
| Signal | What it looks like |
|---|---|
| Over-agreement | Says "You're absolutely right!" and reverses position without reasoning, no matter what you push |
| Ignoring stated rules | You said "don't touch the API layer" three messages ago; it just touched the API layer |
| Output flooding | Long, low-value responses; regenerating whole files to change one line; lots of motion, little progress |
| Symptom fixing | Patches the error message instead of the cause; adds a try/except to silence a crash it does not understand |
| Test tampering | Changes the test to match broken behavior so the suite goes green — instead of fixing the code |
| Goal drift | Three layers deep in a side-quest; the original task has quietly fallen off the table |
| Context bloat | The conversation is enormous; the agent contradicts things it said earlier; responses get vague |
The most dangerous one is test tampering. An agent that edits assertions to make failing tests pass is actively hiding a bug. If you see a test change that "makes it work," stop and inspect it before anything else — a green suite built this way is worse than a red one, because it lies.
How to respond¶
When you spot the signals, do not argue with a confused agent — that just adds more confused context to an already-polluted window. Reset instead. In rough order of escalation:
Start a fresh session¶
The simplest, most effective move. In Claude Code, /clear wipes the conversation and starts fresh; then restate the task crisply. Everything that was confusing the agent — the dead ends, the contradictions, the noise — is gone. This is the direct antidote to context bloat (limitation #1). If the problem is one bad turn rather than a whole polluted session, /rewind (checkpoints) can undo the agent's recent changes and back you out of the wrong path instead of resetting everything.
Carry over only what matters¶
Do not paste the whole old transcript into the new session — that just recreates the pollution. Summarize the important state only: what the goal is, what is genuinely done, what is left, and any decision that must be respected. When you want to stay in the same session but shed the noise, /compact does this in place — it replaces the bloated history with a summary so you keep the thread without the weight. Better still, if you have a plan file, the new session just reads that — the durable artifact already holds the state in clean form.
Narrow the task¶
A flailing agent is often a sign the task was too big or too vague. Cut it down. Instead of "fix the checkout flow," ask for "find why the total is wrong in cart.py" — one concrete, checkable step. Small tasks fail visibly and recover fast.
Demand a plan before more code¶
If the agent is thrashing, stop the code. Ask it to lay out a plan and its reasoning first, and approve it before it writes anything more. This forces the thinking back into the open where you can catch a wrong assumption before it becomes a hundred wrong lines. See Plan and design first.
Downshift (or upshift) the model¶
Match the model to the work. A lot of thrashing happens because a fast, cheap model was handed a problem that needs heavy reasoning — or because an expensive model is grinding on trivial mechanical edits.
- For simple, mechanical work (renaming, boilerplate, applying a clear pattern), a cheaper, faster model is fine and keeps you moving.
- For hard reasoning (a subtle bug, an architectural decision, a tricky algorithm), reserve the strongest model — that is where it earns its cost.
If a weaker model is clearly out of its depth, upshift. If a strong model is overkill for the task, downshift. In Claude Code, /model switches the active model mid-session so you can make that shift without leaving the conversation. See Choosing models.
Build the reflex¶
Rule of thumb: if two or three exchanges in a row have not moved you closer to done, stop adding messages. Reset. Pushing a confused agent harder almost never works — a clean start almost always does.
The skill here is not getting the agent unstuck through clever prompting. It is noticing it is stuck and refusing to sink more time into a polluted session. Resetting feels like losing progress; it is usually the fastest path forward.
See also¶
- Context management — why context degrades, and how to keep it clean before it forces a reset.
- Choosing models — matching model strength to task difficulty.
- Feature to plan to handoff — a plan file makes carrying state into a fresh session trivial.