Claude Code’s creator Boris Cherny described how he uses it at Anthropic, highlighting practices such as running parallel instances, sharing learnings, automating prompting, and rigorously verifying results to compound productivity over time.
Cherny does not customize Claude Code, as he finds it works great out of the box, and runs many sessions in parallel, including five locally in his MacBook’s terminal and 5-10 on Anthropic’s website. To avoid conflicts, each local session uses its own git checkout, rathen than branches or worktrees. He starts remote sessions with & from the CLI and often uses --teleport to move them back an forth. However, 10-20% of those sessions are abandoned due to unexpected scenarios.
Cherny prefers using Opus 4.5 with thinking for all coding, valuing its higher quality and reliability over Sonnet despite its slower speed. He also finds Opus better at tool use and notes that it is ultimately faster overall than the smaller model.
Each team at Anthropic maintains a CLAUDE.md in git to document mistakes, so Claude can improve over time, and best practices, such as style conventions, design guidelines, PR template, and so on. Cherny often uses the @.claude tag on coworkers’s PRs to add learnings to CLAUDE.md, ensuring knowledge from each PR is preserved. Currently, Cherny says, their CLAUDE.md is 2.5k tokens.
One key aspect of his workflow is starting with a plan and refine it iteratively before switching to auto-editing:
If my goal is to write a Pull Request, I will use Plan mode, and go back and forth with Claude until I like its plan. From there, I switch into auto-accept edits mode and Claude can usually 1-shot it. A good plan is really important!
Cherny executes daily workflows like commits, PRs, simplification, and verification using slash commands to start sub-agents. All commands are stored in .claude/commands/, which also helps reduce the need for explicit prompting.
For example, Claude and I use a /commit-push-pr slash command dozens of times every day. The command uses inline bash to pre-compute git status and a few other pieces of info to make the command run quickly and avoid back-and-forth with the model.
While Claude’s code is usually well formatted, inconsistencies can sometimes cause CI failures. To prevent this, Cherny runs a PostToolUse hook to clean up the code:
"PostToolUse" : [
"matcher": "WritelEdit",
"hooks": [
{
"type": "command",
"command": "bun run format || true"
}
]
For security, Cherny almost never uses --dangerously-skip-permissions. Instead, he enables commonly used bash commands that are safe in his environment via /permissions. This spares him unnecessary permission prompts on commands like bun run build:*, bun run test:*, cc:* and many others. The only case when he uses --dangerously-skip-permissions is for running long-running tasks inside a sandbox to prevent Claude from stopping repeatedly.
The most important tip is to give Claude a way to verify its work through a feedback loop, such as running a bash command, or a test suite, or testing the app through the browser or a simulator. This can improve the quality of the final result by a factor of 2–3:
Claude tests every single change I land to claude.ai/code using the Claude Chrome extension. It opens a browser, tests the UI, and iterates until the code works and the UX feels good.
Overall, Cherny explains, this workflow lets his team focus on code review and steering, noting that when an engineer reads a PR, the code is already in good shape.
Cherny’s tweets sparked an extended discussion on X.com, including some useful clarifications we have included here, but be sure to read the original for full detail.
