I've been using Claude Code daily for about a year now. For the first few months, I used it the way most people do — one long conversation, throwing everything at it, getting frustrated when it started forgetting things. It took me embarrassingly long to realize the problem wasn't the tool. It was how I was thinking about it.

Here's what I do now, and why.

The Thing Nobody Tells You About Context Windows

Claude Code gives you a massive context window. And your natural instinct is to use all of it — keep the conversation going, pile on more context, because surely more information means better results.

It doesn't. Here's what actually happens:

• Information in the middle of long conversations gets less attention. That constraint you mentioned 30 messages ago? The model is barely looking at it anymore.
• Every wrong turn is still in there. The three approaches you rejected, the debugging dead ends, the "no, I meant..." corrections — they're all competing for attention alongside the stuff that matters.
• The model starts drifting. It loses its grip on your original instructions and starts producing output that slowly diverges from what you asked for.
• It gets confidently repetitive. It suggests things you've already tried, sometimes with slightly different wording so you almost don't notice.

I call this context rot, and it hits hardest exactly when you've done the most work. You spent an hour building shared understanding of some gnarly problem, and that's precisely when things start falling apart.

The Mental Model That Changed Everything

At some point I had a realization that sounds obvious but genuinely changed how I work:

The conversation is RAM. Files are disk.

You'd never design a system where the only copy of important state lives in RAM. But that's exactly what most people do with Claude Code. They pour an hour of investigation into one conversation and then act surprised when it evaporates.

Once I internalized this, everything else fell into place.

My Actual Workflow

1. CLAUDE.md Is My Project Brain

This is probably the single highest-leverage thing you can do with Claude Code. The CLAUDE.md file sits at the root of your project and gets loaded into every conversation automatically. I use it to store anything the model needs to know across sessions:

• Architecture decisions and constraints
• Conventions the codebase follows
• Known gotchas and footguns
• How to build, test, and deploy

Every new conversation starts pre-loaded with this context. No explanation needed. When I discover something important during a session — say, that a particular service has an undocumented rate limit — I add it to CLAUDE.md before I forget. Future me (and future conversations) will thank me.

2. Let Auto Memory Do the Heavy Lifting

This is where Claude Code goes from "useful tool" to "tool that learns."

Auto memory is a system where Claude Code automatically writes down important discoveries, preferences, and patterns as it works with you. When you tell it "always use pnpm, not npm" or "remember that the API tests require a local Redis instance," it saves that to a memory file — without you having to manually edit anything.

Each project gets its own memory directory at ~/.claude/projects/<project>/memory/. The structure looks like this:

~/.claude/projects/<project>/memory/
├── MEMORY.md          # Concise index, loaded into every session
├── debugging.md       # Detailed notes on debugging patterns
├── api-conventions.md # API design decisions
└── ...                # Any other topic files Claude creates

MEMORY.md is the entrypoint — the first 200 lines (or 25KB) get loaded at the start of every conversation. Claude keeps it concise by moving detailed notes into separate topic files like debugging.md or patterns.md. Those topic files aren't loaded at startup; Claude reads them on demand when it needs them. This is clever design — your sessions start fast with a focused index, and the deep knowledge is one file-read away.

The key thing: all of this is plain markdown you can edit or delete at any time. Run /memory to browse and open memory files from within a session. I check mine regularly, pruning stuff that's outdated and occasionally reorganizing.

This directly attacks context rot. Instead of re-explaining your project's quirks every session, Claude already knows. The understanding persists across conversations, across /clears, across days. It's the "files are disk" principle, automated.

If you want auto memory stored somewhere specific, you can set autoMemoryDirectory in your user or local settings:

{
  "autoMemoryDirectory": "~/my-custom-memory-dir"
}

One caveat: auto memory is machine-local. It's not shared across machines or cloud environments. All worktrees and subdirectories within the same git repository share one auto memory directory, though, which is exactly what you want.

3. Write It Down Before You Lose It

Even with auto memory, I still manually dump investigation notes before a conversation gets too long. Auto memory captures preferences and patterns; manual notes capture the specific state of a debugging session. Different jobs.

I usually drop these under .claude/ or as a debug-notes.md:

## Bug: Intermittent 500 on /api/orders

### Root cause
Race condition in OrderService.process() — two concurrent 
requests can both pass the inventory check before either 
decrements stock.

### What didn't work
- Adding a simple mutex (deadlocks with payment callback)
- Database-level locking (too broad, kills throughput)

### Likely fix
Optimistic locking with retry on the inventory update.

Then I start a fresh conversation: "Read debug-notes.md and implement the fix." The new conversation has all the context it needs and none of the baggage.

