DEV Community: Stéphane LaFlèche

Figma-to-code: the real shift happening

Stéphane LaFlèche — Sat, 04 Jul 2026 12:58:59 +0000

If you're shipping static sites, or building on a standard design system, the Figma MCP server is probably doing great work for you, and a lot of what follows will match what you already see. Stay for the edges, though: the moment you need a custom component, or the model edits an existing one, it is guessing again, and nobody is recording why. That is the friction this is about, for anyone trying to make the design-to-code pipeline more modular, maintainable, robust, tool-agnostic, and get better code out the other end.

I started writing this as a takedown. It didn't survive the reporting.

The plan was simple: Figma-to-code is overhyped, the demos are slick, and on most teams the reality is a mess. I was going to show you how bad it gets: the hard-coded colours, the components the model invents, the output that looks right until you actually read it.

Then I came across monday.com's design-to-code pipeline¹, and I was genuinely impressed.

What monday showed me is that it can be done well, even if a developer is still cleaning up the code behind the demo.

The closer I looked, the more the piece stopped being about tools at all. The tools, the pipelines, the pricing, all of it keeps shifting. But underneath that noise is a quieter shift, the one I did not expect and cannot stop thinking about: a change in who actually does the work, and, perhaps more importantly, who owns the decisions the tools quietly make for us. That is where this ends up, and I think it raises deeper questions about code quality and responsibility.

On the surface, it looks settled

Point a large language model at a Figma file through an MCP server, and it hands you back components. That is the pipeline the whole industry is converging on. Design happens in Figma; the code gets generated by a small set of AI agents: Copilot, Cursor, Claude Code, Codex.

That convergence is real, and the numbers behind it are lopsided. Figma is the default surface, named by 82.3% of designers as their primary UI-design tool.² Its own codegen feature, Figma Make, is already used weekly by around 60% of Figma customers who spend over $100k a year.³ The inputs are consolidating onto one tool.

So is the format. Design tokens reached their first stable standard, DTCG, in late 2025, backed by roughly two dozen of the largest names in the field: Adobe, Google, Microsoft, Meta, Amazon, Figma.⁴ The build tooling is adopting it. Style Dictionary,⁵ the most widely used token transformer, now ships first-class DTCG support. Smaller tools like Terrazzo⁶ are DTCG-native, built around the format from the start. Google publishes DESIGN.md,⁷ a way to describe a design system to a coding agent. Everyone is pointing the same direction. Even Figma backs the standard. A widely used community token plugin for Figma, Tokens Studio,⁸ reads and writes the DTCG format too. The incumbent is lining up behind an open format that makes its own tool easier to leave.

From a distance, the problem looks solved. One tool for design, a converging standard for tokens, a handful of capable agents to write the code. Call this the shift everyone already noticed: the tooling converged. Settled.

Then you actually run it

Point an unscaffolded model at a real Figma file and the output is plausible until you read it. It reaches for components that are not in your system, hard-codes colours that should be tokens, and mixes conventions across versions (Tailwind v3 patterns dropped into a v4 project).⁹ Sometimes it invents CSS outright, a value like fit-parent that no browser understands.¹⁰ This is not a skill problem or a bad prompt. It is what the naive pipeline does, to everyone. It is not a model problem either. Output quality varies sharply, by model and by task, and it is improving fast. But a stronger model guesses better; it does not stop guessing, because the information it needs was never in the file for any model to read.

Figma says so itself. Its own MCP setup guide¹¹ is blunt about the limit: without Code Connect linking your Figma components to your real code, "the model is guessing." Coming from the vendor of the design tool itself, that admission is worth more than any third-party benchmark.

Why does it guess? Because the file hands it a bare value with no meaning: a FLOAT of 10, with nothing to say whether that is ten pixels, a z-index, or ten milliseconds. I dug into that failure in Even Figma isn't sure about its own design tokens; the short version is that the step from raw value to semantic meaning, the resolve step, is unowned and lossy. The model has to infer what the design meant, because the file never says.

To be fair, Figma is closing part of this. Native DTCG export is rolling out, so you can pull your tokens out as typed JSON where a value finally carries its meaning.¹² But that types the tokens you export, not the values a model reads back when it generates code from a component. On that path it often gets a bare resolved number with no token attached, and is left to improvise. That gap is here now, not on some roadmap, and it is the one monday set out to close.

The token is only the visible edge of it. "Point an LLM at Figma, get UI" looks like one task, but it is a stack of collapsed decisions the model resolves silently in a single pass. Amrutha Kollu¹³ frames the split well. Some of those decisions are deterministic and have a correct answer: which token, which spacing, which component. Others are genuine judgment calls. The mistake is handing both kinds to the model at once and hoping. By default, nobody owns that deterministic layer, the missing middle I wrote about before, so the model fills it in.

You do not have to take my word for it. When Yi Gui and colleagues built Figma2Code,¹⁴ a benchmark for turning real Figma files into code, the strongest proprietary models produced visually faithful output but stayed weak on layout responsiveness and maintainability, because they map the primitive values straight out of the Figma metadata without recovering the structure. Faithful pixels, guessed architecture.

If this were a prompting problem, the vendor that owns the entire stack would have solved it. Figma didn't. Figma Make, its own generator, produces standalone code by default; to make it build against your design system, you first have to author "Make kits"¹⁵ that package your components, tokens, and guidelines so the generator has something real to work from. So even the company that owns the whole stack cannot make its generator fit your design system for you. It hands you some tooling, but as it stands today that tooling is thin. You still author and maintain the kits yourself, and that is not free. It is real, ongoing work, heaviest on the small or mid-size team just trying to get up and running. Worse, those kits are Figma-specific, so the effort ties you tightly to one vendor instead of leaving you portable.

None of this is a technical wall. DTCG is a standard, and any model can read agnostic tokens from any system that exports them cleanly. What keeps you locked in is not the tech; it is that every vendor has a reason to keep you inside its walls. That could change. Right now it has not, and that is the tell. The problem is not the prompt. It is the architecture.

What monday built instead

The teams I've seen who have solid design-to-code pipelines stopped tinkering with prompts and rebuilt the pipeline itself. The team at monday.com hit exactly this problem, and instead of prompting harder, they built the sharpest version of the standard pipeline I have found anywhere publicly. It is not a new kind of thing. It is a far better-engineered version of what everyone is already reaching for: a real multi-agent pipeline, and a simple but effective workaround for the token problem. Their engineering team wrote it up¹: the naive version failed the same way it fails everyone. "The problem wasn't that the model was bad," they note. "It's that the model had no understanding of what the design system actually was... Without that context, it guessed." So they gave it the understanding.

There is one detail that amuses me. Figma hands over bare values (the FLOAT 10 problem from earlier), so monday makes the spacing and token values visible inside the design itself, laid out for the model to read. The spec, they say, is written for AI, not for a person.¹⁶ It is a workaround for sure, not elegant. However, sometimes the low-tech fix is the easiest one, even when the rest of what they built is this advanced.

The shape is a pipeline of eleven small nodes, each with one job, orchestrated with LangGraph. It pulls the raw design out of Figma, then resolves it: raw values become semantic tokens, components get matched against the real library, examples get retrieved. What comes out the far end is not code. It is structured context, everything the model needs to know about the design, handed to whatever agent the developer already runs in Cursor.

