Direct answer
Treat the design system as a constraint. Give the agent one change and require existing tokens and components. Inspect the diff for invented styles, then review the rendered state at supported widths. Repeat this check every time.
Why does AI-generated UI drift?
Drift appears when the agent optimizes for the current screenshot without enough context about the product. Broad prompts invite local fixes. Each new screen can introduce another color, radius, shadow, spacing scale, component, or interaction pattern.
The problem compounds because later prompts copy the generated exceptions. A one-off button becomes a second button system, then a new dialog copies that button instead of the approved primitive.
Which loop keeps the interface consistent?
The drift-control loop
Each interface change starts from approved source and ends with rendered evidence.
- Approved system: Name the tokens, components, and patterns that are already allowed.
- One scoped change: Request one observable result and state what must stay unchanged.
- Inspect the diff: Catch new primitives, token escapes, duplicate variants, and unrelated edits.
- Review in browser: Use the changed states with real content, keyboard input, and narrow widths.
What should the prompt constrain?
A useful guardrail prompt identifies the current source of truth and the one result that should change. It names styling decisions the agent must not invent. It also defines the evidence required before completion.
Add the invalid state to the existing sign-up form. Reuse the current form, alert, button, and semantic tokens. Do not add a new palette, radius, shadow, or form primitive. Keep the valid flow unchanged. Verify keyboard use, the error state, and a 320px viewport, then summarize the changed files.What should the diff review catch?
- Literal colors, spacing values, radii, or shadows that bypass semantic tokens.
- A new component that duplicates an existing primitive or variant.
- Page-specific CSS that should be expressed through the shared system.
- Changes outside the requested flow, including unrelated cleanup and dependency updates.
- Removed states, accessibility attributes, tests, or behavior hidden by a good-looking preview.
How does Better Design support the guardrail?
Before implementation, the agent can retrieve visual and behavior guidance. It can then use the project's installed shadcn-compatible components. After implementation, it can load review rules for accessibility, visual design, content, and comprehension.
For a new sign-up error state, the agent can reuse the existing alert and form language. It preserves the semantic token scale, then checks focus, copy, contrast, and the narrow layout. The team still inspects the actual diff and rendered result.
What should the browser review prove?
- The primary action still has the clearest hierarchy.
- Long content, errors, loading, empty states, and disabled states do not break the layout.
- Keyboard order, focus visibility, labels, and status messages still work.
- The smallest supported width has no clipping or page-level horizontal scrolling.
- The changed surface still looks and behaves like the surrounding product.
Questions
Can a prompt alone stop AI UI drift?
No. A prompt can narrow the task. Drift control also needs an inspectable source of truth, diff review, rendered checks, and enforcement in the normal development workflow.
Should I ban every new component?
No. Require the agent to show why existing components cannot express the needed behavior. Add a new primitive only when the product has a real reusable need for it.
How do I measure whether drift is improving?
Track token escapes, duplicate primitives, unapproved variants, visual review findings, and rework per task. Compare repeated work on similar flows rather than judging one polished screenshot.
Implementation references
Primary documentation used for the registry, token, and accessibility practices on this page.