Buoyancy

Every few months a new AI model comes out, and each time, the same event has opposite effects on different products. Some get better the moment the model ships — no one touches a line of code. Others get worse. Their prompt chains misfire, their workarounds start working around problems that no longer exist, and features that took months to build turn into things the model simply does.

The property that separates them needs a name. I call it buoyancy. Buoyant software rises with model improvements the way a boat rises with the tide. It gets better every time the models do, without even trying.

Why would one event help some products and hurt others? Look at where the model sits. An AI product is a model plus everything built around it, and everything around the model is there for one of two reasons: to connect it to the problem — context in, results out, users to the door — or to compensate for something it can't do yet. Call the first kind plumbing and the second scaffolding.

When the model improves, plumbing appreciates: the same pipes now carry something smarter. Scaffolding depreciates, because it was a workaround for a weakness, and the weakness is what just improved. Often it doesn't stop at zero: prompts tuned to one model's quirks misfire on the next, and you end up paying engineers to remove what you paid them to build. So buoyancy is mostly a question of proportions. A product that's mostly plumbing floats. One that's mostly scaffolding is anchored to the model it was built for.

The strange thing is that non-buoyant products are usually built by good engineers — partly because they're good. Ordinary software teaches you to handle the edge cases, add the guardrails, harden the system. And ordinarily that's right, because the platform holds still. A CPU never wakes up one morning understanding your problem. A model does; that's roughly what a release is. When the platform improves along the very axis your hardening covers, the instinct to harden becomes an instinct to build what the tide will strand.

The mistake, in one sentence: every workaround for a model's weakness is a short position on model progress. So far that's been one of the great losing trades. But people mostly make it unknowingly. Every architecture contains a forecast about models, and the default forecast is stasis: next year's models will be like today's. Under that assumption, elaborate scaffolding is simply good engineering. So non-buoyancy usually isn't an engineering error. It's a forecasting error smuggled inside an engineering decision.

You can see the sediment in any long-lived prompt. Instructions accumulate like scar tissue — each added because some model once misbehaved, none ever removed — until no one knows which parts still do anything. The file is overfit to models that no longer exist.

Sometimes, of course, the model can't do the thing yet, and the choice is scaffold or don't ship. Then you scaffold. The mistake isn't building it; it's believing in it. Scaffolding is a loan against the current model's weaknesses, and a payment comes due at every release. Buoyant teams treat it as disposable: the day a new model ships, they delete code, happily. Non-buoyant teams defend it: it was the hard part to build, so it feels like the valuable part. That's backwards. Whatever was hard because the model was weak is what a stronger model erases. In six months it will feel expensive and unnecessary.

We've been through a rising tide before. For fifty years the winning move in software was to waste machine cycles to save programmer time. High-level languages were a long position on Moore's Law; hand-tuned assembly won benchmarks and lost decades^[1]. Models are the new thing that doubles. Machines used to get faster. Now they get smarter.

The reason to want a word for this is to use it as a question. "Is it buoyant?" is a different question from "is it AI?" The second is about ingredients. The first is about the derivative: as models improve, does the thing get more valuable or less? Two startups can have identical demos and opposite signs.

And the question scales down. Suppose you need a classifier. Boosted trees get you 94%; a prompted model gets you 91%. But you can't teach the trees anything from one bad example, and next year's models do nothing for them. The prompted judge you improve by editing a sentence, and it inherits every future model for free. Ask which is more accurate and you choose the trees. Ask which is buoyant and you choose the judge.

By now an alert reader has an objection. If buoyancy means keeping as little as possible between the model and the problem, doesn't maximal buoyancy mean being a thin wrapper? And thin wrappers are what platform owners absorb. There's even a word for it: in 2002 Apple shipped Sherlock 3, which copied a beloved third-party tool called Watson so thoroughly that "Sherlocked" became the verb for being absorbed by the platform. So it seems the tide that lifts you can also dissolve you.

This is where it pays to take the metaphor seriously. What rises with the tide is boats, not water. Pour a bucket of water into the ocean and it doesn't ride the tide; it becomes the tide. To float you need a hull — something that displaces water instead of merging with it. If your product is nothing but intelligence applied to a generic task, you're made of the same stuff as the model, and a better model doesn't lift you. It includes you.

So the definition needs a second clause. Buoyant doesn't mean thin. It means having a hull — something models don't acquire by getting smarter: your users' accumulated context, your data, your distribution — and connecting it to the model as directly as possible. The hull makes you distinct from the tide. The directness lets the tide lift you.

Which means there are two ways to sink. You can be anchored: so much scaffolding that each release arrives as a renovation project. Or dissolved: so little of your own that the next release includes your product as a feature. Buoyancy is the ridge between two ways of drowning.

The question works on people too. If your work is compensating for what models can't do yet — checking their output, being the human in the loop — you are the scaffolding, and the tide is against you. If it's knowing what's worth doing — the context, the taste, the ownership of a problem rather than a task — you're a hull. The most buoyant people greet each release with a backlog: things they already wanted to do, waiting for the intelligence to catch up. That's what "be buoyant" means, decompressed.

There's a diagnostic that requires no analysis. The next release is at most a few months away. When it comes, notice your first reaction. If it's greed — you can't wait to pour the new model through what you've built — you're buoyant. If it's dread — a migration, a re-tune, a quiet question about whether you're still needed — you're not. You can't fake the reaction; that's what makes it trustworthy. But you can change what causes it. The tide is rising either way^[2]. The only thing you choose is what it does to you.

August 17, 2026: This was written by Claude Fable via a custom argument-structuring pipeline with a tweet I wrote as the kernel, and PG's essays as voice input. I was so surprised at the output I'm publishing it as-is.