A few weeks ago, Boris Cherny, the engineer who built Claude Code, posted a thread on X listing how he and the team actually use the tool they made.
I read it twice. First pass: quick, nodding along, bookmarking it mentally. Second pass: slower, with a Notes app open, circling the things that made me feel either validated or embarrassed I hadn't thought of them yet.
Boris is clear upfront: there's no one right way to use Claude Code. What he's sharing is how his team uses it, not how you must. But if you've been using Claude Code seriously for a while, reading a list of tips from the person who built it has a particular texture. Some things land like "yes, obviously." Some land like "oh, that's what's been missing."
This is my honest reaction to the thread, not a summary, not a tutorial. Just what I actually think about each tip, from someone who uses this tool daily.
The three tips I was already living (and why they work)
Plan mode first, always
This one I do every single time now. Part 2 of this series goes deep on hooks, but plan mode is the thing underneath all of it.
The shift is subtle and then suddenly enormous: instead of treating Claude Code like a fast typist who should get started immediately, you treat it like a collaborator you're briefing before any work begins. You spend real time on the plan. You ask Claude to push back on your assumptions. You get it to surface edge cases before a single line of code changes.
Boris adds a detail here I'd missed entirely: one engineer on his team has one Claude write the plan, then spins up a second Claude instance to review that plan as a staff engineer. Two-pass planning with independent perspectives. I've been doing single-pass, trusting the first draft of the plan. That changes now.
The other piece that resonated: "the moment something goes sideways, switch back to plan mode." I've pushed through too many times when the right move was to stop, reset the context, and re-plan. Boris names the exit ramp. That's useful.
CLAUDE.md as a living feedback loop
If you read Part 1 of this series, you know I think CLAUDE.md is the single most leveraged thing you can do in Claude Code. Boris agrees. But his framing of how to maintain it is better than anything I'd articulated.
After every correction: "Update your CLAUDE.md so you don't make that mistake again."
I was adding rules manually, copying a correction into the file, cleaning it up. This is different. You ask Claude to write its own rules. And it turns out Claude is eerily good at this. It doesn't just log the specific mistake; it generalizes. It writes a rule that prevents the class of error, not just the instance. The rule it writes is usually more precise than the one I would have written.
Boris also says to ruthlessly edit CLAUDE.md over time, iterating until Claude's mistake rate measurably drops. That's the right mental model. CLAUDE.md is a feedback loop, not a config file you set once.
Create skills and commit them to git
This is Part 4 of this series. I won't re-explain it here, except to say: yes, always, the moment you do something twice.
Boris's specific example: a /techdebt slash command that runs at the end of every session to find and kill duplicated code. I don't have that exact skill, but I have the same instinct: any workflow you're running manually is a workflow Claude Code should own.
The git commitment part matters more than it sounds. Skills committed to the repo travel with the project. Every collaborator who clones it inherits your workflows. That's not just personal productivity; it's how you standardize an agentic development environment across a team.
The one that stopped me: parallel worktrees
Boris calls this "the single biggest productivity unlock": three to five git worktrees running simultaneously, each with its own Claude session in parallel.
I'll be honest: I don't do this.
I run one Claude Code session at a time, occasionally with a second terminal open for reference. I've read about worktrees. I understand the theory. But I haven't built the habit, and I haven't set up the tooling.
What makes Boris's description compelling is the specificity. Some people on his team use shell aliases (za, zb, zc) to hop between worktrees in a single keystroke. Others dedicate a permanent "analysis" worktree exclusively for reading logs and running queries, never for implementation. That's not just opening more windows. That's a real architecture for parallel thinking.
The reason I haven't done this: context switching costs. When I'm deep in a session, I've been afraid that switching to another worktree breaks my mental state. But that's the wrong frame. Each worktree is a separate Claude session with separate context; I don't need to hold both in my head simultaneously. The human can be reviewing output in one while the other runs.
This is the tip I'm setting up this week.
The tips I haven't tried (and what I think about them)
Subagents for context management
Boris recommends appending "use subagents" casually to any request where you want Claude to throw more compute at the problem. What I hadn't considered: offloading individual tasks to subagents specifically to keep the main agent's context window clean. I've used subagents through skills, but I'd been thinking of them as parallelism tools. Using them as a context hygiene strategy (keeping the orchestrating agent lean so it stays coherent) is a different instinct, and probably the more useful one over a long session.
Routing permission requests to Opus via a hook
Boris mentions routing permission prompts to Opus via a hook, which scans them for attacks and auto-approves the safe ones. I covered hooks in Part 2 and this is probably the most complete real-world hook use case I've seen. You get a security review and less friction at the same time. If you've already built a hooks setup, this is where it goes next.
The Slack MCP "just say fix" workflow
Enable the Slack MCP. Paste a Slack bug thread into Claude. Type "fix." No context switching, no manual reproduction steps, no reformatting into a ticket. It works because the bug report already has what Claude needs: the error, the environment details, the thread context from whoever reported it. I don't have the Slack MCP configured yet. This is the reason to.
BigQuery and analytics via CLI
"I haven't written a line of SQL in 6+ months" is the most Boris thing in the thread. His team has a BigQuery skill committed to the codebase that everyone uses for analytics queries directly in Claude Code. The part that generalizes: any database with a CLI, MCP, or API works the same way. I keep meaning to set this up for Supabase, not because it's interesting to build but because the context switch it removes is one I make five times a day.
The learning configurations
Boris mentions enabling an "Explanatory" or "Learning" output style in /config so Claude walks through the why behind its changes, building HTML presentations for unfamiliar code, drawing ASCII diagrams of new codebases. I tend to ask Claude one-off questions rather than configuring a learning mode, but the spaced-repetition skill he describes at the end of the thread is different: you explain your understanding, Claude asks follow-ups to find the gaps, stores the result. That's an actual system. I'm going to try it on the next codebase I'm onboarding to.
The prompting tip that shifted something
Boris's tip 6 is about prompting, with three sub-points. Two I'd absorbed from other places. This one I hadn't seen framed quite this way:
"After a mediocre fix: 'Knowing everything you know now, scrap this and implement the elegant solution.'"
What I'd been doing: asking Claude to improve or revise the fix. What that produces is an iteration on the mediocre thing, better but built on the same assumptions, the same structural choices, the same approach that led to mediocre in the first place.
What Boris is describing: giving Claude explicit permission to throw out its own work and start over with full diagnostic context. The output isn't an improvement; it's a different solution that happens to be informed by everything the first attempt revealed.
I've used this phrasing three times since reading the thread. Each time, the second implementation was architecturally cleaner than whatever iteration path we'd been on. It's in my rotation now.
What I'd add that Boris didn't say
Boris's list skews toward a team of engineers building software full-time. A few of his highest-friction tips (Slack MCP, parallel worktrees, the BigQuery skill) assume infrastructure that solo developers and freelancers build incrementally, not all at once.
Two things that matter for my context that didn't make his list:
Before starting any new feature in a client project, I point Claude at the relevant files and ask for a plain-English architecture summary. That two-minute pass surfaces assumptions that would otherwise cost 40 minutes of confused edits. Not a Boris-level tip, more basic, but it's the habit I most consistently tell other solo developers to build first.
The other one: name your sessions. Boris mentions naming terminal tabs and worktrees. I'd go further: use remote control (from Part 3) to name running sessions with something readable. When you step away from three parallel tasks and come back, client-auth-refactor, design-system-tokens, and invoice-automation are not the same as three unnamed terminal windows.
Where to start if you're taking one thing from this list
Not parallel worktrees. Not the Slack MCP. Both of those require setup.
Start with the closing ritual from tip 3. After your next correction (any correction), end the message with: "Update your CLAUDE.md so you don't make that mistake again."
That single habit starts a feedback loop that compounds. Everything else Boris describes (skills, plan mode, parallel sessions) works better on top of a CLAUDE.md that's been actively maintained through real use. Boris built this tool. He knows what the foundation is.
This is a bonus installment in the Claude Code Power User series. The foundation pieces:
