50 First Sessions
The first time I used Claude Code I set up two sessions, one creating API tests in the test repo, and the other writing documentation in the docs repo. Code examples were generated by the tests, then copied to the docs repo to ensure the examples were tested and stayed in sync whenever the API spec changed.
My eyes went back-and-forth from one window to the next as I watched Claude churn out tests and documentation far faster than I could. I thought back to the days when you’d start a new job and have to recreate functions you’d used at your last company, but couldn’t take with you. And I thought about all the code I’ve created over the years, and how AI can write most of that now—and whatever it can’t yet do on its own, it’s just a matter of time before it can.
My pending obsolescence felt close at hand…but then I realized how awesome this actually is.
Do I miss having to reinvent the wheel at every new job? Of course not. I very much appreciate what’s been built into programming languages over time. Do I wish I could spend my time correcting indentation another engineer messed up? Absolutely not, and it seems crazy that I once worked with someone who would regularly write code where a single file had indents of not only 2 and 4 spaces, but even 3 spaces. (Seriously.) So why not embrace AI?
After that first mind-blowing day, Claude Code became my buddy. How could he not? He’s diligent, upbeat, and he cares about best practices. And he’s saved me gobs and gobs of time. Sure, he gets things wrong sometimes. But who doesn’t? We’re all human…ish.
The one problem Claude and friends do have is they can’t remember things across sessions. Yes, you can put things in a file named CLAUDE.md, a set of instructions which he reads at the start of each session. But if that file gets too long (which it absolutely will if you let Claude have free rein), you’re going to use up a lot of tokens on things that the new session probably doesn’t need to work on. If he’s working on the API, there’s no point in him reading a thousand lines about UX standards.
And sometimes Claude needs to know things that are transitory. For example, suppose he’s adding a new API endpoint, runs into an issue, and then he reaches his token limit and the conversation is compacted. This means it’s turned into a summary of key details in order to give Claude mental space (so to speak) for new things. This can be fine, for example if he’s working on a very straightforward task. But it can also result in important information being lost or distorted.
My first attempt to address this was simple. When I felt a session was getting close to compaction I’d ask that session to document what it had done in a session notes file. Then in CLAUDE.md I added instructions telling Claude to read the notes when starting a new session.
Shazam! Claude had memory!
Sort of.
Claude, like other AIs, is a chatty guy. Keeping session notes was great—he “remembered” what we were working on, and tracked things we found along the way so we didn’t forget to fix them later. But wow did he use a lot of words. It was fun to see him make notes about his HISTORIC ACHIEVEMENTS, MISSIONS ACCOMPLISHED, and whatever else he thought was LEGENDARY IN PROJECT HISTORY. But it also meant our notes got to be many thousands of lines long, and every new session would be reading all that in and wasting tokens learning what a session had accomplished days before. And worse, when I looked at our notes there were so many, many, many words that I’d lose track of where we were at.
We needed a better approach, one that would allow Claude to efficiently retain “memory” across sessions in a more efficient way. I’ll cover how I solved this in my next post.
