For years, passengers at Houston's airport complained about the wait at baggage claim. The airport added handlers and the bags came out faster. The complaints kept coming. Then someone tried a different fix entirely: they routed arriving passengers to a carousel far from the gate, so the walk took several minutes and the standing-around took almost none. Complaints dropped to near zero. The wait was the same length. People were no longer spending it standing still.

Nothing about the machinery changed. The bags didn't arrive sooner. What changed was the shape of the experience, and the shape was the whole problem.

Empty time feels longer than occupied time. Once you see the wait as a feeling instead of a duration, a different set of fixes opens up, and they cost less than the engineering ones. The mirror beside a slow elevator does the same work. So does the little map showing your car crawling toward you. The car isn't faster. You're no longer staring at a blank screen wondering if it's coming.

Both descriptions of the situation are true. "The elevator is slow" and "the wait is boring" describe the same lobby. Each one points at a different problem, and you can only solve the problem you've named. That naming happens before any work begins, and it decides, before anyone notices, what the work will be.

We are in the middle of naming a new machine right now, and the name we've settled on is doing damage.

The common frame treats a large model as a new kind of mind. You ask it something, it thinks, it answers. Under that frame, when it invents a citation or contradicts itself, the failure reads as a flaw on the way to something greater, a not-yet-smart-enough that next year's version will fix. So you wait. You stop checking its work. You talk to it like an oracle and accept that the oracle is sometimes wrong.

Describe the same software a different way. A large model is a compression of things people have already written, the human record run through a blender, handing back the most probable continuation of whatever you typed. Closer to a salvage yard than a mind. Every part in it came from somewhere. Nothing about the software argues with this description. It fits exactly as well as the other one.

The salvage-yard frame changes how you act. You expect the thing to be strong where the record runs deep and unreliable where it runs thin, which is how these models actually fail. You stop waiting for it to wake up. You go in knowing you're sorting through secondhand material.

You also don't walk the yard expecting a part that was never manufactured. It isn't there, and you'd have nowhere to bolt it anyway. That's the expectation people carry into the oracle frame without noticing: that the thing will hand them the genuinely new, the answer no one has worked out yet. A salvage yard doesn't owe you that. When the model seems to produce it, it isn't reaching past the human record. It's welding two real parts into something that looks whole. Nothing in the yard is truly new, and nothing in the model is either.

And a car is dense with systems most of us can't fully explain: the harness behind the dash, the body panels, the stereo, the seats you came in for. You can pull from any of them without understanding the whole. Standing there with a wrench, the truth of the thing is obvious: it's human engineering, not something handed down by gods. Software loses that obviousness the moment you give it a personality. You don't worship the donor. You strip it for what's useful and move on.

For anyone building the interface in front of one of these models, the frame is the first design decision, and it gets made in the copy long before it gets made in the architecture. A loading state that says "Thinking" installs the oracle. One that says "Searching your files" installs the archive. The latency is identical. The relationship is not.

Every verb on the screen teaches the user what kind of thing they're talking to. A verb like "understand" sets an expectation the software can't meet, and the user feels the gap as disappointment, or worse, trusts the output past the point where they should. A verb like "draft" sets an expectation it can keep. You aren't describing the system to the user. You're deciding how they'll treat it.

The frame is the cheapest thing in the whole stack to change. It costs nothing to describe the machine differently. And we keep reaching for the description that makes us passive, that turns a tool into an authority and the person holding it into someone who waits.

The airport didn't make the bags faster. It gave people something to do. The move worth wanting here is the same one on a larger machine: stop calling it a mind we're waiting on, and start calling it the pile of human work it already is, so the people using it stay awake to their own judgment. The software won't notice the difference. Everyone using it will.