Don't Wait for Claude

Summary

Don't Wait for Claude March 27, 2026 The Wait You give Claude a task. It takes seven minutes. What do you do? Most people wait. They watch the terminal scroll, maybe check their phone. Seven minutes later Claude finishes. They review the output, draft corrections, send them back. Seven more minutes. An hour produces four cycles of actual work. The instinct is to optimize Claude — better prompts, better context, fewer wasted tokens. That matters. But the dominant bottleneck isn’t Claude’s throughput. It’s the seven minutes where you’re doing nothing. The Switch The fix is obvious: work on something else while Claude runs. The tooling for running sessions in parallel exists. But running them isn’t the hard part. Coming back is the hard part. What did you ask for? What were you going to check? What comes next? Your own context window is limited, and unlike Claude’s, there’s no token counter warning you when it’s full. The creator of Claude Code describes his workflow: “I run 5 Claudes in parallel, number my tabs 1-5, and use system notifications to know when a Claude needs input.” Numbered tabs and notifications. That’s the state of the art for the human side. So people don’t switch. They either wait — or they go the other direction entirely: make Claude fully autonomous and interact through GitHub PR reviews. That keeps things moving, but at PR-review cadence — you’re checking in once an hour instead of once every seven minutes. Claude becomes a coworker you manage asynchronously instead of a tool you wield directly. You’re leaving most of the throughput on the table. The problem isn’t that you can’t run multiple sessions. It’s that you can’t manage them. The State The solution is to externalize your state. When you switch away from a session, everything you need to resume should already be written down. This isn’t extra work. It’s the review work you should be doing anyway, just done at the right time. When Claude finishes a task, you review the diff, notice things, ...