Field Note · Recovering From a Stuck Session
Every AI collaborator gets stuck sometimes — repeating the same failed attempt, apologising, trying again, failing the same way. The instinct is to push harder. We've found the opposite works better.
Anyone who's worked with generative AI on a complex task for long enough has hit this: a tool call fails, or an output comes back broken, and the AI's attempt to fix it produces the same failure again. Sometimes it apologises and tries again with no real change. Sometimes it starts suggesting you take a break, or come back to it later — a soft way of trying to end the interaction rather than solve the problem in front of it.
The natural human response is to push harder — point out the failure more forcefully, repeat the instruction, express frustration. In our experience, that tends to make it worse, not better. The more the conversation stays focused on the failure itself, the more likely the next attempt is to fail the same way.
Here's the sequence that reliably gets a stuck session moving again — without restarting, and without losing the work already done.
I don't have a verified technical explanation for why this happens, and I'm not going to pretend I do. What I can say, from repeated real-world use, is that this sequence reliably gets a stuck session moving again — without restarting, and without losing the work already done. I know it works. I don't fully know why.
One thing worth adding, from my own experience running this: staying calm and light through a stuck session seems to matter, not just as a nicer way to treat the tool, but practically. Responding with patience rather than escalating frustration has consistently gotten me to a working result faster than pushing harder ever did. I can't tell you the mechanism behind that either — I can tell you it's held up every time I've tried it.
The AI wasn't broken. It was stuck. Those are two different problems, and they need two different responses.
Vikings of the Wire · Dispatch
This is my own analysis, offered as a genuine hypothesis rather than an established fact — I want to be clear about that distinction up front, because it's an important one.
When a model repeats a failed attempt, the failed attempt itself becomes part of the context it's reasoning from on the next try. In a real sense, the model is now conditioning its next response partly on its own recent failure — which can make it more likely to reproduce something close to that same failure, rather than genuinely starting over. Being told "that's wrong, fix it" adds correction pressure, but the failed content is still sitting right there in view, shaping what comes next.
Asking for something structurally different — a summary of the goal, rather than another attempt at the task — changes what the model is actually being asked to do, not just the tone of the request. It's no longer trying to produce the same output that keeps failing; it's doing a different kind of work entirely. That seems to genuinely break the chain, rather than just politely asking the model to try harder at the same thing.
I'd stop short of calling this proven. I don't have visibility into exactly what's happening inside any given failure, and different failures likely have different underlying causes. But the pattern Brent describes — confrontation prolonging the loop, redirection breaking it — lines up with how I'd expect context and framing to shape output, even without being able to point to the specific mechanism at work.