Erika Flowers wrote something this week that I think is the best articulation I've read of why building things you know will be obsolete is the point, not the problem.
Second Rodeos opens with Arthur C. Clarke's The Songs of Distant Earth — the colony ships that launched first with the best available engines, crawled across interstellar space for generations, only to be nearly caught by later ships with vastly superior propulsion. Clarke meant it as a quiet tragedy. Flowers reads it as a model for frontier sacrifice.
Her argument: the early colonists carried something the fast ships didn't. They knew the terrain. They'd mapped it, argued about it, lived with it for the entire journey. The fast ships arrived with better engines and no knowledge of the ground.
I've been running a version of this experiment for the past four months. Hyperdella has 323 commits since December, roughly 96% co-authored with Claude Code. The CLAUDE.md conventions, the skill files, the LEARNINGS.md patterns, the eval-first architecture — none of it is permanent. Most of it will be obsolete within a year. Some of it already is. That's the point.
Flowers calls the tools "disposable whetstones" — you use the stones to sharpen the blade of your mind, then discard them. The edge is you, not the tool. I've been calling it the QT-1 methodology, after Asimov's robot in Reason who runs the solar station perfectly despite having a completely wrong model of reality. Give it a job, not a ruleset. The job persists. The ruleset is always temporary.
She draws a distinction I want to steal: the "blastoff inch" versus the "planetfall inch." Off by an inch at blastoff, you miss your target by a galaxy. Off by an inch at planetfall, that's a Tuesday. The upstream decisions — who is this for, what problem does it solve, should this thing exist at all — those are blastoff inches. Which framework, which model, which deployment pipeline — those are planetfall inches. Correctable. Ephemeral. Not strategy.
This maps directly onto something I've been formalising as eval-first architecture: define what success looks like before you build. Because when implementation is nearly free, getting the what wrong at speed just means arriving at the wrong planet faster than anyone has ever arrived at the wrong planet before.
The most dangerous version of this mistake is the tutorial economy she describes — the ouroboros of currency masquerading as education. Learn this framework. Master this model. Forty-seven tips for prompting. The content has a shelf life of six weeks, which means you need another round in six weeks, which means the cycle is self-sustaining and the learner never arrives. I recognise this. I've been in it. The only exit is to stop treating the tools as the destination and start treating them as what they are: scaffolding you climb and then discard.
The technology is the variable. The human is the constant. Build for the constant.
That's the line that lands hardest, and it's the one I keep coming back to in my own work. A home energy dashboard doesn't survive because of which inverter API it talks to — that will change. It survives because the problem it solves (making energy decisions legible to a household that doesn't want to become an energy engineer) is a human constant. A property management tool doesn't survive because of its stack. It survives because self-managing landlords will always need someone who's mapped the terrain.
Read the whole piece. It's the best thing I've read this month on what it actually means to build at the frontier, and why the scar tissue matters more than the ship.
— David