Claude Code Tips From the Guy Who Built It

Boris Cherny created Claude Code at Anthropic. Over three Twitter threads (early January, late January, and February 2026), he shared how he and the Claude Code team use it every day. His setup is, in his own words, "surprisingly vanilla."

I've pulled together every tip from all three threads into one place. As Boris keeps saying: there's no single correct way to use Claude Code.

Run Multiple Sessions in Parallel

Boris runs 5 Claude Code instances in his terminal simultaneously, each in its own git checkout. He numbers his tabs 1-5 and uses iTerm2 system notifications so he knows when any session needs input.

He also runs 5-10 more sessions on claude.ai/code in the browser, hands work between local and web sessions using the & command or --teleport flag, and kicks off sessions from his phone via the Claude iOS app.

The team uses git worktrees instead of separate checkouts. Worktrees let you have multiple branches checked out simultaneously under the same repo. The team liked this approach so much that one engineer built native worktree support into the Claude Desktop app.

git worktree add .claude/worktrees/my-feature origin/main
cd .claude/worktrees/my-feature && claude

Some people set up shell aliases (za, zb, zc) to hop between worktrees with one keystroke. Others keep a dedicated "analysis" worktree just for reading logs and running queries, keeping their main work clean.

The team calls this the single biggest productivity unlock.

Pick One Model and Stick With It

Boris uses Opus 4.5 with thinking enabled for everything. It's bigger and slower per request than Sonnet. But because you spend less time correcting it and it's better at tool use, the total time from prompt to done is usually shorter.

Pick one model, commit to it for a week, and measure how much re-prompting you actually do before deciding to switch.

Start Every Complex Task in Plan Mode

Most of Boris's sessions start in Plan mode (shift+tab twice). Enter Plan mode, iterate on the plan with Claude until you're happy with it, then switch to auto-accept edits mode. Claude can usually one-shot the implementation from a good plan.

One person has Claude A write the plan, then spins up Claude B to review it like a staff engineer. Fresh context, less bias. If things go sideways during implementation, they don't push through. They switch back to plan mode and re-plan. They also use plan mode for verification steps, not just for building.

Treat CLAUDE.md as a Living Document

The Claude Code team shares a single CLAUDE.md file for their repo, checked into git. The whole team contributes to it multiple times a week. Any time Claude does something wrong, they add a note to CLAUDE.md so it doesn't repeat the mistake.

Each team at Anthropic maintains their own CLAUDE.md. It's each team's responsibility to keep theirs current.

After every correction, end your session with: "Update your CLAUDE.md so you don't make that mistake again." Claude is apparently very good at writing rules for itself. Then prune the file aggressively over time until Claude's mistake rate measurably drops.

One engineer goes further: they tell Claude to maintain a notes directory for every task and project, updated after every PR, and point CLAUDE.md at those notes.

Use @.claude in Code Reviews

During code review, Boris tags @.claude on coworkers' PRs to add learnings to CLAUDE.md as part of the PR itself. They use the Claude Code GitHub Action (install it with /install-github-action) for this.

The idea comes from Dan Shipper's "Compounding Engineering." A comment like "nit: use a string literal, not a TS enum" followed by "@claude add to CLAUDE.md to never use enums, always prefer literal unions" turns a one-off correction into permanent team knowledge.

Create Slash Commands for Repeated Work

Boris uses slash commands for every workflow he does multiple times a day. Commands live in .claude/commands/, are checked into git, and are shared with the team. Claude can call them too, not just you.

His most-used example is /commit-push-pr, which he runs dozens of times daily. The command includes inline bash to pre-compute git status and other context so it runs fast without extra model calls.

---
description: Prep a clean commit and push a PR
allowed-tools: Bash(git status:*), Bash(git diff:*), Bash(git commit:*), Bash(git push:*)
---

# Context
- Status: !`git status -sb`
- Diff: !`git diff --stat`

# Task
Draft a commit message, commit, and push the current branch.

The team's rule of thumb: if you do something more than once a day, turn it into a slash command or skill. They also suggest building a /techdebt command you run at the end of every session to find duplicated code, and a "context dump" command that syncs recent Slack, Google Drive, Asana, and GitHub into one place.

Set Up Subagents for Common Workflows

Boris thinks of subagents as automations for his most common PR workflows. He keeps a few in .claude/agents/:

code-simplifier cleans up and simplifies code after Claude finishes working. verify-app has detailed instructions for end-to-end testing.

Appending "use subagents" to any request tells Claude to throw more compute at the problem. You can also use subagents to keep your main agent's context window clean by offloading individual tasks. One team member routes permission requests through an Opus-powered subagent via a hook that scans for attacks and auto-approves safe ones.

