The case for compiled, typed CSS (blame AI)

#ai #css #typescript #webdev

We spent years getting TypeScript to where it is. It already checks your APIs, your components, your state. Your CSS values are still strings that nothing compiles. Why wait for a new tool when the one you have can do this today?

A 2025 academic study ^[1] found that 94% of LLM-generated compilation errors were type-check failures. GitHub's Octoverse report ^[2] cited the same stat to explain TypeScript's rise to the most-used language on the platform. In typed languages, the compiler catches most of what AI gets wrong. CSS has no compiler.

Two claims follow, and they're separable. First: CSS lacks a verification layer, and AI makes that gap expensive. Second: build-time typed styles are the fix I've landed on. TypeScript is already in the stack. Anything else is another dependency and another source of drift. You can accept the first claim and argue with the second.

AI fails at CSS

Write var(--spacign-md) and nothing fails. The browser silently falls back. Write padding: 12px when your design token says 16px. It renders. Ship it.

AI has generated width: fit-parent ^[3], a value that does not exist (the real one is fit-content). It writes padding: 12px when the design token is spacing-md at 16px ^[4], because it doesn't check your token file, it approximates. It applies Tailwind v3 logic to v4 projects ^[5], importing deprecated packages and breaking styles. As one writer put it: "AI didn't create this problem. It scaled it." ^[4]

Human developers hesitate when uncertain. AI does not. It generates code with the same confidence whether implementing a known pattern or hallucinating something that has never existed ^[3].

Linters like PostCSS and Stylelint catch syntax errors, not semantic ones. They verify grammar. What's missing is something that verifies meaning. And yes, AI writes better plain CSS than CSS-in-JS: more training data. But better unchecked CSS is still unchecked.

"AI will just get better"

Maybe. But we still need to ship code today.

Web-Bench ^[6] (ByteDance, 2025), a benchmark of real-world web development tasks, showed the then-leading model (Claude 3.7 Sonnet) at 25.1% first-pass accuracy. GitClear's 2025 analysis ^[7] of 211 million changed lines (2020-2024) found copy-pasted code rose from 8.3% to 12.3% while refactoring collapsed from 25% to under 10%. The benchmark scores go up. The real-world quality metrics go the other direction.

Simon Willison argued ^[8] that code hallucinations are the least dangerous kind, because compilers catch them. He's right, except CSS has no compiler. His optimism has a CSS-shaped hole.

"AI will get better" is a bet. A type system is a guarantee.

Where Tailwind stands

Tailwind is dominant for new projects at ~12 million weekly downloads ^[9]. Its LSP flags invalid classes, ESLint plugins enforce scale usage.

But Tailwind v4 moved configuration from JavaScript (tailwind.config.ts) to native CSS (@theme {} blocks). Simpler, yes. But the default path now authors tokens directly as CSS strings, outside any type system. You can still generate @theme from a typed source, that is exactly the move I'll argue for below, but nothing in v4 pushes you there. The path of least resistance lost its types. If AI writes @theme { --color-brand: #3b82f6 } when the designer specified #2563eb, the CSS build passes fine. Both are valid hex. The problem isn't syntax, it's that there's no contract between your styles and your TypeScript components. Meanwhile, Tailwind Labs itself is under AI pressure: revenue down 80%, three engineers laid off ^[10]. The framework thrives while the company scrambles. AI is reshaping even the most popular CSS framework's ecosystem in ways nobody planned for.

Build-time typed styles

Not runtime CSS-in-JS. styled-components, Emotion, runtime style injection: that's dead for good reasons ^[11], and it should stay dead.

This is something different. Values live in TypeScript, get checked by the compiler, and emit static CSS. Zero runtime. The output is plain CSS. The verification happens before it reaches the browser. The AI has to satisfy the TypeScript spec to produce output at all.

You can write custom validation on top: assert that a color pair meets contrast requirements, that a measurement doesn't exceed a bound. If your values already live in TypeScript, why maintain a parallel set in Sass?

Why maintain two sets of values?

TypeScript is the most-used language on GitHub ^[2] as of August 2025. Your spacing scale, your breakpoints, your theme config: they're already in .ts files.

