I've been grappling with a frustrating issue when using AI autocomplete tools like GitHub Copilot with my custom Tailwind setup. I have specific design tokens like `bg-brand-primary` and precise spacing rules, but the tool keeps suggesting basic classes like `bg-blue-500` or `w-[350px]` instead of my custom ones. The problem arises because these AI models generally make probabilistic guesses based on patterns learned from a vast dataset, which often doesn't align with the unique specifications of my codebase. Even when I provide a substantial context, it treats the `tailwind.config.js` merely as another file rather than a crucial rulebook for my design system.
After trying to find a solution that doesn't involve waiting for more intelligent models, I discovered a method to turn the AI into something more like a compiler rather than a guesser. Using Abstract Syntax Trees (ASTs) for parsing my configuration allowed me to create a more deterministic approach. Here's a quick rundown of what I did:
1. **Parse instead of read** - I transformed my `tailwind.config.js` into a static JavaScript object, referred to as the "Theme Dictionary".
2. **Intercept output** - When the AI generates a class name, it's first validated against my Theme Dictionary before being used.
3. **Self-correcting mechanism** - If the AI suggests an invalid class like `bg-navy-900`, it calculates the closest valid option (like `bg-slate-900`) in real-time.
I've wrapped this logic into an open-source extension called LazyUI as a proof of concept. I'm curious to know if anyone else has explored similar methods for enforcing strict constraints on AI outputs to address hallucination issues with custom design tokens.
3 Answers
I think your approach is interesting, but some might find using Levenshtein distance for class validation a bit excessive. It’s good for spotting typos, but isn’t it risky to silently swap classes that could lead to bugs? Just using better prompts or configuration files might do the trick as well. But if it’s effective, I'm all for it! How does it handle unusual arbitrary values?
Honestly, this sounds like a personal issue more than a universal problem. If you're working with a custom design system and Copilot can’t keep up, maybe it’s just not the right tool for you. Some of us manage fine with standard Tailwind classes.
If you’ve got a unique setup, perhaps investing time into configuring those parameters would pay off better than this extensive workaround? But hey, if it works for you, that’s great!
Haha, fair point! I get that it might not be a common struggle, but in my case, the tool kept defaulting to standard colors instead of my custom ones. Each setup is different, I guess!
This seems like an issue specific to Tailwind, which I’ve heard mixed opinions about. Personally, I wouldn't use it since I prefer more traditional styling methods. But kudos on coming up with a solution that fits your needs!
Thanks! Tailwind definitely has its fans and critics. I just enjoy tinkering with parsers, so I’m excited about the project regardless of the framework!
Great question! I’ve actually just released v1.0.3 with improvements based on feedback. Now it includes a **Safety Engine** that locks semantic prefixes and introduces a **Confidence Threshold** setting to avoid silent errors. If there’s ambiguity, it won’t correct it, keeping those red squiggles visible for you to fix.