This is embarrassingly simple and I resisted it for months. Don't be me.

4. Git Commits as Context Checkpoints

Every time Claude Code produces something worth keeping — a partial fix, a useful refactor, even a diagnostic script — I commit it. And I write descriptive messages:

git commit -m "Add diagnostic logging for order race condition

Confirmed: concurrent requests both pass inventory check
at OrderService.java:142 before either writes back.
See failing test in OrderServiceRaceTest."

When I start a new conversation, git log and git diff become high-quality context that costs zero conversation tokens. Claude Code can read your git history — let it.

5. Encode Understanding in Tests

This is the one I'm most evangelical about. If I've found a bug, I get Claude Code to write a failing test before I clear the conversation:

"Write a test that demonstrates the race condition in 
OrderService.process() with two concurrent requests 
for the last item in stock."

That test is the understanding, encoded in something executable. A totally fresh conversation can run it, see the failure, read the test code, and know exactly what to fix. You don't have to explain anything. The test does the explaining.

6. Break Work Into Focused Conversations

Instead of one mega-conversation that investigates, diagnoses, and fixes:

• Conversation 1: Investigate. Explore the codebase, reproduce the bug, narrow down the cause. Write findings to a notes file.
• Conversation 2: Fix. Start fresh. Point to the notes. Implement the solution.
• Conversation 3: Verify. Review the fix, check edge cases, clean up.

Each conversation stays short enough that Claude Code is sharp the whole time. You're working with the context window instead of against it.

7. Use /context to See the Warning Signs

Here's a command I wish I'd discovered earlier: /context visualizes your current context usage as a colored grid and shows optimization suggestions.

Think of it as a fuel gauge for your conversation. When the grid is mostly green, you've got plenty of room. When it's turning red and throwing warnings, you're in the danger zone for context rot. It even suggests specific optimizations — maybe a particular tool is eating too much context, or you've got memory bloat from repeated file reads.

I glance at /context periodically during longer sessions. It takes a second and has saved me from pushing into degraded territory more than once.

8. /rewind Instead of Starting Over

Before I knew about /rewind, my options when things went sideways were binary: keep pushing through the rot, or /clear and lose everything.

/rewind gives you a middle ground. It lets you roll back the conversation (and optionally the code) to a previous checkpoint, or summarize from a selected message. Took a wrong turn three messages ago? Rewind to before that turn. The dead-end exploration is gone, the model's attention isn't wasted on it, and you keep everything that was working.

This is especially useful when Claude Code goes down a rabbit hole — you can surgically remove the bad turns instead of nuking the whole session.

9. /btw for Side Questions That Don't Pollute Context

This one's subtle but important. Mid-debugging session, you need to check some syntax or ask a quick tangential question. If you ask it inline, that question and answer become part of your conversation context forever — noise competing with the actual investigation.

/btw lets you ask a side question without it being added to the conversation. Quick lookup, no context cost. I use it constantly for "what's the syntax for X again?" type questions that have nothing to do with the task at hand.

10. Compact Early, Not Late

Claude Code's /compact command summarizes your conversation to free up context space. The timing matters more than you'd think.

If you compact when the conversation is already confused, the summary inherits that confusion. Garbage in, garbage out.

The counterintuitive move: the moment you think "this is going well but getting long" — that's your window. Compact while things are still clean. Don't wait until you're already fighting the model.

11. /fork When You Want to Try a Different Direction

/fork (also available as /branch) lets you branch your conversation so you can explore an alternative approach without losing your current line of work. Think of it like creating a branch in git — the original conversation stays intact, and you get a copy to take in a different direction.

Considering two different fix strategies? Fork the conversation and try one. If it doesn't pan out, your original conversation is still right where you left it. I use it whenever I want to experiment with an approach that might not work out — refactoring strategies, alternative architectures, risky changes — without committing to it or polluting my main conversation with a dead end.

12. /clear Isn't Scary When You Have /resume

One reason people resist clearing their conversation is the fear of losing everything. But /clear doesn't destroy the conversation — it shelves it. Every cleared session is available through /resume, where you can browse and jump back into any previous conversation.

Combine this with /rename — give your sessions descriptive names like "order-race-condition-investigation" or "payment-refactor-attempt-2" — and you've got a searchable history of all your work. Starting fresh stops feeling like a loss and starts feeling like opening a clean tab.

13. /export and /copy for Archiving

/export dumps the full conversation to a file. I use it as an archive before clearing — cheap insurance in case I need to go back. /copy grabs just the last response to the clipboard, which is handy when I want to pull one specific insight into my notes without copy-pasting around.

