The Fool's Errand

Fable 5 shipped this week, and the reviews from people I trust all say a version of the same sentence.

It is a big step up, enabling less prompts and steers, more efficient token use, better code quality, more intelligent self-verification, longer running sessions, and higher trust and autonomy.

— Boris Cherny, creator of Claude Code, on launch day

Fewer prompts. Fewer steers. Higher trust. That’s a celebration, and it’s also an obituary. Every “steer” the new model no longer needs was something somebody built: a CLAUDE.md rule, a hook, a review ritual, a prompt tuned around last quarter’s failure mode. All of it just became dead weight.

I’ve been writing around this pattern for a year without ever naming it. Time to name it: the fool’s errand. Any effort you invest in making the current generation of tools more compliant is depreciated by the next release. Not occasionally, as bad luck. Structurally, as the business model.

A Year of Receipts

I didn’t arrive at this from theory. The back catalogue is a graveyard tour, and each headstone is a different mechanism:

• Absorption. BMAD’s 19 agents and Spec-Kit’s staged specs became Plan Mode. Steve Yegge’s Beads became native Tasks. The DIY harness patterns became products. The community builds patterns; the platform productizes them; the scaffold becomes friction.
• Obsolescence. Prompt engineering was a workaround for model limitations that stopped existing. The 200-line rules file you maintain is actively making compliance worse, and the next model reads intent well enough not to need it.
• Regression. Depreciation runs both directions. When quality quietly drops mid-lifecycle, the scaffolds tuned to version N’s quirks break against version N’s worse days, and you spend a week debugging your own workarounds.
• Metering. Opus 4.8 absorbed the self-verification loops people hand-rolled, and then the meter started. The verification moved inside the model, where it bills by the token.
• Sunset. Sometimes nothing absorbs your work; the ground it stands on just closes. Ask anyone who standardized on a vendor CLI with an expiry date.

Five mechanisms, one shape. You are renting compliance from a landlord who renovates every quarter and never asks which walls you’ve hung things on.

The Half-Life Is the Point

When I looked back at a year of Claude Code, the tool had rewritten itself five times while my discipline stayed constant. Every specific technique I’d built had a half-life of two to four months. And a step change like Fable 5 doesn’t just deprecate the marginal tricks; it deprecates whole categories. The multi-pass review loop that justified itself against Opus 4.6’s error rate has to re-justify itself against a model that, by Karpathy’s read, “gets it and will just go.”

And the cycle is already restarting at the top. The people writing elaborate prompt workarounds for Fable 5’s trigger-happy classifiers this week are doing compliance work against a filter Anthropic publicly apologized for and promised to retune. That scaffolding has a half-life measured in days, and they’re building it anyway.

What the Thesis Doesn’t Say

Taken straight, the thesis proves too much. The bounds:

• The work isn’t worthless, it’s perishable. Milk isn’t a bad purchase because it expires. The mistake is cellaring it like wine: polishing, abstracting, and open-sourcing scaffolding as if it were a durable investment.
• Some of it pays forward. The edge cases you found debugging your harness are the spec the native version inherits. Yegge’s Beads “lost” to Tasks and shaped it. Depreciated isn’t the same as uninfluential - it’s just unpaid.
• The discipline transfers even when the technique dies. Clean context, plan before code, small verifiable steps: every tool generation has rewarded those, because they’re about the work, not the model.

So what’s left when every specific advantage expires on a schedule? I’ve quoted John Boyd before; his line lands harder here:

The pilot who goes through the OODA cycle in the shortest time prevails because his opponent is responding to situations that have already changed.

— John Boyd

That’s the fool’s errand in one sentence. Compliance scaffolding is, by definition, a response to a situation that has already changed - you’re engineering around a model that’s already been superseded in a lab somewhere. The durable advantage was never the scaffold. It’s the loop: notice the ground moved, write off what stopped paying, re-orient. The team that re-learns in a week beats the team that perfected last quarter’s workaround. That’s arithmetic, not philosophy.

The Razor

What separates the scaffolding that dies from the scaffolding that survives is one question:

Does this encode the model’s weaknesses, or my system’s requirements?

Compliance scaffolding - rules that say don’t touch this directory, prompts that beg for shorter diffs, loops that triple-check because version N hallucinated - is a cast on the model’s broken arm. The arm heals; the cast becomes the thing limiting movement. It dies with the release, and it should.

Specification scaffolding encodes what “correct” means for your system: tests, types, CI gates, invariants, the deterministic checks that would still be true if the model were a human contractor. The model can improve forever and never make your domain’s definition of correct obsolete. That work compounds.

The simplest way to hold the razor: we care about the built, not the building. How the software comes to exist - the model, the prompts, the steers, the agent choreography - is the layer the vendor owns and rewrites every quarter. The artifact, and the definition of correct it has to satisfy, is the layer you own. Invest where you hold the deed.

Most of what the ecosystem built this year is the first kind dressed as the second. The frameworks, the mega rule files, the agent choreography: compliance work, capitalized. The next release writes it down, the release after writes it off, and the only durable output is the lesson.

Build the cast when the arm is broken. Just don’t tattoo it.