How the Creator of Claude Code Actually Uses Claude Code

Boris Cherny, the creator of Claude Code, shared his development workflow publicly, and the post accumulated over 5,000 likes in two hours. When the person who built the tool reveals how they actually use it, the specifics are worth examining closely.

What the specifics reveal is restraint. No elaborate customization, no secret configurations. The core of his approach is combining Claude Code’s built-in features in disciplined, deliberate ways. Several of the techniques take real effort to maintain consistently, which is precisely why most teams skip them.

If you’ve read Andrej Karpathy’s breakdown of the abstraction layers developers need to understand in AI code agents, Boris’s guide is the practical companion piece.

Parallel Sessions: Run 15 Claude Instances at Once

Boris runs five Claude instances simultaneously in the terminal, plus another five to ten on claude.ai/code through the browser. He even starts sessions from his phone in the morning and checks on them later.

His terminal setup uses numbered tabs 1 through 5, with system notifications signaling when input is needed. The & command switches between local and web sessions, and --teleport jumps between sessions. Each terminal tab has its own git checkout, so every session runs an independent plan on an independent branch.

This is not multitasking for its own sake. Each session handles a discrete, well-scoped task. The parallelism works because the plans are clear before execution starts, not because Boris is skilled at context-switching. One detail from the comments: he uses separate git checkouts per tab rather than git worktrees, finding the simpler model easier to reason about when managing many sessions simultaneously.

Opus with Thinking: Bigger Is Actually Faster

Boris uses the largest available model for every task. This is counterintuitive because Opus is slower per token and more expensive. His reasoning is practical: the bigger model requires fewer corrections, uses tools more accurately, and produces better first-pass results. Total task completion time is shorter with Opus than with smaller models because you spend less time fixing mistakes and re-prompting. Overall wall-clock time decreases despite higher per-token latency.

This holds for his workload. Whether it generalizes depends on the task type and the cost tolerance of your project.

CLAUDE.md: Team Context Engineering

The entire team checks a single CLAUDE.md file into Git. Every time Claude makes a mistake, someone adds a note to this file so the same error doesn’t happen again. Multiple team members contribute updates weekly. During code review, the team uses @.claude tags to request CLAUDE.md additions. Each team maintains its own CLAUDE.md.

The file becomes a growing body of institutional knowledge that every Claude session inherits. The concept is straightforward, but maintaining it consistently takes real discipline. Most teams start the file and let it go stale within a month.

Plan Mode: Good Planning Is 90% of Success

Boris starts most sessions in Plan Mode (shift+tab twice). If the goal is a pull request, he discusses the plan with Claude until he’s satisfied, then switches to auto-accept mode and lets Claude execute the entire plan without interruption.

The pattern: invest time upfront in the planning phase, iterate on the plan until it covers edge cases and potential issues, then switch to automated execution and minimize back-and-forth corrections during implementation. Planning is cheap. Rework is expensive. This eliminates the most common failure mode, which is starting to code before the approach is clear.

Slash Commands and Subagents: Automate Repetitive Work

Any workflow Boris uses more than a few times a day becomes a slash command, saved in .claude/commands/. Commands like /commit-push-pr are available to Claude itself, not just the developer. Inline bash pre-computes context, making commands faster. Subagents like code-simplifier and verify-app handle common validation workflows. PostToolUse hooks auto-format code after every edit.

Boris treats Skills as a form of slash commands: reusable, shareable workflow definitions that standardize how Claude approaches specific tasks.

Permission Management and Tool Integration

Instead of using --dangerously-skip-permissions, Boris uses /permissions to pre-approve safe commands. The team shares MCP server configurations so Claude can directly access Slack, BigQuery, Sentry, and other tools, via .claude/settings.json for permission settings and .mcp.json for tool integrations.

This is the pragmatic middle ground between full lockdown and unrestricted access. The team agrees on what is safe, codifies it, and moves on. The alternative, prompting for permissions constantly, creates enough friction that people start skipping checks entirely.

Verification Loops: The Quality Multiplier

The single most important practice in Boris’s workflow: give Claude a way to verify its own work.

On claude.ai/code, he has Claude test every change through a Chrome extension that interacts with the actual application. The verification loop includes background agents that check work after completion, Agent Stop hooks that run deterministic validation, the ralph-wiggum plugin for additional verification, sandbox environments with adjusted permission modes to avoid blocking, and real UX testing in browsers and simulators.

Boris considers this the difference between 1x and 2-3x output quality. Skipping it is the most common way teams undermine the value of running Claude at all.

What Holds the Practices Together

Strip away the specific tools and configurations, and four principles remain. Run many sessions, each with a clear scope and its own branch. Invest in the planning phase before touching code. Check CLAUDE.md into Git and update it after every mistake. Let Claude check its own work before you review it.

The most striking thing about Boris’s setup is not any single technique. The creator of the tool doesn’t rely on exotic configurations. He relies on fundamentals, applied consistently, which turns out to be harder than it sounds.