The flying-stage mental shift ​

Why this is Week 1 ​

The leap from 2–3 parallel Claude Code sessions to 10+ is not "the same thing, more of it." It changes how you hold context, how you make decisions, how you experience a working day. Engineers who try to install the fleet mechanics without first making the mental shift end up at 4–5 sessions, brain-fried, and convinced they've "hit a ceiling." The ceiling isn't capability. The ceiling is that they're still operating as a 2–3-session running-stage engineer, just with more tabs open.

Week 1 is a re-orientation. The substrate for everything that follows.

Principle 1 — The 2–3 → 10–15 leap is qualitative, not quantitative ​

At running stage, you supervise each agent carefully. You hold its context in your head. You context-switch deliberately between tabs and feel the friction of each switch. You make sure not to push too far past what you can keep track of. This is correct at 2–3 sessions; the practice is "few agents, supervised closely."

At flying stage, this model breaks. You can't carefully supervise ten agents. You can't hold ten contexts in your head. Trying to context-switch deliberately between ten tabs is what produces brain-fry.

The mental shift is from supervisor to orchestrator. From "I am watching each agent" to "I am orchestrating a fleet that mostly works without me watching." From "context lives in my head" to "context lives in each tab's working memory, my job is to set them up well and check in." From "I make sure each agent is doing the right thing" to "I make sure the fleet is moving the work-stream forward, and intervene only where it isn't."

Concretely:

• You stop trying to fully understand what each agent is doing right now. You trust the brief (the mission file, the CLAUDE.md, the prompt) and check the output.
• You stop deliberately context-switching between tabs. You scan, you triage, you go where attention is needed, and you let the rest cook.
• You stop optimising for per-agent quality. You optimise for fleet throughput, accepting that any individual agent's output will sometimes be subpar — that's what the review pass and the re-prompt are for.

This is the part of the practice that most "I plateaued at 3 sessions" stories trace back to: still trying to be the supervisor at a count where supervision doesn't scale.

Principle 2 — The "almost never say no" reflex ​

At running stage you might still say, "we'll get to that next sprint" or "that's not in scope this week" or "let me think about whether it's worth the effort." At flying stage, this reflex changes.

When a teammate, a partner, or your own brain raises something that would be useful — you don't queue it. You open a new tab and have a rough version this afternoon.

The shift isn't "say yes to everything." It's "the cost of a rough exploration has collapsed." When the marginal cost of trying something is a fresh Claude tab and a brief, the calculus of "is this worth doing" changes. Things that used to be "maybe next quarter" become "let me see what it'd look like."

Practical consequences:

• Your week stops being organised around "what's on the sprint." It's organised around what's moving and what's worth exploring.
• You ship more rough first-passes. Many die. Some turn out to be the right thing to invest in. The hit rate matters less than the volume.
• You stop being the bottleneck on "deciding whether to try things." Anyone on the team who can articulate a thing can have a rough version of it in a few hours.

This reflex is what makes flying-stage practice feel categorically different from running-stage. It's also what makes the political layer in Week 5 hard — colleagues who haven't made the shift will think you're cheating, or being chaotic, or wasting effort on stuff that "won't ship."

Principle 3 — Browser automation as the coordination layer ​

Baseline assumed: you've already replaced your manual web clicking with Claude-driven browser automation for routine SaaS work. This is the Week 2 territory of the Augmented Mind Course — partner portals, GitHub UI for routine PR ops, MFA flows, dashboards you check daily, the basic class of "stuff that's pure coordination overhead."

What changes at flying stage isn't the technique. It's making it the default policy rather than a useful habit. Every web interaction that's pure coordination overhead routes through Claude's browser automation. Not the easy ones. All of them.

Why this matters at the fleet level: when you're orchestrating 10+ streams, the time you spend hand-clicking through dashboards isn't just lost — it's also time you're not paying attention to the fleet. Every minute clicking is a minute the agents are operating unsupervised, and minutes of unsupervised drift compound into rework. The fleet's effective throughput is what you'd get from full attention minus the attention you give to coordination overhead.

The deep practice — browser automation against auth, MFA, partner portals with broken JS, the "Claude says it can't, push back" routine, the recovery patterns when a flow stops working — is Week 3. This week is about adopting the policy that everything routine routes through the agent, even when it's slightly slower the first time you set it up.

Principle 4 — Comms automation for the routine surface ​

Same principle, applied to the second-biggest source of coordination overhead: messages.

Status updates, scheduling, inbox triage, routine Slack / Teams / email replies — Claude drafts, you review, you approve send. This isn't about being a hands-off communicator. It's about reserving your communication attention for the high-value conversations: context clarification with teammates, creative direction with collaborators, the meetings worth transcribing.

The flying-stage framing: the high-value conversations get more of your time, not less, because the routine surface has been delegated. This is the inversion that confuses people. They assume comms automation means less interaction with humans. It means the opposite — more presence for the conversations that matter, because you're no longer paying attention tax on inbox-triage and status-update overhead.

What's in scope this week is the policy commitment. Pick the routine-comm surfaces (the standing weekly status update? the partner-onboarding emails? the calendar-coordination back-and-forth?) and make the call that those route through Claude going forward. Deep practice on the comms-automation discipline — drafting voice, fallback escalation, when to overrule the draft — is Week 3.

The assignment — write your manifesto ​

One concrete deliverable this week. Not a configuration change, not a tool install. A document.

If you're going through the course with a cohort or a peer group, share your manifesto with them and read theirs. The shift is easier to make when you've named it out loud. (The paid Bootcamp formalises this as a Week 1 cohort exercise — cohort reads, cohort reacts. The free course version is "do it solo or with a willing peer.")

Self-check — did this week land? ​

Honest answers, not aspirational ones. If most of these are "not yet," sit with this week before moving to Week 2 — the rest of the course compounds on the mental shift.

• Can you describe in your own words how the supervisor-to-orchestrator shift differs from "supervise harder, supervise faster"?
• Have you written your manifesto? (If not, the rest of this list doesn't matter yet.)
• Did you ship at least one rough first-pass this week of something you'd normally have deferred? What happened?
• Have you named at least one coordination surface that you're committing to route through the agent from now on, even when it's slower the first time?
• Are you noticing the urge to context-switch deliberately between tabs? (Noticing it is enough this week. Letting it go is Weeks 4–5 work.)

What's next ​

Week 2 — Tooling stack. The mechanical layer. cctabs, worktrees, foreground-vs-background streams, Anthropic quota management, local-model fallback. The substrate that makes 10+ parallel sustainable across a full working day without manual tab-juggling.