Generators vs in-repo agents.
Design-to-code tools split into two camps. Generators — Stitch (Google Labs preview), v0, Lovable, Magic Patterns — take a mockup, Figma frame, or prompt and emit a self-contained UI. In-repo agents — Cursor, Claude Code, Codex CLI — read your codebase, reuse your components, and write files where your app actually lives.
The mistake is treating them as interchangeable. Generators optimize for looks good in a sandbox. Repo agents optimize for fits the conventions you already ship. Stitch is a useful Google Labs preview for layout exploration; it is not a substitute for your design system.
| Tool type | Best for | Worst for |
|---|---|---|
| Stitch | Turning a screenshot or prompt into a layout prototype. Strong spatial fidelity from Google Labs. | Dropping output into a repo with an existing token system and component library. |
| v0 | Greenfield Next.js + shadcn/ui iteration. Fast visual riffing. | Anything that must inherit your brand, routing, or data layer. |
| Cursor / Claude Code | Implementing UI inside a real repo. Reuses primitives, respects AGENTS.md. | "Make it pretty from scratch" with no tokens, no reference component, no spec. |
A workflow that actually ships:
- Explore in a generator if you need to see layout options fast.
- Extract the decisions — spacing rhythm, hierarchy, component boundaries — not the code.
- Reimplement in-repo with your tokens, your
<Button />, your test patterns. - Polish with design fluency skills (next chapter) and the merge checklist.
For prompt structure once you're in-repo, see the Prompting for UI Code guide. Generators skip that discipline at your peril.
Stitch is a Google Labs preview. APIs, output quality, and availability can change. Treat it as an exploration tool, not a CI step. Your repo conventions are the source of truth — generators don't learn them unless you re-teach them every session.
Figma MCP workflow.
When design lives in Figma, the Figma MCP server pulls frame structure — spacing, colors, text styles, component instances — directly into your agent's context. That beats a PNG for accuracy and beats retyping specs by hand for speed.
Token cost is roughly 850 tokens per turn. Worth it if you build from Figma weekly; dead weight if designers hand you exports or your system doesn't map to Figma components.
{
"mcpServers": {
"figma": {
"url": "https://mcp.figma.com/mcp"
}
}
}A practical Figma-to-code loop:
- Link the frame. Paste the Figma URL in your agent prompt. Ask it to fetch the node via MCP before writing code.
- Map, don't mirror. Tell the agent which Figma components correspond to your repo primitives ("Figma
Button/Primary→ our<Button variant="primary" />"). - Override with tokens. Figma hex values are reference, not gospel. Instruct the agent to translate colors and spacing to your token file.
- Verify visually. Playwright MCP screenshot diff or manual check at two breakpoints. Figma MCP gets structure right; edge cases still need eyes.
Full MCP shopping guidance — which servers earn their overhead — is in MCP Servers for Web Devs.
Implement the pricing section from this Figma frame: https://www.figma.com/design/ABC123/...?node-id=42-118 Before writing code: 1. Fetch the frame via Figma MCP. List spacing, type scale, and colors you see. 2. Map each Figma component to an existing repo primitive (see AGENTS.md). 3. Translate all colors/spacing to tokens in app/styles/tokens.css — no raw hex. Output: app/components/PricingSection.tsx Reuse <Button />, <Card /> from app/components/. Do not create parallel button styles.
Impeccable & CSS.dev for design fluency.
Repo agents write code that compiles. They don't automatically write code that looks designed. Two skill frameworks close that gap by giving agents vocabulary for typography, spacing, hierarchy, and modern CSS.
| Tool | What it adds | When to invoke |
|---|---|---|
| Impeccable | 20 design commands — /polish, /audit, /typeset, /hierarchy — with curated patterns for visual refinement. |
After first implementation, when the layout works but feels "AI-generated." |
| CSS.dev | 9 CSS-specific skills: container queries, subgrid, logical properties, scroll-driven animations, oklch color. | When the task is layout-heavy or the agent keeps reaching for outdated CSS patterns. |
Install them the same way you install any skill — drop into .cursor/skills/, .claude/skills/, or reference from AGENTS.md. They don't replace your tokens file; they make the agent use it better.
Typical sequence after the agent writes a component:
- Run Impeccable
/auditon the new file for spacing and hierarchy issues. - Run CSS.dev skills if layout uses flex/grid in non-idiomatic ways.
- Run your axe test. Design fluency without accessibility is still demo quality.
# Design fluency
- After implementing new UI, run Impeccable /audit on changed files.
- For layout work, apply CSS.dev container-query and subgrid patterns.
- Never introduce raw hex or arbitrary Tailwind values — tokens only.
- Reference component for visual density: app/components/SettingsCard.tsxHandoff checklist before merge.
Demo-quality UI passes the default state in a narrow viewport. Shippable UI passes a checklist. Run this on every AI-generated component before you approve the PR — whether it came from Stitch, Figma MCP, or a plain repo-agent prompt.
| Check | Pass criteria |
|---|---|
| Tokens | No arbitrary Tailwind values, no raw hex, no inline styles. Colors and spacing from your token file only. |
| States | Default, loading, empty, error, disabled, and focus all handled. Not just the happy path. |
| Responsive | Behavior specified at <640px and ≥640px minimum. No horizontal scroll at 320px. |
| A11y | Keyboard-operable, visible focus rings, programmatic labels. axe-core reports zero violations. |
| Primitives | Existing <Button />, <Input />, etc. reused. No duplicate component files. |
| Tests | At least one render test + axe assertion. Behavior the prompt promised is pinned. |
Put the tokens and states blocks in AGENTS.md so every session inherits them. The Prompting for UI Code guide has copy-paste blocks for both.
AI UI checklist: [ ] Tokens only — grep for [#] and [px] arbitrary values [ ] States: loading / empty / error / disabled / focus [ ] Responsive at 320px and 768px [ ] axe-core zero violations in test file [ ] No new Button/Input — reused from app/components/ [ ] Matches SettingsCard visual density
Live: pick your workflow.
What are you starting from? Pick an input type and get a recommended tool sequence plus a sample prompt you can paste into Cursor or Claude Code. Runs entirely in your browser.
Pitfalls.
Pasting Stitch or v0 output into a repo that already has tokens and components creates a seam — your system plus theirs plus a third style emerging from the glue code. Generators don't replace repo conventions. Reimplement the layout; don't transplant the CSS.
AI UI that "looks fine" in the default state but breaks on focus, empty arrays, or mobile is demo quality. It passes a screenshot review and fails in production. The checklist in CH 04 exists because models default to the path of least tokens — one state, one breakpoint, no axe test.
Fetching a frame and asking the agent to "build it" produces pixel-close div soup. You need the mapping layer — which Figma instances become which repo primitives — or you get a second component library with Figma-accurate spacing and wrong semantics.
Impeccable and CSS.dev only help when the agent runs them. Adding skills to a folder without a line in AGENTS.md saying "run /audit after new UI" is decoration. Make invocation explicit in your project rules.