Components Are Dead
Something I’ve been thinking about a lot recently: are components going to exist in a few years?
I know that sounds dramatic, but I don’t think it’s hyperbole. The ground underneath design systems is shifting faster than I can grind my coffee beans, and based on my conversations with teams who can scratch their heads at components taking 6 months to be pushed to production, we might have to change what we know is true.
The more we generate code by hitting cmd + enter and letting a prompt do the typing, the less the code itself seems to matter. Not because code stops being important in some abstract sense, but because the thing we used to protect (the contribution model, the review gate, the "please don't just add another Button component" conversation) was built for a world where writing and editing code was expensive. That world is toast. Code is becoming cheap to write, cheap to edit, cheap to migrate. The bottleneck we spent a decade designing around is quietly becoming redundant.
To an engineer, this might be relief. To me in my pretty Figma files, it feels a bit like vertigo.
For those of us who work in design systems, consistency is what we hang our hat on. It’s an anchor point of a lot of slides we present to the higher-ups. But if we’re no longer paying close attention to the output, if a person is generating a component with a prompt rather than composing it from parts we’ve blessed, how do we even know whether any of it is consistent?
I used to think that was the question. Now I’m kind of struggling to figure out whether there’s a question mark at all here, because the thing that actually produces consistency was never the component. It was the values powering the component: the tokens. Color, spacing, radius, type scale, motion curves, the decisions that get consumed by components rather than the components themselves.
Tokens are the layer we can still control. And if we let go of the instinct to componentise every single surface of the product, we might actually be able to build faster, at greater scale, and stay just as consistent, maybe more.
There’s an obvious objection here: more building, with fewer guardrails, in theory means more debt gets baked into the codebase. That’s probably true. But does it matter as much as it used to, now that editing is nearly free? Debt used to be expensive because fixing it was expensive. If code is cheap to rewrite and cheap to migrate, the cost side of that equation has changed even if the volume of debt hasn’t.
I don’t think this fully cancels the problem out. But it does mean we’re arguing about the wrong metric if we keep measuring “debt introduced” without also measuring “cost to remove it.”
Get Luis Ouriach’s stories in your inbox
Join Medium for free to get updates from this writer.
Here’s what worries me more than any of the technical stuff. In conversations with execs lately, what keeps surfacing as the priority isn’t better products, it’s more products, built faster. That’s the shift this technology enables, and it’s the one nobody in a design system team gets veto power over. The bottleneck arguably gets larger.
And that’s the part that should make us raise an eyebrow, because more isn’t what most products need. We don’t need more surface area. We need less bloat, more targeted products, more efficient ones. Cheap code doesn’t just remove a bottleneck on quality, it removes a bottleneck on volume, and volume was never our friend.
I keep returning to the same question: is a robust, semantic token set actually sufficient to hold all this together?
Increasingly, I don’t think it is, not on its own. If code is being generated in a way that bypasses the contribution model entirely, the argument for component-level tokens (sorry, I know) starts to resurface. Not because components need to come back as the unit of build, but because they might still be needed as the unit of constraint: the place where “this is what an input field is allowed to look and behave like” gets encoded, even if ten different LLM-generated input fields exist in the codebase at once.
Which raises my actual thought experiment: what if you did have ten versions of an input field in your codebase, but every single one of them pulled from the right tokens, was styled correctly, was accessible, and was generated on demand by an LLM?
That still hurts my head a little to be honest. Abundance always does make a systems team sweat if you’ve spent your career trying to collapse everything into one canonical component. But it might not be a problem. If the thing we’re actually optimising for (consistent, accessible user experience) is being controlled and verified at the token level rather than enforced through a single shared implementation.
Maybe that’s the point? The code that powers the interface becomes less important, and the token layer becomes the thing we actually govern. Not because governance disappears, but because it moves: from the component, which we can no longer promise is the only path to the UI, down to the values the component was always just a delivery mechanism for.
Components aren’t dead because consistency stopped mattering. They’re dead because we finally have a layer that can hold consistency without needing them.
—
Edited 22 July 2026 after receiving some helpful feedback from the community.
