Every screen Claude or Cursor generated for me looked almost right.
Slightly different button radius. A shade off on the primary color. Spacing that was close to my scale but not on it. Each screen fine in isolation — put five of them together and the app looked like it was built by five different freelancers who'd never met.
I started calling it UI drift, and once you see it, you can't unsee it in every AI-built product on the internet.
Why drift happens
It's not the model's fault. It's a context problem:
Your design system isn't in the prompt. The AI defaults to its training-data average: generic Tailwind, purple gradients, shadcn-out-of-the-box. That's why so many vibe-coded apps look identical.
When it is in the prompt, it's stale. You pasted your tokens into a rules file three weeks ago, then changed the design. Now the AI is confidently generating against a snapshot that no longer exists.
When it's fresh, it's too big. Dumping an entire design system into context on every prompt burns tokens, slows everything down, and buries the signal — models follow a focused 2KB rules file far better than a 200KB JSON dump.
So you get to pick: generic output, outdated output, or expensive output.
I wanted a fourth option.
What I built
GliaKit is a Next.js SaaS boilerplate with a design system your AI tools actually follow. The core idea is a single source of truth with three synced views:
A Figma library — tokens, components, and screens (this part is free on Figma Community)
Cursor rules + Claude rules files — generated from the library, so they always describe the current system, not a memory of it
The Next.js codebase — components that map 1:1 to the Figma components, so what the AI generates already exists in code
When the design changes, the rules files change with it. Your AI stops hallucinating a design system and starts referencing yours.
The token-efficiency part
This was the constraint that shaped everything: the rules files are deliberately minimal. Instead of feeding the model every property of every component, they encode just the decisions — the token scale, the component names, the composition rules. Less context re-ingested per prompt means cheaper generations, faster responses, and (counterintuitively) more consistent output, because the model isn't drowning in irrelevant detail.
If you use Figma MCP, the same logic applies: the file is structured so MCP pulls compact, relevant context instead of the whole document.
What "day one" actually looks like
Duplicate the free Figma kit, restyle the tokens to your brand
Grab the boilerplate, run the sync so the rules files reflect your tokens
Prompt Cursor or Claude: "build the billing settings page"
Get a screen that uses your components, your spacing, your colors — on the first try
No "make the buttons match the other buttons" follow-up prompts. That prompt is where indie builders' evenings go to die.
Honest scope
The Figma UI kit is free — take it, use it, no strings.
The boilerplate (Next.js code + synced rules files) is paid. It's the part that took months and it's how I keep building this.
It won't make AI output pixel-perfect 100% of the time. It makes the failure mode "small fix" instead of "different app."
Try it / tear it apart
The free kit is on Figma Community, and everything else is at https://www.gliakit.com/.
I'm genuinely curious how others are handling drift — hand-maintained rules files? MCP? Just accepting the chaos? Tell me in the comments, especially if you think there's a better approach than syncing. I'd rather find out here than after v2.
Top comments (0)