Related: this is the Token Economics argument from The Meter Runs taken one level up — from writing prompts efficiently to handing a model the metaphor that builds good architecture.
I didn't tell the model that built Fire to organize the AI providers and models from a couple of aggregators. I told it to map them out according to biological taxonomy — and the kingdom is AI.
That's the whole instruction. Not "make a list of providers." Not "build a categories table." Kingdom, phylum, class, order, genus, species — the actual Linnaean ranks, applied to a problem that had nothing to do with biology. A year later, that one sentence is still holding up the architecture, and I think the gap between the instruction I gave and the instruction I could have given is an article by itself.
The Instruction I Didn't Give
Here's what "organize the models from these aggregators" would have produced, if I'd said it the boring way: a flat list, or a table with a provider column and a model_name column, sorted alphabetically, extended by tacking a new row on the end every time a new model shipped. That's not a bad instruction. It's clear. It's unambiguous. A capable model would have executed it correctly and handed back exactly what I asked for.
It also would have been wrong — not incorrect, just structurally thin. A flat list has no relationships in it. It can't tell you that Claude Sonnet and Claude Opus are siblings, that EdenAI and Venice are proxies sitting in front of other providers rather than providers in their own right, that "add a new model" and "add a new provider" are different operations that should touch different layers of the system. A list is data. It isn't a shape.
Kingdom, Phylum, Class, Order, Genus, Species
What I actually told the model to build was a taxonomy, with AI itself as the kingdom — everything in the system descends from one root, the same way every animal on Earth descends from Animalia. Fire's real, running schema looks like this:
| Level | Example | Meaning |
|---|---|---|
| Kingdom | ai | Always ai — the root every model in the system descends from |
| Phylum | llm | Large language model (leaves room for other phyla later — image, audio, whatever comes next) |
| Class | anthropic | The provider — Anthropic, OpenAI, EdenAI, Venice |
| Order | claude | The model family |
| Genus | sonnet | The model variant within that family |
| Species | claude-sonnet-4-6 | The exact, callable model ID |
EdenAI and Venice — aggregator and proxy providers that sit in front of other companies' models rather than training their own — slot into this exact same taxonomy alongside direct APIs like Anthropic and OpenAI. They're a different class, not a different kind of system. Nothing about the shape changes to accommodate them. That's not an accident. That's what the taxonomy was for.
Why It Actually Matters
A year on, here's what that instruction bought: adding a new model is a config change, not a code refactor. A new species slots under an existing genus. A new genus slots under an existing order. Even a brand-new provider — a new class — has an obvious place to go, because the shape of "class" already exists and already knows how to hold one. Nobody has to touch the parts of the system that already work just to make room for something new. That's the entire promise of good architecture, and it fell out of a metaphor, not a spec.
Compare that to the flat-list version aging for a year. Every new model is a new row, fine — but every new kind of thing (a proxy provider, a non-text model type, a model that needs a different routing rule) is a decision nobody made in advance, resolved ad hoc, at 11pm, under deadline pressure, by whoever's on call. The taxonomy didn't just organize what existed on day one. It pre-built the slots for things that didn't exist yet.
Clarity vs. Creativity
I've written before about precision of instruction as a cost question — a tight prompt is cheaper and faster than a bloated one, the same way tight code beats bloated code. That's true, and it's not the whole story. This is the same principle at a different altitude. Clarity avoids ambiguity — it makes sure the model does the thing you meant. But a well-chosen metaphor, handed to a model capable enough to run with it, does something a merely-clear instruction never will: it produces architecture. "Organize these models" is clear. "The kingdom is AI" is a design decision disguised as a sentence, and the model I gave it to had more than enough capability to unpack everything that sentence implied — hierarchy, inheritance, the fact that a class can hold species it hasn't met yet.
That's the actual lever here. Not "be specific." Be specific about the shape, not just the content. The instruction that seems more abstract — reach for a real structure instead of describing the output directly — is very often the one that does more work, precisely because it hands the model something to extrapolate from instead of something to merely fill in.
What to Do Right Now
Next time you're about to hand a capable model an organizing task — data, a directory structure, an API surface, anything that's going to need to grow — don't just ask "is my instruction clear." Ask a second question: is there a real structure, borrowed from somewhere else entirely, that already solved this shape of problem? Biology solved "many things, related in nested ways, growing indefinitely" a very long time before software did. It won't always be taxonomy. But the metaphor is very often sitting one field over from the one you're staring at.
— J.P. Howlett
Related:
- The Meter Runs — the same "precision of instruction" argument, one level down: writing prompts like code instead of like prose.
- If You're Measuring AI in Percent, You're Not There Yet — the scaffolding half of this same practice: how the instructions get executed once they're given.
- The Scaffolding Prescription — the personal, lived-in version of this same argument: how the daily practice actually runs, tabs and all.
- Knowledge Distribution — the same "build it so it outlives you" principle, applied to people and teams instead of code.
Sources
- Design by Contract, "Object-Oriented Software Construction" — Bertrand Meyer's open/closed principle: software entities should be open for extension, closed for modification. The taxonomy is that principle applied to a provider/model registry.
- Linnaean taxonomy — the actual classification system (kingdom, phylum, class, order, genus, species) Fire's model abstraction borrows its ranks from.