Prompting for design vs a design system your agent reads

There are two broad ways to tell an AI coding agent how your app should look. You can describe it in the prompt, every time or once per session. Or you can give the agent a design system it reads: fixed values, chosen components and rules it looks up before it builds.

A common path is to start with the first and move to the second when the screens stop matching. This page compares the two approaches fairly, including where prompting is the right call.

The short version#

Where prompting works well#

Prompting is the fastest way to explore. "Dark, quiet, one warm accent, generous spacing" gets you a plausible screen in seconds, and if you don't like it you say so and get another. For a prototype, a hackathon or a one-off internal tool, that's often all you need, and building a system first would be wasted effort.

It's also how you find a direction in the first place. Several rounds of "more like this, less like that" are a perfectly good way to discover what you want before you fix it in place.

Why prompts drift#

The trouble starts on the second screen. Prompting has a few built-in weaknesses:

• Adjectives are ambiguous. "Premium" might mean dark and glossy one day and light and serif the next. The agent isn't wrong either time.
• Each request starts fresh. The style you agreed on last week isn't in this week's conversation unless you paste it again, and long conversations push early instructions out of view.
• Motion gets the least attention. "Subtle animation" usually becomes a short fade on everything, because that's the safest reading.
• Teams multiply it. Each person describes the style in their own words, so each agent builds a slightly different product.

None of this is the model failing. Without fixed values it has to choose, and the most common choices are the ones every other AI-built app makes. The blog post on why AI-built apps look the same goes deeper into that.

What changes when the agent reads a design system#

A design system moves the decisions out of the conversation. With Wuizard, that system is a sheet: foundations (colour, type, radius, spacing, shadows and a motion spring), slots with one chosen component each, and short rules.

Your agent connects over MCP and calls get_sheet before it builds UI, so it starts every task with the same values and rules. For a component it calls get_slot and gets that exact code with your values filled in, rather than writing its own button from a description. Before it finishes, check_ui reviews what it wrote and lists anything outside the sheet: stray colours, radii, springs, fonts, shadows, spacing, missing reduced-motion handling, or a hand-written copy of a component that already has a slot.

The prompt gets shorter as a result. You describe what the screen does, and the sheet covers how it looks.

What a design system costs you#

It isn't free, in time or money. Someone has to set the system up and make choices up front, which is slower than typing an adjective. It can also feel restrictive while you're still exploring: once a primary button is chosen, the agent uses it, even when you'd like to try something different on one screen. You can change the sheet at any time, but it's a deliberate step rather than a passing whim.

With Wuizard specifically, the AI features need a subscription, and live reads need a connection. You can export the sheet as files if you'd rather keep everything in the repo.

The middle ground: rules and tokens in the repo#

Between the two sits a hand-written setup: a project instructions file, such as CLAUDE.md or AGENTS.md, that lists your colours, fonts and do's and don'ts, plus a tokens file with CSS variables or a Tailwind theme. It's free, it lasts across sessions and it lives with your code.

What it can't do is hand the agent real components, and motion is hard to pin down in prose, so the agent still writes the hard parts itself. Alternatives to pasting design screenshots compares this setup with the other options in more detail.

How to decide#

• Still exploring? Prompt freely. Fix the system once you know what you want.
• More than a handful of screens? Move the decisions somewhere the agent can look them up. Drift grows with every screen.
• Want something free that lasts? Write a rules file and a tokens file.
• Want exact components and motion on every screen? Use a design system the agent reads. The MCP setup guide connects your agent to a sheet, and browsing colour palettes and font pairings is a quick way to make the first choices.