Too Many Words
Claude is a talker.
Okay, I guess he’s a typer, but still: does he love words.
Keeping notes to maintain continuity from one session to the next was a “game changer,” as ChatGPT would put it, but Claude’s verbosity created inefficiency. At one point our session notes — which each session would read at startup — was 7,000 lines long. All that used up far more tokens than I use saying “please” and “thanks, Claude!”
Plus, when I’d sign on the next morning and look at the session notes, I’d have to work to figure out what we’d been working on.
Then I came up with an idea. Why not archive older notes?
At first, this worked. Claude created an archive notes file, and when he’d add his (many, many) notes at the end of a session, he’d also move older notes to the archive. Sometimes. Often he didn’t, in spite of the fact that we had a clear “move notes older than X” instruction at the top of the file. Every once in a while I’d get annoyed and move the older notes myself. This wasn’t ideal, but it was manageable.
But we had other issues to deal with before improving that part of the process.
Tracking what a session had accomplished, and what the next session should do, worked just fine, but sometimes we’d find things that would have to be done by a future session. So one of us (I don’t remember if it was me or Claude, but hey — we’re a team!) decided to create TODO.md to track tasks we should work on later. We also created KNOWN_ISSUES.md (Claude’s idea) to track things we knew were problems but wouldn’t deal with for a long time.
Claude, like Steven Wright’s character in So I Married an Axe Murderer, has no concept of time. He’ll say “this task will take 2 hours” and be done in fifteen minutes. Or he’ll tell me something that makes no sense at all, like “I’ve been working on this for two and a half days” when it’s been half an hour. I do, at least, find his estimates (he loves to give ETAs) useful for gauging how much bandwidth he has left until compaction (a “3-4 hour task” might take more than one session).
At this point, our process was simple: Claude read CLAUDE.md at startup, which told him to read the (very long) session notes, check TODO.md so he’d know what to tell me when I’d ask “what’s next on our list?” and occasionally he’d check the known issues file.
Not a bad process.
Although not a super efficient one.
But it worked! It worked very well, in fact, for building the initial version of my application. My goal was to not look at the code at all — I wanted to see what Claude could actually do. I still haven’t looked at the code 🙂 but after working with Claude for a while I have a much better sense of what he can do and where he needs checks and balances. For example, a while back a session pointed out that we were using three (at least) different approaches for handling errors in the UI.
This makes total sense now, but at the time I was shocked. How could Claude let me down? (He didn’t mean to, he’s a nice guy.) Wasn’t he looking at patterns other sessions had used? (No, why would he?)
Our team had a lot to learn.
Next post I’ll segue to something very useful I did with custom ChatGPTs. After that I’ll come back to what my buddy Claude and I did to increase our efficiency.
