How Boris Cherny, the Creator of Claude Code, Actually Uses It [With Examples]

Boris Cherny's style can be summed up in a phrase: "vanilla setup, parallel operation." Each individual session is unadorned; instead he runs many Claudes at the same time to maximize output. In this article we look at how the creator himself uses the tool, with concrete examples.

This article is based on our research into interviews with Boris Cherny and sources that aggregate his public posts. The sources include his own direct statements (primary information), media reporting (secondary information), and community sites compiled by volunteers, and we distinguish between them in the text where possible. Please check the original articles for the exact wording of any quotes.

1. The setup is "surprisingly vanilla"

Surprisingly, the creator's own setup is not elaborate. He describes his configuration as "surprisingly vanilla." It is also a message that Claude Code works well out of the box. Rather than differentiating through fancy configuration, his style is to compete with the "parallelism," "verification," and "memory" described below.

2. Run multiple Claudes in parallel

His most distinctive trait is parallel execution. Initially he ran about five checkouts of the same repository at once in numbered terminal tabs, using system notifications to know which session was waiting for input. Then, as new models arrived, the workflow evolved toward git worktrees. From his own post on X (formerly Twitter):

Spin up 3–5 git worktrees at once, each running its own Claude session in parallel. It's the single biggest productivity unlock, and the top tip from the team. Personally, I use multiple git checkouts, but most of the Claude Code team prefers worktrees.

— From Boris Cherny's post on X (primary information / wording to be verified)

# Set up 3-5 worktrees and run a separate Claude in parallel in each
git worktree add ../feat-auth   feature/auth
git worktree add ../feat-search feature/search
# Start claude in each directory -> work in parallel

He says that "personally I'm a multiple-checkouts person, while most of the team prefers worktrees," positioning going parallel itself as the single biggest productivity gain. More recently he has said that "running just one is rare; it's several to dozens, hundreds, thousands" (secondary information).

3. Carve mistakes into CLAUDE.md

This is the most famous of his team's habits. The phrase, attributed to him and quoted consistently across multiple sources:

Anytime we see Claude do something incorrectly we add it to the CLAUDE.md, so Claude knows not to do it next time.

— Boris Cherny (consistent across multiple sources / attributed as a direct statement)

In other words, "every time Claude does something wrong, add it to CLAUDE.md so it won't repeat it next time." Instead of ending with an on-the-spot fix, you turn it into permanent institutional memory. Recently this is said to have evolved into writing it not only into CLAUDE.md but also into "skills" (secondary information).

4. Turn anything you do more than once a day into a slash command

Repetitive tasks become custom slash commands. The most frequently cited example is /commit-push-pr (commit -> push -> create PR in a single command). He says he uses it many times a day. Slash commands can also embed Bash inline and precompute things like git status in advance.

# Define it in .claude/commands/commit-push-pr.md -> call it with /commit-push-pr
# Consolidate "commit, push, and open a PR" into a single action

5. Plan mode -> auto-accept, and then "auto mode"

His workflow has a clear evolution. The classic approach used to be to plan in plan mode and then switch to auto-accept. A quote attributed to him:

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!

— Boris Cherny (direct quote via media reporting)

However, with newer models (4.6 and later), explicit planning became less necessary, so he is said to have started making "auto mode" the default instead of using plan mode. Statements to the effect of "I don't use it anymore; I use auto mode, because the model doesn't need it" have been reported (sourced from a community site / to be verified).

6. The most important thing is "giving it a way to verify"

And here is what he calls the "most important tip."

Give Claude a way to verify its work. If Claude has that feedback loop, it will 2-3x the quality of the final result.

— Boris Cherny (consistent across multiple sources)

"Give Claude a way to verify its work. If it has that feedback loop, the quality of the final result will be 2-3x better." Furthermore, he has recently argued that verification should not stop at "unit tests, lint, and type checks" but should ask, more sharply, "Can the agent run the thing?" (secondary information).