i have 4+ terminals open right now. each running claude code in bypass permissions, each on a different project. two are running experiments in independent worktrees, two i’m babysitting to fix prod issues.

i’m not really doing any of it. i’m orchestrating.

the old advice

there’s a popular take that calls context switching “the silent killer of productivity.” batch your tasks, turn on do-not-disturb, single-task your way to clarity.

for years this was right. but it was right for a specific reason that nobody states out loud: context switching was expensive because you were the one holding the context. deep in a problem, someone pings you, and you lose 23 minutes rebuilding the mental model in your head.

the cost was never the switch. it was the rebuild.

the shift

harness writes code now — claude code, cursor, aider, opencode. and the thing it’s actually good at isn’t typing, it’s holding context. the file tree, the bug, the half-finished refactor — it keeps that resident while you look away.

so the rebuild cost moves off you and onto the agent. the switch gets cheap on your side because you’re not the one reconstructing anything.

but here’s the part i want to be honest about, because it’s where this idea usually gets oversold: this only works cleanly when the task is well-specified. “here’s the repo, here’s the bug report, fix it” is a 30-second handoff when you already understand the bug. the moment the work is ambiguous — wrong symptoms in the report, a subtle cross-system interaction, a feature nobody’s pinned down — you can’t write a good prompt without building the exact mental model you were trying to offload. you can’t steer toward the right issue if you don’t already hold the issue.

so it’s not that gathering context got cheap. it’s that shallow, well-scoped context got cheap to hand off. the deep stuff is still on you. the trick is knowing which is which before you spin up a terminal for it.

the workflow:

1. terminal 1 → “run experiment X…”
2. terminal 2 → “write tests for …”
3. terminal 3 → “debug this prod error, use this mcp to fetch logs…”
4. terminal 4 → “generate an html view of this service’s internals…”

each agent holds its own deep context. you rotate — check progress, answer questions, feed more context when it’s stuck.

the context switching still happens. it just happens in your terminals, not in your head.

the part the productivity blogs skip

running four agents isn’t free. you didn’t delete the cost, you moved it — from focus to review. every stream you’re not watching is an agent that can confidently do the wrong thing while you’re three terminals away. bypass permissions on prod work makes that blast radius real.

so the new bottleneck isn’t attention, it’s verification. how fast can you read what four agents did and trust it? that’s the skill that’s actually scarce now, and it caps how wide you can parallelize before the merge in your own head gets worse than just doing one thing well.

how i actually do it

i keep a small list in apple notes — nothing fancy, just what needs to ship by end of day.

each experiment goes into its own cc session, always starting in plan mode — that’s my context-and-thoughts dump before i let the harness run. once a plan looks confident enough to produce learnings, i move to whatever session needs more steering.

a few things that help me run this all day:

• gstack
• repo-level skills i’ve built
• a few global skills + my own mental model for approaching things

i’m not saying context switching is good. i’m saying the limit on how much a human can switch goes way up when the agents hold the context — as long as you stay honest about which tasks you can actually hand off, and how much you can review.

thanks!