Build with AI
How to make AI coding tools follow your design system
Give coding agents real components, usage guidance and scoped visual references so new screens fit the product. Includes a component-selection prompt.
Give the agent the system that actually exists
To make an AI coding tool follow a design system, provide the current components, their supported APIs and the rules for composing them. A list of colors alone does not explain which button variant to use or how a validation error belongs beside an input.
Begin with the repository or maintained design-system documentation. Identify where tokens, components and examples live. If multiple versions exist, say which one this project uses. A screenshot of the latest product cannot reliably supply every implementation detail.
Separate product rules from reference direction
The design system sets reusable constraints. A Taste collection can supply task-specific direction: denser comparisons for a reporting screen, or a clearer sequence for a booking flow. Explain how to resolve conflicts. Existing product components should not be replaced just because a reference has different corner radii.
For an illustrative admin form, the agent should reuse the established input, error treatment and save controls. References may help reorganize the sections or clarify the hierarchy. A new component is justified when the required behavior is missing, not merely because the generated version is easier to produce.
Use component documentation as live context
Storybook’s MCP documentation describes tools that help agents discover components and read their documentation and stories. That can give an agent a more precise starting point than guessing APIs from names. Check support for your Storybook setup and framework in its current documentation.
When Figma files are the source of truth for design, Figma MCP can supply design context in supported clients. Establish how that context maps to the codebase. A similarly named component is not proof that its implementation matches the design file.
Require a component map before implementation
Ask for a short mapping from the screen’s elements to existing components. This exposes missing pieces and prevents the agent from quietly creating substitutes.
Before implementing this screen, locate our current tokens, components and usage examples. Map each required control to an existing component and verify its supported props. Read my selected Taste references for layout direction, but preserve the product design system. Identify genuinely missing behavior and propose the smallest addition. Implement with existing variants, then list any new styles or components and explain why they were necessary. Review loading, error and narrow-screen states.
Review exceptions and keep decisions current
Inspect the diff for repeated hard-coded colors, new spacing values and duplicate controls. Some exceptions may be appropriate, but they should be deliberate and named. Check the new screen beside an existing one to see whether the shared parts behave consistently.
When a successful pattern becomes reusable, document it in the system rather than leaving the explanation in one chat. Keep Taste notes focused on the visual intent and keep implementation APIs in the maintained source. That gives the next agent clear places to look for both kinds of context.