> use 5 subagents to explore the codebase

This launches five parallel exploration agents, each diving into a different part of the codebase simultaneously.

Use Hooks for Automation

The team uses a PostToolUse hook to auto-format Claude's code after every write or edit. Claude gets formatting right about 90% of the time, and the hook handles the last 10% to avoid CI failures later.

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

Hooks also route permission requests to Slack or to a reviewing agent, nudge Claude to keep going when it reaches the end of a turn, or add your own logging to tool calls.

Manage Permissions Properly

Boris doesn't use --dangerously-skip-permissions. Instead, he runs /permissions to pre-allow specific bash commands he knows are safe in his environment. Most of these are checked into .claude/settings.json and shared with the team.

The permission system supports full wildcard syntax: Bash(bun run *) or Edit(/docs/**). For sandboxed environments or very long-running tasks, he'll use --permission-mode=dontAsk, but only when appropriate.

The February thread introduced sandboxing as an additional option. Run /sandbox to enable Claude Code's open-source sandbox runtime, which provides file and network isolation while reducing permission prompts.

Integrate Your Tools

Claude Code connects to Boris's full toolchain. It searches and posts to Slack via MCP, runs BigQuery queries using the bq CLI, and grabs error logs from Sentry. The MCP configuration is checked into .mcp.json and shared with the team.

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

The Slack MCP integration is great for bug fixing. Paste a Slack bug thread into Claude and just say "fix." Or just say "Go fix the failing CI tests" and let Claude figure out how. The team also points Claude at Docker logs to troubleshoot distributed systems.

Boris says he hasn't personally written a line of SQL in over six months. He just asks Claude Code to use the bq CLI.

Handle Long-Running Tasks

For tasks that take a long time, Boris has three strategies. First, prompt Claude to verify its work with a background agent when it's done. Second, use an agent Stop hook for more deterministic verification. Third, use the ralph-wiggum plugin (a community idea from Geoffrey Huntley).

In sandboxed environments, --permission-mode=dontAsk lets Claude run without getting blocked on permission prompts.

The Most Important Tip: Give Claude a Way to Verify

Boris calls this the most important thing for getting good results from Claude Code. If Claude has a feedback loop to verify its own work, it 2-3x the quality of the final result.

For changes to claude.ai/code, Claude uses the Chrome extension to open a browser, test UI changes, and iterate until things work and feel right. Verification looks different for every domain: running a bash command, executing a test suite, testing in a browser, or running a phone simulator. The point is giving Claude a way to close the feedback loop.

Level Up Your Prompting

Challenge Claude. Say "Grill me on these changes and don't make a PR until I pass your test." Make Claude your reviewer. Or say "Prove to me this works" and have Claude diff behavior between your branch and main.

After a mediocre first attempt, try: "Knowing everything you know now, scrap this and implement the elegant solution."

Write detailed specs and reduce ambiguity before handing work off. The more specific you are up front, the better the output.

Set Up Your Terminal

The team loves Ghostty (note: so do I 💪🏽) for its rendering and unicode support. For Claude-juggling, use /statusline to customize your status bar to show context usage and current git branch. Color-code and name your terminal tabs, one per task or worktree.

Use voice dictation. You speak roughly 3x faster than you type, and your prompts get way more detailed as a result. On macOS, double-tap the fn key.

Use Claude as a Learning Tool

Set the output style to "Explanatory" or "Learning" in /config so Claude explains the reasoning behind its changes as it works. Have Claude generate a visual HTML presentation explaining unfamiliar code. Ask for ASCII diagrams of protocols and codebases. Build a spaced-repetition skill where you explain your understanding and Claude asks follow-ups to fill gaps.

Customise Everything (and Share It)

The February thread was all about making Claude Code your own. Every keybinding is customisable via /keybindings. You can set custom spinner verbs (one team member has Star Trek-themed spinners). Custom agents go in .claude/agents/ with their own names, colours, tool sets, and models. You can even set a default agent for all conversations.

The Plugins system lets you install LSPs for any major language, MCPs, skills, agents, and custom hooks from the official Anthropic marketplace or your company's own marketplace.

Check your settings.json into git so your team benefits from your customisations. Claude Code supports 37 settings and 84 environment variables. If a behaviour exists, you can probably configure it.

The Big Picture

Across all three threads, the philosophy is the same: treat Claude Code as a parallel execution engine, not a chatbot. Front-load your thinking in plan mode. Build persistent knowledge in CLAUDE.md. Automate repeated workflows with slash commands and subagents. Give Claude a way to verify its own work.

Worktrees, clear prompts, shared configuration, and verification steps that don't get skipped. That's it.