The problem nobody warned me about when migrating to Tailwind v4.

The config file is gone. Tokens live in CSS now. And someone still has to write them manually from Figma.

Photo by ThisisEngineering on Unsplash

One of our developers came to me with a very specific complaint. He’d started migrating our project to Tailwind v4. The config file was gone. Everything was CSS variables now. And he was sitting there manually copying spacing values, color tokens, and border radii from our Figma file into a stylesheet — one component at a time. He looked at me and said ‘why does this still require a human?’. I didn’t have a good answer.

What actually changed in Tailwind v4

I’ll keep this simple, because most articles explaining Tailwind v4 immediately lose half their audience with jargon.

In the old way, Tailwind had a tailwind.config.js file. Developers typed your design tokens into it — colors, spacing, font sizes — and Tailwind turned them into utility classes. That file was the bridge between design and code.

Tailwind v4 removed it.

Honestly! Removing the config file was the right call. But it created a problem nobody thought through. now someone has to write all those CSS variables by hand. And in most teams, that someone ends up being a developer who’s guessing values from a design file that may or may not be accurate.”

Now tokens live directly in CSS as custom properties. what developers call CSS variables. It looks like this:

@theme {
  --color-background-primary: #6750A4;
  --spacing-button-py: 10px;
  --spacing-button-px: 16px;
  --radius-button: 20px;
  --text-button-label: 14px;
}

Clean. Modern. CSS-native. Your AI agent references var(--color-background-primary) instead of a hardcoded hex. Developers stop guessing values.

The problem? Your Figma file already has every single one of these values. Every spacing decision. Every colour token. Every radius. Every typography spec.

Writing them into a CSS file manually is just transcription. Slow, error-prone, and becomes stale the moment a design change happens.

The gap nobody talks about

Our design tokens lived in Figma variables. Properly set up — named, organized, linked to components. We’d done the work. Or so I thought.

When our developer started the Tailwind v4 migration, he had to manually look up every token value from Figma and write the CSS variable by hand. For every component.

And here’s the part that actually hurts.

For a single complex component, our navigation bar, it took almost two hours to correctly map every Figma token to its Tailwind v4 CSS variable equivalent. We have 40+ components in our system. Do that math.

Why Figma Variables alone don’t solve it

Figma doesn’t store token names next to the values they’re applied to. It stores a pointer, a variable ID that gets resolved separately. An AI agent or a developer reading the raw file takes the path of least resistance and uses the resolved hex value. The token name never makes it into the output.

So you end up with this

/* What gets written manually */
background: #6750A4;
padding: 10px 16px;
border-radius: 20px;

Instead of this

/* What should be written */
background: var(--color-background-primary);
padding: var(--spacing-button-py) var(--spacing-button-px);
border-radius: var(--radius-button);

The first version is connected to nothing. If the token changes in Figma, the CSS doesn’t know. The second version is connected to your system. Change the token once, everything updates.

Our corrective approach:

To automate Figma-to-CSS bridge, we built a Plugin — FigSpecs

FigSpecs generates component UI specs, anatomy diagrams, accessibility audits, Exports details as Tailwind v4 @theme blocks, JSON, CSS, and a component.rules.md file that is AI readable. All from a single Figma component. No copy-paste. No manual docs.

A component.rules.md is a structured annotation for AI agents to understand the component's intent, variants, states, and usage rules.

A Tailwind v4 CSS file is a ready-to-use @theme {} block with every design token correctly named and mapped:

@theme {
  --color-background-primary:  #6750A4;
  --color-text-on-primary:     #FFFFFF;
  --radius-button:             0.5rem;
  --text-button-label:         0.875rem;
  --spacing-button-gap:        0.5rem;
  --spacing-button-px:         1rem;
  --spacing-button-py:         0.625rem;
}

Drop that file into the project. Your AI agent references variable names instead of hex guesses.

Your design system stays connected to your codebase not because someone remembered to update it, but because the tooling makes it automatic.

Why this matters more than it sounds

We haven’t fully automated the entire pipeline yet. There are still edge cases. tokens that don’t map cleanly to Tailwind v4 namespaces. But the 90% case the everyday components your team ships every sprint is now handled without a human in the loop. That’s enough to change how the team works.

The Tailwind v4 migration isn’t just a CSS change. It’s a signal that the industry is moving toward design tokens as the shared language between design and code.

Which means the teams that get this right who have their tokens properly structured, properly named, and properly connected to their codebase are going to have a significant advantage when AI agents start doing more of the implementation work.

An AI agent that can reference var(--color-background-primary) is more accurate, more consistent, and easier to correct than one guessing #6750A4.

Here’s Demo:

[embed]End to end demo of FigSpecs plugin

Incase if you wish to try out our plugin: Click here

Q: Anyone else migrating to Tailwind v4 right now? How are you handling the token-to-CSS pipeline?

FigmaPlugin #DesignSystems #UXTools #Accessibility #FigSpecs#tailwindcss #figma #webdev #ai #css