How the Creator of Claude Code Uses Claude Code

Boris Cherny created Claude Code. On January 3rd, he posted a thread showing how he actually uses it. The setup is surprisingly vanilla. The philosophy underneath is worth studying.

The Setup

Boris runs 5 Claude Code sessions in parallel in his terminal, numbered 1-5. System notifications tell him when a session needs input. He also runs 5-10 more sessions on claude.ai/code, sometimes teleporting between local and web with --teleport. A few sessions start from his phone each morning.

This confirms something I’ve learned firsthand: Claude Code’s power comes from parallelization, not complexity. Multiple simple sessions beat one overloaded session.

My setup might be surprisingly vanilla! Claude Code works great out of the box, so I personally don’t customize it much.

— Boris Cherny

The model choice is unambiguous: Opus 4.5 with thinking for everything. His reasoning matches what I wrote about Plan Mode being mandatory: despite being bigger and slower than Sonnet, you steer it less. Better tool use. Almost always faster in the end.

CLAUDE.md as Team Infrastructure

The Claude Code team shares a single CLAUDE.md, checked into git. The whole team contributes multiple times a week. When Claude does something wrong, they add it to CLAUDE.md so it doesn’t happen again.

This is Compounding Engineering in practice. Every correction becomes permanent context. The cost of a mistake pays dividends forever.

I’ve written about CLAUDE.md as personal training data. The team-level pattern takes it further: shared context, collective learning, institutional memory that survives individual sessions.

Plan Mode for Everything Non-Trivial

Most sessions start in Plan Mode (Shift+Tab twice). When the goal is a Pull Request, Boris goes back and forth with Claude until he likes the plan. Then switches to auto-accept edits mode and Claude usually one-shots execution.

A good plan is really important!

— Boris Cherny

This echoes what I see with developers who ship consistently. The ones struggling often skip planning to save time, then spend more time fixing mistakes. Plan Mode isn’t training wheels: it’s the measuring before you cut.

Slash Commands and Subagents

Boris uses slash commands for every “inner loop” workflow he does many times a day. The /commit-push-pr command runs dozens of times daily. Commands are checked into git in .claude/commands/ and use inline bash to pre-compute context (git status, etc.) to avoid back-and-forth with the model.

A few subagents run regularly:

• code-simplifier: Simplifies code after Claude finishes working
• verify-app: Detailed instructions for end-to-end testing
• build-validator, code-architect, oncall-guide: Task-specific automation

The pattern: identify workflows you repeat constantly, then codify them. Same philosophy as CLAUDE.md, applied to execution.

Hooks for Formatting

A PostToolUse hook auto-formats Claude’s code:

"PostToolUse": [{
  "matcher": "Write|Edit",
  "hooks": [{
    "type": "command",
    "command": "bun run format || true"
  }]
}]

Claude generates well-formatted code out of the box. The hook handles the last 10% to avoid CI failures later. This is hooks for automation, not workflow orchestration: a deterministic trigger solving a mechanical problem.

Permissions, Not Skip-Permissions

Boris doesn’t use --dangerously-skip-permissions. Instead, /permissions pre-allows common bash commands that are safe in his environment. Most are checked into .claude/settings.json and shared with the team.

The permission list includes things like bun run build:*, bun run test:*, bun run typecheck:*. Safe commands that would otherwise require constant approval. Team-shared settings mean consistent behavior across developers.

MCP for Everything External

Claude Code uses all of Boris’s tools for him: Slack (via MCP server), BigQuery queries, Sentry error logs. The Slack MCP configuration is checked into .mcp.json and shared with the team.

{
  "mcpServers": {
    "slack": {
      "type": "http",
      "url": "https://slack.mcp.anthropic.com/mcp"
    }
  }
}

On-demand tool loading makes this practical: tools are available without consuming context until invoked.

Long-Running Tasks

For very long-running tasks, three options:

1. Prompt Claude to verify with a background agent when done
2. Agent Stop hook for deterministic verification
3. Ralph Wiggum plugin for autonomous loops

With either --permission-mode=dontAsk or --dangerously-skip-permissions in a sandbox, Claude can cook without being blocked on input.

The Most Important Tip

Boris saved the best for last: give Claude a way to verify its work.

Probably the most important thing to get great results out of Claude Code: give Claude a way to verify its work. If Claude has that feedback loop, it will 2-3x the quality of the final result.

— Boris Cherny

Claude tests every change to claude.ai/code using the Chrome extension. It opens a browser, tests the UI, iterates until the code works and the UX feels good.

Verification looks different for each domain:

• Simple: Running a bash command
• Moderate: Running a test suite
• Complex: Testing in a browser or phone simulator

The investment in verification infrastructure pays off across every task.

What This Confirms

Boris’s workflow validates patterns I’ve been writing about for months:

• Plan Mode is foundational, not optional
• CLAUDE.md compounds over time, especially at team scale
• Verification is the force multiplier that separates good results from great ones
• Parallelization beats optimization: multiple simple sessions over one complex one
• Shared config (permissions, MCP, commands) standardizes team workflow

The surprising part isn’t what’s in his setup. It’s what isn’t. No exotic customization. No clever hacks. Just disciplined application of the fundamentals, with team-scale coordination.