Boris Cherny on How to Use Claude Code Correctly

There's a particular kind of authority that comes from being the person who built the thing. When Boris Cherny, the creator of Claude Code, sits down to explain how developers should be using his tool, the implicit message is hard to ignore: you're probably doing it wrong, and I know because I wrote it.

That framing deserves some scrutiny — and I'll get to it — but first, the substance. AI LABS, a YouTube channel covering AI workflows for software teams, recently broke down Cherny's approach in a video titled Claude Code Creator's Greatest Tip For Using AI Agents. It's a useful synthesis of ideas that a lot of developers haven't fully absorbed yet, and some of those ideas are genuinely worth sitting with.

The configuration debt problem

The central insight Cherny offers is almost embarrassingly simple: your Claude Code setup is probably haunted by the ghost of a less capable model. Every instruction you ever added to steer Claude around a limitation — every compensating rule, every workaround baked into your claude.md — was written for a model that no longer exists.

When Opus 5 shipped, Anthropic reportedly deleted roughly 80% of Claude Code's own internal system prompt. That's a signal worth taking seriously. The AI LABS video uses a crisp test for deciding what to keep: would Claude have worked this out on its own? If the answer is yes, the line is dead weight. The safe mode feature strips your entire custom configuration and leaves you running on the base model — useful for seeing what you're actually paying for in context and what's just friction you've accumulated.

This argument about configuration bloat has been gaining traction beyond Cherny's interview. Research has been pointing in the same direction: the elaborate scaffolding that developers built when models needed hand-holding has become a liability now that models mostly don't. Emerging evidence suggests those Agent.md and Claude.md files that the community spent months optimizing may actively degrade performance on current-generation models.

The question worth asking, though, is who gets to declare when the hand-holding is over. When the tool's creator is the one making that call, there's an obvious alignment of interest. "Delete your old workarounds" is also a way of saying "trust the model more" — which is a message Anthropic has every incentive to promote. That's not a reason to dismiss it. It's a reason to test it empirically before trusting it wholesale, which is exactly what safe mode lets you do.

The eval problem, which is actually the "done" problem

Cherny identifies evaluations — evals — as the single most misunderstood piece of agent-based workflows. The AI LABS video captures his framing precisely: "A check you can't fail isn't a check."

This is test-driven development applied to agent tasks, and it's correct. The reason agents drift, loop, or produce plausible-but-wrong output is usually that they lack a hard termination condition. Cherny's own example is instructive: he gave Claude an empty codebase and tasked it with rewriting the Claude desktop app in Swift. The agent ran a virtual Mac, took screenshots of the original app, compared them pixel-by-pixel against its own version, and continued iterating until the comparison passed. That ran for over two weeks. The pixel comparison is what made sustained autonomous work possible — not the model's capabilities alone, but the model having a concrete, binary way to answer the question am I done?

What this means in practice is that evals are a form of labor that currently falls entirely on the developer. The model can execute; you have to define what success looks like, in terms specific enough to fail. That's a non-trivial burden, and it's one that scales poorly for solo developers or small teams who don't have the time to write proper evaluation suites before building the thing they're trying to build.

Cherny acknowledges that evals have a shelf life too. "Boris says they last two or three model generations, then everything starts passing," the AI LABS video notes, "and you need to throw the set out and write different ones from wherever it's struggling now." The Sisyphean quality of this is, I think, underappreciated.

Prompting: the expert trap

The counterintuitive claim in the video that will annoy the most people is this: "Boris says experienced engineers are the worst at this." This being high-level prompting — describing what you want rather than specifying how to get it.

The instinct to specify implementation is deeply wired in anyone who has spent years debugging other people's code. You've seen what happens when you leave a gap. You've cleaned up the mess. So you fill the gaps preemptively, and in doing so, you cap the model's solution space at your own best approach.

The concrete version Cherny offers is the inspiration image problem. Hand an agent an image and tell it to build a UI inspired by that design. What you get is a near copy — the model treats concrete artifacts as things to reproduce rather than learn from. Describe the aesthetic instead, and it has to synthesize an approach. Same task, structurally different output.

This principle extends beyond design. It's about the difference between delegating a task and delegating a method. The former scales; the latter doesn't.

The Bun rewrite, and who this is actually for

This is where I have to be direct about something the AI LABS video treats as a cautionary tale but doesn't fully reckon with.

The canonical demonstration of Claude Code's dynamic multi-agent workflow capabilities — the one Anthropic itself points to — is the rewrite of Bun, the JavaScript runtime, which involved rebuilding roughly a million lines of code in under two weeks using a swarm of coordinated agents. According to reporting from Simon Willison, that rewrite cost approximately $165,000 in API fees.

One hundred and sixty-five thousand dollars.

The AI LABS video flags this as a reason to avoid dynamic workflows in favor of simpler "routines" — recurring, single-sentence cloud jobs that handle maintenance tasks. That's sensible practical advice. But it sidesteps the more interesting question: what does it mean that the paradigmatic example of this approach required Anthropic's resources to attempt?

The developer community is not homogeneous. The norms being set here — what "correct" Claude Code usage looks like, which patterns count as best practice — are being demonstrated at a scale that most independent developers, open source maintainers, and small engineering teams simply cannot access. The Bun rewrite isn't a tutorial. It's a proof of concept that happens to have a price tag that would represent months of runway for a typical funded startup.

I'm not saying Cherny's advice is wrong. I'm saying the implicit frame — that this is how a software company runs AI coding — deserves more scrutiny than it usually gets. Governance questions in open source communities are always partly questions about who gets to define the defaults, and right now, those defaults are being defined by the company that both builds the tool and has essentially unlimited API budget to demonstrate its potential.

The hierarchy that actually matters

The practical framework Cherny offers for what goes where is the most durably useful part of the whole breakdown. The AI LABS video lays it out as a cost hierarchy: fix the prompt first (free), add it to claude.md if the model needs it every session, promote it to a skill file if you're explaining it repeatedly, and reach for an MCP server only when the information is genuinely inaccessible.

The claude.md versus skills distinction is worth understanding clearly. Your claude.md loads on every session start; a skill file loads only when Claude actually needs it. The same instruction costs you every single turn if it lives in claude.md and nothing if it lives in a skill that claude.md points to. This is a context window efficiency question as much as anything else — dead configuration doesn't just slow you down conceptually, it consumes capacity on every turn.

MCP servers sit at the expensive end of that hierarchy not because they're hard to build, but because they're often the wrong tool. The video is explicit: MCP is for when there's genuinely no other way for the model to access information, not for when it misunderstood you or when you keep repeating yourself. That distinction matters for teams that have been reaching for MCP solutions prematurely.

What I keep coming back to is the meta-dynamic here. Cherny is Claude Code's creator. His guidance is valuable and largely correct. But "correct according to whom" is always the right question to ask when the person setting the norms is also the person who built the tool, works at the company that trains the model, and has access to infrastructure that operates at a completely different order of magnitude than most of the developers they're advising.

The best developer communities push back on this kind of authority — politely, empirically, with pull requests and forum threads and "actually I tested that and found..." The question is whether Claude Code's community is mature enough yet to do that productively, or whether we're still in the phase where the creator's word travels unchallenged because the tool is too new and too complex for anyone else to have equivalent standing.

That's the moment I'm watching for.

Dev Kapoor is Buzzrag's Open Source & Developer Communities Correspondent.