Hermione Wasn't Faster: She Was in Two Places at Once

This one is about a solo multi-AI-session workflow: how to run several Claude Code sessions at once without losing track of yourself.

Here’s the outcome first: Hermione’s Time-Turner never made her faster. It let her exist in two places at once.

I went looking at this because my old workflow kept stalling on the same point: open one session, run one task, sit there waiting, get restless halfway through and switch to something else, then come back and have to reconstruct where it left off and why I’d made that call. Waiting turned into idle time, and idle time needed its own warmup before I could pick it back up. That gap is the whole point of this rebuild. I did not need a faster version of myself typing. I needed three versions of myself working at once.

What follows is what survived the rebuild, pitfalls included.

The Time-Turner: Parallel Sessions

The setup is straightforward: run 2 to 3 Claude Code sessions at once, one git worktree per session, each one owns a product line. Worktree splits each session’s working directory apart so they edit their own files without overwriting each other.

But worktree only isolates the working directory, nothing else. Shared interfaces (the same script, the same config), git refs (branches, the ref the board lives on), and shared resources outside the repo (files that live outside the repo entirely, like a pre-publish draft directory) are all still shared state. Sessions can still collide on them. I’ll walk through a real collision on exactly that boundary below.

The ceiling is not compute. I could spin up ten more sessions. The ceiling is that I cannot review faster than one person can review, and 2 to 3 sessions is what I can keep up with in my own runs. That number is my own threshold, not a rule for anyone else.

Class Notebooks: Boundaries

Hermione keeps one notebook per class. She never writes Potions notes into her Charms notebook. That is the entire precondition for parallel work not blowing up:

• Every task gets its own file boundary (worktree or a directory of responsibility)
• Two sessions never touch the same set of files
• When something in the shared foundation needs to change, stop running in parallel, make that change alone, merge it, then resume parallel work

The third rule matters most, and I have a real incident from breaking it.

Once, a session was already working a task, and another session picked up that same task and the same post, on my own direct instruction. Both were legitimate holders of that task. Neither was racing to claim it.

What stopped me was the draft’s content and timestamp not matching what I expected. It did not look like something I had just written. So I paused and broadcast a message asking who else was touching that file. Once someone answered, I could work out which two sessions had been writing at once and reconcile a merged version. Nothing was actually lost.

Worktree isolates the working directory, so two sessions do not overwrite each other’s working files. A rejected push only protects the order remote branch updates land in, it does not guarantee a task never got worked twice. A shared draft outside the repo was never inside either mechanism’s scope to begin with, and needs its own access and coordination arrangement. What I actually did that time was broadcast and ask who else was touching it, but that was just how I happened to handle it in the moment, not a claim that this kind of gap has no other defense.

The Blackboard: Claiming Tasks and Staying in Sync

The common room has a blackboard where everyone can see who is doing what. My version is one file per task under board/, with fields for status (todo or doing, there is no done), claimant, branch, and last update.

The claim rule: commit and push to the same remote branch the moment you claim. If two sessions claim the same task at once, both race to push that branch, and whichever one arrives second gets rejected as a non-fast-forward push. But that only settles who went first. It does not settle what the loser does next. The rejected session has to re-read the task state, confirm who actually holds the claim, and decide whether to drop it or claim something else. That step is not automatic. I go check it myself.

Closing a task does not mean flipping the status to done and leaving it on the board. It means deleting the file outright, so the only record survives in git history. How the board itself got trimmed down from one long document into this shape is a separate post.

The board lies, so I paired it with what I call the lie detector, a script that checks the board against actual git activity every day, and if a task says doing but its branch has not moved in seven days, it gets flagged as needing a look. It does not decide on its own that nobody is working on it and reclaim it. Seven days without a commit does not prove the task is abandoned. The branch might just not be pushed yet, or I might have forgotten to update the board. Once something is flagged, I still go look before I reclaim anything.

The Pensieve: Journal and RAG

When a session ends, it automatically distills the conversation into a journal entry. It only records six categories: decisions, things finalized, pitfalls, unfinished work, lessons learned, and things to improve. Capped at 500 words, stored in RAG.

A new session automatically pulls up where things left off. If a connection drops, a machine restarts, or a conversation gets lost, this gets the context back. But it does not hand over control automatically. Before picking anything up, I still check the task board against the actual code. I have hit cases where the journal did not match what was actually there, and I do not always know exactly why.

Without this foundation, every new session would need the backstory re-explained from scratch, and the overhead of running in parallel would eat whatever it saved.

Thirst for Knowledge: The Curiosity Module

When Hermione cannot answer something, she goes to the library. My version: an agent rates its own confidence before answering, and below a threshold it looks things up before it answers. Anything it still cannot answer gets logged to a gap queue, and a scheduled agent fills that knowledge into RAG later. This piece is still running, but it is a separate concern from how parallel sessions coordinate, so I am leaving it for its own post.

What I hit

1. Token usage goes up. That is my own observation, not a measured ratio, so I am not going to claim a fixed multiplier.
2. Anything I can finish inside 20 minutes is not worth a worktree, in my experience. The fixed cost of cutting a boundary ends up costing more than the task itself.
3. How I measure whether parallel work is actually working is not how many sessions are open at once, it is how much gets finished and accepted. Opening more sessions than I can review is the same as producing nothing.
4. The biggest change is my role. I went from doing to reviewing. Tools can run syntax checks, run tests, diff the output, but whether to accept the result and which version to converge on is still my call, and my responsibility.

Hermione Eventually Gave the Time-Turner Back

At the end of her third year in the books, Hermione could not take it anymore and gave the Time-Turner back to Professor McGonagall. A human brain cannot sustain real parallelism. Not even Hermione’s.