Split Parallel Decisions into Parallel Sessions
Halfway through the deployment work, I had two different kinds of work to do at the same time.
First: analytics planning. Adding event tracking — figure out what users were doing, where they were struggling, which songs were most practiced. Not really a coding task. A thinking task. Which events mattered? What did I actually want to learn? Long, meandering, output mostly a plan with a little wiring.
Second: deploy infrastructure — auth, storage, observability, getting the app on the internet. A building task. Fast, iterative, one concrete change at a time.
The natural impulse was to do both in one conversation. After 15 minutes of mixing them, I felt the friction. Analytics thinking kept getting interrupted by build output. The build kept getting derailed by me wanting to talk through event schemas. Each thread was making the other worse.
Opened a second Claude Code window. One for analytics, one for the build. Each got its own history, context, momentum.
Why it worked
The two conversations were optimizing for different things.
The analytics conversation: optimizing for completeness of thinking. Long turns. "What about..." follow-ups. I wanted to argue myself out of some events, refine the names, think about consent and privacy.
The build conversation: optimizing for throughput. One clean PR per piece, minimal discussion. Short turns. "Yes do it" or "no try again."
In one window, the AI was being asked to code-switch constantly. "Let me think carefully about whether we really need a line_completed event" doesn't belong in the same breath as "yeah push that branch." The two modes pulled against each other.
In separate windows, each had a shape. Analytics was slower, more reflective — I'd sometimes let a turn sit unanswered for 20 minutes while I thought. Build was fast and transactional, more like a shell prompt than a conversation. Both ran in parallel. Both finished faster.
What came out
Analytics window: a PRD-style document — list of events, what each should include, how to name them consistently, where to instrument them. That doc became the implementation plan, built in the same window over a few hours. Final output: a clean PR (which, when merged, triggered the outage from post 01 — but the outage was about a latent bug elsewhere, not the analytics design).
Build window: five back-to-back infrastructure PRs across about a day. Each short, focused, fast. No philosophical content — procedural, one decision at a time.
Both paths worked because they hadn't been forced to share context.
When to split
Split when tasks are in different modes. Thinking versus building. Research versus implementation. Design versus execution. When tasks want different pacing and different turn shapes, they fight when in the same window.
Don't split when tasks are in the same mode, just different things. Two features being built in parallel belong in the same window or in quick succession. Both are building. Splitting would just cost the context they share.
Don't split when shared dependencies will change under both tasks. If both will touch the same files, the same window keeps context in sync. One window won't know what the other did; you'll end up with two partial pictures and merging is worse than it would have been.
In this case, analytics planning and infrastructure build were genuinely independent. Analytics was thinking about product events; infrastructure was deploy pipelines and auth. No shared files until the very end, when the analytics PR landed in a codebase the deploy work had been evolving. By then the analytics PR was a clean unit.
What I'm taking from this
When I notice myself pulling against my own conversation — "I was in the middle of a careful thought and now I'm answering an unrelated build question" — open a second window. Each task gets its own context. Both run at their natural pace.
Two conversations is two pieces of thinking happening at once, even with the same collaborator.
Takeaways
- Split when the two tasks are in different modes (thinking vs building). Different modes want different pacing and different turn shapes; they fight when forced to share a window.
- Don't split when tasks are in the same mode but different things. Splitting throws away shared context for no benefit.
- Don't split when tasks share files. Two windows can't keep partial pictures in sync; the merge is worse than the original friction.
- Two conversations on the same collaborator is closer to "second teammate" than expected. Cost is opening a window.
Terms
PRD (Product Requirements Document) — A doc that describes a feature: what it does, who it's for, what success looks like, edge cases. PMs write these before engineers build.
Event tracking / instrumentation — Code that fires a record (an "event") whenever a user does something interesting. "User clicked sign up." "User completed a flashcard." Stored in an analytics backend (PostHog, in this project) so you can see usage patterns over time.
Pull request (PR) — A proposed batch of code changes, opened on GitHub, with a Merge button.
Auth — Authentication. Sign-in, sign-up, sessions.
Observability — Tools that let you see what's happening inside a running app. Errors going to Sentry; user actions going to PostHog; logs going to Fly.
Deploy pipeline — The chain of automated steps that takes a git commit and turns it into a running, accessible service.
Latent bug — A bug that's been in the code for a while without manifesting. Often gets exposed by an unrelated change that shifts conditions just enough to wake it up.