Sometimes the problem isn't the code.
Sometimes the problem is the conversation.
That's one of those things that sounds obvious after you've been burned by it, but it's not obvious while you're in the middle of it.
You're working with an AI assistant. You give it a task. It gets part of it right, but it makes one very bad assumption. So you correct it. It apologizes. It says it understands. It tries again.
And then it does the same thing again.
So you explain it more clearly.
It apologizes again.
Then it gives you a new answer that is still built around the same bad assumption.
At that point, most of us have a natural instinct to keep pushing. We think the answer is one more prompt. One more clarification. One more warning in all caps that says, "Do not do this thing again."
Sometimes that works.
But sometimes it doesn't.
Sometimes the thread itself has caught fire.
That's where I think the old safety lesson applies.
Stop.
Drop.
Roll.
When you're on fire, you don't keep running. You stop, drop, and roll.
And when an AI session catches fire, you may need to do the same thing.
Stop the work.
Drop the polluted context.
Roll into a clean thread.
The conversation is part of the work
One of the traps with AI is that chat feels casual.
It feels like you're just talking.
And in one sense, you are. You can explain things. You can correct things. You can ask follow-up questions. You can say, "No, that's not what I meant," and the AI will try again.
That's useful.
But it's also dangerous if you forget what the conversation really is.
The conversation isn't just a conversation.
It's part of the working context.
Every wrong answer is still in there. Every correction is still in there. Every failed attempt is still in there. Every explanation of why something went wrong is still in there.
And when you ask the next question, the AI isn't answering from some perfectly clean version of what you meant.
It's answering from the whole conversation.
That includes the good instructions.
It also includes the bad attempts.
That's where things can start going sideways.
"I understand" doesn't always mean the thread is clean
We've all seen this pattern by now.
The AI makes a mistake.
You correct it.
It says something like:
You're absolutely right. I misunderstood the requirement. I will preserve the existing structure and only make the requested change.
Then it makes the same mistake again.
Maybe not exactly the same way. Maybe it changes the shape of the mistake. But the underlying assumption is still there.
That's the important part.
The AI may be able to state the correction correctly while still producing output that's influenced by the earlier bad pattern.
This is especially true when the mistake isn't just a typo or a missing import.
It's much worse when the mistake involves structure.
Or architecture.
Or the shape of an interface.
Or a boundary you told it not to cross.
Or a working system that it decided to "simplify" because it didn't understand why all the parts were there.
That's when the conversation can become contaminated.
Not because the AI is being stubborn.
Not because it's trying to ignore you.
But because the wrong shape is now part of the context.
It has seen the wrong version.
It has reasoned about the wrong version.
It has tried to fix the wrong version.
It has explained the wrong version.
And now you're asking it to continue from inside the same thread.
That may not be the safest place to keep working.
Bad context has gravity
AI is very good at continuing patterns.
That's one of the reasons it's useful.
If you give it a clear pattern, it can often extend that pattern. If you give it clean examples, good boundaries, and a working design, it can often stay inside the lane.
But that cuts both ways.
If the thread contains a bad pattern, that pattern has gravity.
If the AI has already made the same wrong move three times, then the conversation is now full of that wrong move.
Even if each one is followed by a correction, the wrong move is still sitting there in the context.
You can end up with a thread where half the conversation is what you want, and the other half is warnings about what went wrong.
At some point, that's not a clean workbench anymore.
That's a workbench covered in broken parts.
You may still be able to build on it.
But you probably shouldn't trust it as much as you did at the start.
A correction is not the same thing as a reset
This is the big distinction.
Correcting a mistake inside a thread is normal.
Resetting the thread is different.
A correction says:
That part was wrong. Fix it and continue.
A reset says:
This conversation has too much bad history in it. Extract what we learned, and start clean.
Those aren't the same thing.
Most AI mistakes don't require a reset. If the assistant gets a function name wrong, misses a parameter, misunderstands a sentence, or produces something that just needs a normal revision, keep going.
That's not what I'm talking about.
I'm talking about the sessions where the AI keeps circling the same drain.
You correct it, but it keeps returning to the same assumption.
You tell it not to remove something, and it removes it again.
You tell it not to simplify the structure, and it simplifies the structure again.
You tell it that a part of the system is intentional, and it keeps treating it like leftover clutter.
At that point, one more correction may not be the answer.
The answer may be to stop, drop, and roll.
When to stop
The first step is to stop.
That sounds simple, but it usually isn't.
When a session starts going bad, there's a strong temptation to keep typing.
You want the AI to understand.
You want it to admit the mistake.
You want it to fix what it broke.
You want to get back the time you've already lost.
So you keep pushing.
The problem is that every new correction is also more context.
Every frustrated explanation becomes part of the session.
Every failed fix becomes part of the session.
Every "no, that's still wrong" becomes part of the session.
Sometimes you reach the point where you're not improving the thread anymore. You're just adding more smoke.
That's when you stop asking for code.
Don't ask for another patch.
Don't ask for another rewrite.
Don't ask for another "final corrected version."
Change the task.
Ask the AI to summarize what went wrong and prepare a clean restart prompt.
Something like:
Stop making changes. Summarize the correct goal, the important boundaries, the mistake that happened, the root cause if we know it, and the safest restart instructions for a new thread.
That turns the bad session into a diagnostic tool instead of a workbench.
That's a much better use for it.
What to drop
Dropping doesn't mean you throw away everything.
You don't want to lose the lesson.
You don't want to lose the diagnosis.
You don't want to lose the corrected rule.
What you want to drop is the polluted context.
You don't need the new thread to inherit every failed attempt.
You don't need it to read three pages of frustration.
You don't need it to see every wrong version that led you to the fix.
What you need is the clean version of the lesson.
There's a big difference between this:
The last session kept removing the parts of the interface it didn't think we needed, then it rebuilt the wrong layout, then it apologized, then it did it again, then we found out there was also stale local state involved, and I was getting pretty frustrated by the whole thing.
And this:
Preserve the shared shell exactly. Do not remove existing surfaces just because the first product doesn't use them yet. Before judging the visual result, make sure old local application state isn't being restored.
The second version is useful.
The first version may be true, but it brings too much smoke with it.
A good restart prompt should include:
- the real goal
- the known-good source of truth
- the boundaries that must be respected
- the specific mistake to avoid
- the root cause, if known
- the first safe verification step
- the next small task
It should not include the entire emotional history of the fire.
Take the lesson.
Leave the wreckage.
How to roll into a clean thread
Starting a new thread doesn't mean you just paste the same prompt and hope for the best.
That's not rolling.
That's just running back into the same burning building through a different door.
A clean restart should be deliberate.
Start with the cleaned-up prompt.
Provide the current source artifacts or repo state.
State the boundaries plainly.
Then give the AI a small first task.
Not the whole project.
Not the big feature.
Not the grand redesign.
A small first task.
Something like:
Confirm the project builds without changing behavior.
Or:
Rename only the product identity. Preserve the existing shell and surfaces. Report the files you expect to change before making feature edits.
Or:
Inspect the startup behavior and identify any persisted local state that could affect what we see when testing. Do not change code yet.
The first step should rebuild trust.
If the AI can't respect the boundary on a small task, you don't want it working on the large one.
Don't confuse a longer thread with a smarter thread
This is another trap.
A long thread feels valuable because it contains a lot of history.
And sometimes it is valuable.
If the work has gone well, a long thread may contain a lot of useful decisions, naming conventions, design choices, and accumulated understanding.
But a long thread can also contain a lot of junk.
More context isn't automatically better context.
A thread full of bad assumptions, failed fixes, stale screenshots, frustrated corrections, and half-true explanations may be worse than a short thread with a clean restart prompt.
That's the part we have to learn as AI users.
We don't just manage prompts.
We manage context.
And sometimes the best context is less context.
Cleaner context.
Context that says what we know now, not everything we stumbled through before we knew it.
The fire drill
Here's the practical version.
When an AI session catches fire:
- Stop asking it to continue the work.
- Ask it to summarize the actual goal.
- Ask it to identify the mistake and the root cause.
- Ask it to create a clean restart prompt.
- Remove the drama and the failed attempts from that prompt.
- Keep the corrected rules.
- Start a new thread.
- Give the new thread the clean prompt and the current artifacts.
- Start with a small verification task.
- Only then continue the real work.
That may feel like a delay.
But it usually saves time.
Because once a thread has gone bad, one more correction can turn into ten more corrections. And each one adds more smoke.
The rule
The rule is simple:
If the thread has become part of the bug, start a new thread.
Not every mistake requires that.
Not every frustrating answer means the session is ruined.
But when the same bad pattern keeps showing up, when the conversation is mostly corrections, when the AI keeps crossing the same boundary, or when you discover a root cause that invalidates half the earlier discussion, it's probably time.
Stop.
Drop.
Roll.
Sometimes the smartest thing you can do with an AI assistant is not to ask for one more fix.
Sometimes the smartest thing you can do is leave the damaged conversation behind.
Related field note: When the Conversation Became Part of the Bug.
-- Charles