Inside Claude Code: Building for the Model, Not the Moment

Chapter 1 · Narration: WOW Mentor

Inside Claude Code: Building for the Model, Not the Moment

WOW Mentor breaks down the strategy of Boris Cherny, the engineer who turned a terminal chat app nobody asked for into Claude Code and, with it, rewrote how developers work. He built the whole product on three principles — build for the model six months out rather than today's, never bet against the model, and chase latent demand — resting the entire thing on accident and iteration. Keep scaffolding minimal, rules short, and judgment humble, he argues, and simply trace the exponential toward a world where coding becomes a solved problem for everyone.

Today, WOW Mentor breaks down how a tiny terminal program that nobody asked anyone to build ended up rewiring the way developers around the world work. At the center is Boris Cherny, the engineer who first built Claude Code. He admits that when he first built it, in September 2024, he went three straight months without a day off, telling himself: my god, this is going to be a thing — I just don't know if it's useful yet. What WOW Mentor flags first is that even the creator had no certainty about what he was holding: this story begins not with conviction but a hunch, not with a plan but an accident. Looking back, he names two things that still astonish him. One is that we are still using a terminal at all; it was supposed to be the starting point, never the ending point. The other is that the thing became genuinely useful — by his recollection, as late as February the tool wrote maybe ten percent of his code, and he still wrote most of it by hand. And yet he bet on this direction anyway, wagering not on what the model was good at but on what it was about to become good at. This is the advice he still gives founders: at Anthropic they don't build for the model of today — they build for the model six months from now. Find the frontier where the model is weak right now, because it is going to get good at it, and all you have to do is wait. This runs against startup common sense, WOW Mentor notes. Founders are taught to build something that works now and find product-market fit; Boris pushes back that if you find fit against today's model, the next model leapfrogs you in months. He proves it with his own codebase: Claude Code has been written and rewritten over and over, and no part of it was around six months ago — they unship and add tools every couple of weeks, and most of the codebase is only months old. He treats code not as an asset but as something disposable: in a world where the model improves this fast, no UI worth building stays relevant for six months, so they stayed in the CLI. So where did it begin? His account is disarmingly modest. Anthropic's long bet has been coding — the belief that the path to safe superintelligence runs through teaching the model to code, then to use tools, then computers. But nobody told him to build a command-line tool; the team was simply in explore mode. To learn the API, he built a tiny terminal chat app — the terminal because he didn't have to build a UI, and it was just him. Then tool use shipped, and the docs example happened to be a bash tool in Python, so he ported it to TypeScript. And here comes the pivotal scene: he asked the model a throwaway question — what music am I listening to? — and it wrote AppleScript to drive his Mac, dug through his music player, and answered. This was the Sonnet 3.5 days, and he calls it his first-ever "feel the AGI" moment: the realization that this model just wants to use tools — that's all it wants.

WOW Mentor calls that sentence the beating heart of the strategy. Boris did not put the model in a box and say, here is the API, this is how you touch the world; he watched what the model wanted to do and enabled it, the way you would for your users. From that posture comes his single most important product principle, the biggest idea in product he knows: latent demand. It works like this: people will only do a thing they already do. You cannot get them to do a new thing; if they are already trying to do something and you make it easier, that's a good idea, but if you try to make them do something different, they won't. Every piece of Claude Code, he says, was built on latent demand. Two days after the first prototype he handed it to his team, and the next morning the engineer across from him was already coding with it — though Boris still thought of it as just a prototype. CLAUDE.md is itself a product of latent demand: people had started writing markdown files for themselves and having the model read them, and observing that is where the feature came from. He invented features not by imagining what to build but by catching what was already happening. Plan mode is the same — users were already asking Claude to plan but not write code, and the punchline is disarming: all plan mode does is add one sentence to the prompt — please don't code. Here his other key concept, scaffolding, enters. You can wrap code around the model to squeeze out maybe ten to twenty percent more performance, but that gain gets wiped out the moment the next model ships. So the choice is binary: build the scaffolding and rebuild it each time, or wait and let the next model do it for free. On the team's wall hangs a framed copy of Richard Sutton's "The Bitter Lesson": the more general model always beats the more specific one, so never bet against the model. The habit WOW Mentor recommends is to treat every optimization as disposable — a real asset, or a sandcastle the next wave will erase? His CLAUDE.md is the most concrete case. His personal one is exactly two lines: enable automerge on a PR, and post it to the team's stamps channel. Every other instruction lives in the shared CLAUDE.md checked into the codebase, which the whole team contributes to weekly, often by tagging Claude on a PR to fold a preventable mistake into the rules. His advice is counterintuitive: when yours gets too big, don't refine it — delete it and start fresh. The goal is the minimum needed to get the model on track; add a little back only when it drifts, and with every model you add less. Most people over-engineer this, and because capability changes with every model, today's elaborate rulebook becomes tomorrow's shackle. That humility extends to how he sees people. He calls himself an average engineer who uses plain VS Code, not Vim, and every engineer holds their tools differently — which is exactly what makes Claude Code good: you don't have to know Vim or tmux or SSH, you just open it and it guides you. The strong opinions engineers spend years sharpening are often no longer relevant as the model improves, so the skill he values most is thinking scientifically, from first principles. In hiring he asks: when were you wrong? He wants someone who can own a mistake and learn from it — half his own ideas are bad, he admits, and you only find the good ones by trying, shipping to users, and learning. His memory-leak story is emblematic: he dug slowly through a heap dump in DevTools, while another engineer simply asked Claude Code to look — and it wrote a tool for itself to analyze the dump and found the leak faster. He also prizes Daisy, who, asked to add a feature, first gave Claude Code a tool to test arbitrary tools, then had Claude write the feature itself. His team uses the Claude Agent SDK to automate nearly every part of development — code review, security review, issue labeling, shepherding to production.

… The rest of this chapter continues in the full edition, available with a subscription.

Listen to this chapter