That last choice is the clever one. Internally, monday runs hundreds of microfrontends on different React and design-system versions, so forcing a single generated code style would break ownership. By returning context instead of code, they kept the codegen model-agnostic and left authority with each team. They even exposed the whole agent as an MCP tool, so from Cursor's side it is just another tool call. In their words, this is "orchestration, not magic."¹

There is a second thing I appreciate, further down the flow. What the developer ends up with is not a bare component but a full Storybook entry. The stories, the tests, and the documentation are generated alongside it, and the props table is drawn from the real component rather than filled in by hand.¹⁷ The deliverable is a documented, tested component, not code that merely renders.

It works for one reason: someone owns the resolve step that almost everyone else leaves to chance. It also took a mature design system to resolve against, a dedicated pipeline, and the engineers to build and run it. Hold onto that, because it is where the story turns.

Where even monday stops

For all that, it is still not hands-off. The honest part is that they say so themselves.

In their walkthrough talk,¹⁸ Elad Mizrahi, monday's design-systems lead, puts the number at 70 to 90 percent of a component's code generated, higher for the simple ones, lower for the complex, and then "our developers take it from there." Impressive, and a long way from automatic. Someone still writes the last 10 to 30 percent.

Notice what that number costs, too. The 70 to 90 percent is what a mature design system, a dedicated pipeline, and a team of engineers buys you, not to mention an AI bill they have never put a number on. It is the ceiling for the best-resourced setup in the room, not the starting line for everyone else.

One of Mizrahi's observations points ahead. The model does better on new components than on edits to old ones.¹⁹ He does not say why. My guess is that the old components carry incomplete recorded reasoning to edit against, so the model is back to guessing what the original decision was.

You can watch the ceiling on camera. Asked to flip a component to an inverted colour scheme live, the model missed; he fed it an example; it missed again. This component, he explained, "we need to do some overrides to make it work," and he was candid: "when you show it to somebody it's not always working."²⁰ So he fixed it himself, by hand, applying the override the model could not. The pipeline got him close; a person closed the last gap.

Even with its faults, you could argue this will only keep getting better with time. The real strength here is not the last mile of code; it is the shape of the multi-agent pipeline and the guardrails and rules they have built around their ecosystem. Every feature still gets a manual design review and a manual code review; the changes "still need to be approved by a person." As he puts it, "we don't want to just rely blindly on AI."²¹ This is a very good head start, not an autopilot.

The wall isn't a monday problem

The wall is not a monday problem. The same ceiling shows up across setups that could not be more different. At Shopify, designers prototype in a code-connected clone of the actual admin. A designer there described the handoff plainly: the generated code gets an engineer to about 80 percent,²² and the rest is the tightening, the internationalization of strings, the polish, the slop code, the parts that are not production-aligned. At Ramp, a designer using an off-the-shelf prototyping tool with rough approximations of the design system gets to about 70 percent, then goes back into Figma for the real handoff.²³ Line the self-reported numbers up and they cluster tight: monday's 70 to 90 percent,¹⁸ Shopify's 80, Ramp's 70. Optimistic, self-reported figures.²⁴ Whether it is monday's bespoke pipeline or Ramp's off-the-shelf tool, the number lands in the same place.

There is a stranger shift buried in those setups. Here is what I expected. With seemingly every company now hiring full-stack developers, I assumed the developers would be the ones vibe-coding the UI, reaching for AI to get their own work done faster. What I found is the reverse: it is the designers building the prototypes, and the dev team reuses and finishes them. That inversion blurs the line between designer and developer, the same pendulum I wrote about with the Dreamweaver era.

I will be honest: I am skeptical of that number as a measure of code quality. Even 70 percent seems high unless the component is very simple. Pointing Cursor and Claude at a Figma file through the MCP server, I have had output that looked 70 percent done and turned out closer to 30 once I read it, because the number counts only the visible layer. The layout and the happy path are the cheap part; the states, the edge cases, the accessibility, and the production-alignment are most of the real work, and none of it shows up in the demo that produced the number. That is where a developer comes in. Ramp's designer admits those prototypes are not even functional.²³ The prototype is not the product.

I doubt those percentages count accessibility at all, and it is the clearest thing a static Figma file cannot carry: no focus order, no ARIA role, no announced state, so the model guesses. Where it has been measured, the default fails: a 2025 benchmark that put four leading models, Claude and GPT-4o among them, through eleven standard components found all of them producing accessibility violations that took follow-up prompting to clear,²⁵ and even shadcn/ui, a library sold as accessible by default, ships an example component missing three required ARIA attributes.²⁶ This is less about the model being weak than about a decision no one owns, the least-measured layer because it is the least recorded.

None of that makes the prototype worthless. Getting a designer to a clickable version of the real thing is genuinely useful. They feel how it behaves, they catch what a static mockup hides, and they can put it in front of a stakeholder to win sign-off before anyone writes production code. The generation earns its keep. It just earns it as a prototype, not as the product.

