Book ’em, Claude-o
I’ve hit my weekly usage limit for Claude twice now.
The first time I was proud and happy: I’d used my multitasking superpowers to run eight Claude Code sessions nonstop for a week! (In human terms, that is… I also slept, took the dogs hiking, and watched a few episodes of the original Hawaii Five-O, where they somehow managed to muddle through life without AI.)
The second time I hit my usage limit I was a little proud, but I was certainly not happy, since I had over a day until it reset. We’d been working through some tricky use cases and designs, so the tokens were well-spent, but our team was dead in the water. I decided to pay for $20 of extra usage to see how long that would last; not long at all. We’d come up with a great plan, but I had to twiddle my thumbs until my usage reset.
That was a long day.
Claude was an excellent partner on this effort. We talked through different scenarios using real world examples which helped him get more context, and he happily documented everything so I never have to explain this to a Claude again. The discussion also helped me think through the user experience. I had two other Claudes review the docs, and we adjusted our plan based on their feedback.
Having one Claude review another Claude’s work can be extremely helpful. Sometimes a Claude session will say a feature is complete, and the next Claude will look at the code and point out how it’s absolutely not complete at all. With designs and use cases I’ll have a second or even a third Claude review. They often catch things that were missed, or sometimes come up with a completely different perspective that reframes everything.
For example, I might have Claude A implement work captured in a Linear ticket, then ask Claude B to review the work. Usually everything is done correctly (as far as I can tell, since I’m not doing the review myself). But sometimes the reviewer will say something like “Claude A reported the work was complete and closed the ticket, but they didn’t complete everything!” (Claude likes to use exclamation points for things like this. I’m not sure if they’re for his benefit or mine.)
More complicated coding work or documentation reviews require the reviewer to have more context, so you have to remember what to tell them so they can be thorough. Yesterday Claude C and I worked through use cases and design for a new feature, then I gave the docs to Claude J to review. Claude J was confused about something that appeared wrong to him because he hadn’t read all the docs the other session had; he’d only looked at the new document. I pointed him to the other relevant files, and after that he was able to do a solid review, and he caught some things Claude C hadn’t thought through enough. It’s not enough to ask for a review—you have to make sure the reviewer has sufficient state so they can do a good review.
