Design once, generate everywhere: what we learned building a design engine

The first version of our Design Engine was a prompt. It generated colors and typography from a description, and it was delightful for exactly one afternoon — after that it was unusable, because the same brief produced a different palette on every run, and no client wants "that blue, you know, the one from Tuesday."

So we rebuilt it around a hard idea: generativity without determinism is decoration. What a design system needs is not a model that improvises, but a pipeline where intelligence is applied once and everything downstream is executable.

The shape that worked

The engine takes a structured brief — domain, personality adjectives, constraints — and produces:

1. A token tree (colors, spacing, typography, radii, motion) in the same JSON format our token pipeline consumes.
2. A Flutter theme generated from those tokens.
3. A component contract — which components exist, which tokens they may consume, which variants ship.

The critical property: every stage is reproducible. Given the same brief and the same engine version, you get byte-identical tokens. The "design intelligence" lives in the translation from brief to token decisions — not in randomized output.

Why determinism changed everything

Adopting that constraint fixed problems we did not know we were signing up for:

• Reviews became possible. You cannot review a design system that is different every time you look at it. Diffs need two comparable things.
• Regeneration became safe. Updating the engine and re-running the brief shows a real diff — "spacing scale tightened, primary shifted 4%" — instead of an unusable avalanche.
• Client branding became an input, not a fork. A client palette enters the brief as facts (brand colors, personality constraints) and flows through the same pipeline. No forked engine per client.

Where the hand still matters

A generative system that claims to replace design judgment is lying to you. Three places where the human stays in the loop, deliberately:

• The brief. "Playful but institutional, trustworthy to procurement, not childish" — translating taste into constraints is design work, and a good engine makes that work visible rather than automated.
• The exception list. The button that must break the radius rule because it sits on a hero image. Exceptions are declared in the contract (and reviewed) rather than hand-patched in code, which is how systems survive contact with real screens.
• The final pass. The engine guarantees coherence, contrast ratios, and spacing rhythm. It does not know the product. Somebody still has to look at the screen and say "this is right."

What this means for the token discipline

Design tokens get interesting precisely when a machine generates them. When tokens are hand-maintained, the discipline question is "did you update the file?" When they are generated, the discipline question becomes structural: the brief, the engine version, and the tokens form a lineage you can audit. A rebrand is a brief change, not an archaeology project.

That lineage is why the engine's output is our token pipeline's input and not a parallel format — every generated system lands in the same machine-checked lane as everything else we ship.

The takeaway

If you are building generative tooling for design, make the generator deterministic, put the intelligence at the front, and make every downstream artifact regenerable and diffable. The demo will be slightly less magical. The system, unlike the demo, will survive its second week — and its second client.