There Is No Right Way to Use Claude Code — But There Are Smarter Ways

Boris Cherny ships 20 to 30 pull requests per day. He runs five parallel Claude Code sessions on his local machine and another five to ten on claude.ai/code. He wrote the tool — he's the Head of Claude Code at Anthropic — and yet, his approach to using it is not particularly exotic. It's structured. It's diligent. And it's grounded in one surprisingly simple principle.

There is no single correct way to use Claude Code. But there are ways that compound over time, and ways that don't. Boris's workflow is a case study in the former.

The single most important practice

When Boris describes how he works, one idea comes up more than anything else: give Claude a way to verify its own work.

He calls this the most impactful thing you can do — claiming it 2-3x the quality of output. Not better prompts. Not more detailed specs. Verification.

The logic is intuitive. When you give Claude access to a browser to check its own frontend output, or connect it to a test suite so it can validate its own code, you close the feedback loop. The agent doesn't need you to tell it something is wrong. It can see it, diagnose it, and fix it — often before you've even looked at the result.

For anyone running AI-assisted development workflows, this is worth sitting with. The bottleneck in most setups isn't the AI's capability. It's the fact that the human has to review everything before the next step can happen. Verification changes that equation.

Compounding engineering

Boris maintains a shared CLAUDE.md file across his team that gets updated multiple times per week. Every time Claude makes a mistake — a wrong assumption, a missed edge case, a pattern that doesn't fit the codebase — it gets captured in that file.

He calls this "compounding engineering." The idea is that mistakes, once documented, never repeat. Each correction makes every future session slightly better. Over weeks and months, the cumulative effect is significant.

This is not a new idea in engineering culture. Runbooks, postmortems, and coding standards all serve the same function. What's different here is that the consumer of the documentation is an AI agent, which means it actually reads and follows it every single time, without exception.

For teams starting to adopt AI-assisted development, this is one of the highest-leverage investments you can make: maintain a living document of lessons learned, and make sure it's loaded into every session.

Parallel sessions and worktrees

One of the more practical patterns Boris uses is running multiple Claude Code sessions simultaneously using git worktrees. Each session works in its own isolated copy of the repository, which means they can't create merge conflicts with each other.

This is how he reaches 20-30 PRs per day. It's not one session working faster — it's many sessions working in parallel, each scoped to a specific task.

The takeaway for developers and technical founders: the throughput ceiling of AI-assisted development is not how fast one session can go. It's how many independent tasks you can break your work into.

There is no one right way

The Claude Code community has produced dozens of different workflow methodologies. A repository called claude-code-best-practice, curated by developer Shayan Rais, documents eight major approaches side by side — from TDD-first methodologies to spec-driven development to role-based agent orchestration.

What stands out when you look at them together is that they all work. The differences are in philosophy, not in correctness. Some teams prefer rigid test-driven cycles. Others prefer giving Claude a detailed spec upfront and letting it execute. Others run parallel "sprints" with multiple agents taking different roles.

Boris himself is notable for how little he customises the tool. He's said that Claude Code "works great out of the box." His edge comes not from exotic configuration, but from disciplined habits: verification, documentation, and parallelism.

The repository is worth exploring not because it prescribes a single workflow, but because it maps the landscape. It includes 87 categorised tips covering everything from prompting strategies to git management to debugging patterns. It also documents Boris's own 15 tips — drawn from his public posts — alongside community patterns from projects with hundreds of thousands of stars.

What this means for non-developers

If you're a founder or operator who doesn't write code, the meta-lesson here still applies.

Boris's workflow works because it follows three principles that have nothing to do with programming:

1. Close the loop. Don't just give instructions — build in a way to check whether they worked. This applies to outbound campaigns, ad experiments, and content performance just as much as it does to code.
2. Document what went wrong. Mistakes are inevitable. What separates a compounding system from a static one is whether lessons get captured and applied to the next run.
3. Parallelise independent work. The fastest way to increase output is not to speed up one process, but to run multiple independent processes at the same time. This is true whether you're shipping code or running multi-channel marketing.

These are the same principles that underpin any well-designed operations system. The tools are new. The thinking isn't.

Getting started

If you're setting up Claude Code for the first time, or looking to move from casual usage to a more structured workflow, we've written a step-by-step guide that walks through the full environment setup — from CLAUDE.md configuration to hooks, commands, and agent architecture. You can find it in our Claude Code Setup Guide.

For a broader look at the community landscape and the full collection of tips, Shayan Rais's claude-code-best-practice repository is the most comprehensive reference available. It's actively maintained and covers everything from beginner patterns to advanced multi-agent workflows.

By Pascal, Founder — Ryzo

Last updated: 31 March 2026