Writing

First, invent a planet

I built a cabinet as a physics rig. Its door, it turned out, couldn't open without a fully to-scale procedural world underneath it — and I hadn't noticed the world was there.

Somewhere in this project, opening a cabinet door requires a planet. A real one — continents, mountain ranges, volcanoes, to scale, procedurally generated down to individual rocks. I built it by accident, and for a while I didn't know it was there. Here's how that happens.

How a cabinet becomes a physics problem

I wanted furniture I could animate — a door that swings, a drawer that slides — while still drawing the whole piece in a single call. The clean way to get both is to stop thinking of a cabinet as a model and start thinking of it as a mechanism: parts linked by joints, the exact articulated-body machinery you'd use for a robot arm. A door is a hinge joint. A drawer is a slider. A shelf is welded. Build the piece as a little kinematic rig and the physics engine animates it for free.

So the cabinet runs on the physics solver. And the physics solver, written earlier for something else entirely, had an assumption baked into it that I'd long stopped thinking about: gravity has a direction, and it gets that direction from a planet. Gravity points toward the planet's center. To settle the door against its hinge, the solver needed to know which way was down — and to answer that, somewhere, a planet had to exist.

To open the cabinet door, there had to be a planet.

Code grows into itself

This is a specific thing that happens when you build with language models, and it's the shadow side of the discipline I usually preach. Ask a model for gravity and it reaches for what's available — and what was available was a planet, with a center, with a perfectly good down vector — and it wires them together into something that works. It isn't wrong. It runs. But a boundary I wasn't watching quietly dissolved: the physics now assumed the planet instead of being handed a direction. Encapsulation isn't the default state of code. It's a discipline you enforce and verify, and the moment you stop checking, things fuse at the nearest convenient seam. Components are the cure; this is the disease when you look away.

Why I didn't notice

Normally a stray dependency on an entire planet announces itself loudly. This one didn't — because of the level-of-detail system. Unobserved, the planet is a point mass and maybe 150 kilobytes of code. It costs nothing. It generates nothing. It just waits, handing out a single down vector. So the cabinet sat in its studio, lit and serene, and the world it secretly leaned on was a dot you couldn't see. The bug had no symptoms, because the thing it depended on was, until looked at, almost nothing at all.

Until you look down

Tip the camera past the floor of the studio, and the dot resolves. You begin an orbital descent, and the planet builds itself to meet you as you fall — continents surfacing out of the low-frequency noise, then mountain ranges, then the dark shapes of volcanoes, and finally, as the ground comes up, individual rocks: layer upon layer of fBm unfolding the whole way down. The thing that existed only to tell a cabinet door which way is down turns out to be a world.

I did eventually give the physics an honest seam — it asks an environment for gravity now, and the furniture studio answers "no planet, just down," while the planet answers with a real field. That's the correct fix, the dependency turned right-way-round, and it's exactly the discipline these models demand of you. But I'm a little glad it happened the wrong way first. It's the most literal version I know of something true long before any of this: to make a thing from scratch, you sometimes have to invent a universe to hang it in. Mine just happened to be 150 kB, and procedurally generated all the way down to the rocks.