QUICK INFO
| Difficulty | Intermediate |
| Time Required | 15 minutes to read, ongoing to implement |
| Prerequisites | Claude Code installed, Max subscription recommended |
| Tools Needed | Claude Code 2.0+, terminal emulator, git |
What You'll Learn:
- Run multiple Claude sessions in parallel without conflicts
- Configure CLAUDE.md files that actually improve output quality
- Use plan mode to get things right on the first try
- Set up verification loops that catch errors before you do
Boris Cherny created Claude Code at Anthropic. In early January 2026, he shared his setup publicly, and the notable thing was how unremarkable it seemed. No elaborate custom commands. No complex agent orchestration. The improvements came from how he structured his sessions, not from bolting on extra tooling.
This guide walks through the eight patterns he described, with enough detail to actually implement them.
The Setup
Cherny runs Claude Code in what he calls a "surprisingly vanilla" configuration. The power comes from parallel execution and disciplined use of plan mode, not from customization.
Before diving into specifics: Claude Code works out of the box. You don't need to configure anything to start using it effectively. The patterns below are optimizations, not prerequisites.
1. Run Multiple Terminals in Parallel
The first pattern is the most immediately actionable. Instead of waiting for one Claude session to finish before starting another task, run 5 terminals simultaneously. Some engineers also keep 5-10 browser tabs open for web-based Claude sessions alongside their terminal work.
The key constraint: each terminal should work on different parts of your codebase, or use git worktrees to avoid file conflicts.
# Create worktrees for parallel work
cd your-project
git worktree add ../your-project-feature-a -b feature/auth-system
git worktree add ../your-project-feature-b -b feature/api-refactor
# Terminal 1
cd ../your-project-feature-a && claude
# Terminal 2
cd ../your-project-feature-b && claude
The parallel approach shines for independent tasks. If you're running code migrations, bug fixes, and documentation updates, there's no reason these need to wait for each other.
Expected result: Multiple Claude instances running without stepping on each other's files. When you're done, merge branches normally.
2. Use Opus 4.5 with Extended Thinking
Cherny uses Opus 4.5 exclusively with extended thinking enabled. It's slower than Sonnet, but the accuracy difference matters for complex tasks.
Access model selection with the /model command. Option 4 gives you Opus 4.5 for planning and Sonnet 4.5 for execution, which balances speed with capability.
The thinking budget maps to specific phrases:
- "think" (baseline)
- "think hard" (more budget)
- "think harder" (even more)
- "ultrathink" (maximum)
I haven't measured the exact token differences, but the quality improvement on multi-step reasoning is noticeable. For simple file edits, this is overkill. For debugging a race condition or designing an API, it's worth the wait.
3. Treat CLAUDE.md as Team Documentation
This is where the Anthropic team's approach diverges from what I see most developers doing. They don't treat CLAUDE.md as a static config file. They update it multiple times per week, and they check it into source control so the whole team shares the same context.
What goes in CLAUDE.md:
- Typical errors and their solutions ("always use X instead of Y")
- Project-specific commands and workflows
- Code style preferences that differ from defaults
- Testing patterns specific to your codebase
What doesn't belong:
- Generic best practices Claude already knows
- Long explanations (keep it scannable)
- Information that changes daily
The file lives at your repository root and gets pulled into every Claude session automatically. You can also have nested CLAUDE.md files in subdirectories for component-specific context.
# Build commands
- npm run build: Build the project
- npm run typecheck: Run the typechecker before committing
# Common issues
- If you see "Module not found: @internal/config", run npm install first
- Always use pnpm, not npm, for package management
# Code patterns
- Use ES modules syntax, not CommonJS
- Error handling: wrap external API calls in try/catch with specific error types
4. Let Claude Update CLAUDE.md
Here's the part I initially missed: Claude can and should update its own documentation. When you hit a problem and figure out the solution, type # followed by the lesson learned.
# Always rebuild the docker image after code changes before testing
Claude will ask where to save the memory (project, local, or global) and incorporate it into CLAUDE.md. You can also tag Claude in pull request reviews or Slack threads and have it describe problems it encountered, then add those to the documentation.
This creates a feedback loop. The team's collective knowledge about project quirks accumulates in a file that every Claude session reads.
5. Start Sessions in Plan Mode
The single biggest tip, per Cherny: almost always start in plan mode.
Press Shift+Tab twice to enter plan mode, or use /plan. In this mode, Claude can read files and search the codebase but cannot make changes. You discuss the approach, refine requirements, and align on implementation before any code gets written.
The workflow:
- Describe what you want to build or fix
- Let Claude ask clarifying questions
- Review the generated plan (often saved to
~/.claude/plans/) - Switch to execution mode once the plan looks right
- Claude implements based on the agreed approach
Why this works: when you align on a detailed plan first, Opus 4.5 gets the implementation right more often on the first try. The time spent planning saves debugging time later.
For simple tasks (fix a typo, rename a variable), skip the planning. For anything involving multiple files or architectural decisions, the upfront conversation pays off.
6. Automate Repetitive Work
If you're typing the same kind of prompt more than a few times, create a slash command or subagent.
Slash commands for simple, scripted tasks:
# Create .claude/commands/fix-lint.md
Please run the linter and fix any errors. After fixing:
1. Run the linter again to verify
2. If new errors appear, fix those too
3. Stop when lint passes clean
Now /project:fix-lint runs this exact workflow.
Subagents for slightly more complex delegated work:
Subagents are separate Claude instances spawned by your main session. They run in parallel and report back. Create them at .claude/agents/your-agent.md or use the /agents command.
I use subagents for code review: one checks style guidelines, another looks at the git history for context, another scans for obvious bugs. The main session synthesizes their findings.
7. Configure Approved Commands
The flag --dangerously-skip-permissions lets Claude run without asking for approval on every bash command. Most people shouldn't use this, for obvious reasons.
The middle ground: configure a list of approved commands in your settings. This way you're not interrupted every five minutes for routine operations, but you still get prompted for anything potentially destructive.
Edit .claude/settings.json:
{
"permissions": {
"allow": [
"Edit",
"Bash(npm run:*)",
"Bash(git status)",
"Bash(git diff:*)",
"Bash(git commit:*)"
]
}
}
The wildcard syntax lets you approve categories of commands. Bash(git commit:*) allows any git commit without asking.
8. Give Claude Ways to Verify Its Work
This is the tip Cherny emphasized most: quality improves 2-3x when Claude can check its own output.
For web development, this means giving Claude access to a browser. The Puppeteer MCP server or Claude Chrome extension let Claude take screenshots and verify that UI changes look correct.
For everything else, tests are your verification mechanism. The workflow becomes:
- Write tests first (or have Claude write them)
- Implement until tests pass
- Claude runs tests after each change to verify
Without verification, Claude is working blind. It generates code that looks reasonable but might fail in ways it can't see. With verification, Claude iterates toward correctness automatically.
Write tests for the new authentication flow. Once tests are written and failing:
1. Implement the auth flow
2. Run tests after each significant change
3. Keep iterating until all tests pass
Troubleshooting
Symptom: Claude keeps asking permission for the same command
Fix: Add the command pattern to your permissions allowlist. Use /permissions during a session or edit settings.json directly.
Symptom: Context window fills up during long sessions
Fix: Use /clear between distinct tasks. Or use /compact to summarize and continue. For complex work, start fresh sessions rather than fighting context limits.
Symptom: Claude makes changes you didn't ask for Fix: Start in plan mode. Explicitly say "do not write any code yet" during the planning phase. Course-correct with Escape before changes accumulate.
What's Next
The Anthropic team is working on swarming capabilities for orchestrated multi-agent execution. If you're comfortable with parallel terminals and subagents now, you'll be positioned to use those features when they ship.
For immediate next steps: pick one pattern from this guide and apply it to your current project. Parallel terminals or plan mode are the highest-impact starting points.
PRO TIPS
Press Escape twice to jump back in conversation history and try a different approach without losing context. You can edit the prompt and branch from that point.
The /context command shows current context usage. Start a fresh session or compact when you're past 60% on complex work.
If Claude suggests something that fixes a recurring problem, type # followed by the lesson. It gets saved to CLAUDE.md for future sessions automatically.
Syntax highlighting in diffs (added in 2.0.71) makes reviewing changes in the terminal practical. Many developers have stopped switching to their editor for code review.
FAQ
Q: Do I need the Max subscription to use these patterns? A: The parallel terminals and plan mode work on any plan. Opus 4.5 requires Max, and the extended thinking budgets eat through credits faster. The $100/month tier gives 5x usage; $200/month gives 20x.
Q: How do I know when to use Opus vs Sonnet? A: Sonnet handles 90% of tasks fine. Use Opus for planning sessions, debugging complex issues, or when Sonnet keeps missing the mark. The model switching option (plan with Opus, execute with Sonnet) is a reasonable default.
Q: What's the difference between CLAUDE.md and CLAUDE.local.md? A: CLAUDE.md gets checked into git and shared with your team. CLAUDE.local.md is gitignored, for personal preferences or local-only configuration.
Q: Can I use these patterns with Cursor or other tools? A: The CLAUDE.md approach is Claude Code specific, but the principles transfer. Plan before executing. Verify outputs. Document solutions to recurring problems. Other tools have their own mechanisms for these patterns.
RESOURCES
- Claude Code Documentation: Official reference, including command syntax and configuration options
- Anthropic Engineering Blog: Original best practices post from the Claude Code team
- Awesome Claude Code: Community-maintained collection of commands, hooks, and configurations
