9 ways to give your AI coding agent real design taste

Your agent does not lack taste because it is dumb. It lacks taste because you handed it nothing to have taste about. A language model fills every gap you leave open with the statistical center of its training data, and the center of "nice modern web UI" is Inter, a purple gradient, a centered hero, and three feature cards. Ask for "clean and modern" and you are asking for the average, so you get the average.

Taste, for an agent, is context: specific references, real values, named patterns, and tight constraints that push the highest-probability answer away from the mush. Below are nine concrete ways to supply it, ordered from the biggest lever to the finishing ones. uiscanner is one item on this list, not the whole list.

1. Start from a real reference, not an adjective

The single biggest upgrade is replacing abstract descriptors with a concrete reference. NN/g's research on prototyping with AI is blunt: vague prompts fail, and the fix is pointing at an established style or a specific artifact instead of describing feelings. "Make it premium" moves you a few inches inside the same cloud of averages. "Build it like Linear's marketing site" collapses a thousand open decisions at once.

Pick one or two sites you genuinely admire in the archetype you are building, and name them. The explore gallery is a fast way to browse teardowns of sites worth studying, from Stripe to Linear. Anchoring to a real reference is what everything below builds on.

2. Turn that reference into design tokens

Naming a site helps, but the agent still has to guess its actual values. Close that gap by extracting the tokens: the exact colors, font families, type scale, radii, spacing rhythm, shadows, and motion. Tokens are the atomic units of a look. Hand the agent #635bff and a 14/16/20/24 type scale and it stops inventing a color and a scale from the training soup.

This is where uiscanner fits. Paste any public URL and it returns a design teardown: tokens (colors, fonts, type scale, radii, spacing, shadows, motion), a section-by-section structure, and a Claude-tailored build prompt. It reads the rendered page with vision plus the DOM, so it catches the real primary button rather than the first one in the source, whether the hero is centered or split, and which imagery is decorative (with prompts to recreate it as originals). It describes and tokenizes; it never copies or re-hosts the original asset bytes, so you rebuild in your own stack from the tokens and structure.

Paste a URL on the web app to get a teardown in the browser, or once the MCP is wired in (section 5) let the agent pull it directly with a single tool call:

ui_teardown("stripe.com", target: "landing")

3. Give it components, not just tokens

Tokens set the palette; components set the shape. A #111 button on an 8px grid can still be built ten different ways. If your project has a component library (shadcn/ui, Radix, your own primitives), tell the agent to use it by name: "use our Button and Card primitives, do not roll new ones." The more you point at real components, the less the agent invents, and the more consistent the output stays across sessions.

The failure mode here is the agent quietly re-implementing a button that already exists three files over. Reference the component explicitly and that stops.

4. Show it examples in context

Taste transfers best by demonstration. Instead of describing your conventions, drop two or three real, well-built components from your own codebase into the context and say "match this." The agent infers your spacing habits, naming, prop patterns, and restraint far better from three good examples than from a paragraph of rules.

This is the cheapest high-leverage move on the list. You already have the examples; put them in front of the model instead of assuming it knows.

5. Wire in an MCP server for live design context

Prompts are ephemeral; a Model Context Protocol server is a standing pipe of structured facts the agent can pull on demand. Figma's team frames MCP as the unlock precisely because it replaces guesswork with accurate, machine-readable context: the tool asks for a token or a component and the server returns the real value instead of a hallucinated one.

uiscanner runs as one of those servers. One line wires it into Claude Code:

claude mcp add uiscanner -- npx -y uiscanner-mcp@latest

It works as an MCP client tool for Claude Code, Cursor, and Codex, and the setup page covers each one. It exposes five tools:

Target archetypes are landing, dashboard, marketing, ecommerce, portfolio, mobile, and general. It is stdio-only, so it runs on your machine and there is no remote endpoint to point at. Every scan returns an id and a shareable uiscanner.com/t/<id> link.

6. Give it a style guide with adopt and avoid lists

Once you know your direction, write it down as a short, opinionated brief the agent reads every time. The strongest pattern here is explicit adopt/avoid language. Because the model is pulled hard toward the most plausible answer, listing what to avoid is as important as listing what to adopt: no three-identical-card rows, no fake-precision stats like 99.99%, no gradient-on-everything, no em dashes. A style guide of ten sharp rules does more than a thousand words of prose.

Keep it in the repo (an AGENTS.md, a DESIGN.md, a system prompt) so it applies to every generation without you re-pasting it.

7. Put the constraints in the prompt

Even with all of the above, the request needs edges. The GenDesigns framework for AI UI prompts is a useful checklist: platform, user, output spec, mood/style, patterns/components, and technical constraints. State the framework and styling system up front (Next.js, Tailwind, our tokens), name the layout pattern ("split hero, bottom tab nav, bento grid"), and use exact values when you iterate. "Add 32px of vertical padding" beats "add more space," because the vague version just re-invites the average.

8. Iterate against a visual feedback loop

First drafts are drafts. The real differentiator is what happens after generation. The Agentic Coding Handbook's visual feedback loop is the pattern: render the UI, screenshot it, feed the screenshot back to the agent, point at what is wrong, regenerate, and repeat. Pairing a screenshot with the prompt gives the model direct visibility into the actual output instead of its imagined one. Annotate the screenshot when you can; marking the problem region beats describing it.

This loop is where a reference earns its keep: compare your screenshot against the teardown you started from and the gaps are obvious.

9. Hold it to an eval, not a vibe

Finally, define what "good" means before you look at the output, so you grade against a bar instead of a mood. A lightweight eval for UI is a short checklist you run every time: does it use our tokens, reuse existing components, hit AA contrast, avoid the banned patterns, and match the reference on spacing and hierarchy. Have the agent self-check against the list, and diff a new screen against a prior one to catch drift across a multi-screen build. Vibe-checking scales to one screen; an eval scales to fifty.

the through-line

Every item here is the same move at a different altitude: replace an open decision with a specific fact. A reference beats an adjective, tokens beat a reference, components beat tokens, examples beat descriptions, a live MCP feed beats a one-time paste, a style guide beats memory, constraints beat hope, a feedback loop beats a first draft, and an eval beats a vibe. Taste is not something you convince the model to have. It is context you supply, and the more of it you supply, the less room the average has to win.

The fastest way to start is to give your agent one real reference with real values. Scan a site you admire, hand your agent the tokens and structure, and build in your own stack. If you want to see what a teardown looks like before wiring it in, browse a few in the explore gallery.