Neither is life-changing on its own. Together with the notes habit, they make context management almost painless.

14. /diff to Track What Actually Changed

/diff opens an interactive viewer showing uncommitted changes and per-turn diffs. You can switch between the overall git diff and what each individual Claude turn modified.

I use this before committing — it gives me a clear picture of what's worth keeping versus what was exploratory. It's also useful before clearing a conversation: glance at the diff to make sure you've committed everything valuable.

15. /batch for Large-Scale Changes

When a task is big enough to need many focused conversations, /batch takes this to the logical extreme. It researches your codebase, decomposes the work into independent units, and spawns a separate agent for each one — each in its own isolated git worktree with clean context.

This is the "focused conversations" principle, fully automated. Each agent gets a small, well-defined task and none of the context from other agents' work. No rot by design.

16. Learn to Smell Context Rot

The obvious failure mode is wrong code. But context rot announces itself more subtly:

• It suggests something you already rejected three messages ago.
• It asks for information you already provided.
• Responses get vague — lots of "you could try..." instead of concrete solutions.
• It proposes changes that contradict constraints you set earlier.
• It gets weirdly agreeable — stops pushing back, just says yes to everything.

When this starts happening, don't repeat yourself louder. Check /context to see where you stand. Use /rewind if the rot is recent. Save your progress and /clear if it's pervasive. Repeating yourself into a degraded context makes it worse, not better.

What This Looks Like in Practice

A typical debugging session for me now:

1. Start a conversation. Describe the bug. Let Claude Code explore the codebase. Auto memory means it already knows my project's conventions.
2. After 10-15 minutes, we've usually narrowed it down. I write a quick notes file with findings.
3. If the fix is straightforward, I keep going. If I want to try a different approach, I /fork to experiment without losing my current progress. If it's complex enough to need a clean slate, I start a new conversation pointing at the notes.
4. Commit working changes frequently. Write a failing test if I haven't already.
5. Use /btw for any tangential questions that would otherwise clutter context.
6. Glance at /context periodically. If things are long but productive, /compact while it's still sharp.
7. If the conversation goes sideways, /rewind to the last good point. If it's too far gone, save notes and /clear.

The whole thing takes less time than my old approach of pushing through one increasingly confused conversation. And the output quality is noticeably better because the model is always working with clean context.

Will This Get Better?

Some of this is just the physics of how attention works in language models. Context windows have limits, and cramming more tokens in doesn't make them all equally useful. That's not changing soon.

But the tooling is improving fast. Auto memory already persists knowledge across sessions automatically. CLAUDE.md gives every conversation a running start. Smarter summarization, better compaction, commands like /batch that decompose work into clean parallel contexts — all of these chip away at the problem from different angles. A year from now I expect half the manual strategies in this post to be unnecessary.

Until then, auto memory plus some git discipline gets you 80% of the way there.

The Real Differentiator Now

Here's the thing nobody wants to say out loud: AI has made it so anyone can produce working code. The barrier to building software has effectively collapsed. Which means writing code is no longer what separates developers.

What separates them is how well they control the agent.

And make no mistake — strong programming fundamentals make you a better agent driver. If you understand how a problem should be solved in code, you can steer the model toward the right architecture, catch it when it drifts into a bad pattern, and frame your prompts in ways that produce shippable output. Someone who knows what good code looks like will always get more out of these tools than someone who doesn't.

But coding skill alone is no longer enough. Two senior developers can use Claude Code on the same feature — one gets a clean result in an hour, the other spends a full day fighting hallucinations and spaghetti output. Same programming ability, different outcomes. The gap is context management, task decomposition, knowing when to clear and when to push through. It's everything in this post.

That's why context rot isn't just an annoyance. It's the bottleneck. The craft is shifting from "can you write this?" to "can you write this and drive the agent that writes the rest?"

The Bottom Line

The single biggest shift in how I use Claude Code wasn't learning a new command or feature. It was changing where I store knowledge.

Conversations are for thinking. Files, commits, tests, and memory are for remembering.

Claude Code already gives you a full toolkit for this: auto memory for persistent learning, CLAUDE.md for project-level instructions, /context for awareness, /rewind for surgical fixes, /btw for clean side questions, /compact for timely summaries, /fork for exploring alternative directions, and /clear plus /resume for fresh starts without losing history.

Keep the thinking and remembering concerns separate and most of the frustration goes away. Your AI assistant will forget what you talked about — but with the right workflow, it never forgets what matters.

What's your Claude Code workflow? I'm always looking to steal good habits — drop a comment if you've found something that works.