When the person who created Claude Code explains how he uses it, the surprise isn't any advanced technique. It's the restraint. Boris Cherny's setup, as he described it on Lenny's Podcast, is almost aggressively minimal: start in plan mode, keep the instruction file short and treat it as a ledger of the model's mistakes, run independent sessions in parallel, and give the agent a way to verify its own work. I've spent months running a production Laravel platform with Claude Code, and my honest take is that Cherny is right about three of these and incomplete about one. The incomplete one is where I'll push back, because my repo has the receipts.
Plan mode first, and why it's the cheapest habit to adopt
Cherny starts most sessions in plan mode: Shift+Tab twice, and Claude reads, asks, and proposes without touching a file. He iterates on the plan until it's solid, then flips to auto-accept and lets it execute. The insight underneath is simple: the model solves problems fast, but not necessarily the right problem, and misalignment caught at the plan stage costs minutes instead of hours.
My version of this predates my hearing the podcast, because I'd converged on it from pain. My project instructions require every non-trivial task to start by stating three things: which domain of the codebase it touches, which existing sibling file it's copying the pattern from, and which concrete commands will verify it. That last one matters most. "Make it work" is not a verify step; php artisan test --filter=SpecificTest is. The interview-style prompt Cherny favors, where you make Claude question you and summarize the task back before writing code, catches the same class of error: wrong assumptions surfacing before they become wrong architecture.
If you adopt one thing from his workflow, adopt this. Planning feels slow precisely when it's saving you the most time.
The short CLAUDE.md, where we agree
Cherny's instruction file philosophy: the file contains only rules that fix recurring mistakes. His team at Anthropic adds a line whenever Claude does something wrong, prunes lines as models improve, and keeps the whole thing around a hundred instructions. It's checked into git and maintained like code.
Here's the part I can confirm from my own repository rather than from a podcast: my project CLAUDE.md is 110 lines, and it got there by exactly the process Cherny describes. Every line is a scar. "composer test runs PHPStan, not PHPUnit" is in there because Claude burned sessions being confused by it. "Use the $casts property, not the casts() method" is in there because the model kept reaching for the newer Laravel idiom in a codebase that standardized on the older one. "Never commit public/hot" is in there because that file once broke a production deploy. None of it is documentation. All of it is correction.
My global file is even smaller, 37 lines, holding only rules true across every project: git conventions, a hard prohibition on writing directly to production databases, security non-negotiables. The scoping discipline matters as much as the length; a rule at the wrong scope actively steers sessions sideways. I've written a fuller breakdown of what belongs in these files in my 50 Claude Code tips guide, but the compressed version is Cherny's version: if a line doesn't fix a mistake the model currently makes, delete it.
Parallel sessions, adopted with a caveat
Cherny runs around five Claude Code instances in his terminal plus another five to ten on the web, each on independent work: one building a feature, one on tests, one investigating a bug. The isolation is the trick. Sessions never share files, so they never conflict.
I run three, not ten, and the constraint isn't hardware, it's review bandwidth. Every parallel session produces output that I must eventually read with full attention, and my attention doesn't parallelize. Three streams keeps the review queue honest. The mechanical setup I use is worktree-based rather than separate clones, which I documented in my git worktrees guide for parallel agents; same isolation property, less disk churn.
One unadvertised benefit of parallel sessions that I can confirm: the fresh-context effect. When a session has been grinding a bug for half an hour, its context is full of failed hypotheses. A clean session pointed at the same bug, with a clean description, solves it disturbingly often. Not because it's smarter. Because it's unburdened.
Verification loops, where I go further than prose
Cherny's principle: give Claude a way to verify its own work, tell it about that method explicitly, and quality jumps. Tests, a browser, a type checker, anything that closes the loop between "code written" and "code correct."
Agreed, and I'd add a hard-won amendment: instructions decay, exit codes don't. My repo enforces the verification contract twice. The prose layer lives in the instruction file: run Pint before finalizing, run the relevant test filter, run PHPStan at level 8. The enforcement layer lives in a git pre-commit hook, wired through core.hooksPath, that runs Pint against staged PHP files and blocks the commit on failure, then runs PHPStan and warns. The hook doesn't care whether the model read the instructions, had them fall out of context, or decided this change was too small to check. It runs anyway.
This is my one real disagreement with the minimal-configuration philosophy. A short CLAUDE.md is correct for guidance, but the non-negotiables shouldn't live in prose at all. They should live in mechanisms: hooks, CI, a permissions allowlist. My settings file pre-approves the exact commands the verify loop needs, php artisan test, vendor/bin/pint, the PHPStan invocation, so the agent can self-verify without a permission prompt interrupting the loop. Configuration that fails closed beats instruction that fails silent, especially on a repo where a push to main auto-deploys.
Betting on the model, the philosophical piece
Cherny's last principle borrows from Sutton's bitter lesson: don't over-engineer scaffolding, because model improvements will obsolete it. Elaborate prompt chains you perfect today become unnecessary in months. Invest in context quality, clean code, good tests, honest naming, instead of prompt cleverness.
I've watched this happen in my own history. Formatting incantations I maintained for older models are dead weight now; the model just writes clean code. What survived every model generation is exactly what Cherny predicts survives: project-specific truths no model can know without being told. My quirks section, my domain conventions, my deploy gotchas. When I catch myself tweaking a prompt for the third time, the question I ask is the one his framework implies: is this a prompt problem or a context problem? It is almost always a context problem.
What I actually changed after studying his workflow
Three concrete changes, honestly reported. I now start a higher share of sessions in plan mode, including small tasks I would previously have free-handed, and the false-start rate dropped noticeably. I audited both instruction files against the "does this fix a current mistake" test and deleted lines I was keeping out of sentimentality. And I turned my most-repeated workflows into slash commands and skills rather than re-typed prompts, which is the systemizing move his approach points toward and which I detail in my daily slash-command workflow.
What I kept from my own way of working: the hook-enforced verification layer, the three-session cap, and a CLAUDE.md that documents quirks a hundred-line generic file never could. The lesson of Cherny's workflow isn't "copy the creator." It's that discipline compounds and configuration doesn't. Plan before building, keep instructions short and true, parallelize only what you can review, and make verification mechanical.
Most of the prompts and interview patterns I mention here, including my planning and verification prompt templates, live in my free prompt library, organized by workflow stage. Steal the ones that fit and prune the rest, which is, fittingly, exactly what Cherny would tell you to do with any instruction file.
