AI is fast until it starts freelancing your design

If you’ve built UI with an AI assistant for more than a day, you’ve probably seen the pattern: the first version looks fine, but the next prompt produces a different button style, a new spacing scale, and "helpfully" adds a whole new styling approach you never asked for. You ship faster, but your UI starts drifting.

The fix is not better vibes. The fix is clear constraints + a reusable spec + a prompt you can reuse. The good news: you don’t need a framework-specific setup to do this. You just need to be explicit about what the assistant must detect, what it must reuse, and what it must not introduce.

Two rules that prevent "AI UI drift"

1) Force detection before coding

Instead of telling the assistant "use Tailwind", make it inspect your project first: your package.json, existing components, config files, and style imports. That’s how it learns what you already use - and avoids guessing.

2) Enforce "use only what’s already in the project"

Most UI inconsistency comes from the assistant mixing approaches. You want one clear rule: reuse the detected styling system and match existing component patterns. No new styling system, no ad-hoc "just this one CSS file," no surprise UI kit.

This single constraint does more for consistency than any "make it look modern" prompt ever will.

What to paste into the AI: a spec, not a library

When you give the assistant a detailed UI guide (dimensions, states, responsive behavior, accessibility requirements, testing checklist), it has less room to invent. It’s working from a concrete blueprint rather than its own preferences.

A reusable prompt template you can keep in a snippet

You can paste this into ChatGPT or Claude and reuse it any time you implement UI. The key is that it is constraint-first and project-aware.

You are implementing a UI component in my existing project.

1) First, DETECT my setup before writing code:
- Determine the framework (if any) and the current styling system by checking package.json, existing components, config files, and style imports.
- If detection is uncertain, ask me what framework/styling approach I want.

2) Constraints (must follow):
- Use ONLY what is already in the project for styling. Do not introduce a new styling system or ad-hoc CSS approach.
- Match existing component patterns exactly (file structure, naming conventions, and how components are composed).
- Do not add new dependencies unless I explicitly approve.

3) Implementation requirements:
- Follow the provided component guide/spec exactly: structure, dimensions, behavior, states, and responsive breakpoints.
- Include accessibility requirements (ARIA semantics and keyboard navigation) as described in the guide.
- Include or outline a testing checklist aligned with the guide.

4) Output:
- Provide the implementation steps briefly, then the code.
- Keep the code production-ready and consistent with the project’s existing patterns.

A concrete spec example the AI can actually follow

A good stress test is something easy to get wrong: an accessible dropdown/select with search, multi-select, loading and error states, and correct keyboard behavior.

Here’s an example spec you can paste in as the source of truth: https://uipotion.com/potions/components/dropdown-select.json

Even if you don’t build that exact component, it’s a great template for what good spec looks like: clear structure, complete states, and explicit accessibility expectations. Fewer gaps = less improvisation.

The small habit that keeps everything consistent

Consistency comes from repetition and constraints - not from writing longer prompts.

Make the assistant detect first. Make it reuse what’s already there. Give it a spec it can’t "interpret creatively."

That’s how you keep AI fast without letting it rewrite your design system on the side.