Direct answer
Designers should define the system, interaction intent, and acceptance examples; coding agents should implement those constraints and return rendered evidence for review.
Divide ownership clearly
Name the user, task, priority, and required states
Keep the implementation scoped to that task
Approve semantic tokens, type, spacing, and component variants
Reuse the approved system without inventing page-specific styles
Define behavior, edge cases, and accessibility expectations
Implement the complete keyboard and pointer flow
Choose acceptance examples and review the rendered result
Run checks, capture changed states, and fix verified findings
Developers own architecture and release decisions
Produce a focused, reviewable change that fits the repository
The designer-agent review loop
Human intent, agent implementation, browser evidence, and shared-system updates form one repeatable loop.
- Designer intent: Define the screen job, system constraints, and acceptance examples.
- Agent build: Implement the complete flow within the approved boundaries.
- Browser review: Inspect real states and return concrete rendered findings.
- Shared system: Promote durable decisions into tokens, components, and rules.
Before the agent writes code
- Describe one screen job and the user who needs it.
- Provide the existing tokens and component source, or approve a design system first.
- List loading, empty, error, disabled, and success states that can occur.
- Attach reference screens as acceptance examples, not as images to copy blindly.
- Name the files or product areas that must remain unchanged.
Review rendered evidence
- Check the primary task at desktop and the narrowest supported viewport.
- Use the keyboard through every changed control and verify visible focus.
- Compare hierarchy, spacing, type, and component variants with the approved system.
- Inspect real loading, error, empty, and long-content states rather than the ideal path only.
- Return concrete findings tied to the rendered screen, then let the agent fix and re-run the review.
Govern without blocking delivery
The design system should hold durable decisions while the task brief holds local intent. That lets designers supervise the system instead of redrawing every screen and lets developers keep code as the implementation source of truth.
Start with one flow and a small set of approved components. Expand the rules only after a repeated decision appears. This keeps governance proportional to the product rather than turning it into a second project.
Steal this workflow
Run this guide in your own assistant. The prompt carries the guide link and the workflow summary, so the assistant can adapt it to your project.
Read the guide "Designer playbook for AI coding agents" at https://better-design.com/guides/designer-playbook-ai-coding-agents and help me apply it to my project.
Designers should define the system, interaction intent, and acceptance examples; coding agents should implement those constraints and return rendered evidence for review.
Start by asking what I am building and which tools I use. Then walk me through the workflow step by step, adapted to my answers.Claude and ChatGPT open with the prompt filled in. Gemini copies the prompt to your clipboard first, so paste it when the app opens.
Questions
Do AI coding agents replace product designers?
No. Agents can implement and check explicit constraints, but humans still own product intent, system direction, tradeoffs, and final judgment of the rendered experience.
Can this workflow keep Figma?
Yes. Figma can remain the collaboration and exploration surface while semantic tokens, component source, and interaction rules form the contract the coding agent implements.
What should a designer hand to a coding agent?
Provide the screen job, approved tokens and components, required states, interaction rules, acceptance examples, and the boundaries the change must not cross.