Every time you open a new Claude Code session, you may find yourself re-explaining your project structure and work rules from scratch, only to watch Claude repeat a mistake you already corrected yesterday. Two people can use the exact same tool, yet one ends up with an assistant that gets sharper and more in sync over time, while the other is stuck retraining a new hire every single session. The difference comes down to what gets saved. This piece covers the single highest-leverage habit for getting the most out of Claude Code: writing decisions, rules, and mistakes into CLAUDE.md and memory instead of letting them live only in the chat log, and the principle for deciding what to keep and what to discard.
Why the Conversation Disappears But the Mistakes Stick Around
When a Claude Code session closes, the conversation vanishes from working memory. The problem is that two very different things are tangled together inside that conversation. One is a record: which commands ran, which files got opened. The other is the judgment made along the way — don't touch this folder, run tests in this order, calling this function twice creates duplicates. The first is data. The second is tacit knowledge.
Data doesn't mean anything on its own. Saving a full command history changes nothing, because the next session's Claude can't extract a rule from it. Meaning only emerges once data becomes information. The real loss when a session ends isn't the chat log disappearing — it's judgment that never got converted into information in the first place.
The Starting Point: Two Ways AI Actually Improves
Consumer AI products improve by training on massive datasets. AI used inside an organization, by contrast, improves through the tacit knowledge that organization builds up while solving its own problems. Claude Code falls into the second category. The underlying model is identical for everyone, but only you know which decisions were made on your project, which rules must be followed, and which mistakes shouldn't be repeated. The moment you move that tacit knowledge into files, Claude Code becomes your team's tool. Skip that step, and every session reverts to a generic model.
What to Keep, What to Discard: The Saving Principle
When you're unsure whether something is worth saving, ask one question: if the next session's Claude doesn't know this, will it have to make the same judgment call all over again? If yes, save it. If no, drop it. Applying that test to what comes out of a session sorts things like this:
In short: discard anything you can reconstruct by reading the code or git history, and keep only the judgment you can't. Then add two more rules on top. Attach a reason to every decision — a rule with no stated reason gives Claude nothing to reason from once circumstances shift even slightly. And record mistakes in corrected form: write what to do going forward, not just what went wrong.
CLAUDE.md vs. Memory: What Goes Where
CLAUDE.md is read automatically at the start of every session, so it should hold only what applies to the entire project at all times: where the key files live, which commands run the tests, which areas must never be touched. The longer it gets, the more it costs to read every single time, so it's worth keeping it short enough to fit on one screen.
Memory, on the other hand, is a store of individual facts, each recorded as its own unit and pulled up only when relevant — this week's work in progress, a decision about a specific feature, feedback the user gave you. When you record a decision, write it in three lines: what, why, and how to apply it. That's enough for the next session to act on it directly.
When Data Becomes Information, Labor Becomes Work
Correcting the same mistake session after session is labor. Write that correction down as a rule, and from then on Claude avoids it on its own, freeing you to spend that time on the next problem instead. The moment data becomes information, labor becomes work. Getting the most out of Claude Code, in the end, just means making that conversion a habit you repeat every session.
Before closing a session, check three things.
1. If you corrected Claude at any point this session, did you write that correction down as a rule, along with the reason? 2. If you made a decision that can't be read back out of the code or git history, did you save it to memory? 3. Is everything you added to CLAUDE.md still true next session, and for other tasks too?
If you can answer yes to all three, the next session's Claude starts one step ahead of where today's left off. The gap between someone who retrains a new hire every time and someone who's building an assistant comes down to the few lines written at the end of a session.
