I spend a fair amount of time helping teams get more out of AI coding agents, so when Boris Cherny — the person who actually built Claude Code — started sharing how he uses it day to day, I read all of it. I was half expecting a list of obscure settings and clever hacks. That’s not what it is. The setup is mostly stock. What’s different is the way he thinks about the tool, and that turned out to be the part worth stealing.
Most people, me included when I started, use Claude Code like a chat window: ask, wait, read, ask again. Boris uses it more like a small team he’s running. Once that clicked, his specific habits started to make sense. Here are the ones I’ve actually changed my own workflow around.
He runs a fleet, not a conversation
Boris keeps around five Claude Code sessions going at once, each working in its own git worktree — a separate checkout of the same repo — so they can all make changes without stepping on each other. Notifications tell him when one needs his input. While one session is grinding through a refactor, he’s planning the next task in another and reviewing output in a third.
The mental shift is the whole thing. He isn’t waiting on one agent; he’s scheduling several and keeping them fed. The Anthropic team calls running parallel worktrees their single biggest productivity tip, and having tried it, I understand why. It’s also the hardest habit to build, because it asks you to hold a few threads in your head at once instead of pair-programming with one. If you’ve never used them, git worktree add checks out a branch into its own folder from a single repo — that’s the mechanism that makes the parallel sessions safe.
Almost everything starts with a plan
Something like 80% of his sessions start in plan mode, where Claude works out an approach and you approve it before it writes any code. For anything non-trivial, he spends the effort on a solid plan first, then lets the agent implement against it.
This one was easy for me to accept, because it’s how I’d want any engineer to work. You wouldn’t hand someone a meaningful change and expect them to start typing before they’ve thought it through. The plan is where you catch the misunderstanding cheaply, before it’s spread across ten files and you’re reviewing a diff that solved the wrong problem.
Give it a way to check its own work
If there’s one tip Boris repeats, it’s this: the most valuable thing you can do is give Claude a way to verify what it did. A test it can run, a script that tells it whether the thing works, a way to see the result for itself. He says it can two or three times the quality of the output, and that matches what I’ve seen.
This is the same lesson I keep running into everywhere else with AI. The model is a strong first draft and an unreliable judge of its own work. When you give it a way to check itself — to close the loop — it stops handing you confident, broken answers. It’s the coding version of the evaluation discipline I’d apply to any AI feature: don’t trust the output, give it something to measure against.
A CLAUDE.md that remembers the team’s mistakes
He solved the “starts from zero every session” problem the same way I wrote about recently: a CLAUDE.md file that Claude reads at the start of every session. His teams keep theirs in git and fill it with the unglamorous stuff — style conventions, design guidelines, a PR template, and a running list of mistakes the agent has made so it stops repeating them.
I won’t make the whole case for it again here, but it’s worth noting that the person who built the tool leans on exactly this. The memory file isn’t a power-user trick. It’s table stakes.
Use the best model, and push work to subagents
Two smaller things stuck with me. He runs the most capable model for everything, rather than reaching for a cheaper, smaller one to save money on hard problems. The time you lose to a weaker model fumbling a tough task isn’t worth the savings. And he leans on subagents to handle chunks of work off to the side, which keeps the main session’s context clean instead of clogging it with every detail at once. Managing what’s in the context window matters here as much as it does anywhere else with these models.
The surprising part is how plain it is
What struck me most is what’s missing. There’s no elaborate rig, no stack of clever hacks. The setup is mostly the defaults, applied with discipline: plan first, verify always, write down what you learn, and run more than one agent at a time. The gap between getting a little out of Claude Code and getting a lot out of it isn’t some configuration you haven’t found. It’s the shift from treating it as a thing you chat with to treating it as a small team you run.
That’s the part I’ve started passing on to the teams I work with. Stop waiting on a single agent. Plan the work, give it a way to check itself, write down the lessons so they carry over, and keep a few sessions busy at once. None of it is exotic, which is exactly the point — the creator of the tool gets the most out of it not with secrets, but by doing the obvious things consistently.
