How agent mode creates drift
Lovable's agent mode works in iterations. You describe what you want, it generates code, you refine, it regenerates. Each iteration starts fresh from your prompt plus the existing code. That "plus the existing code" part is where drift enters.
When the agent modifies a component, it reads the current styles and tries to stay consistent. But "consistent" is relative. If the existing code uses bg-gray-100 in one file and bg-slate-50 in another (because a previous generation picked a slightly different neutral), the agent might match either one. Over five or ten iterations, these micro-differences compound. The product looks assembled, not designed.
This is not a Lovable-specific problem. Every AI coding tool has this drift pattern. The difference is that Lovable's speed encourages more iterations, which accelerates the drift. The faster you build, the faster the design falls apart. Unless you anchor it.
The token-first approach
Design tokens are the anchor. Instead of letting Lovable infer design decisions from existing code, you define them explicitly in a central location that every component references. When the agent modifies a button, it doesn't look at the other buttons for color guidance. It references the token.
The implementation has two parts: a CSS variables file that defines your tokens, and prompt instructions that tell Lovable to use them.
Part 1: Define your tokens in globals.css
/* globals.css - single source of design truth */
:root {
/* Colors */
--background: #FFFFFF;
--surface: #FAFAFA;
--text-primary: #09090B;
--text-secondary: #71717A;
--text-tertiary: #A1A1AA;
--border: #E4E4E7;
--accent: #2563EB;
--accent-hover: #1D4ED8;
--destructive: #DC2626;
--success: #16A34A;
/* Typography */
--font-heading: "Inter", sans-serif;
--font-body: "Inter", sans-serif;
--font-mono: "JetBrains Mono", monospace;
/* Shape */
--radius-sm: 6px;
--radius-md: 8px;
--radius-lg: 12px;
--radius-full: 9999px;
/* Spacing */
--space-xs: 4px;
--space-sm: 8px;
--space-md: 16px;
--space-lg: 24px;
--space-xl: 32px;
--space-2xl: 48px;
}Part 2: Reference tokens in your prompts
/* Include this at the start of every Lovable prompt */
DESIGN RULES:
- All colors MUST use CSS variables from globals.css
- Never use Tailwind color classes directly (no bg-blue-500)
- Use var(--background) for page backgrounds
- Use var(--surface) for cards, modals, popovers
- Use var(--accent) for primary actions
- Use var(--border) for all borders and dividers
- Border radius: var(--radius-lg) for cards,
var(--radius-md) for buttons, var(--radius-full) for badges
- No shadows on cards. Use 1px border with var(--border).When every prompt references the same token system, every generation uses the same visual language. The fifth iteration looks like the first because they're both reading from the same source. Drift eliminated.
Setting up the first prompt right
The first Lovable generation sets the foundation. Get this right and every iteration after is cleaner. Get it wrong and you're fighting drift from generation two onward.
/* First prompt template for Lovable */
Create a React + Tailwind project with this structure:
1. Set up globals.css with these CSS variables:
[paste your token block here]
2. Create a utility file (lib/cn.ts) with clsx + twMerge
3. Build these base components using the CSS variables:
- Button (primary, secondary, ghost, destructive variants)
- Card (with CardHeader, CardContent, CardFooter)
- Input (with label and error state)
- Badge (default, success, warning, destructive)
4. Then build the main layout: [your app description]
ALL styling must reference the CSS variables.
No hardcoded colors. No Tailwind color palette classes.This prompt creates the token file and the base components in one shot. Every subsequent prompt builds on this foundation. When you ask for a settings page, Lovable sees the existing Button and Card components, sees the CSS variables, and uses them. No guessing.
The iteration guard pattern
Even with tokens in place, agents sometimes stray. The iteration guard is a prompt prefix you add to every refinement:
/* Add this prefix to every refinement prompt */
Before making changes, verify:
- All colors reference CSS variables from globals.css
- No new color values are introduced
- Border radius follows the token scale
- Spacing uses the defined scale
Now: [your actual change request]This takes 10 seconds to paste but saves entire rounds of "why did the sidebar change color?" debugging. The agent checks its own output against your constraints before shipping code.
Where to get cohesive tokens
Writing a token system from scratch requires design experience most developers don't have. Which colors pair well? What radius values feel cohesive? How do you balance a type scale? These are design skills, not coding skills.
SeedFlip handles this. Each of the 100+ design seeds is a complete, curated token system. Colors, fonts, spacing, radius, shadows. All designed to work together. Export as CSS variables, paste into your Lovable globals.css, and the foundation is set.
/* Example: SeedFlip "Amethyst" seed exported as CSS vars */
:root {
--background: #0F0B1A;
--surface: #1A1425;
--text-primary: #F5F0FF;
--text-secondary: #A78BDB;
--accent: #8B5CF6;
--accent-hover: #7C3AED;
--border: #2D2440;
--font-heading: "Space Grotesk", sans-serif;
--font-body: "Inter", sans-serif;
--radius-md: 8px;
--radius-lg: 16px;
}This is a cohesive dark purple theme. The background, surface, and border colors relate to each other (they're tonal variations, not random picks). The accent complements the palette. The fonts were chosen to pair. You get these decisions made for you by someone who cares about typography and color theory. Then Lovable executes them consistently.
Dark mode without the headache
Lovable's agent mode struggles most with dark mode because it doubles the number of color decisions. Without tokens, the dark mode palette often conflicts with the light mode palette. Buttons that were blue-500 in light mode become blue-400 in dark mode but only on some screens.
The token approach makes dark mode trivial. Define both palettes in globals.css and swap with a class or media query:
:root {
--background: #FFFFFF;
--text-primary: #09090B;
--accent: #2563EB;
}
.dark {
--background: #09090B;
--text-primary: #FAFAFA;
--accent: #3B82F6;
}Every component already references var(--background) and var(--text-primary). Adding the .dark class swaps every color automatically. No component-by-component dark mode migration. No drift between themes.
When to reset vs. iterate
If your Lovable project has already drifted, you have two options. For projects under five iterations deep, add the token file and ask Lovable to refactor existing components to use variables. For projects deeper than that, it's faster to start fresh with tokens from the beginning and rebuild. The rebuilding is fast because you're giving the agent a clear foundation this time.
Design drift in agent mode is a solved problem. Define tokens once, reference them in every prompt, and the agent stays on-brand across unlimited iterations. The 10 minutes you spend setting up a token system saves hours of visual debugging later. For more on design tokens in AI workflows, read Design Tokens for AI. For the one-click design system approach, see One-Click Design System for Vibe Coding.