The Claude Code team has a framed copy of Rich Sutton’s “The Bitter Lesson” on the wall. Boris Cherny calls all non-model code “scaffolding” and describes a constant trade-off: “Engineering work now to extend capability maybe 10-20% in whatever domain, or you just wait for the next model.”
The practical consequence is radical: “There is no part of Claude Code that was around six months ago. It’s just constantly rewritten.” The team unships tools every couple weeks and adds new tools every couple weeks. This isn’t technical debt in the traditional sense — it’s intentional impermanence. The UI stayed as a CLI specifically because “we felt there is no UI we could build that would still be relevant in 6 months because the model was improving so quickly.”
The same pattern appeared with verbose output. Boris tried hiding file reads and searches, but couldn’t ship it six months earlier because the model wasn’t ready — “it would have read the wrong thing pretty often.” The feature only worked when the model improved enough to be “on the right track almost every time.” The scaffolding (showing file reads) was necessary until the model made it unnecessary. This connects to Tool design is continuous observation — see like an agent — tools designed for weaker models constrain stronger ones, and Build for the model six months from now, not the model of today — if you accept scaffolding’s shelf life, you invest only where the model genuinely can’t reach yet.
Boris’s CLAUDE.md philosophy embodies this: “Delete your CLAUDE.md and just start fresh. The capability changes with every model. Do the minimal possible thing in order to get the model on track.” This reinforces CLAUDE.md should be a routing table, not a knowledge base — minimalism isn’t just a preference, it’s a survival strategy against model capability turnover. Hex’s production experience confirms this at scale — they find 5+ once-necessary, now-harmful workarounds per week (details below). And the Sand vs Stone — if models double in capability tomorrow, what washes away and what remains? framework makes this actionable: scaffolding is definitionally sand.
Jaya Gupta gives this an investor’s edge: the developer tooling that looked durable — “retrieval pipelines, output parsers, and prompt scaffolds were prosthetics for model weaknesses” — got swallowed as capability advanced, and “gains don’t lift every application equally; they move the bottleneck.” That bottleneck-relocation is why scaffolding decays unevenly rather than uniformly, a direct consequence of AI strategy is a self-rewriting equation — solving one constraint changes which constraint matters next, and the mechanism by which In AI the threat is layer migration, not a competitor — work relocates across layers when any variable moves — a capability gain migrates your scaffolding’s function straight into the model.
Thariq Shihipar’s account of Claude Code’s own system prompt gives the anatomy of this decay inside prompt design specifically: a prompt full of examples and “do not do this” guardrails was necessary for a weaker model, then Claude Code “removed 80% of the system prompt” once those same examples started constraining a model “more imaginative than the examples we give it.” The scaffolding here isn’t code at all — it’s the accumulated caution baked into the prompt — but it decays on exactly the same schedule.
Hold this against A better model makes your library worth more, not obsolete — a smarter reader extracts more from the same books, which argues the opposite direction for a different artifact — the tension is deliberate. Garry Tan takes the bitter-lesson objection head on and answers that “the better the models get, the more the differentiator moves to context,” so each release is “a free upgrade to a workforce I already own.” Both can hold at once, and the discriminator is what the artifact is made of: scaffolding is code written to patch a capability the model lacks, so it is a bet against the next release and dies when the release lands; an accumulated private library bets on nothing about the model and appreciates when the reader gets smarter. The usable test on any artifact is whether a model twice as capable would delete it or make it more valuable.
Hex’s figures come from Izzy Miller (@izzymiller — “Building AI Agents for Data Analytics”, sources/izzymiller-hex-building-ai-agents-data.md): “A remarkable amount of things that at one point we felt very proud of building and were in fact necessary are now hobbling the agent.” The concrete case is a complex ID-mapping/reference-registry system built because earlier models hallucinated cell IDs in notebooks with 50+ cells. Current models don’t need it, but the compensation code still introduces bugs, complexity and behavioral constraints that actively degrade the agent. At 5+ examples a week, auditing past compensations is a continuous maintenance task, not a one-time cleanup — Build for the model six months from now, not the model of today also means removing what you built for the model of six months ago.
Thariq’s account of the prompt (Thariq Shihipar — “A Field Guide to Fable”, sources/thariq-field-guide-to-fable.md) traces the full arc: “originally… the best practice for a system prompt was a small system prompt, few tools, and lots of examples”; as models got smarter the prompt grew; then “most recently, we found this new class of models want a smaller system prompt. The examples tend to constrain it because it’s actually more imaginative than the examples we give it.” The mechanism is that examples don’t just teach, they implicitly cap — they communicate “the space of acceptable outputs looks like these,” and a sufficiently capable model reads that as a boundary rather than a floor. The diagnostic: before writing another “do not do X” clause, ask whether you’re guarding against a limitation the current model generation has already outgrown.