Boris Cherny doesn't prompt Claude anymore.
That's not a viral paraphrase. It's his own, on-the-record statement: "I don't prompt Claude anymore. I have loops running that prompt Claude and figure out what to do. My job is to write loops." He said this across multiple public appearances, a Sequoia talk, an Acquired interview, Y Combinator's Startup School, and the pattern underneath it is the actual subject of this article. Not tips. Not a feature list. The specific way the person who built Claude Code actually uses it, day to day, verified against his own public statements rather than secondhand paraphrase.
This is the complete breakdown, grounded in what Cherny has actually said, plus Anthropic's own documented best practices for the tool he built.
Claude Code Was Never Supposed To Be A Product
Understanding how Cherny uses the tool starts with understanding where it came from, because the origin explains the philosophy, and it's a more interesting story than most people using the tool today realize.
Claude Code began in 2021 as an AI safety alignment research project, not a product. A rough VS Code extension, then an internal CLI tool called clide, used inside Anthropic for years before anyone outside the company had heard of it. Cherny joined the project in September 2024 and rebuilt the core in a two week sprint that December. The public launch in February 2025 landed quietly, without much fanfare, met with more of a shrug than excitement. Then Claude 4 shipped, and adoption exploded almost overnight.
His own assessment of where the tool stands now, stated directly: "We're only 1% done."
That framing matters for how you should approach using it. Cherny is not describing a finished product with a fixed correct usage pattern. He's describing something still being actively rebuilt, by a team using the tool to build the tool. Claude Code has been rewritten repeatedly using Claude Code itself, a loop of self-improvement that predates the term "loop engineering" existing as a phrase anyone used publicly. This is worth sitting with for a moment, because it explains something that confuses a lot of new users: why does the "right" way to use this tool seem to keep shifting. It's not inconsistency. It's a tool whose own creators are still actively discovering what it's actually capable of, in real time, using the tool itself to find out.
The years spent as an internal research tool before ever becoming a product also explains why so much of the philosophy below reads as unusually opinionated for a piece of developer software. Most tools accumulate features to satisfy a broad external user base with competing needs from day one. Claude Code accumulated its philosophy first, inside a small team solving their own problems, before it ever had to satisfy anyone else's workflow. That history is exactly why understanding Cherny's own usage patterns specifically, rather than generic "AI coding tool" advice, is worth the time it takes to actually absorb.
The Core Shift: From Prompting To Designing Loops
The single most important thing Cherny has said publicly about actually using Claude Code is the loops statement above, and it's worth unpacking what it actually means in practice, not just as a quotable line.
A prompt is a single instruction, sent once, answered once. A loop is a system: it prompts Claude, evaluates what came back, decides what happens next, and repeats, without a human sitting in the middle of every single cycle. Cherny's stated job description, "my job is to write loops", means he spends his time designing the systems that generate and evaluate prompts, not typing prompts himself turn by turn.
His confirmed daily workflow reflects this directly. Phone as his primary interface, not a laptop keyboard. Five to ten active sessions running at once, each capable of spawning sub-agents, sometimes a few hundred at once, sometimes a few thousand overnight on deeper work. Dozens of loops running continuously in the background, babysitting pull requests, keeping continuous integration healthy, clustering feedback on a recurring schedule. Routines that persist server-side even when his laptop is closed.
The practical takeaway for anyone using Claude Code day to day: the ceiling on what the tool can do is not set by how good a single prompt is. It's set by how well you design the system around repeated, automated cycles of prompting, checking, and retrying.
What Actually Changed In The System Prompt, And Why It Matters
Cherny has also spoken directly about a specific, technical decision that reveals how he thinks about instructing Claude at all: "We removed ~80% of the Claude Code system prompt for our newest models, this is what we've learned about writing system prompts."
That cut happened specifically with the Opus 4.8 generation, reducing the system prompt from roughly 15,000 characters down to around 4,500, with no measurable loss on coding evaluations. The lesson behind it, according to Anthropic's own context-engineering guidance, is that rigid, exhaustive rule lists stop being necessary once a model is capable enough to exercise real judgment. Rules become judgment calls. Tool usage examples get replaced by interfaces designed to be self-documenting. Upfront, exhaustive context gets replaced by progressive disclosure, information surfaced only when a specific situation actually calls for it, rather than loaded into every single session by default.
One nuance worth including honestly, since it complicates the simple version of this story: when Opus 5 shipped, independent developer testing found its actual system prompt came back roughly 72% longer than Opus 4.8's. That's not a contradiction of the lesson above, it's a deeper version of it. The prompt shrank in rigid instruction volume, then grew again in richer, more specific references, worked examples, test suites, evaluation rubrics, the kind of context a genuinely more capable model can actually make good use of. The takeaway isn't "shorter is always better." It's that instruction volume should track what the specific model actually needs to exercise good judgment, not a fixed target in either direction.
Writing A CLAUDE.md The Way Anthropic's Own Teams Do
This connects directly to how you should structure your own project-level instructions, and Anthropic's own official documentation is explicit about the mental model to use: think of Claude as a brilliant but very new employee, with amnesia, who needs explicit instructions.
The practical implications of that framing. Brilliant means you don't need to over-explain general competence, it's already there. New means zero accumulated knowledge about your specific project's history or conventions. Amnesia means every single session starts from scratch, CLAUDE.md is the only thing reliably carrying context forward between sessions.
Anthropic's documented guidance targets keeping this file under 200 lines, with some of the most disciplined teams running as low as 60. The test for whether something belongs in the file: is this genuinely relevant to nearly every session, or only to a narrow, situational slice of work? Universal things, build commands, non-negotiable style rules, testing expectations, genuine guardrails, belong in the root file. Anything narrower belongs in an imported file, pulled into context only when a session's specific work actually calls for it, using the @path/to/file import syntax the tool supports directly.
For instructions that genuinely cannot be skipped, Anthropic's own internal practice uses explicit emphasis markers, "IMPORTANT" or "YOU MUST", reserved specifically for the handful of rules where the cost of Claude missing them is genuinely high. Marking everything this way defeats the purpose entirely, since it stops functioning as a signal the moment it's applied indiscriminately.
Plan Mode: Understanding Before Acting
A specific behavioral pattern worth building into how you actually work the tool: getting Claude to plan before it executes, rather than jumping straight into changes.
This isn't just a feature toggle, it reflects a real shift Anthropic's own materials describe: newer models plan correctly without needing heavy upfront steering the way earlier ones did, to the point that some teams have reported no longer needing to force an explicit plan mode step for every task, because the model's own default reasoning already produces a coherent plan before acting. That said, for genuinely complex, multi-file changes, explicitly requesting a plan first, and reviewing it before approving execution, remains a meaningfully useful checkpoint, catching a misunderstood requirement before it propagates through a dozen file edits rather than after.
Sub-Agents And Parallel Work
Cherny's confirmed workflow of running hundreds, sometimes thousands, of sub-agents in a single session points to a structural capability worth understanding and using deliberately rather than accidentally.
A main agent can decompose a complex task into smaller pieces and deploy sub-agents to execute them independently, each working in its own context rather than all of it competing for space in one continuous conversation. This serves two purposes at once. It lets work that would overflow a single context window run across many smaller ones instead. And it adds a real verification layer, since a sub-agent reviewing another agent's output is checking work it did not itself produce, which is structurally more reliable than an agent grading its own homework in the same breath that produced it.
For parallel work specifically, git worktrees let multiple sessions operate on separate branches or directories simultaneously without one session's in-progress changes disrupting another's. This is the mechanical infrastructure underneath running many concurrent loops the way Cherny describes doing personally, not a single agent working faster, but many agents working on genuinely separate pieces of work at the same time.
The Grep Decision: A Case Study In Simplicity Over Cleverness
One specific, well-documented technical decision from Cherny's own team illustrates a broader philosophy worth internalizing. Claude Code dropped vector search and embeddings for codebase search in favor of plain grep and glob. His own words on the result: "outperformed everything. By a lot."
The lesson generalizes past this one specific decision. A more sophisticated-sounding solution, semantic vector search, is not automatically better than a simpler one, grep, if the simpler one is actually well matched to the problem. Codebases have exact syntax, exact function names, exact import paths, the kind of precise, literal matching that grep excels at and that a fuzzy semantic match can actually undermine by surfacing plausible-but-wrong results.
The practical takeaway for how you configure your own workflows: don't default to the more complex-sounding tool or architecture out of an assumption that complexity implies capability. Test the simple option against your actual use case first. Often it wins, and even when it doesn't, you've confirmed the more complex approach earns its place rather than assumed it.
Never Let An Agent Grade Its Own Work
A separate, confirmed principle from Anthropic's own harness engineering practice, directly relevant to how you should structure any verification step in your own Claude Code workflows: generation and evaluation should happen in genuinely separate roles, because a model reviewing its own output in the same breath that produced it tends to skew positive, even when a human reviewer would immediately spot the flaw.
Practically, this means the agent that writes code should not be the same pass that decides whether that code is good enough to ship. A separate evaluation step, ideally with access to something the generating agent didn't have, the actual test suite output, the original requirements document, catches what self-assessment misses. This is the same principle behind the sub-agent verification pattern above, applied as a general discipline rather than a specific feature.
Effort And Context Management
For anyone running longer, more demanding sessions, understanding how to signal effort level directly matters. Including "ultrathink" in a prompt signals maximum reasoning depth for that specific response without changing broader session settings. For session-level automatic workflow orchestration, setting the effort level to its highest tier combines deep reasoning with automatic task decomposition across a session, though this requires a model that actually supports that effort tier, not every model in a given lineup does.
Context management itself deserves deliberate attention on long sessions. As a session runs longer, accumulated context can start diluting the signal of what actually matters right now, the same problem that bloated CLAUDE.md files create, just happening dynamically within a single conversation rather than statically in a file. Periodically starting a fresh session for a genuinely new phase of work, rather than extending one conversation indefinitely, is a real, practical discipline worth applying rather than assuming more context is always strictly better.
A Worked Example: Applying This To A Real Task
To make all of the above concrete rather than abstract, here's how these principles actually combine on a real, common task, adding a new feature to an existing codebase with reasonable complexity, a few interconnected files, some existing tests, a non-trivial but not exotic change.
Start with the CLAUDE.md already in place, short, universal, the build and test commands, the non-negotiable style rules, nothing situational cluttering it. This means the session starts with real, relevant context loaded automatically, without you re-explaining your project's conventions from scratch.
Rather than writing a single, long, hopeful prompt describing the entire feature in exhaustive detail, describe the goal and let the model's own planning handle decomposition, trusting the reduced-scaffolding philosophy from the system prompt discussion above. For a task this size, explicitly requesting a plan first is worth the extra step, since a misunderstood requirement caught here costs a two minute correction instead of an hour of unwinding changes across multiple files later.
Once the plan looks right, let execution proceed. If the task naturally splits into genuinely independent pieces, updating a data model and separately updating the UI that consumes it, for instance, that's a natural candidate for sub-agent decomposition, each piece working in its own context rather than all of it crowding a single continuous conversation.
Before treating the result as done, run a separate verification pass rather than trusting the implementing agent's own self-report that everything works. This can be as simple as a fresh session, or a sub-agent with read-only access, checking the actual test output and the diff against the original plan, not just accepting a confident "this is complete" from the same context that wrote the code.
Notice what's absent from this walkthrough. No exotic tooling. No unusual configuration. Just the ordinary application of plan-first for genuinely complex work, sub-agent decomposition for genuinely independent pieces, and separated verification instead of self-assessment, the same three principles running through everything above, applied to one concrete task instead of described abstractly.
Scaling This Beyond A Single Person
Everything above describes practices for one person using Claude Code deliberately. Cherny's own confirmed workflow, hundreds of sub-agents daily, thousands overnight, is itself already a form of scaling, one person directing a genuinely large amount of parallel, automated work. But the same principles extend to a team adopting these practices together, with a few specific considerations worth naming directly.
CLAUDE.md stops being a personal preference file the moment more than one person on a team is actually working against the same codebase with Claude Code. Treat changes to it with the same review discipline you'd apply to any shared configuration affecting the whole team's workflow. A teammate adding a one-off "hotfix" instruction after a single frustrating session, without review, is exactly the mechanism that produces the bloated, self-contradicting files that stop actually being followed reliably. A lightweight review step, even just a second person glancing at the diff before it merges, catches a meaningful share of this before it accumulates into a genuine problem.
The verification discipline matters even more at team scale than it does for a solo user. When one person is both writing and reviewing their own agent-assisted work, there's at least a chance they'll personally catch something the agent missed. When a team is relying on Claude Code output flowing through a shared review process, the separated-evaluation principle from earlier isn't optional anymore, it's the actual mechanism protecting the codebase from an agent's confident but wrong self-assessment reaching production, since the alternative is trusting that some human, at some point in a busy team's workflow, happens to catch what the agent didn't flag itself.
Worth establishing explicit ownership over periodic CLAUDE.md audits too, the same maintenance discipline recommended for any shared, accumulating document. Without a clearly assigned owner, this work tends to fall through the cracks precisely because it doesn't block any single immediate task the way a broken build does, and six months of unowned additions produces exactly the kind of bloated, contradictory file the universal-applicability principle exists to prevent in the first place.
Where People Misapply These Principles
A handful of specific misreadings of the ideas above show up repeatedly, worth naming directly since each has a simple, specific correction.
Treating "loops over prompts" as license to skip understanding the task entirely. Cherny's own statement is that his job is to write loops, not that he stopped thinking about what those loops should actually do. Designing a good loop, a good definition of success, a good stop condition, still requires understanding the problem as clearly as writing a good single prompt would. The loop replaces the repeated manual typing, not the upfront thinking.
Reading the system prompt reduction as "give the model less context, always." The Opus 5 counterexample earlier in this article exists specifically to correct this misreading. The actual lesson is that instruction volume should match what a specific model genuinely needs to exercise good judgment, which sometimes means less rigid rule-listing and sometimes means more rich, specific reference material. Cutting context indiscriminately because "the newest models need less" misapplies a nuanced, model-specific finding as a blanket rule.
Over-decomposing simple tasks into sub-agents out of habit. Sub-agent decomposition earns its complexity on genuinely large, genuinely independent pieces of work. Splitting a small, tightly coupled change into artificial sub-agent pieces just to use the pattern adds coordination overhead without the benefit that justifies it on larger tasks. The worked example earlier in this article deliberately used sub-agents only where the pieces were naturally independent, not as a default for every task regardless of size.
Skipping verification on the assumption that "the newer models don't need it anymore." The separated-evaluation principle isn't a workaround for weaker models that will become unnecessary as capability improves. It's a structural fact about self-assessment, a model checking its own work in the same context that produced it will always have a harder time catching its own blind spots than an independent check would, regardless of how capable that underlying model becomes. This is true of human reviewers too, and it doesn't stop being true just because the reviewer gets smarter.
The Actual Daily Habits Worth Adopting
Pulling everything above into a concrete, practical daily practice, here's what actually following Cherny's demonstrated approach looks like.
Stop treating every task as a single prompt to get right on the first try. Design a loop instead: an agent that attempts the task, a way to check whether the attempt succeeded, and a defined path for what happens next depending on that check, pass, retry, or escalate to you directly.
Keep your CLAUDE.md short and treat it as onboarding material for a capable but context-free new hire, not a comprehensive manual. Move anything situational into imported files rather than bloating the root document.
Use plan mode deliberately on genuinely complex, multi-file work, and trust the model's own default planning on simpler, well-scoped tasks rather than forcing an extra step everywhere out of habit.
Decompose large tasks into sub-agents working in separate contexts rather than trying to hold an entire complex task in one continuous conversation. Use a separate pass to verify significant work rather than trusting a single agent's self-assessment.
Default to the simplest tool that could plausibly solve your specific problem, the way grep beat vector search for this exact use case, and only reach for more complexity once the simple option has actually been tested and found wanting.
Build real parallelism into your workflow using git worktrees for genuinely independent pieces of work, rather than running everything through one sequential session because that's the default way of working.
Where This Is Actually Heading
Cherny's own "we're only 1% done" framing is worth taking seriously as a practical statement, not just a humble-sounding line. The specific patterns described above, loop design over single prompting, aggressive system prompt pruning as models get more capable, sub-agent decomposition, separated verification, are not a fixed, final methodology. They're the current state of a tool and a practice that its own creator describes as still early.
The actual skill worth building isn't memorizing today's specific configuration of best practices. It's understanding the underlying principles well enough to keep adapting as the tool itself keeps changing, the same way Cherny's own team rebuilt Claude Code repeatedly using Claude Code, refining the loop rather than treating any single version of it as finished.
That's the real throughline connecting everything in this article. Not a static list of tips, but a working philosophy: design systems instead of typing single instructions, keep instructions lean and let model capability do more of the work as it improves, verify independently rather than trusting self-assessment, and default to simplicity until complexity actually proves itself necessary. Straight from how the person who built the tool actually uses it himself.
Follow @cyrilXBT for more Claude Code breakdowns grounded in verified, on-the-record material.
