How to use Claude Code with tips from Boris Cherny

Issue #1026

Boris Cherny created Claude Code. He also uses it more heavily than almost anyone. He runs dozens of sessions at once, automates team workflows, and uses features most developers haven’t tried. These are his techniques.

Run Multiple Sessions in Parallel

Most developers open one terminal, type a prompt, and wait. Boris runs five Claude instances at once, each in its own git worktree on its own branch.

The key tool is git worktree. Each worktree gives Claude an isolated folder, so sessions never overwrite each other’s changes. Launch one with:

claude --worktree my_feature

Think of Claude Code as a pool of workers, not a single assistant. Dispatch tasks in parallel.

Use the Strongest Model With Thinking Enabled

Boris uses Opus with thinking mode for all coding tasks. It’s slower, but it makes fewer mistakes — so you spend less time on corrections.

Three correction prompts cost more time than the latency you saved with a faster model. Thinking mode lets Claude reason through the problem before writing code. That cuts the “looks right but isn’t” outputs that waste the most time.

Use a lighter model for simple tasks like renaming a variable. Use Opus for architecture, edge cases, and design decisions.

Treat CLAUDE.md as Living Documentation

Every project needs a CLAUDE.md file checked into git. Not a README — an instruction file. It covers naming rules, test commands, style preferences, and mistakes Claude has made before.

When Claude gets something wrong, don’t just fix the output. Fix it, then ask Claude to update CLAUDE.md so it doesn’t happen again. Boris calls this “Compounding Engineering.” Every caught mistake becomes future prevention.

Teams share one CLAUDE.md in git. One engineer’s fix helps every session across the whole team.

Start Complex Tasks in Plan Mode

Before Claude writes any code on a complex task, switch to Plan mode. Press Shift+Tab twice. Claude maps out the approach, flags ambiguities, and shows what it plans to do.

Review the plan. Push back on steps that don’t make sense. A solid plan saves far more time than discovering a wrong approach halfway through.

Some teams run two Claudes — one writes the plan, one reviews it as a senior engineer. Only after both agree does execution start.

Build Slash Commands for Repeated Workflows

Teams repeat the same workflows constantly. Those shouldn’t require re-explaining every session.

Store custom commands in .claude/commands/ and track them in git. A /commit-push-pr command handles commit, push, and PR in one step. Commands can run bash to pull in context — failing tests, recent commits, current sprint tasks.

Whatever your team does repeatedly belongs in a slash command.

Use Subagents to Keep Context Clean

Context fills up as a session runs. Too much noise and Claude loses focus.

Subagents fix this by offloading work to fresh instances. Need to verify a build, run a check, or review a diff? Dispatch a subagent instead of doing it inline.

Boris keeps reusable subagent definitions for common jobs: a code simplifier, a build checker, a test runner. Each starts clean and returns a result without cluttering the main session.

Wire Up Hooks to Automate the Boring Parts

Claude Code runs shell commands at specific points in its lifecycle. These are hooks.

PostToolUse is the most useful one. Run a formatter every time Claude edits a file — no more CI failures from missing prettier or swiftformat. Claude never needs to be reminded.

Other hooks worth setting up:

• SessionStart — loads recent commits, open issues, and sprint context at the start of every session
• PreToolUse — logs every bash command Claude runs
• PermissionRequest — sends approval prompts to Slack so you can approve from your phone
• Stop — nudges Claude to keep going if there’s still work left
• PostCompact — reloads key docs after context is compressed

Pre-Allow Safe Permissions

--dangerously-skip-permissions removes all approval prompts. Boris doesn’t use it.

Instead, use /permissions to allow specific safe commands. For example:

Bash(bun run *)
Bash(git log *)

These run without prompting. Commands that write files or touch config still ask. You keep the guardrails that matter.

Give Claude a Way to Verify Its Work

This is Boris’s top tip: Claude needs a feedback loop.

For web work, Claude can screenshot the browser and compare to the spec. For mobile, it can build and run the simulator. For backend, it runs tests. The method doesn’t matter — what matters is that Claude checks its own output before handing it back.

Without verification, Claude assumes its output is correct. With it, Claude iterates until something works. Boris estimates a 2-3x quality improvement.

Before starting any big task, ask: what does “done and correct” look like? Then give Claude a way to check.

Set Up Your Terminal Properly

Boris uses Ghostty as his terminal. It handles Claude’s structured output cleanly.

Enable voice dictation if you haven’t. On macOS, double-tap Fn to start dictating. Speaking is about three times faster than typing for longer prompts.

Run /statusline to add a status bar with the current model, context usage, and git branch. Watch context fill so you know when to start a fresh session.

Use tmux or tab colors to tell sessions apart. When five instances are running, visual labels are how you stay oriented.

Integrate the Tools Your Team Uses

Claude Code gets much more powerful when it can access your actual tools. Boris has connected Slack, BigQuery via bq, Sentry, and GitHub.

For a bug fix, paste a Slack thread into Claude. Claude reads it, checks Sentry logs, reviews the code, and suggests a fix — without you switching tools.

Setup takes time. The payoff is Claude owning full workflows, not just individual steps.

Use Scheduling for Long-Running Tasks

Not every task needs you watching it. /loop runs recurring tasks locally for up to three days. /schedule runs cloud jobs that keep going after your laptop closes.

Code review can be fully automated this way — an agent triggers on new PRs, checks logic and security, and posts a summary comment.

Use --permission-mode=dontAsk for background agents when you’ve already reviewed the plan and trust the execution.