Order Out of Chaos
Documenting protocols and standards made a noticeable difference in Claude Code’s consistency. Adding just-in-time protocol checking, where he refers to a reference instead of reading in all the files, allowed him to document even more things (which of course he loves to do), but because he referred to his protocols only when he needed to, he made more efficient use of his tokens. We added features! Wrote tests! Improved stability!
Our app had finally reached a point where I felt comfortable using it in production. “Production” just meant I ran code in the main branch on another port on my laptop, but still: I finally had the application I’d wanted for years.
This was great. We had laid a solid foundation, or at least it was pretty solid. Occasionally we’d find things we’d missed, like the time I asked why something hadn’t been caught by our tests, and Claude pointed out that it actually had—but that the test suite returned success when it ran, instead of pointing out that only 1.9% of the tests in that suite were actually passing. (At that point I asked the Claudes to audit our tests, which I still do every once in a while, just in case.)
At this point I used two sessions at a time, who I referred to as A and B (so I could remember which one I was talking with). Working with two sessions at once worked very well, but I had trouble staying on top of our backlog since it was still tracked in a now extremely long Markdown file. Even the Claudes had trouble keeping track of our priorities.
Then one day I thought: normally I’d use an issue tracker. Would that work for Claude Code?
He loved the idea. Loved, loved, loved it.
We (okay, Claude) moved our todos into GitHub issues, and suddenly I could see the big picture! Even better, Claude could now not only clearly see exactly what we needed to do, he could add voluminous comments to tickets instead of to our Markdown files. He turned out to be very good at writing comprehensive tickets. If there’s a complex topic, or if Claude has questions, we’ll talk through things in more detail, but once we’ve agreed on the plan I mostly let him take it from there.
If a ticket was large, I’d ask Claude to break it into chunks (which for some reason he always calls “phases” no matter what term I use). He identifies which tasks can be done in parallel and which must be sequential, then I assign sessions to work on these tasks. And that led us to adding a new team member:
Claude C!
Claude C was, of course, quickly followed by Claude D. E and F came a week or so later, and then—because why not?—they were joined by Claudes G and H. It did feel a little like Severance, especially because they all lose their memory at the end of each session. But we have enough in place now that they “remember” key things we’ve added to the files they read at startup.
Next post I’ll talk about how I manage eight Claude Code sessions at once.
