Mature enough to be forgotten
The paradox of a design system mature enough that the organization stops seeing why it needs the designer behind it.
Every product organization eventually asks the same question, usually too late: when did we stop being able to move fast without breaking something?
The answer is almost never "when we grew." It's when growth outpaced the infrastructure holding the product together. Features shipped by different teams, at different speeds, with different assumptions about how a button should behave or what a status color means. None of it was wrong in isolation. Together, it was unmanageable.
This is the pattern before any AI enters the picture. A startup ships fast because there's nothing to slow it down: no design system, no shared components, no one asking whether this decision matches the last one. For a while, that's not a cost. It's a feature. Then the product hits a certain size, and every new screen takes longer to build than the last, because nothing can be reused and nothing agrees with anything else. The company hires a design lead, and the first project is always the same project: stop, rebuild the foundation, rewrite what already shipped.
A design system, at that point, isn't a nice-to-have. It's the thing that determines whether the next two years of building are fast or slow, coherent or fragmented.
At Omniva, that question came early. There was no formal design team yet, no established process, and ambitious targets for how fast the product needed to grow. I made the call to start with the design system before almost anything else, not because it was standard practice, but because of exactly the dynamic above: a fast-moving frontend team, high ambition, and no time to rebuild later what could be built right the first time.
It wasn't a popular sequencing decision in the moment. Design systems don't produce visible features. They produce the conditions for features to be built consistently, which is a much harder thing to defend in a roadmap review. But two years in, the payoff was structural: new screens shipped faster, not slower, because the foundation didn't have to be renegotiated every time.
That was the old cycle: skip the system, pay for it later. It's a lesson most fast-growing companies eventually learn, one way or another.
What's different now is where the risk shows up. Agentic prototyping means anyone, a PM, an engineer, a stakeholder with an idea, can generate a working interface in code, built from real components, and ship it directly. The system can be flawlessly documented, every token named, every variant accounted for, and the outcome can still drift, because using a design system correctly was never just about having access to the right components. It's about judgment: recognizing when a case is different enough that the existing pattern shouldn't apply, and knowing what to build instead. That judgment doesn't ship with the component library, no matter how mature it is.
So the output looks right. It behaves correctly. Nothing about it screams "unreviewed." And that's precisely when organizations stop asking why a designer needs to be in the loop at all. Not because the system failed, but because it worked well enough, on the surface, to make the person who built it look optional.
Not because the system failed. Because it worked well enough to make the person who built it look optional.
There's a version of this story where the ending is obvious: badly built systems eventually collapse under their own inconsistency, and someone gets called in to fix it. That's the failure mode every design leader already knows how to recognize, and every organization already knows how to respond to. A visible collapse forces a conversation.
This is the other one, and it's harder to see coming, because nothing breaks. The system holds. The components render correctly. Stakeholders ship features on schedule, sometimes faster than the design team ever could. By every visible measure, success keeps happening, quarter after quarter.
But visible success and design judgment are not the same thing, and a system can deliver one while quietly losing the other. Every shipped screen is still a decision: does this case fit the existing pattern, or does it need something the system doesn't have yet. When that decision keeps getting made without anyone trained to make it, the system doesn't fail. It just stops being steered. Nobody notices, because nothing looks wrong. It only shows up later, in the same place it always does: a product that technically works but no longer holds together as one coherent experience, and no one left who remembers why the original decisions were made the way they were.
None of this means the outcome is already written. We don't yet know what happens, long-term, to products that ship fast on a well-built system with no one asking why behind them. Maybe the components hold up fine on their own. Maybe they don't, and the cost just takes longer to show up than it used to.
What's clearer is the alternative: when a designer stays in that loop, the job isn't different from what it's always been. It was never about drawing the screens. It was about having a say in what ships, and why, before it ships, not after. Agentic tooling didn't change that function. It changed how easy it is to skip it entirely.
It was never about drawing the screens. It was about having a say in what ships, and why, before it ships.
It's a strange irony that the loudest fear about AI and design right now is framed as "AI will replace designers," as if the job being replaced was making things look polished in Figma. That framing was already wrong before any of this started. It just took a tool good enough to expose it.
There's a version of this story where the ending is obvious, and a version that's harder to see coming.
The version of this that should worry design teams isn't the one where the system fails. It's the one where it succeeds without them in the room.