How Boris Cherny, Builder of Claude Code, Uses It — And Why That Should Change How You Think About AI
Source: Dev.to
If a person who invented the oven waits for it to heat properly, you do the same.
If the camera designer adjusts the lighting settings, you do the same.
If the car maker buckles the seatbelt first, you do the same.
Hey, I’m Karo 🤗
AI product manager, Substack bestseller, and someone who believes the most valuable lessons come from people who invent tools and then use them themselves.
This article was originally published here.
About Boris Cherny
Boris Cherny is a Staff Engineer at Anthropic who helped build Claude Code. In this post we’ll explore:
- how he uses Claude,
- what he does (and avoids),
- and why it matters for anyone building with AI.
1️⃣ He Runs a Fleet of Claudes in Parallel
What he does
- Keeps 10–15 concurrent Claude Code sessions alive:
- 5 in terminal (tabbed, numbered, with OS notifications)
- 5–10 in the browser
- Mobile sessions started in the morning and revisited later
- Hands sessions off between environments, sometimes “teleporting” them back and forth.
What this means
Why it matters – Boris treats AI not as a single tool but as a capacity you schedule. He distributes cognition like compute: allocate it, queue it, keep it hot, and switch contexts only when value is ready. The real bottleneck is attention allocation, not generation speed.
- Agents as workers – Each session is a separate worker with its own context, not a monolithic assistant that must hold everything.
- Implications for vibecoders – This goes beyond prompt or context engineering; it’s about pipeline design: run many partial brains in flight and interact only with the ones that are “ripe”.
2️⃣ He Uses the Slowest, Smartest Model by Default
What he does
- Uses Opus 4.5 (the biggest, slowest Claude model) for everything, because the higher quality reduces overall iteration time.
What this means
Why it matters – He optimizes for total iteration cost, not raw token‑per‑second speed. A fast but wrong answer costs more in human time than a slower, correct one.
- Responsibility – He acknowledges the “correction tax”: every hallucination or half‑right patch consumes human attention. Paying extra compute to reduce that tax is a net win.
- Implications for vibecoders – Optimize for cost per reliable change, not cost per token.
3️⃣ He Maintains a Shared CLAUDE.md That Turns Mistakes Into Institutional Memory
One of my favorite takeaways.
What he does
- The team keeps a single
CLAUDE.mdfile in the repo, updated multiple times a week. - Rule: Whenever Claude does something wrong, add it to the file so the mistake never repeats.
- Each team member owns the upkeep of their own sections.
What this means
- Why it matters – AI is powerful but forgetful. External memory (the markdown file) is the only way to give it lasting context.
- Responsibility – It’s cheaper to write a rule once than to double‑check everything forever.
- Implications for vibecoders –
CLAUDE.mdbecomes your product’s safety rails (e.g., “never touch prod”, “run tests first”, “preferred architecture”). This validates the advice in If You Build With AI, You Need This File.
4️⃣ He Uses Claude in Code Review to Update the System, Not Just to Approve a PR
What he does
- Tags
@.claudeon coworkers’ pull requests. - The Claude Code GitHub Action adds learnings to
CLAUDE.mdautomatically.
What this means
- Why it matters – Code review is training the development system, not merely bug catching.
- Agents in workflow – Agents become participants in the team’s social workflow (PRs) and can update shared norms. They’re not a side‑tool; they’re part of the collaboration loop.
- Implications for vibecoders – Treat PR reviews as the place to encode product standards, so future agent outputs stay aligned.
5️⃣ He Plans First, Then Lets Claude Run
The ever‑planning PM in me was thrilled by this.
What he does
- Starts in Plan Mode: iterates on a plan until it’s solid.
- Switches to auto‑accept edits mode: Claude executes the entire implementation in one go, without back‑and‑forth.
What this means
- Why it matters – AI performs best when it can commit to a structured plan (what to do, in what order, why). Plan Mode forces explicitness before execution.
- Implications for vibecoders – Prevents the classic failure where the agent makes dozens of unwanted changes. Never let a system act before you’ve agreed on intent and constraints; make planning part of the spec process.
6️⃣ He Uses Sub‑agents as Reusable Workflow Atoms
What he does
- Treats sub‑agents like slash commands that can be invoked on demand.
What this means
- Agents as modular roles – Not one monolithic AI, but a collection of specialized, constrained agents. Reliability comes from specialization.
- Coding as a pipeline – The workflow becomes a series of phases (spec → draft → simplify → …) each handled by a dedicated sub‑agent.
TL;DR for vibecoders
| Insight | Action |
|---|---|
| Fleet of agents | Run many small Claude sessions in parallel; allocate attention, not just compute. |
| Choose the smartest model | Prefer quality over speed; treat hallucinations as hidden costs. |
Shared CLAUDE.md | Keep a living document of “what not to do”; use it as your safety rail. |
| AI‑augmented code review | Let Claude add learnings to the shared doc during PRs. |
| Plan before execution | Use Plan Mode to lock down intent, then let Claude run autonomously. |
| Sub‑agents as commands | Build reusable, specialized agents for each workflow step. |
By mirroring how Boris treats Claude—as a distributed, accountable, and memory‑augmented teammate—you can turn AI from a novelty into a reliable productivity multiplier. 🚀
How he sees responsibility: Best practices get encoded into tools that run automatically. That’s ethics‑by‑design: fewer failures from fatigue.
What this means for vibecoders: Consider building one agent that writes PRDs, one that codes, one that checks UX.
#claude #claudecode