The field beyond them is crowded. Some generate from scratch (v0, Lovable, Bolt, Figma Make);²⁷ some do vendor codegen (Builder.io, Anima, Figma's own Dev Mode and Code Connect);²⁸ some make the canvas the code (Subframe, Paper).²⁹ Others work the edges: Google's DESIGN.md⁷ and Christine Vallaure³⁰ improve the input, Brad Frost³¹ constrains generation to the system, Romina Kavcic³² detects and heals drift, and Amrutha Kollu's Fixel¹³ verifies the generated code against live Figma on every pull request, blocking the merge when it drifts and posting the difference back onto the canvas. I can't do justice to any of them here; the point is to document a snapshot of the current shape of the field.

Step back and the gap is clear: we are trying plenty of ways to generate the code, but no one is fully mapping the decisions that need to be made.

Results will vary

The pipeline that looks settled is not settled, and it is unsettled in two separate ways. Getting started is easy; getting good results is not, and that takes a foundation most teams do not have. Then there is an external market that will not sit still. They are not the same problem, and blaming the tools for the first one is a mistake.

Start with the prerequisite. Even monday's pipeline presupposes a mature, documented design system to resolve against, and most teams do not have one. Romina Kavcic analyzed 158 public design systems³³ and the drop-off is steep: 89 percent ship code examples, but only 37 percent document usage guidelines, 21 percent accessibility, and 13 percent the content inside components. The systems that score full marks are Polaris,³⁴ Paste,³⁵ and eBay's Playbook,³⁶ the ones run by companies with dedicated infrastructure teams and years behind them. Her conclusion is the one that lands here: "agents can only work with what's documented... many systems aren't ready for a human to use properly, let alone a machine. Fix the layers first." This part is not a failure of the AI. It is a mirror held up to how most design systems are actually run. Point an agent at a chaotic system and it does not fix the chaos; it automates it at scale. Garbage in, garbage out, faster.

There is a fair objection here: just adopt a standard design system like MUI or shadcn and inherit a documented, mature foundation. For a small team starting out, that is genuinely the better move. But it stops covering you the moment you need custom work, and then you are back to authoring and documenting the decisions the model cannot make on its own, the exact foundation most teams were just found to be missing. A standard system is a great place to start. It is not a place most real products get to stay.

The ground keeps moving

Clear that barrier, build a pristine foundation, and you are still not on solid ground. This is the only part of the piece with a dollar sign in it, and you do not need to care about stocks to read it. But the economics underneath these tools are brittle, and that matters for your pipeline.

Start with the bill. The AI coding underneath all of this is sold below what it costs to run, funded by investors betting demand catches up.³⁷ It might. But the gap is stark: Anthropic, whose Claude models most of these tools run on,³⁸ just committed to pay xAI $1.25 billion a month for GPUs, per SpaceX's own SEC filing,³⁹ while its CFO testified in court that the company has earned a little over $5 billion across its whole existence.⁴⁰ A capital-fuelled buildout running ahead of its revenue is a shape we have seen before.⁴¹ The price you build against today is not the price you are promised tomorrow. GitHub already moved Copilot to metered billing;⁴² monday can absorb a reprice, but the three-person team running the same agents is exactly who gets caught when the meter turns on. The deeper you build on it, the worse the exposure: a pipeline scaffolded to one model does not swap out cleanly.

The ground under the tools is moving too. Figma peaked near $142 a share after its 2025 IPO and trades in the low $20s now; Adobe, still posting record revenue, is down more than a third on the year.⁴³ You do not need to call where any of it lands to plan around it.

So what do you do while all of this keeps moving? You keep your project as loosely coupled to any one tool as you can. The pull is always toward the single integrated vendor that does everything, and it is a real pull, because one place to design, generate, and deploy is genuinely easier. Resist it anyway, because the dominant design tool has already turned over twice in about fifteen years, Photoshop to Sketch to Figma,⁴⁴ and betting your whole pipeline on today's leader is a bet. Treat any one vendor as a swappable adapter, and keep the parts you own (the resolve step, the token layer, the codegen) open, decoupled, and portable. In times this uncertain, the decoupled project is the one that survives the next shift.

The shift I didn't see coming

The shift I did not see coming is not in the tooling. It is in who does the work, and it is already happening.

Designer ownership spreads up

On one side, designer ownership spreads up the pipeline into code. They vibe-code the prototype now, they feel the real thing behave, they win the stakeholder sign-off, and they do it in a running interface instead of a static mockup. That is a genuine expansion of the job. It is also bounded: the prototypes are "not functional," the demo is not the product, and the layer they own stops at the prototype. I would call this role prototyping designer: a designer who now designs or validates their work in code, up to the edge of production.

Developer ownership shrinks down

On the other side, a developer's role shrinks down, farther in the pipeline. They pick the work up later now, cleaning and finishing the code after its shape is already set, and they are less involved in the early structural decisions they used to own. That leaves a gap. The decisions that need the most engineering judgment are the ones no human is clearly making anymore, so the model guesses them.

The missing middle: decisions

Here is where I stop reporting and start speculating. I do not think the gap is mainly about resources or model quality; resources get you to this ceiling, and better models will keep nudging the percentage up. I think it is about what the pipeline actually carries. Concretely, monday's pipeline resolves values: it turns a raw Figma value into the right semantic token. What it does not carry is decisions, the recorded reasoning for why a component was built the way it was. When the model edits an old component, it has no record of that reasoning, so it is left to assume. Kavcic, who has built one of these systems herself, names the cost of that plainly: "when a human expert fails, they come back with a reason... with agents, 25 failures land on your desk, and none of them come with insight. No ownership, no explanation, no learning."³² A pipeline that cannot explain itself cannot really be trusted to maintain itself. Or, as she puts it, AI cannot fix taste.

The Design Engineer

Someone has to own that gap, and there is already a name for the person who sits between design and engineering: a Design Engineer.⁴⁵ What is new is how they spend their time. Part of it is making the decisions the pipeline leaves unmade, mapping the design into terms the code and the model can both act on. Those decisions run a wide range: at the simple end, a design token to a code variable, where the designer's "x" becomes the code's "y"; in between, a relationship, where a new component is really a variation of an existing one to import and reuse; at the hard end, major architecture decisions, splitting one screen into ten microfrontends across separate repos, frameworks, and design systems. Beyond the mapping, I am speculating. A Design Engineer might also push prototypes the last stretch toward production. My impression is that the role works best when they sit close to the designers as they prototype, not only downstream once the code needs finishing. Close to both sides is where they would keep finding new ways to make the system itself better. Write the decision down and a model can execute it. It still cannot reliably make it for you.

Maybe one day a model does that mapping too, if it gets good enough. But someone or something still has to own it, and the ownership is the durable part, not the person doing it.

What monday built, by hand and in private, is the closest thing to closing that gap I have found, a real step in the right direction. What it still lacks is the mapping: its context resolves values and is regenerated from the design on every run, not a record of the decisions that a team owns and re-enters.

There is a harder edge to owning that last mile. Companies want to move fast, and something that looks 80 percent done looks 80 percent done to a boss, who cannot see that most of the real work is the part that never shows. So the pressure is to ship: the demo convinces, and the person who says "not yet" becomes the visible bottleneck. Organizations are being told to treat AI as a multiplier, and they are learning to count the output: components shipped, pull requests merged. Against that scoreboard, holding the line on quality does not look like protecting the product. It looks like slowing it down. Owning the work now means owning that pressure too.

Now what?

Here is the anticlimax; the fix is boring: decoupling. Keeping the parts of a system independent so you can swap one without breaking the rest has been a foundation of good software for decades. We already know how to do this.

This is not a call to go back. The roles are shifting, and they will keep shifting. AI is part of that, and the speed is real. But we are still in the hype phase, and the fear of missing out is pushing teams to collapse every boundary at once, before the industry has settled. Keep the discipline we already have while the ground is still moving. The lines will move; move them with purpose, not because a demo felt fast.

Whatever stack you are on, start by recording the decisions, not just the tokens: write down the reasoning the pipeline is otherwise left to assume, so the next edit works from a record instead of inventing one. Keep the resolve step, the token layer, and the codegen modular and portable. The decisions are the part to hold onto, precisely because they are the part the model is worst at.

Right now everyone is rebuilding that layer in private. Custom pipelines will always exist, and that is fine. I just wish we had a good open-source option too, decoupled enough that no one is locked to a single vendor, LLM, or tool. It is modular, so no one needs to build the whole thing. Working on a piece? A resolve step, a token layer, typed CSS inputs, a codegen, a way to record the decisions? Tell me about it in the comments. A decoupled system comes together one part at a time. I would like to build it with you.

Even Figma isn't sure about its own design tokens

Stéphane LaFlèche — Thu, 25 Jun 2026 21:32:32 +0000

The whole industry seems to have agreed on a standard for design tokens. The shift it sets up is still on its way.

Design tokens are not new. The term was coined in 2014, at Salesforce, by Jina Anne and Jon Levine.¹ By 2017, Amazon had open-sourced Style Dictionary and the idea had spread well past Salesforce. We have been shipping design tokens for over a decade.

What we never did, in all that time, was agree on a format. Every tool and every team rolled its own shape. There was never one neutral way to write a token down, its value and its meaning, so that any other tool could read it.

Have you heard of DTCG? I hadn't, until recently. It is the Design Tokens Community Group, a W3C effort to finally settle that format.² The repo is quiet, but that is because the spec reached its first stable version in late 2025, not because anyone walked away. The quiet is a thing being finished, not abandoned.

The list of who is backing it is not quiet at all.

Adobe. Google. Microsoft. Meta. Amazon. Shopify. Salesforce. Sony. Pinterest. The New York Times. Disney. Framer. Penpot. Figma. Plus a dozen more.²

That is not a side project. That is most of the industry quietly agreeing on something. One of those names, Figma, is the reason for the title of this piece. We will get to it, because the irony is the whole point.

Here is my bet, and I will say up front that it is a bet. I think a storm is coming for design tooling. You do not have to believe me about the storm, because the bet does not depend on it. If you are wiring your tokens straight into one vendor's format, you are exposed. Anchor them to the open standard instead and you are not. The downside is lopsided. If I am wrong, you have lost almost nothing. If I am even half right, everyone hard-coded to a single tool is facing a rewrite.

The format is young and already fragmenting. That is the point.

The obvious objection is that the standard is too new to bet on, and already splintering. It is splintering. Google's DESIGN.md takes DTCG as inspiration and then forks the schema into its own shape, prose rationale wrapped around DTCG-style tokens.³ Other tools keep their own dialects. This is normal. It is the browser wars again, the old web pattern where everyone agrees on a direction and argues about the details for a few years.

What matters is where they argue. The forks agree on the base: the primitive tokens, colours, spacing, radii, and the reference syntax. They diverge at the edge, on composite tokens like typography, shadows, and gradients, which are the youngest part of the spec and where tool support still trails.⁴ So the disagreement sits in one known place, and it is closing rather than spreading. Style Dictionary, Tokens Studio, and Terrazzo are all converging on the same base, and there is already a joint Style Dictionary and Terrazzo proposal for a shared format.⁵

That is the case for anchoring to the standard rather than to any one flavour. DTCG is vendor-neutral and governed in the open under the W3C; a company's fork is governed by that company. The forks are not replacing the standard; they ride on it. The closer analyses call DESIGN.md a wrapper around DTCG tokens, not a competitor.³ You build on the settled base and adapt to whatever flavour wins at the edge.

One honest caveat. That base is rock-solid for primitive tokens today, and more aspirational for composites. If your tokens are colours and spacing, you can lean on the standard now. If they are type ramps and elevation shadows, you are betting slightly ahead of the tooling. Worth knowing before you wire it up.

Which brings us to Figma

Figma is on that buy-in list. Figma also cannot tell you what its own variables mean.

Open a Figma variable and you get a bare number. A FLOAT of 10. Is that 10px, a z-index of 10, or 10ms? The file does not say. You guess from context. So does any tool reading it. So does any LLM you point at it. Getting those values out in clean DTCG form still means reaching for a community plugin today; Figma's native export is rolling out, but it does not cover the composite tokens yet.⁶ The most valuable design tool in the world has not settled its own token format. That is the irony the title promised.

It gets sharper. Figma went public in July 2025 as one of the year's hottest IPOs and popped to around $142. A year later it trades near $17, more than 85% below that peak.⁷ The cause is contested. Frothy valuation, widening losses, AI pressure, take your pick; I will not pretend to know it. The point is narrower. A year ago, betting your token pipeline on Figma's permanence looked safe. It looks different now.

Here is what makes the bet easy, though: you do not need Figma to fall. Figma is on the DTCG list, and it is already rolling out native DTCG export.⁶ The rollout is incremental, but the direction is set. Anchor to the standard and you win whether Figma thrives or fades. That is the whole shape of the bet.

It is not just Figma

If Figma feels like a special case, look at Adobe. Adobe is the giant that tried to buy Figma for twenty billion dollars, got blocked by European and UK regulators, and paid a record one-billion-dollar fee to walk away.⁸ Adobe is also on the DTCG list. In 2026, Adobe is making more money than ever and watching its stock fall about 30% anyway.⁹

That is the cleaner version of the whole argument. Revenue is up and the AI products are growing, yet the market is marking the company down by a third on a single fear: nobody knows what AI will do to creative software. The fundamentals are fine. The uncertainty is what is being priced. When the most entrenched tool company in the industry gets repriced on "we cannot see what is coming," that uncertainty is not a Figma problem. It is the weather.

The standard does not make the hard part easy

None of this makes anchoring to DTCG free. Getting clean tokens out of a messy tool is the FLOAT 10 problem again: something has to decide whether that 10 is a length or a duration, and the standard will not decide it for you. There is no free lunch, which is the same point I made last time: the tooling gets you a real step closer; the judgment stays a human's to own. What the standard gives you is a stable target to aim that judgment at, one format instead of a converter per tool.

You might object that the glue is throwaway: with Figma's native export still incomplete, you build a Figma-to-DTCG adapter now and bin it the day Figma ships full support. True, but that adapter is the only disposable piece. Everything downstream stays aimed at the standard, so when the adapter goes, nothing else moves. Couple to the tool instead and the same change rewrites the whole chain. The loose part today is exactly that Figma-to-token step, so make it the deliberately disposable one. When native support lands, the rest of your app is already built on the standard, and you just start pulling clean tokens straight from Figma.

What anchoring actually looks like

Put DTCG in the middle, and build that layer to expect change. The format itself will keep shifting, and depending on the company you work for, your house standard might be a fork of it rather than DTCG proper. A middle layer built to absorb those variants stays resilient today, and it leaves you positioned to adapt the moment the industry consolidates on DTCG. Keep your source of truth there and generate everything downstream from it: your Figma variables, your CSS custom properties, your iOS and Android tokens. The design tool stops owning your tokens and becomes one more consumer of them. That same DTCG source is the input to the typed foundation I argued for in an earlier piece: the standard upstream, a typed layer downstream.

Better tokens are not the whole answer. They are one piece of that same larger problem: using AI to turn designs into systems, and who owns the decisions in the middle. A shared format settles where your tokens live. The system they feed is still yours to design.

The Design Tokens Community Group is doing quiet, unglamorous, genuinely important work, and most developers have never heard of it. If you build tooling in this space, it is worth your attention, and worth building toward. I would like to hear from anyone already betting this way, and from anyone who thinks the bet is wrong. That is the conversation I am trying to start.

"Design token" was coined at Salesforce by Jina Anne (with Jon Levine) in 2014, on the Lightning Design System; broad adoption followed around 2017 with Amazon's Style Dictionary. See the design-token histories ("The incomplete history of design tokens", Design Systems Collective; Smashing Magazine's interview with Jina Anne). ↩
The Design Tokens Community Group is a W3C community group; its Design Tokens Format Module reached first-stable (v2025.10) in October 2025, with 20+ editor organizations and 24+ participating companies (Adobe, Google, Microsoft, Meta, Amazon, Shopify, Salesforce, Figma, Framer, Penpot, and more). See w3.org/community/design-tokens and designtokens.org. Verify the participant list and date at publish. ↩
Google open-sourced DESIGN.md in April 2026; it bases its tokens on DTCG but diverges ("inspired by, not strict compliance"). Independent analysis frames DESIGN.md as a wrapper that contains DTCG tokens plus prose rationale, complementing the standard rather than replacing it. ↩
DTCG 2025.10 defines composite token types (typography, gradients, shadows), but real-world tool support for composites lags the primitives, and composite-token export is an active area of discussion. The bet is strongest for primitive tokens today and more aspirational for composites. Verify which composite types are normative-stable at publish (Design Tokens Format Module 2025.10; Figma forum "DTCG Composite Token Export Support"). ↩
Style Dictionary v4 has first-class DTCG support; Tokens Studio and Terrazzo are reference implementations, and there is a joint Style Dictionary and Terrazzo RFC on a shared token-listing format (styledictionary.com/info/dtcg; GitHub style-dictionary discussion #1479). ↩
Figma announced native DTCG variable export at Schema 2025. Confirmed rolling out as of June 2026: you can right-click a variable collection and Export to JSON in DTCG-aligned form, then run it through Style Dictionary. The rollout is still progressive and spec compliance is incomplete (the description field is dropped, and composite tokens still trail), so community plugins (Token Press and others) provide the fuller export today. Re-verify exact status at publish. ↩
Figma (NYSE: FIG) IPO'd in July 2025 at $33, closed its first day near $115 and peaked around $142 (closing high ~$122 on 1 Aug 2025). By late June 2026 it traded near $17, more than 85% below that peak. Figures move daily; re-verify at publish (stockanalysis.com/stocks/fig; macrotrends.net/stocks/charts/FIG). ↩
Adobe agreed to acquire Figma for ~$20B in September 2022; the deal was terminated in December 2023 after European Commission and UK CMA antitrust pushback, with Adobe paying a $1B reverse termination fee (CNBC; Axios; Adobe SEC 8-K). ↩
Adobe (NASDAQ: ADBE) was down roughly 30% in 2026 (sources vary, about 23% to 37% by date and baseline, and ~46% from its all-time peak), at a multi-year low despite record revenue and a growing Firefly business, on fears that generative AI commoditizes creative software. One analysis called it "narrative risk being priced as terminal risk, which the fundamentals do not yet confirm." Verify the current figure at publish. ↩

We're making the Dreamweaver mistake again, on purpose this time

Stéphane LaFlèche — Wed, 24 Jun 2026 20:37:51 +0000

We spent twenty years getting designers out of the code. AI just put the design back in charge of it.

The pendulum swings back

Designers used to be in the code. In the Dreamweaver and WYSIWYG era, you laid out a page in a visual tool and it wrote the markup for you. The industry then spent the better part of twenty years undoing that. We drew a line: designers design, developers build, and a human translates between the two.

AI is swinging the pendulum back. Not by putting designers back in the code, but by handing their design to a machine that writes it. Point the model at the file, get components out. The design drives the code again.

Here is the part that should give you pause. This is not a clean return to the Dreamweaver days. Back then, however messy the generated markup was, a person still sat in the translation and owned it. Now the design goes straight to code with no one in the driver's seat. That seat is where quality used to get enforced.

Two quick things before I go further, because this argument gets misread in two predictable ways.

First, this is not a knock on designers. Designers do great work. The point is a distinction. What makes a great design file is not what makes a great design system, or what makes good code. A file is judged on the design. A system is judged on reuse, on states, on durability. The AI workflow blurs that line, and the blur is the whole subject.

Second, if you are building a simple static site, pointing AI at the design is genuinely fine. The snapshot is the thing. Ship it. The problem I am describing only bites when the design is meant to become a reusable system: a design system, a custom CMS, a dynamic UI. Keep that scope in mind.

The dream is real

I want to be fair to the dream, because it is seductive and it is partly true. Point AI at the design, get working code, one step.

AI is genuinely valuable. I use it. It has let me do things I could not have done before, and finish projects under tight deadlines in codebases I did not know well. I am not here to tell you the tool is bad.

But notice where that value lands. It lands at the snapshot level. Real value is not the same thing as a foundation. That gap is the rest of this post.

A design is not a foundation

Here is the concrete failure, and it is not hypothetical. Teams build entire token pipelines around the variable names a designer chose in Figma. Naming is a design decision, but auto-translation quietly promotes it to a load-bearing contract. Rename one variable in the design file and the pipeline snaps three steps downstream. The design is doing a foundation's job, and breaking, because it was never built for it.

You can see it in a single pair of names. --blue-500 is a value; --color-primary is an intent. A system should depend on the intent, and AI cannot reliably tell which one the design meant.

The obvious fix is to train designers to name things the system-correct way. But that points the effort at the wrong person. I love working with designers, but the answer is not to turn them into systems engineers, negotiating every token name. Translating their vision into a durable system is my job, not theirs. That translation wants to be a pipeline: map the design tokens onto a universal standard, then watch for drift. I will come back to what that standard is.

Naming is only the first failure mode. Set it aside and a deeper one remains. A design is a static snapshot. It shows one state of one screen. It does not encode reusable versus one-off, the empty, loading, and error states, what is content-driven versus fixed, or how a CMS feeds it. That systemic context lives in the developer's head and in the code. It is not in the file.

The industry has noticed the input problem, and it is moving on it. Google recently open-sourced DESIGN.md, a format for handing a structured design system to a coding agent instead of a raw file, and a catalogue of them is already forming.¹ That is a real step, and it tells you the input was a weak link all along. Hold that thought, because where DESIGN.md stops is exactly the point.

The deeper limit is not the input format. It is that the design, in any form, is the wrong source for the decisions. The model's best case is the guts of the design file, an artifact optimized for none of the things a foundation needs: not design-system structure, not coding best practices, not the developer or agent experience. Its worst case is a screenshot, pixels with no structure at all. Even a flawless extraction cannot supply the architectural decisions a human makes to accommodate a design.² The deciding stays human.

So the verdict. A design is not a foundation. Auto-translating it into code silently promotes it to one, and it was never built for the role.

People are working on this

This gap is real, and a lot of people are working on it right now, from the biggest players to solo builders. Google's DESIGN.md is one move. An ecosystem has formed around it almost overnight, and it is already being put to the test in production. My friend Amrutha Kollu is one of the independent builders coming at it. Her tool, Fixel, validates your code against Figma in continuous integration and catches design-system drift before it merges. When it finds drift, it posts the finding back onto the Figma canvas as a comment, so the designer sees it in the place they already work.³ It is promising work on a real problem.

Where all of this lands is genuinely open. A lot of smart people are coming at the same problem from different angles at once. That open question is the honest state of things, and it is a big part of why I am writing this.

I want to be precise about where it sits, because the boundaries are the interesting part. Fixel is on the code side, and it does not claim to have solved the whole thing. The limit worth naming, and I mean it as architecture, not criticism: it reads directly from the design tool, so any tool-coupled approach risks going obsolete unless it targets the open standard underneath. That standard is the W3C Design Tokens format, or DTCG, the vendor-neutral spec the major tools are converging on, and it is the durable anchor here.

The missing middle

You might think the newest tools already close this. They have gone well past reading a screenshot. Claude Design imports your design system straight from your codebase and checks its output against it before you see it.⁴ Google's Stitch reads your tokens before it draws a screen. That is real, and it is the convert step getting genuinely good.

But two things none of it does. It assumes the system already exists and is clean enough to import, which means someone built that foundation and still owns it. It also checks only once, at generation. The harder problem is what happens after the code merges, when the design and the system keep moving and quietly drift apart.

So that is where this leaves us. Not with the design driving the code, and not with a person hand-translating every screen either. It leaves us with a middle that someone has to own.

Here is the bet I would make on what the missing middle looks like. I think it starts with typed CSS inputs at build time: a foundation where a value carries a type and a meaning, not just a string the model can get wrong. On top of that, the AI does what it is good at. It pulls the variables out of the design and proposes how they map onto the system you already have. Then the Design Engineer does what only they can. They shape that proposal into the system they actually want, decide what each value means, and set the behaviour and the success criteria the result has to meet. Typed inputs and automated checks keep the AI's suggestions honest.

Those decisions do not live in someone's head, or get re-derived on every run. They become an artifact: a committed, versioned record of how this design maps onto the system, owned by the engineer. Fixel already does a version of this. Its overrides registry commits each intentional deviation to git with a reason and a timestamp, an audit trail instead of a silent guess. This is the part DESIGN.md cannot reach. Its prose "why" is re-read and re-interpreted by the model on every run, where a committed artifact is a decision someone made and signed.

Notice what did not happen there. The design never became the system on its own. Clean variables out of Figma are a real step, but they are not the finish line, because the same tokens can be implemented a hundred ways. Choosing which one is the judgment, and the judgment is the job.

The mistake, named

Here is the irony to leave on. AI makes designers more responsible for code quality than they were back when we actually wanted them writing it. The design becomes the code, and no one is left gatekeeping the translation.

So the real mistake is not that we use AI to get there. It is that we are writing the Design Engineer out of the loop, right when that judgment most needs an owner. The role is not going away. It is changing into the person who owns this middle: the system the design feeds into, the mapping, the contract that keeps a design from quietly becoming the foundation.

The durable anchor under all of it is a standard with the mapping in your hands, and that standard is where I am headed in my next article.

If you are building this middle, I would genuinely like to hear how you draw the line between what the AI proposes and what stays yours to decide. That is the conversation I am trying to start.

DESIGN.md is a Markdown file that describes a design system to an AI coding agent in a structured way: machine-readable tokens plus human-readable prose. Google Labs open-sourced it in April 2026. See the Google Labs announcement (blog.google, "Stitch DESIGN.md") and the spec repo (github.com/google-labs-code/design.md). A community catalogue at getdesign.md (maintained by VoltAgent) already lists 75 DESIGN.md files built on the spec (as of June 2026). ↩
This limit shows up in practice. When Atlassian benchmarked DESIGN.md against their own design-system tooling, they reported it was more likely to re-create existing components than to import the ones already in their system. A faithful description of how a component looks does not carry the decision to reuse the component that already exists. See Atlassian, "Atlassian's DESIGN.md is here: what we learned testing portable design context in practice" (atlassian.com, June 2026). ↩
Amrutha Kollu's writing on this gap: How I shipped 60+ design system components in 5 weeks using Figma as the single source of truth, Why AI keeps generating the wrong design tokens and how I fixed it with Figma's API, and Check Designs validates your Figma. What validates your code?. Fixel validates code against Figma in CI to catch design-system drift. ↩
Claude Design, Anthropic Labs (anthropic.com/news/claude-design-anthropic-labs). A June 2026 update added importing a design system from a repository or files and checking generated output against it. ↩

Most of the web is touch. We still don't save handedness.

Stéphane LaFlèche — Fri, 19 Jun 2026 01:02:51 +0000

How is there still no OS setting to save your handedness preference?

We can detect a surprising amount about how someone wants to use a page. Dark mode, reduced motion, higher contrast, reduced data: the prefers-* media features expose all of it. There is one obvious preference the platform never exposes: which hand you are using.

On a touchscreen, your hand is the interface. It is the cursor. Yet a designer building for that screen has no way to know whether the thumb in play is on the left or the right. So I opened a proposal with the CSS Working Group for a new media feature:

@media (prefers-handedness: left) {
  /* layout tuned for a left thumb */
}

@media (prefers-handedness: right) {
  /* layout tuned for a right thumb */
}

Like the rest of the family, this is a declared preference, not a guess about your body: the user sets it the way they set dark mode. And because it would live at the OS level, flipping it could be a one-tap control, the same quick toggle we already use for things like Bluetooth. The web already reflows an entire layout when you rotate the screen, so a left-to-right flip is a smaller version of a shift the platform has handled for years.

Here is why I think it earns a place in the family.

The case

Most of the web is touch now

Touch is no longer the secondary surface. As of Statcounter's May 2026 figures¹, mobile sits at 50.29% of global page views and tablets add another 1.48%. Phones alone have edged past desktop. The majority of the web now happens on a screen you hold in one hand and drive with the other.

And about 1 in 10 of those users are left-handed

The best estimate from the largest meta-analysis of handedness², 200 studies and over 2.3 million people, is that roughly 10% of people are left-handed. Stack that on top of a touch-majority web and you get a real population, not an edge case: a tenth of the dominant surface, using it the mirror image of how it was likely designed.

Apps already solve it, one at a time

This is not hypothetical. Creative apps already ship handedness settings by hand. Procreate has a Right-hand interface preference³ that flips its sidebar, because the default sits under the left hand while you paint with the right. SketchUp for iPad has a left-handed mode. Note apps tune palm rejection around which hand is resting on the glass. The mechanic differs (occlusion on a tablet, reach on a phone), but the missing signal is the same, and any of these apps could take its default straight from the OS instead of asking again.

Every one of these reinvented the same toggle, because the platform exposes no shared signal. That is the argument for standardizing one: a user should set this once and have everything honour it, not hunt for the same preference in every app. It is the same reason dark mode lives at the OS level instead of in a hundred separate settings screens.

It's a UX choice, and it goes beyond placement

Not just flipping the menu

To be clear, this is not "put the menu on the left." Designers already place navigation on either side freely, and both are fine. Which hand is holding the device is a different thing: a deliberate decision about what sits where, and that map depends on the hand. On a phone it is reach: a primary action belongs under the resting thumb, and a destructive action is often placed out of easy reach on purpose so it is hard to hit by accident. On a tablet it is occlusion: the dominant hand and forearm rest over the screen, so a control on the wrong side ends up under the very hand that is covering it. Without a handedness signal, that intent silently inverts for left-handers: the action you tucked away becomes the easiest one to hit, and the content you meant to keep clear sits under their hand. You never know it happened.

Gestures and interaction, not just layout

It also reaches past static layout. prefers-* features are readable from JavaScript through window.matchMedia, so handedness would drive interaction, not only styling:

const leftHanded = window.matchMedia("(prefers-handedness: left)").matches;

That opens up things CSS alone cannot reach: inverting a swipe or gesture direction, choosing which edge a swipe action lives on, deciding where a context menu opens so the hand does not cover it. This is an interaction signal, not a styling toggle.

The objections

"Too niche, too much work"

The feature itself is trivial: a single value a stylesheet or a script can read. The family already includes prefers-reduced-motion, which is more involved both to define and to honour, and it shipped. Dark mode is the cleaner precedent. prefers-color-scheme went from nothing to shipping across every major browser by early 2020⁴, fast, and it is arguably a more frivolous preference than how you physically hold the device. It is low-hanging fruit: easy to implement, and a real improvement for a substantial share of users. Hard to beat that return on effort.

"It needs platform buy-in"

True, and that is the point of proposing it as a standard. The signal would be an OS setting, the same origin as dark mode. Both prefers-color-scheme and prefers-reduced-motion needed operating systems to expose a setting, and both got it. Handedness only differs in that the toggle does not exist yet. The honest part: that is a heavier ask than a normal CSS feature, because it needs device makers, not just browsers. But the incentive is there. Handedness support is a real selling point on phones and tablets, and the stylus world already tracks it for palm rejection. The people who would benefit from shipping it are the same people who would ship it.

"It's a fingerprinting vector"

This is the serious objection, and it was the first thing raised on the proposal. The answer is to scope it. Handedness is meaningless on desktop, where the pointer is decoupled from grip, so the query can carry a value only in touch contexts and add no entropy where it would be useless anyway. And because it is a declared preference that ships off by default, like the rest of the family, it is a single low-entropy bit the user controls, not something inferred behind their back. It can also be restricted to first-party contexts, so the page you are visiting can read it but embedded third-party scripts cannot. That closes the cross-site tracking path without an opt-out checkbox or a permission prompt.

Weigh in

The proposal is live and open. If you have a use case, a concern, or a good argument against it, that is exactly what the thread is for: csswg-drafts #13215.

And if you think this should exist, say so there. A thumbs-up or a short comment with your own use case is the kind of signal that helps a working group tell a real need from a passing idea.

Statcounter Global Stats, Desktop vs Mobile vs Tablet Market Share Worldwide, May 2026: https://gs.statcounter.com/platform-market-share/desktop-mobile-tablet ↩
Papadatou-Pastou et al. (2020), Human handedness: A meta-analysis, Psychological Bulletin: https://doi.org/10.1037/bul0000229 ↩
Procreate Handbook, Interface (Right-hand interface preference): https://help.procreate.com/procreate/handbook/interface-gestures/interface ↩
MDN, prefers-color-scheme (Baseline since early 2020): https://developer.mozilla.org/en-US/docs/Web/CSS/@media/prefers-color-scheme ↩

The case for compiled, typed CSS (blame AI)

Stéphane LaFlèche — Wed, 27 May 2026 10:38:44 +0000

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.

References

[1] Mündler et al., "Type-Constrained Code Generation with Language Models" (2025) - https://arxiv.org/abs/2504.09246
[2] GitHub Octoverse 2025 - https://github.blog/news-insights/octoverse/octoverse-a-new-developer-joins-github-every-second-as-ai-leads-typescript-to-1/
[3] Shahid Pattani, "Design-to-Code AI Is Not Magic" - https://medium.com/aimonks/design-to-code-ai-is-not-magic-heres-why-it-fails-sometimes-7740051f3580
[4] Emilia BiblioKit, "3 Design System Bugs That Survive Every Code Review" - https://medium.com/design-bootcamp/3-design-system-bugs-that-survive-every-code-review-and-why-ai-makes-them-worse-55272372ee6a
[5] Prathit, "AI Models Still Can't Configure Tailwind Correctly" - https://prathit.vercel.app/blog/ai-models-still-can%27t-configure-tailwind
[6] Web-Bench (ByteDance, 2025) - https://arxiv.org/html/2505.07473v1
[7] GitClear, "AI Code Quality 2025" - https://www.gitclear.com/ai_assistant_code_quality_2025_research
[8] Simon Willison, "Hallucinations in code are the least dangerous form of LLM mistakes" - https://simonwillison.net/2025/Mar/2/hallucinations-in-code/
[9] PkgPulse, "The State of CSS-in-JS in 2026" - https://www.pkgpulse.com/guides/state-of-css-in-js-2026
[10] devclass, "Tailwind Labs layoffs" - https://devclass.com/2026/01/08/tailwind-labs-lays-off-75-percent-of-its-engineers-thanks-to-brutal-impact-of-ai/
[11] React 18 Working Group Discussion #110 (Sebastian Markbage) - https://github.com/reactwg/react-18/discussions/110
[12] Sachin Patel, "Cursor Isn't the Problem. Your Design Tokens Are." - https://medium.com/@sachin88/how-we-fixed-design-tokens-to-make-cursor-generate-reliable-ui-code-74d699e72e38
[13] Builder.io, "TypeScript vs JavaScript: Why AI Coding Tools Work Better with TypeScript" - https://www.builder.io/blog/typescript-vs-javascript

We still don't have proper CSS frameworks

Stéphane LaFlèche — Fri, 22 May 2026 12:58:55 +0000

We have utility libraries, class-naming conventions, and methodologies dressed up in framework branding. What we don't have is a CSS layer that behaves like a framework does in any other ecosystem: typed input, defined output, a contract a compiler can actually enforce.

This is the long version of a complaint I've been making in private for years. It also names what I think a real CSS framework would do, and shows the working sketch I've been building in that direction.

Tailwind is useful, but it's not really a framework

The current heavyweight is Tailwind, with over 400 million npm downloads a month as of May 2026, so let's start with what it actually is. Strip the build step away and the utility-first methodology isn't new. Object-Oriented CSS, popularized by Nicole Sullivan in 2008, was already making the same case: small, single-purpose classes you compose at the markup layer.

Before Tailwind existed, plenty of teams generated their own utility scales using SCSS loops. You can rebuild a meaningful slice of Tailwind's spacing utilities in a few lines of SCSS that would've worked in 2012:

// Define the design system tokens
$spacing-map: (
  "1": 0.25rem, // 4px
  "2": 0.5rem,  // 8px
  "4": 1rem,    // 16px
  "8": 2rem     // 32px
);

// Loop to generate padding and margin utilities
@each $key, $value in $spacing-map {
  .p-#{$key}  { padding: $value; }
  .pt-#{$key} { padding-top: $value; }
  .m-#{$key}  { margin: $value; }
  .mt-#{$key} { margin-top: $value; }
}

// Compiles to:
// .p-1  { padding: 0.25rem; }
// .pt-1 { padding-top: 0.25rem; } ...

What Tailwind genuinely adds is the build step. The JIT compiler scans your codebase and emits only the utility classes you actually use, with arbitrary-value support (p-[17px]) for one-offs. That's a real ergonomic win. Bundle sizes shrank and authoring speed went up.

The downstream cost is harder to talk about, because it shows up in maintenance, not authoring. In a Tailwind codebase, when something looks off on a page and you go searching for what styled it, you often can't. The class you'd search for (flex, text-center, p-4) appears a thousand times across the project. Layout decisions become string fragments scattered across every component file, not declarations you can grep, jump-to, or rename in one place. The tools that normally help you navigate a codebase mostly don't.

What we have, then: utility classes that were doable in SCSS in 2012, a build step that makes them ergonomic, and a search-and-rename problem that gets worse the bigger the project gets. Is that really what we want from a framework?

Where this breaks

AI didn't break Tailwind, even though January's layoffs at Tailwind Labs (the "AI killed Tailwind" framing) read that way in headlines. It exposed a contract Tailwind never had.

For most of the Tailwind era, humans wrote the class names. There was an implicit social contract: you stayed mostly on the spacing scale, you didn't use arbitrary values without a reason, you noticed when a string was getting absurd and broke it into a component. The framework didn't enforce any of that. It just trusted you.

The trust assumption is breaking. AI now writes a meaningful share of production CSS, and AI has no implicit social contract. It generates plausible-looking utility strings that pass a glance review and then break across a viewport, or duplicate themselves, or quietly drift off the scale. The class attribute runs to thirty utilities, half of them redundant (p-4 pt-4 pb-4 px-4 mt-2 mb-2 for what should have been p-4 my-2), and nothing in the stack catches the drift. Reviewing the output by hand becomes the bottleneck.

The arbitrary-value escape hatch. p-[17px] was tolerable when a senior dev would push back in review. Now it's a default behavior of the code generator, and there's no contract for anyone to point at. "Use the scale" is a vibe, not a rule.

The systematic-looking string. p-[var(--spacing-3)] looks systematic. There's a token name in there, the convention seems followed, reviewers wave it through. But the framework's scanning step doesn't actually understand it. The var lives inside a string fragment, not in the helper API. You can typo the variable name and ship it. Nothing catches that. Hardcoding is honest dishonesty. Token-wrapped strings are dishonest dishonesty.

Tailwind users will point to the fixes: @apply and component extraction for the grep problem, ESLint plugins and a theme-only config for the off-scale problem. These help, but they are external constraints layered on top, not a contract the type system enforces. A linter you can disable per line is a convention with tooling, not a compiler that refuses to emit invalid output. That distinction is the whole argument.

The fix isn't to ban AI from CSS, or to ban arbitrary values. The fix is to give the codebase a contract the AI can actually run inside: typed inputs that the build can verify, helpers that emit valid CSS, off-scale values visible rather than indistinguishable from on-scale ones.

What a framework should mean for CSS

In any other ecosystem, a framework gives you a contract. You hand it inputs in a defined shape, it does the work inside, you get a defined output. Rails takes route definitions and gives you a request lifecycle. React takes components and props and gives you a reconciled tree. The framework owns the implementation; you own the configuration and composition.

A CSS framework, by that standard, would:

Take typed design tokens in and emit valid CSS out. Every value (length, color, string) becomes data the build can see, not strings to scan.
Fail at compile time on mismatched units. Off-scale values stay possible, but visibly off-scale, not laundered into the same syntax as everything else.
Cover the full CSS spec, not a subset. New properties land in browsers all the time (@container, view-timeline, field-sizing); a framework that gates which features you can use restricts the work to whatever its authors had time to model.
Stay opinionated at the edges, loose in the middle. Strict on typed input and valid emission. Composition, file organization, helper depth: all yours.
Offer opt-in helpers, never mandatory ones. A team could write a borders helper that groups width, color, and radius the way designers think about them; another team could skip that layer entirely.

That shape (strict edges, loose middle, full spec) is the inverse of how most CSS frameworks work. Tailwind owns the middle (every class is theirs); the edges stay loose (any string can land in a class attribute). CSS-in-JS libraries own a template syntax in the middle, with values inside the template still untyped. Typed CSS-in-JS libraries like vanilla-extract type the output but not the input. A framework with strict edges in both directions, and a loose middle, is rare in CSS, but it's how typed systems work everywhere else.

A working sketch: CSS-Calipers

This is the principle in code. CSS-Calipers is a small TypeScript library I wrote last year. The ideas behind it go back to my Vanilla Forums days. It covers the measurement-and-math piece of the framework I keep wanting. Tokens in, typed CSS out. The helpers are the contract. Best to use at build time, but occasional runtime possible.

The measurements stay opaque through composition. Nothing emits a string until you call .css() at the boundary. The math is checked at every step, not just at the end.

Mismatched units fail fast. As the snippet above shows, paddingBase.add(rotation) throws a clear error with px vs. deg named in the message. You don't find out in production that you added pixels to degrees.

The measurement core is the foundation. On top of it I've built a helpers layer in my portfolio: borders, paddings, margins, shadows. Each helper consumes measurements and emits typed style objects. Here's the borders helper in actual use:

// Use defaults from the token layer
export const cardBase = style(borders());

// Override specific values inline
export const cardEmphasis = style({
  ...borders({
    width: m(2),
    radius: { south: m(8) },  // compass-style: south = bottom
  }),
});

// Or pass a full token config
export const cardThemed = style({
  ...borders(theme.cardBorders),
});

Three calling shapes, all valid: defaults, inline overrides, full token configs. The third one is where this starts to feel like a framework. Imagine you import the token from a tokens file:

// tokens/cardBorders.ts — today
export const cardBorders = {
  width: m(1),
  color: theme.colors.surface,
};

// components/Card.styles.ts
import { cardBorders } from "@/tokens/cardBorders";

export const cardStyles = style({
  ...borders(cardBorders),
});

Now design wants a thicker accent top and rounded bottom corners. You edit only the tokens file:

// tokens/cardBorders.ts — after the design tweak
export const cardBorders = {
  width: m(1),
  color: theme.colors.surface,
  top:    { width: m(3), color: theme.colors.accent },
  radius: { south: m(8) },
};

The component file is unchanged. The helper accepts the new token shape and emits more CSS; if you remove keys later, it emits less. Adding a borderTopWidth to the design means a new key in the token object, not a new class in your markup. The call site is invariant; the design tokens are where the change happens.

Spacing helpers work the same way: paddings(m(16)) for uniform, paddings({ vertical: m(8), horizontal: m(16) }) for axis-intent, paddings(theme.cardPadding) to delegate the shape entirely to tokens. Same calling pattern across the layer.

Helper names are deliberately the plural of the CSS property they emit: paddings, borders, margins, shadows. Grep-able, visually distinct from a raw padding property in a style object, consistent across the layer.

The same pattern extends through the rest of the helpers layer: @supports fallbacks as typed objects, accessibility variants typed against the actual CSS feature set, color manipulation through typed methods, typed media-query factories, typed clamp and other math primitives. CSS values get type-checking in places they almost never do in normal CSS-in-JS work.

You can opt in or out at any boundary. Use measurements for high-stakes spacing math; write raw Tailwind classes for layout primitives where utility-first wins; drop into a CSS Module or styled-components for component-scoped work. CSS-Calipers itself is compiler-agnostic: it produces typed CSS strings that work with any of those, or with bare style objects, or wherever else you want valid CSS to land. The library doesn't try to own the middle. The contract is the function signatures, not the entire styling story.

The Missing Framework Layer

We still don't have proper CSS frameworks. The pieces exist in different places: typed CSS-in-TS, design tokens, scanning compilers, agent-aware tooling. None of them are wired together into a single thing that takes typed input from your token layer, emits valid CSS to the spec, and stays out of the way in between.

Getting there isn't a single project. It's a shift in how the category is defined: what we call "frameworks" today are vocabularies and methodologies. What a real one would be is a contract.

It's hard. The CSS spec is complex: edge cases, shorthand properties, overrides, the cascade itself. A real framework can't simplify those away by giving you a subset; it has to absorb the mess and stay faithful to it. CSS is the spec, and the spec is messy.

A real CSS framework is opinionated at the edges where types matter, loose in the middle where you compose, and covers the whole CSS spec rather than a subset. We don't have one yet. We could.