This pair is about what happens when an AI coding session gets contaminated by its own history.
We tend to think that once we correct the AI, we’re back on track. Sometimes that’s true. But sometimes the conversation has already picked up too many bad assumptions, failed attempts, and wrong examples. The AI may say it understands the correction, but the next answer is still being shaped by the whole thread.
That’s especially dangerous when the mistake isn’t just a syntax error. It’s worse when the AI misunderstands the architecture, removes things it shouldn’t remove, simplifies something that was deliberately built that way, or keeps crossing the same boundary after being told not to.
The guide lays out the “Stop, Drop, and Roll” pattern:
Stop the work.
Drop the polluted context.
Roll into a clean thread with a clean restart prompt.
The field note tells the story behind it. In my case, part of the problem turned out to be old local application state being restored, which made new attempts look wrong even after the code path had changed. By the time that was understood, the original AI thread had become more useful as a diagnostic record than as a safe place to keep working.
The main takeaway:
If the conversation has become part of the bug, don’t keep arguing with it. Extract the lesson and restart clean.
Curious whether others using AI coding tools have seen this same pattern: the assistant says it understands the correction, but the session keeps pulling back toward the same bad idea.
Co-Pilot remembers earlier parts of the conversation.
It can go either way in terms of usefulness, sometimes it remembers the correct stuff, other times it doesnt.
I’ve mentioned it here, where its remembered my naming schema for equates, but you have/had to (might have changed) switch Personalisation and memory to On for previous conversations to be remembered.
Its why I am still out on Ai. Its good for left field ideas. Its good for suggesting working code examples, where the official docs are wrong, but I wouldnt attempt to build a major app with it.
Memory can definitely be useful when it remembers the right thing. Naming conventions, preferred patterns, project structure, terminology, and “how I usually do this” are exactly the kinds of things that can make an AI assistant more helpful.
The problem, at least from where I sit, is that memory can also become another source of hidden state. Sometimes it remembers the useful rule. Sometimes it remembers an old assumption, a half-correct naming pattern, or something that was true three experiments ago. Then the developer is left trying to figure out whether the bug is in the code, the prompt, the current context, or the AI’s remembered context.
That’s really the part I’m trying to point at with Stop, Drop and Roll. It’s not that memory is bad, or that AI is useless. It’s that once the conversation becomes part of the working environment, we have to treat it as part of the debugging surface.
I’m probably a little more optimistic than you are on building serious applications with AI, but only with some discipline around it. I don’t see it as “turn it loose and let it build the app.” I see it more as a very fast assistant that still needs boundaries, checkpoints, review, source control, and the occasional reset when the context starts drifting.
So yes, memory helps. But I’d still want the important project rules written down somewhere I can inspect, edit, and deliberately feed back into the conversation instead of depending entirely on what the assistant thinks it remembers.
That’s true, Richard. Hallucinations and bad assumptions are still part of the landscape, and I don’t think any amount of happy talk changes that.
Where I may separate this a bit is that I don’t see the answer as only “run your own local LLM.” That may give you more control over some pieces of the puzzle, but it doesn’t magically remove the need for discipline. A local model can still be wrong. It can still confidently go down the wrong path. It can still misunderstand the architecture. It can still generate code that looks plausible but breaks something subtle.
To me, the real control point is the working process around the model.
That means source control, backups, small changes, review, clean restart prompts, written project rules, and knowing when the conversation itself has become contaminated enough that it needs to be dropped. Whether the model is local, cloud-based, Copilot, ChatGPT, Claude, or something else, the developer still has to treat it as a powerful assistant, not as an authority.
So yes, make people aware of the risks. Absolutely.
But I’d also say the practical lesson is not “don’t use it for serious work.” It is “don’t use it casually for serious work.”
But then you lose control and knowledge over how something works. It makes you become a manager who is not really in touch with whats going on and why.
The first screenshot is PageSnip watching the PageSnip repo itself. After a refresh, it tells me exactly what changed: the change log and one source file. The second screenshot is me opening the changed file directly from that review list. I can click the source files in the list that were changed and open them directly from there too.
That is the difference in how I try to use AI.
I am not asking it to run wild across a codebase while I sit back and trust whatever happens. Each change is small. Each update gets written into the change log. The changed files are visible. I can open them, read them, review them, test them, and decide whether the work actually fits the project.
That does not mean mistakes can’t happen. They absolutely can. But it means I have a process that keeps the AI in the role of a tool instead of letting it become the driver.
To me, that is the important distinction.
Using AI casually for serious work is dangerous.
Using AI deliberately, with source control, change review, containment, testing, and the developer still in charge of the architecture, is a very different thing.