The question isn't "should I put CSS in JavaScript?" It's "should I type the values that are already there?"

If you maintain CSS variables separately from your TypeScript tokens, you have two sets of values to keep in sync. That's where drift creeps in. Define your tokens once in TS, output to CSS variables, a Tailwind theme, responsive helpers, whatever your project needs. One source, no sync problem.

CSS variables are great. They're not a contract.

I used to dismiss CSS variables. Then I found a real use for them: responsive values from Figma design tokens that replaced a React context for window sizes. Huge simplification. I'm strict about keeping usage limited to where they genuinely earn it.

But CSS variables have specific weaknesses with AI. var(--spacign-md) is valid syntax that silently fails. When a variable is set at the root, overridden in a layout component, overridden again in a card, and consumed in a button several layers deep, AI has no way to reason about which level set it. @property adds native type checking, but it validates at render time, not build time. The wrong value still ships. Going the other direction, reading CSS vars in JavaScript with getComputedStyle is runtime string parsing. No type safety going in, no type safety coming out.

And native CSS features always lag behind in browser support. When your values live in TypeScript and compile to static CSS, you control the output. Browser compatibility becomes a build concern, not an architecture concern.

You can still output CSS variables from your typed tokens. That's not a tradeoff, it's the point. One typed source, visible to both CSS at runtime and TypeScript at build time.

Verification, not authoring

The argument is about verification, not authoring. AI made authoring effortless: it produces CSS as fast as you can ask for it. Producing correct CSS is a different problem, and nobody solved the checking part. "Design systems solve the vocabulary problem. They do not solve the verification problem." ^[4] Types are the verification layer.

The strongest counter is "just give AI better context." It's partially right. Sachin Patel's team ^[12] aligned Figma tokens with CSS variables and got reliable output. I use context engineering myself: I've written Claude Code skills and Cursor rules to keep AI aligned with codebase standards. These approaches work.

But context is a conversation. The next developer, or the next AI session without the rules loaded, can ignore it. Types are a contract. You can't compile past them. Or as a Builder.io blog post ^[13] framed it: "Without types, the AI is guessing. With types, it's reading a spec."

Off-scale is fine, as long as it's visible. An explicit m(17) is different from a magic p-[17px] buried in a Tailwind class string. And because it's structurally distinct, you can lint for it. A CI rule that flags off-scale density is trivial when escape hatches have their own syntax. When off-scale and on-scale look identical, that rule is impossible.

In practice, visual regression testing, human review, checking layouts across viewports: that work exists whether you use typed styles or not. What typed styles change is what you spend your review time on. Without them, reviewers catch both mechanical errors and visual ones. With them, the mechanical layer is handled before the code reaches review. What's left is the judgment work. There's a taxonomist quality to writing good CSS: classifying values, deciding where things belong. That part stays human. Types clear the noise so you can focus on it.

I've been building the typed-measurement piece of this with CSS-Calipers. That layer is solid: compile-time unit safety, immutable values, off-scale values that are explicit rather than invisible. The broader framework around it is not solved, and I'm not claiming it is.

Use what your project needs

This is not an all-or-nothing proposition. Nobody is asking you to rewrite your project in CSS-in-JS. Maybe you type your entire spacing scale. Maybe you type one mission-critical token that keeps breaking. Maybe you don't need any of this. You know your project best.

I'm resistant to change myself. I had a visceral reaction to CSS-in-JS when I first encountered it. Had the same reaction to CSS variables. Both times, a specific use case changed my mind. Not hype. A real problem the tool solved better than the alternatives.

The industry was right to leave runtime CSS-in-JS. Native CSS is more powerful than ever. Tailwind dominates for real reasons. The point isn't to replace any of that. It's that a verification layer should exist for the parts that matter, and you should know the tradeoff when you skip it.

The output is still the full CSS spec. Nothing is restricted. What changes is how many guardrails you put between your values and that output. One project might need strict token enforcement across every component. Another might need a single typed measurement in a critical layout. The point is you choose the constraint level, not the framework.

CSS should fail silently in the browser. That's a feature. It should fail loudly in the build. That's what's missing. I wrote about what a real CSS framework could look like if you want the longer version of that argument.