Screen generators give you mockups. You still need a design system.

AI screen tools make convincing mockups fast, but not the decisions every future screen should share. When a screen is enough and when you need the system underneath.

A screen is one state

Prompt-to-screen tools are good now. Type a sentence, get a dashboard, and for a pitch that may be all you need. What you don't get is the set of decisions the next forty screens should share: which blue, how much space sits between a label and its field, what a disabled button looks like, and what all of it becomes in dark mode.

Those decisions are the design system. A screen is one output of them, and the system is what makes the outputs agree with each other.

We make a design system tool, so our bias is obvious. We'll try to be fair anyway, including about when you shouldn't use one.

What a generator hands you

Generate screen forty from a fresh prompt and you get a fresh set of guesses. Each generation decides everything again, and the small differences pile up: three greys that are nearly the same, button corners at 6, 8 and 12px, two slightly different ideas of what "card" means.

What a system has to produce

A design system you can ship looks boring on purpose:

• Foundations: colour ramps with semantic aliases for light and dark, a type scale, a spacing scale, radius, shadow, motion.
• Names: --color-surface-raised and --radius-control, not #F8FAFC and 8px.
• Components that reference those names instead of copying the values.
• Exports your repo can import: CSS variables, a Tailwind theme, JSON your other tools read.

Could you open a pull request with those files in it? If not, you have screens, not a system.

The same button, twice

Here's the button a screen generator writes:

<button className="bg-blue-500 text-white rounded-lg px-4 py-2">
  Continue
</button>

And the one a system writes. First the decisions:

:root {
  --color-primary: var(--blue-600);
  --color-on-primary: var(--neutral-0);
  --radius-control: 0.5rem;
}

[data-theme="dark"] {
  --color-primary: var(--blue-400);
  --color-on-primary: var(--neutral-900);
}

Flash's own export does it the other way round, dark by default with light opted in, but the idea is the same. Then the usage:

<button className="bg-primary text-on-primary rounded-control px-4 py-2">
  Continue
</button>

Change --color-primary and every primary button changes, in both themes, with the text colour following along. The first button is a literal. In six months you'll find it with grep, next to forty siblings that say bg-blue-600 because a different prompt ran that day.

When a screen generator is right

Sometimes a system is overhead, and we'd rather say so than pretend otherwise. Reach for a screen generator when:

• You're pitching on Thursday and need something to point at.
• You're exploring directions. Ten throwaway screens teach you more than one careful one.
• The page has a short life: an event microsite, a landing page test you'll delete next month.
• You're testing a flow with users and the visual layer isn't the question.

Don't build tokens for a page with a two-week lifespan. The moment to switch is usually easy to spot: it's the second time someone says "make it match the other one".

Use both, in the right order

You can use both. The setup that works is to decide the system once, then let screen tools and coding agents work inside it instead of guessing.

That's what the Handoff tab in Flash does. It hands your tokens to Lovable, v0 and Bolt up front, so the generated screens start from your palette and type instead of a default. If you change tokens after the handoff, it warns you that the builder still holds the old ones and gives you a patch prompt to paste. The walkthrough is in handing off to Lovable, v0 and Bolt.

Coding agents get the same treatment. An MCP server and agent files like AGENTS.md and DESIGN.md mean Cursor or Claude Code read your token names instead of inventing bg-blue-500. More in keeping AI coding tools on brand.

[!NOTE] A screen generator fed a real system is a better tool than either on its own.

Four questions for any AI design tool

1. Do I get a token file, or only JSX and images?
2. Can I rename a foundation and have every usage follow?
3. Does dark mode use the same semantic names as light?
4. Can I drop the export into a real repo without the vendor's runtime?

Four noes means you're buying a mockup tool. That's fine, if mockups are what you need.

Try it on your own brand

Run this once and you'll know which side of the line you're on:

1. Generate from a one-line brief on the home page, or use Import on the Dashboard to pull a system out of your live site.
2. Change three tokens by hand in Foundations: a font, the primary colour, a radius.
3. Open [[Export > Copy code]] and read the CSS.

If the file looks like something you'd commit, you want a system. If you only wanted a hero section, use a screen generator. We won't be offended.