Go back

Inside Claude Code's Creator's Workflow—And Why You Might Do It Differently

DRAFT
Published: Jan 6, 2026
Vancouver

Recently, Boris Cherny (creator of Claude Code) shared his workflow on Twitter, and it sparked a lot of discussion. His approach is sophisticated—parallel sessions, shared .claude conventions, human-in-the-loop review cycles. But here’s what I found most interesting: how many of his techniques depend on context, and how some need refinement based on real constraints.

Let me walk through Boris’s approach and share what I’ve learned doing this differently.

The Thread

My approach is simpler. I run one Ghostty (iTerm2 competitor) terminal per project and work on 3-5 projects at a time on macOS. Right now I’m limited to 8 GB RAM on an M1 MacBook Air. Once I upgrade to a MacBook Pro with 16 GB or more, RAM won’t be the constraint.

I like that he switches between laptop, web, and iOS. I am not there yet, but I find myself coding mostly on desktop because it gives me the most control and speed.

Even though Opus 4.5 takes longer, Boris does less re-work and less review with a smarter model. That comes with more money and more time. This is a catch-22 that improves when you use the right model for the right task. I believe Opus 4.5 is best for implementation, but it is not the best for discovery. See the screenshot for my current recommendations.

I like the human-in-the-loop component where you retrospectively review Claude Code sessions and update CLAUDE.md. In agency work, I have seen this done with a separate Claude Code session that reviews ~/.claude/projects and offers suggestions based on how the conversation goes.

I do not recommend using Opus 4.5 in Plan mode, since sometimes it uses Opus 4.5 and other times it switches to Haiku 4.5. I recommend running Plan mode using Haiku 4.5, since planning is closer to discovery and involves research.

I do not recommend sub-agents due to context issues (maybe I will describe this in another post).

I love the ralph wiggum technique dreamt up by @GeoffreyHuntley, which I use for many new projects to bootstrap quickly.

I love the idea of giving Claude Code simple ways to test against tests, simulations, or DOM controls.

The Setup: More Terminals, More Thinking

Boris runs 5 Claudes in parallel locally plus 5-10 more on the web, juggling them with system notifications and browser tabs. I do something simpler: one Ghostty terminal per project, typically working 3-5 projects simultaneously on my M1 MacBook Air (8GB RAM limit).

His approach scales beautifully if you have the hardware. Mine works because I’ve accepted the constraint—and it forces better session isolation anyway.

The Model Question: Opus 4.5 Isn’t Always Right

Boris uses Opus 4.5 with extended thinking for everything, and his reasoning is solid: less steering, better tool use, faster overall despite longer inference time.

But here’s where I diverge:

For implementation: Opus 4.5 is unbeatable. The quality improvement justifies the cost and latency.

For discovery and planning: It’s actually overkill. This is where I’d use GPT-5.2 Pro or even Haiku 4.5. Planning is research-adjacent—you need breadth and speed, not deep reasoning.

One important caveat: don’t use Opus 4.5 in Plan mode. Claude Code sometimes switches to Haiku 4.5 mid-session, creating inconsistency. Use Haiku 4.5 explicitly for planning.

The .claude Convention: Shared Rules Matter

I love that Boris’s team checks .claude/commands/ into git and reviews it like code. They’ve also built a shared .claude/settings.json with pre-approved permissions, and tag @claude in PRs during code review to update their playbook.

This is the human-in-the-loop component done right. You don’t need sub-agents for this (I’d warn against those due to context bleed). Instead, retrospectively review sessions and update your guides. This compounds knowledge over time—similar to what Dan Shipper calls ‘Compounding Engineering.’

Feedback Loops Are Everything

Boris’s final tip is the most important: give Claude a way to verify its work. Test it. Run it. Show the results.

This is where I’d push further: give Claude direct feedback loops. Tests. DOM simulation. Quick verification scripts. When Claude can see immediately whether something works, output quality jumps 2-3x.

What I’d Add to Boris’s Workflow

  1. Use the right model for the right task, not Opus for everything
  2. Plan with lightweight models to avoid model switching confusion
  3. Build verification into .claude/ commands—make testing as easy as a slash command
  4. Avoid sub-agents—they fragment context unnecessarily
  5. Consider the ralph-wiggum technique (shoutout to @GeoffreyHuntley) for bootstrapping new projects quickly

The Bottom Line

Boris’s workflow is sophisticated and battle-tested. But it’s also optimized for a well-resourced team with unlimited compute. Most of us need to be more selective: right model, right task, tight feedback loops, and ruthless about context.

The real win isn’t running more Claudes in parallel. It’s running smarter ones.

Share this post on:
Share this post via WhatsApp Share this post on Facebook Share this post on X Share this post via Telegram Share this post on Pinterest Share this post via email
Previous Post
Follow Your Intuition
Next Post
GraphX: Why I'm Building a Graph-Based Execution Engine in Zig