Genie

Genie’s original canvas had four layers: Generators, Tools, Widgets, Plugins. I can reconstruct exactly why. Generators call a model and cost money. Tools run deterministically in the browser. Widgets are built-in but specialised. Plugins come from outside. Every one of those boundaries is real, and every one of them is a fact about the codebase.

None of them is a fact about the person using it. Nobody has ever wanted a Widget. The audit I eventually wrote against my own system listed the symptoms plainly: the same capability reachable from three different places, naming nobody could keep straight — widget versus plugin versus model — and entry points that simply did not exist for things people asked for weekly. Those are not four separate bugs. They are one bug, which is that the menu was an org chart.

The tell is that the taxonomy was easy for me to use. I had built the thing, so the categories matched my model perfectly. That is the trap in designing a tool you also engineer, and it is not solved by being careful. It is solved by watching someone else fail to find something you can find instantly.

The replacement has two layers, and they come from the only two questions a creative user actually asks: am I making something new, or am I changing something I already have?

Those two questions want opposite organising principles, which is why one flat menu could never serve both. When you are creating from nothing, the output type is the decision — image, video, text, audio, 3D — so CREATE is organised media-first. When you are modifying something that exists, the media type is already settled and the verb is the decision, so EDIT is organised intent-first: Adjust, Enhance, and so on. "Enhance → Upscale", not "Widgets → Image → Generation → Upscale".

I did not derive this in a vacuum. Every mature creative tool has already made this choice and made it differently: Photoshop is verb-first, DaVinci Resolve is stage-first, Figma is object-first, Blender is mode-first, ComfyUI is search-first with no hierarchy at all. Each is coherent for its own user. Search-first is genuinely the right answer when your user knows the name of the thing they want, and it is the wrong one when they know only what they want to happen — which is the user I was building for.

The decision I would defend hardest is a deletion. In the new taxonomy, whether an operation is AI-powered is not a category. Upscale, Denoise and Restore call models; Sharpen, Crop and Levels are arithmetic. They sit in the same menu, sorted by what they do to your picture. The AI ones carry a small marker, because processing takes time and cost, and knowing that is useful. But the marker is a processing indicator, not a place to live.

This runs directly against how the industry has organised itself since 2022, where AI is a wing of the building with its own door. That framing makes sense while the capability is novel and you are selling it. It stops making sense the moment someone is trying to get work done, because "make this sharper" is one intention, and forcing a choice between the AI aisle and the normal aisle is asking the user to make an implementation decision in order to express a creative one.

The cost is real and worth naming: you lose a merchandising surface. You cannot show off the AI when the AI is not a section. For a product whose whole pitch is AI, giving that up is a genuine concession, and I made it on purpose.

Every node graph has a type system, and the question is only whether the user has to learn it. ComfyUI surfaces its internals as first-class user-facing types — latents, conditioning, samplers, sigmas — and for its audience that is correct, because those handles are the control they came for. Genie exposes none of them. What a user sees is a short list of nouns they already own: text, image, video, audio, mask, file, 3D, code, number, boolean.

The pipeline underneath is not simpler for it. Latents still exist; they are just the backend’s problem. That is the trade the whole product rests on — the artist gets a vocabulary made entirely of things they can point at in the world, and gives up the knobs that live between those things.

The same instinct produced the detail I am fondest of. Adjustment nodes have one input that accepts either an image or a video, and the output type follows whatever you plugged in; connect a video and it processes per frame. The engineer’s version of that is two nodes with clear signatures, which is more honest and worse. Nobody thinks of cropping a video as a different operation from cropping an image, and a tool that insists otherwise is teaching its own architecture.

That the hard part of designing for artists is not simplification. It is resisting the pull to expose power you are proud of having built. Every capability in this product was expensive, and every one of them wanted a place in the menu, and most of that wanting was mine rather than any user’s.

That a taxonomy is a design artifact with a version number, not a decision you make once at the start. The first one was wrong in a way that was invisible from the inside and obvious the moment someone else used it. I would now treat "the categories feel natural to me" as evidence against a taxonomy rather than for it.

And that building the thing you are designing gives you exactly one advantage and one liability, and they are the same fact. You know what is possible, so you design against real constraints instead of imagined ones. You also know how it works, which quietly makes you the worst available judge of whether the interface explains itself.