How the Creator of Claude Code Actually Uses Claude Code
13 tips from Boris Cherny
Back in January, Boris Cherny, the creator of Claude Code, posted a thread breaking down his entire workflow. I had a chance to meet with him and ask questions, and I found his setup genuinely enlightening. I’ve been replicating a lot of it into my own workflow since.
His setup is surprisingly vanilla. Claude Code works great out of the box, and Boris doesn’t customize it much. But the way he orchestrates everything around it is where the real leverage comes from.
Below I wrote out my thoughts on his full posts and also made a video if you prefer to watch it.
Here are 13 tips from Boris
1. Run 5 Claudes in Parallel
Boris runs five Claude Code instances in his terminal simultaneously. He numbers his tabs 1 through 5 and uses system notifications to know when a Claude needs input.
I work very similarly. I use iTerm hotkeys (Cmd+1, Cmd+2, etc) to switch between instances and Cmd+left/right bracket to switch tabs within each. One additional thing I do is rename each tab to the project I’m working on, like “push-to-prod” or “anime-pomodoro.” It keeps the mental context clear when you’re bouncing between sessions.
2. Run 5-10 Web Claudes Too
Boris also runs 5 to 10 sessions on claude.ai/code in parallel with his local instances. He hands off local sessions to web, manually kicks off sessions in Chrome, and teleports back and forth between them. He even starts sessions from his phone using the Claude iOS app every morning.
The teleport feature was new to me. You can push a local session to the web and pick it up from any device. The phone sync is particularly interesting. I can see myself kicking off sessions before bed and checking results in the morning.
3. Opus with Thinking, Always
Boris uses Opus with thinking for everything. Even though it’s bigger and slower than Sonnet, he says you have to steer it less and it’s better at tool use, so it’s almost always faster in the end.
I also default to Opus. You can switch models mid-session with /model. And if you have multiple sessions running in parallel, the slower speed per session doesn’t really matter. You’re not sitting there waiting. You’re orchestrating.
4. Share Your CLAUDE.md
The Claude Code team shares a single CLAUDE.md for their entire repo. They check it into Git and the whole team contributes multiple times a week. Anytime Claude does something incorrectly, they add it to the CLAUDE.md so it knows not to do it next time.
I asked Boris what his personal CLAUDE.md looks like. He said it’s basically two lines pointing to the team’s shared one. The whole idea is compound engineering: building institutional knowledge directly into the codebase so every Claude session gets smarter. I do this too. My Pomodoro app has a CLAUDE.md with iOS navigation flows, design patterns, and project-specific conventions. You can bootstrap one with /init.
5. Add Claude in Code Reviews
During code review, Boris tags @claude on his coworkers’ PRs and adds something to CLAUDE.md as part of the PR. They use the Claude Code GitHub Action for this. It’s their version of Dan Shipper’s Compounding Engineering.
This is powerful. When Boris spots an anti-pattern in a PR, he doesn’t just leave a comment. He tells Claude to update the CLAUDE.md so the pattern is caught automatically next time. The feedback loop is: human spots issue, Claude updates the rules, future Claude sessions avoid the issue entirely.
6. Plan Mode First
Most of Boris’s sessions start in Plan mode (Shift+Tab twice). If his goal is to write a Pull Request, he uses Plan mode to go back and forth with Claude until he likes the plan. Then he switches to auto-accept edits mode and Claude can usually one-shot it.
I use Plan mode constantly, not just for PRs. I use it for deep dives into different parts of a codebase, investigating bugs, exploring performance optimization options. Plan mode is essentially a way to build really good prompts. You’re doing the orchestration to bring all the context Claude needs into a single session so it can execute correctly.
7. Slash Commands for Everything
Boris uses slash commands for every inner-loop workflow he does many times a day. This saves repeated prompting and means Claude can use these workflows too. Commands are checked into Git and live in .claude/commands/.
For example, he uses a /commit-push-pr command every day. The command uses inline bash to precompute Git status so it runs quickly. Creating these is easy. Just ask Claude Code to make one for you. Describe what you want and it’ll create the skill file. Slash commands, skills, subagents, MCPs. Let Claude Code set them all up.
8. Custom Subagents
Boris uses a few subagents regularly. Code Simplifier simplifies code after Claude is done working. Verify App has detailed instructions for testing Claude Code end to end.
Subagents are really about protecting context. They’re useful when you want side effects or when you just want the result of a Claude instance running without caring how it got there. The new Agent Teams feature (with Opus 4.6) takes this further, with subagents that have different roles and share context through a master orchestrator.
9. Post Tool Use Hooks
The Claude Code team uses a post tool use hook to format code after Claude edits it. Claude usually generates well-formatted code out of the box, and the hook handles the last 10% to avoid formatting errors in CI later.
These are similar to pre-commit hooks. Nothing revolutionary, but it’s another example of automating the tedious stuff so you never think about it.
10. /permissions, Not --dangerously-skip
Boris doesn’t use --dangerously-skip-permissions. Instead, he uses /permissions to pre-allow common bash commands that he knows are safe in his environment. These are checked into .claude/settings.json and shared with the team.
This is compound engineering again. You put these settings into the codebase and share them with the team. Everyone agrees on the safe defaults. The team needs to be AI-native first, and that means agreeing on these patterns together.
11. MCP for All Tools
Claude Code uses all of Boris’s tools for him. It searches and posts to Slack via MCP, runs BigQuery queries for analytics, grabs error logs from Sentry. MCP configurations are checked into Git and shared with teams.
Be careful with MCPs though. They can blow up your context window. Only use them for specific things that are outside normal coding, like Slack, analytics, and error logs. Also watch out for prompt injection. Always have Claude Code review an MCP before you install it.
12. Long Running Tasks
For very long running tasks, Boris either prompts Claude to verify its work with a background agent when it’s done, uses an agent-stop hook for deterministic verification, or uses the Ralph Wiggin plugin for autonomous looping.
I’m less bullish on fully autonomous loops. The hype has died down a bit. You need a near-perfect spec for it to work well, and that’s a lot of upfront work. But for side projects where you don’t care as much, it’s fine to spec it out and let it run overnight.
13. Give Claude a Way to Verify Its Work
This is probably the most important tip. Give Claude a way to verify its own work. If Claude has that feedback loop, it will 2-3x the quality of final results.
Boris’s team tests every change using the Chrome extension. Claude opens the browser, tests the UI, and iterates until it works. It’s a different form of end-to-end testing. You don’t write the test. Claude just knows how to navigate and validate.
The Bigger Picture
Think about what your workflow looked like six months ago compared to this. We were still manually coding. Now we’re running multiple Claude instances at all times, playing StarCraft with our codebase, filing PRs from one session while debugging in another while kicking off a review in a third.
The mental context switching is probably the bottleneck at this point, not the coding. Challenge yourself to try some of these patterns this week. Even adopting two or three of them will fundamentally change how you work.
Boris's workflow is gold — especially the post-tool-use hook for formatting. Been using Claude Code in terminal for weeks now, and adding 'respect existing style' changed everything. How do you handle large codebases without token limits biting? Loving this series!
The vanilla approach is interesting. Boris keeping it simple tracks with what I've found too. The one area where I've gone heavier on config is hooks. Once you set up a SessionStart hook to validate deps and a Stop hook to run the test suite, you stop having to think about whether the agent remembered to do it.
Claude Code's hook system is powerful but Codex CLI just shipped its own version with a much simpler config format. Two events, one JSON file. I did a comparison across both plus Cursor here https://reading.sh/codex-cli-has-hooks-now-stop-stuffing-agents-md-c181465fe271 if you're curious how they stack up.
Boris's point about permissions is solid though. The /permissions approach is way better than dangerously-skip-permissions for shared team configs.