Buoyancy

Menu

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...