AI coding agents are very good at producing a component that looks reasonable in the current context. That local competence creates a new product risk: every isolated success can introduce a slightly different button, card, spacing rule, empty state or interaction pattern.
Over a few weeks, the repo still compiles and the UI still looks broadly consistent. But the system has started to drift.
The Agent Drift Loop
UI drift is not one bad generation. It is a feedback loop.
Agent Drift Loop
- Ambiguous task. “Add a billing card” describes the feature, not the product rules.
- Incomplete retrieval. The agent sees nearby code but not necessarily the canonical component, token file or design decision.
- Local invention. It creates a plausible component that solves the immediate task.
- Build passes. The new pattern is technically valid, so there is no hard failure.
- New precedent. Future agents discover the duplicate and may treat it as an accepted pattern.
The dangerous step is number four. Traditional defects often fail tests. Design-system drift frequently passes every automated check because the duplicate component is valid code.
Why prompts alone do not solve this
A team can write “use our design system” in every prompt. That instruction is directionally correct and operationally weak.
The agent still needs to answer:
- Which button component is canonical?
- Which variant should be used for destructive actions?
- Where are the spacing tokens?
- Is a card allowed to have a new radius?
- Which existing flow is the best precedent?
- When is creating a new component justified?
Cursor's current documentation reflects this directly. Project Rules live in the codebase, can be version-controlled, and can point the agent to canonical files. Cursor's own designer guidance gives a design-system rule example that says to reuse UI components, use CSS variables and spacing scales, and reference specific canonical files. This is not prompt decoration. It is retrieval architecture.
The five controls that break the loop
1. Canonical components must be easier to find than duplicates
Do not rely on naming alone. Create one obvious component location and reference it from agent rules. If two button systems exist, decide which one wins before asking an agent to build more UI.
A useful contract is simple:
- reuse canonical components by default;
- extend a canonical component before creating a local substitute;
- create a new component only when the interaction model is genuinely new;
- delete or deprecate obsolete duplicates so retrieval does not surface competing precedents.
2. Tokens need semantic names, not only values
An agent can reproduce #111827. It cannot infer why that color exists. Semantic tokens carry intent: text-muted, surface-danger, space-section, radius-control.
The design system becomes more robust when the same semantic vocabulary appears in Figma, CSS and agent instructions.
3. Rules should point to examples, not duplicate the whole system
Cursor's current customization guidance recommends short, specific rules that point to canonical examples rather than copying large amounts of code into instructions. Anthropic's context-engineering work makes the same broader point: context is finite, so the goal is to curate the highest-utility information, not dump everything into the window.
A strong UI rule usually contains:
- the non-negotiable behavior;
- the canonical file or component to inspect;
- the token source;
- one or two anti-patterns;
- the verification step after implementation.
4. Add anti-examples
Design systems usually document what to do. Coding agents also benefit from explicit boundaries around what not to do.
| Weak rule | Stronger operational rule |
|---|---|
| Use consistent spacing. | Use only spacing tokens from tokens.css; do not introduce raw pixel gaps unless the canonical scale cannot express the layout. |
| Use our buttons. | Use Button from the canonical UI package. Do not create local button styles or native buttons for product actions. |
| Match the design. | Compare the changed state at desktop and mobile against the referenced pattern before completing the task. |
5. Verify system compliance, not only build success
The agent's final check should include product-system questions. Did it create a new color? New radius? New button? New spacing value? New loading pattern? If yes, was that intentional?
This can be partly automated with linting and token restrictions, but visual and interaction review still matters. Vercel's 2026 article on teaching agents product design makes the deeper point: code shows what shipped, but not why a pattern became standard. They address that by keeping accepted product decisions in the repository and making those decisions available to agents.
A practical agent-ready rule stack
You do not need a giant AI documentation layer. Start with four levels.
Minimal rule stack
Three signals that your system is not agent-ready yet
- You repeatedly correct the same class of mistake. The knowledge exists in a person, not in persistent context.
- Agents create components that humans would never approve as new primitives. Canonical reuse is not obvious enough.
- The prompt must contain screenshots and long explanations every time. The repo does not yet carry enough product intent.
The goal is not zero drift
No design system eliminates review, and no rule file turns an AI coding agent into a product designer. The realistic objective is different: reduce repeated correction, make deviations visible, and make the correct decision the easiest decision for both humans and agents.
That is why the best unit of work is not “write better prompts.” It is to improve the relationship between design system, repository and agent context.
Sources and further reading
- Cursor Docs — Rules: persistent project rules, version control and contextual application.
- Cursor for Designers: official design-system rule example for components, tokens and patterns.
- Cursor Learn — Customizing agents: short, specific rules that reference canonical examples.
- Vercel — Teaching agents product design at Vercel: storing accepted product decisions as agent-accessible repository context.
- Anthropic — Effective context engineering for AI agents: context curation as an agent engineering discipline.