Scaffolding is tech debt against the next model — the bitter lesson applied to product building

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: Model compensations become liabilities as capabilities advance — yesterday's fixes hobble today's agent — they find 5+ once-necessary, now-harmful workarounds per week. 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.