The Hidden Cost of Generic UI Components: Why AI Keeps Getting Colors Wrong

The $10,000 Color Mistake

You ask Claude Code to build a dashboard. It generates 20 components. Everything looks good — until you notice button colors are inconsistent. Some use bg-blue-500, others use bg-indigo-600, and a few have hardcoded hex values like #4F46E5.

You spend the next 3 hours fixing it manually. Then you generate 10 more components next week, and the problem returns.

This isn't a bug. It's a fundamental design flaw in how AI works with generic UI libraries.

Why AI Keeps Getting Colors Wrong

When AI generates UI code using libraries like shadcn UI, Tailwind, or Material UI, it faces three critical problems:

1. No Semantic Context

Generic component libraries use arbitrary values:

// AI sees this in the docs
<Button className="bg-blue-500 hover:bg-blue-600">
  Primary Action
</Button>

The AI doesn't know that blue-500 is your "primary" color. It just sees an example. Next time it generates a button, it might use:

• bg-blue-600 (darker blue)
• bg-indigo-500 (different hue)
• #3B82F6 (hardcoded)
• bg-primary (guessing a non-existent token)

Result: Inconsistent colors across your codebase.

2. Hardcoded Values Everywhere

Look at any generic UI library:

// Typical shadcn UI component
<div className="rounded-md border border-gray-200 bg-white p-4">
  <h3 className="text-lg font-semibold text-gray-900">Title</h3>
  <p className="text-sm text-gray-600">Description</p>
</div>

Every value is hardcoded:

• gray-200 for border
• white for background
• gray-900 for heading
• gray-600 for text

When AI generates similar components, it hallucinates variations:

• Sometimes gray-100, sometimes slate-200
• Sometimes text-gray-700 instead of gray-600

Result: Your design system degrades with every AI-generated component.

3. Context Window Limitations

AI can't remember every color choice across a large codebase. Even if you include 50 existing components in the context, the AI might:

• Misremember the exact shade
• Mix patterns from different components
• Interpolate "in-between" values that don't exist in your system

Result: Gradual style drift that's hard to catch in code review.

The Hidden Cost of "Free" Components

Generic UI libraries seem free and flexible. But when you build with AI, they create hidden costs:

That's 20-40 hours per month — or $2,000-$10,000 in engineering time — just managing color consistency.

How Semantic Tokens Solve This

FramingUI takes a different approach: every color, spacing, and style is a semantic token.

Instead of hardcoded values:

// ❌ Generic library (hardcoded)
<div className="bg-blue-500 text-white">
  Primary content
</div>

You use semantic tokens:

// ✅ FramingUI (semantic)
<div className="bg-primary text-on-primary">
  Primary content
</div>

Why This Works for AI

1. Clear Intent

   • bg-primary tells AI "this is the primary brand color"
   • Not "blue-500" which could mean anything

2. Self-Documenting

   • text-error is obviously for error states
   • bg-surface-raised is clearly an elevated surface
   • AI doesn't have to guess

3. Automatically Consistent

   • AI uses bg-primary everywhere → all primary colors match
   • Change the token value → everything updates

4. Theme-Aware

   • Tokens adapt to light/dark mode automatically
   • AI doesn't need to think about theme variations

Real Example: Before & After

Before (Generic UI + AI)

AI generates a login form:

// First component
<Button className="bg-blue-500 hover:bg-blue-600 text-white">
  Sign In
</Button>

// Second component (generated later)
<Button className="bg-indigo-600 hover:bg-indigo-700 text-white">
  Create Account
</Button>

// Third component (hallucinated)
<Button className="bg-primary-600 hover:bg-primary-700 text-white">
  Continue
</Button>

Result: Three "primary" buttons, three different colors. Manual fix required.

After (FramingUI + AI)

AI generates with semantic tokens:

// All components
<Button variant="primary">Sign In</Button>
<Button variant="primary">Create Account</Button>
<Button variant="primary">Continue</Button>

// Internally uses: bg-primary text-on-primary

Result: Perfect consistency. Zero manual fixes.

The Economics of Semantic Tokens

Let's do the math:

Without Semantic Tokens:

• Time fixing inconsistencies: 30 hours/month
• Cost at $100/hour: $3,000/month
• Annual cost: $36,000

With Semantic Tokens:

• Initial setup: 4-8 hours ($400-800)
• Ongoing maintenance: ~2 hours/month ($200/month)
• Annual cost: $3,200

Savings: $32,800/year for a small team.

For a team of 5 engineers building with AI, the ROI is massive.

Getting Started with Semantic Tokens

FramingUI makes it easy:

1. Install FramingUI (it's a fork of shadcn UI)
2. Use semantic variants instead of hardcoded classes
3. Let AI generate components — they'll be consistent by default

Example:

import { Button } from '@/components/ui/button'

// AI can generate this reliably
<Button variant="primary">Primary Action</Button>
<Button variant="secondary">Secondary Action</Button>
<Button variant="destructive">Delete</Button>

Every variant maps to semantic tokens:

• primary → bg-primary, text-on-primary
• destructive → bg-error, text-on-error
• secondary → bg-secondary, text-on-secondary

Conclusion

Generic UI libraries work great when humans write code carefully. But AI doesn't work carefully — it works probabilistically.

The hidden cost isn't the library itself. It's the hundreds of hours fixing AI-generated inconsistencies because the library wasn't designed for AI.

Semantic tokens aren't just a nice-to-have. They're the difference between AI that helps and AI that creates technical debt.

FramingUI gives you the best of both worlds:

• ✅ All the components you love (shadcn UI fork)
• ✅ Semantic tokens for AI consistency
• ✅ Automatic theme support
• ✅ Zero runtime overhead

Stop fixing AI's color mistakes. Start building with semantic tokens.

---

Try FramingUI: framingui.com
Read the docs: framingui.com/docs