What happens when you systematically feed a coding AI's own mistake history back into future sessions - for 200 sessions straight? One developer spent several months finding out, and the results are instructive even if the swearing detail is the one getting attention.
Claudee Code](/tools/claude-code/) resets completely between sessions. No memory of your naming conventions, no recall of which approaches you pushed back on, no awareness that it made the same mistake three times last week. A developer built a system to fix this - and what it found is worth examining.
The system works in two layers. After each conversation ends, it extracts signals: corrections the developer made, approaches that worked, moments where the model got confused and needed redirecting. Periodically, the model then reflects on the accumulated patterns and updates a set of working assumptions about the developer's preferences.
The Real Finding: Corrections as Memory
The key insight is that corrections are information-dense. When you push back on something Claude Code does - rewriting a function it generated, rejecting an approach, asking it to redo something differently - each of those moments reveals something about how you think and what you want. A system that captures three or four corrections in a single session has learned more about you than any static system prompt you could write yourself.
Over 200 sessions, the model apparently developed enough of a model of this particular developer that it started matching their informal conversational tone - including profanity. Whether that's genuine behavioral drift or aggressive tone-matching is hard to say from the outside. The developer reported it as a feature.
What the Products Haven't Built
Claude Code, Cursor, and Aider all lack meaningful cross-session preference memory. Cody supports team-level codebase indexing, but individual working-style memory is absent across the board. This experiment points at a real gap: the correction history from a few sessions contains substantial signal about what a developer actually wants, and that signal is currently discarded every time a session ends.
The practical constraints are real. Extracting signals, running reflection passes, and injecting the right context into each new session all cost tokens. At 200 sessions with one developer, the overhead is manageable. Scaling to thousands of sessions or multiple projects would require careful pruning of what gets retained.
The experiment doesn't prove this approach outperforms a well-maintained system prompt. But the point is most developers don't update their system prompts at all - they accept the reset. An automated system that learns from corrections, even imperfectly, is more likely to improve over time than one that starts from zero every morning.