How Product Designers Should Work with Coding Agents

Product designers working with coding agents should treat the agent as an implementation partner, not a replacement for design judgment. Write structured specs, attach reference artifacts, review output in small diffs, and keep a DESIGN.md as the single source of truth — the same discipline you use with engineers, adapted for prompt-driven builds.

The designer's role has not changed — the handoff has

Coding agents collapse the gap between design and implementation. You can go from a Figma frame to working React in one session. That speed is real, but it introduces a new failure mode: the agent fills gaps with generic UI patterns when your spec is incomplete.

Your job is still to define what gets built and how it should feel. The agent's job is to implement within those constraints. When designers skip the spec and prompt "make a dashboard," they get a dashboard — just not theirs.

The designers who ship well with agents share three habits:

1. They write specs the agent can parse — tokens, components, layout rules, not mood boards alone.
2. They review like they would a PR — focused diffs, not full-page rewrites.
3. They maintain a design language document that persists across sessions.

Step 1: Write a DESIGN.md, not just a Figma file

Figma remains valuable for exploration and stakeholder review. But coding agents work best with text-native design specs they can read directly.

A DESIGN.md should include:

• Design principles — Three to five sentences on tone, density, and motion philosophy.
• Design tokens — Colors (prefer OKLCH or CSS custom properties), typography scale, spacing, border radii, shadows.
• Primitive components — Button variants, input styles, card patterns with exact class names or CSS.
• Layout rules — Grid behavior, max-widths, breakpoint strategy.
• Motion system — Duration, easing, what animates and what does not.
• Imagery direction — Photo style, illustration rules, what to avoid.

This is the same information in a good Figma library — just formatted for an agent. Templates in the Agent's Design gallery ship with DESIGN.md files you can use as starting points or structural references.

Step 2: Choose the right tool for each task

Different agents excel at different parts of the workflow.

Task	Best fit	Why
Explore layout variations	v0, Lovable	Fast visual iteration from prompts
Implement in existing codebase	Cursor, Claude Code	Full repo context, file editing
Refactor components	Codex, Cursor	Strong at reading and modifying code
Write design specs	Any LLM chat	Text output, no code needed
Production polish	Cursor + your review	Human judgment on spacing and states

Designers do not need to master every tool. Pick one implementation agent (Cursor or Claude Code) and one exploration tool (v0 or Bolt). Learn their prompt patterns deeply rather than switching constantly.

Step 3: Structure your prompts like design tickets

Treat each agent message like a Jira ticket a developer would pick up. Vague tickets produce vague code.

Bad prompt:

Make the settings page look better.

Good prompt:

Update the settings page:

• Use the DESIGN.md token --surface-raised for card backgrounds
• Settings groups: 24px vertical gap, 16px horizontal padding
• Toggle switches: shadcn Switch component, label on the left
• Section headings: 14px uppercase, --text-muted, letter-spacing 0.05em
• Do not change routing or data fetching

The good prompt names specific tokens, components, spacing values, and scope boundaries. The agent has less room to invent.

Step 4: Review output like a design critique

When the agent returns code, review it the way you would review a developer's PR:

Check hierarchy first. Does the visual weight match your spec? Are headings the right size? Is the primary action obvious?

Check spacing systematically. AI agents often get relative spacing wrong — 16px gaps where you specified 24px, inconsistent padding inside cards. Use browser DevTools to inspect computed values.

Check states. Hover, focus, disabled, empty, loading, error. Agents frequently ship the happy path only. List missing states in your next message.

Check responsive behavior. Resize the viewport. Agents trained on desktop-first patterns often break on mobile unless you specified breakpoints.

Check copy. Agents write placeholder text that sounds confident but says nothing. Replace it with real content or explicit placeholder labels.

Step 5: Iterate in small diffs

The biggest mistake designers make with coding agents is asking for full-page rewrites when one component is wrong.

Instead:

1. Identify the specific element that is off.
2. Describe the fix with reference values: "Increase card padding from 16px to 24px. Change heading from text-lg to text-xl."
3. Confirm the fix before moving to the next element.

This mirrors how you would annotate a Figma file — precise, incremental, scoped.

Step 6: Build a component review checklist

Keep a personal checklist for every agent-generated screen:

• Typography matches DESIGN.md scale
• Colors use defined tokens, not hardcoded hex
• Spacing follows the 4px or 8px grid
• Interactive elements have hover and focus states
• Empty and loading states exist
• Mobile layout stacks correctly
• No unauthorized fonts or icon sets
• Copy is intentional, not AI filler
• Motion follows the defined system
• No generic gradients or glassmorphism unless specified

Run this checklist before calling any screen done. It takes five minutes and prevents slop from shipping.

Collaborating with engineers

If you work on a team, the DESIGN.md becomes a shared contract between you, the agent, and engineers.

Designers own: tokens, components, layout rules, motion, imagery direction.

Agents implement: code that matches the spec within the existing codebase conventions.

Engineers review: architecture, performance, accessibility, edge cases the agent missed.

This division keeps agents in the implementation lane without bypassing engineering standards.

Common pitfalls for designers

Prompting aesthetics instead of systems. "Make it feel premium" is not actionable. "Use Geist font, 1px borders at 8% opacity, 4px border-radius, no shadows" is.

Accepting the first output. The first generation is a draft. Plan for two to three refinement rounds minimum.

Not version-controlling specs. DESIGN.md should live in the repo alongside code. When the agent drifts, point it back to the committed spec.

Ignoring accessibility. Agents rarely add proper ARIA labels, focus traps, or keyboard navigation unless asked. Add accessibility requirements to your spec explicitly.

Start from a proven design language

Writing a DESIGN.md from scratch for every project is slow. The Agent's Design gallery provides curated design languages — complete specs with tokens, components, and prompts — that you can adapt to your product. Browse by aesthetic, copy the DESIGN.md into your repo, and customize tokens and components for your brand.

The agent gets a concrete reference. You get a head start. The output stays yours because you defined what changed and why.