Builder Guide
How operators get 10x leverage from Claude Code
A guide for Builders ready to climb to Orchestrator.
You’re past the hard part.
You have a CLAUDE.md. You plan before you execute. You switch models. You start new sessions for new work. You’re shipping things you couldn’t ship a year ago.
Most operators never get this far. The fact that you’re reading this means you cleared the threshold where the technology stops feeling like a gimmick and starts producing real output.
So the question isn’t whether Claude Code works for you. It does.
The question is what’s on the other side of the rung you’re standing on.
The leverage gap
Builder fluency produces a 3x output bump over a Tourist. You ship more, faster, with less friction.
Orchestrator fluency is a different animal.
The gap between Builder and Orchestrator isn’t 3x. It’s closer to 10x. And not because Orchestrators work ten times harder. They sleep the same hours. They drink the same coffee.
The gap is structural.
Builders run one Claude Code session at a time. Orchestrators run five. While one agent runs tests, another refactors, another drafts docs, another processes data, another handles infra. The agent isn’t helping them work. The agent is doing work while they direct other agents to do other work.
A Builder shipping at 3x is fast. An Orchestrator shipping at 10x is operating with the leverage of a small team. Alone.
This guide is the bridge.
What native fluency looks like
Boris Cherny built Claude Code at Anthropic. He runs five Claude Code instances simultaneously across numbered terminal tabs. System notifications tell him when each one needs input.
He runs five to ten more in his browser at the same time.
His CLAUDE.md updates itself. Every time the agent makes a mistake during code review, the human reviewer doesn’t just fix the code. They tag the agent to update CLAUDE.md so the same mistake never happens again.
Every error becomes a rule. The system compounds.
This is not a stunt. This is what 10x looks like operationally. One person running a small department of autonomous workstreams.
You don’t need to copy his setup exactly. You need the mental model.
At the Orchestrator level, you’re no longer the worker. You’re the conductor.
The five patterns that separate Builders from Orchestrators
1. Parallel sessions over sequential focus
The Builder’s instinct is to focus. One task, one session, full attention.
This is correct for Builder level. Sequential focus produces better-than-Tourist results because it forces context discipline.
It’s also what’s keeping you at Builder.
The move: when you have multiple independent tasks, run multiple sessions in parallel. Number your terminal tabs. One for the feature you’re building. One for the test suite. One for documentation. One for the unrelated client work.
You don’t sit and watch any of them. You start each agent on a defined task. Switch to the next. Circle back when notifications tell you input is needed.
The shift is treating yourself as a router, not a worker. Your job is no longer to do the work. Your job is to keep five workers unblocked.
The block: Most Builders try parallelization once, get overwhelmed, and conclude it doesn’t work for them.
The fix isn’t more discipline. It’s better task scoping. Parallel sessions only work if each task is well-defined enough that the agent can run for 10 to 20 minutes without your input. Vague tasks force constant intervention. Precise tasks run themselves.
2. Verification loops that don’t require you
Builders execute a task, then check the output. Careful. Correct. A bottleneck.
Orchestrators build verification into the agent’s loop.
Instead of “write the function,” the prompt is “write the function, run the test suite, iterate until tests pass.”
Instead of “draft the email,” the prompt is “draft the email, check it against our brand voice guide in CLAUDE.md, revise if it doesn’t match.”
Boris Cherny’s claim is that verification loops alone improve output quality 2 to 3x. The agent isn’t smarter. The workflow is.
By giving the agent a way to verify its own work, you remove yourself as the verification step.
The block: Verification loops require the verifier to exist. No test suite, no brand voice guide, no acceptance criteria document, no verification possible.
The fix is upstream. Spend an afternoon writing the verification artifacts. Then every future task uses them.
3. Custom slash commands for everything you do twice
The Builder writes prompts. Good prompts. Carefully scoped, with the right context, the right format, the right model.
The Orchestrator writes a prompt once, saves it as a slash command, and never writes it again.
Slash commands let you turn a recurring prompt into a single keystroke. /commit-push-pr runs a complete workflow that would take five minutes to type out. /review-pr pulls the diff, checks against your standards, reports findings. /update-changelog reads recent commits and writes the entry.
The rule: if you write the same kind of prompt twice, the second time you save it as a command. By the third time, you’ve forgotten you ever wrote it manually.
The block: Most Builders don’t know slash commands exist, or assume they’re “for engineers.”
They’re not. They’re for anyone who does the same task more than once.
Spend an hour cataloging your repeated workflows. Each one becomes a command. Your ten most common tasks now take a single keystroke.
4. Subagents for work that doesn’t need your context
The Builder runs everything in their main session. Even when a subtask is unrelated. The whole conversation lives in one place, in one context window.
The Orchestrator delegates discrete subtasks to subagents. Autonomous Claude Code instances spawned from the parent agent, given a specific job, returning a clean result without polluting the parent context.
Parent task: build a customer onboarding flow.
Subagent 1: database schema. Subagent 2: email templates. Subagent 3: analytics events. Subagent 4: documentation.
They each run independently. They each return their work. The parent never sees the noise of how the work got done. Only the deliverable.
This is how Anthropic’s own engineering team operates. It’s also how YC startups like Ambral build production systems with one engineer. Each subagent is a domain specialist, called when needed, returning to silence when done.
The block: Subagents require the parent task to be decomposed cleanly. Builders who try subagents on poorly-decomposed work get chaos. Agents stepping on each other. Conflicting outputs. More reconciliation than they saved.
The fix is upstream. Spend 10 minutes on task decomposition before spawning anything. Subagents amplify whatever planning you bring. They don’t replace it.
5. The self-correcting CLAUDE.md
You have a CLAUDE.md. That’s the Builder threshold.
The Orchestrator’s CLAUDE.md is qualitatively different in one specific way: it updates itself.
Every time the agent makes a mistake, the next action isn’t fixing the output. It’s editing CLAUDE.md so the same mistake never happens again.
First time is a one-off. Second time is a pattern. Patterns get rules.
After three months, your CLAUDE.md is a codified version of every lesson you’ve learned about working with your codebase or your workflow. The agent gets smarter over time without anyone consciously training it.
The compounding kicks in around month two. Before that, it feels like overhead. After that, the agent stops making whole categories of mistakes you used to catch manually.
The block: Most Builders update CLAUDE.md once a month, when something feels broken. Orchestrators update it during the session, the moment a mistake repeats.
The fix is just a habit. When the agent does something wrong twice, your next action is editing CLAUDE.md, not fixing the output.
Future you will thank present you. In compounding output.
The realistic timeline
You’re not going to wake up tomorrow as an Orchestrator.
The patterns above compound. Each one builds on the others. Trying to install all five at once is how Builders burn out and slide back to where they started.
A realistic ramp:
Weeks 1 to 2: Slash commands. Catalog your repeated workflows. Build the ten that matter most. Lowest-friction pattern. Pure ROI from the first command. Gives you the dopamine to keep going.
Weeks 3 to 4: CLAUDE.md self-correction. Update it every time the agent makes the same mistake twice. The compounding starts in week 6. The habit starts now.
Weeks 5 to 6: Verification loops. Write the verification artifacts you don’t have. Test suites, brand voice guides, acceptance criteria. Then build prompts that ask the agent to verify against them.
Weeks 7 to 8: Subagents for decomposable work. Start with one project. Decompose it. Spawn subagents. Iterate on the decomposition until they run cleanly.
Weeks 9 to 12: Parallel sessions. Only after the four patterns above are working. Parallel sessions amplify everything else. Slash commands, verification, CLAUDE.md, subagents. Trying parallel first amplifies chaos, not output.
By week 12 you’re operating at Orchestrator level. Not perfectly. But measurably. Observably. With the leverage that comes from running multiple agents instead of being one.
What’s on the other side
Orchestrator output isn’t 10x because Orchestrators type faster.
It’s 10x because while one agent runs tests, another drafts docs, another processes data, another reviews the previous build. The bottleneck is no longer your fingers. It’s no longer even your brain.
It’s the quality of the systems you build around the agent.
You become a designer of agent workflows. Not an executor of tasks.
This is the threshold most operators never reach. Not because it’s technically hard. None of the five patterns above require engineering depth. But because Builder fluency feels good enough.
Most operators stall at “I’m shipping more than I used to” and never push to “I’m operating like a small team.”
The ones who climb do it deliberately. One pattern at a time. Over twelve weeks.
If you’ve made it this far, you have everything you need to start.