42% of React Code Is AI-Generated. Your Design System Isn't Ready.

When Claude Code generated a button component for my design system last week, it used a prop name that doesn't exist in my API. The prop was close enough to fool the model, but wrong enough to break in production. Somewhere, a developer copied that code into their pull request, and only a type checker caught it before merge.

This is the new normal. And it's breaking design systems in ways we didn't anticipate.

According to Belitsoft's 2026 State of React report, 42% of committed React code is now AI-generated, projected to climb to 65% by 2027. That's not a small number anymore. That's a majority of new code. And if you build design systems for a living, you've already felt the tremor. AI models are generating components by the millions, and most of them don't know your tokens exist.

The conversation around AI in development usually splits two ways: either "AI is writing better code than humans" or "AI is writing broken garbage that slows us down." Both miss the real story for design systems. The issue isn't whether AI code is good or bad in isolation. It's that AI doesn't understand systems. It doesn't see the shape of your design tokens, the philosophy behind your component API, or the constraints that make your system worth having in the first place.

This is a design system maintainer's nightmare, and also an opportunity I think we're missing.

The AI hallucination problem is real, but not where you think

Let me be specific about what I mean. AI-generated code creates 1.7x more issues than human-written code. That's alarming. But it's not because AI is bad at writing JavaScript. It's bad at writing code that respects constraints it can't see.

I've seen Claude, ChatGPT, and other models suggest component props that sound plausible but don't exist. `variant` instead of `type`. `color` instead of `colorScheme`. `rounded` instead of `borderRadius`. The model hallucinates because it's trained on code across thousands of projects, all with different conventions. It's guessing at your rules.

Here's where it gets worse: only ~30% of AI-suggested code gets accepted by developers. That number sounds like a win, until you realize 70% is still 30 million lines of code being reviewed and rejected every month. And the 30% that gets accepted? 20% of the package dependencies suggested by AI don't exist in official repos. It's not just making mistakes. It's confidently inventing things.

For design systems, this is catastrophic. When a developer asks an AI to "build a button," they're not telling it "use my company's design system." Most developers aren't even thinking about that. They're just asking the AI, and the AI generates plausible-looking code that violates your system in subtle ways. And because it's plausible, it sometimes makes it through.

Type checkers are your defense, but they shouldn't be your only one

There's one piece of good news: type checkers catch ~60% of AI-related issues, including property hallucinations. If you're running TypeScript (and you should be), your compiler becomes your first line of defense against AI mistakes.

But here's the problem: type checkers catch type errors, not architecture errors. A type checker will stop you if you pass a prop that doesn't exist. It won't stop you if you're using `div` instead of your design system's wrapper component. It won't warn you if you're hardcoding a color instead of using a token. It won't prevent you from building a button that looks different from the 10,000 other buttons in your codebase because the AI didn't know your design system existed.

That last 40% of AI issues that type checkers miss? That's where design systems live.

The default became a real problem

Here's something that surprised me: shadcn/ui broke 100k GitHub stars and 1.87M weekly downloads, and it became the default component library that AI tools use. Bolt, Lovable, v0, and Cursor all generate shadcn components by default.

That's not inherently bad. shadcn/ui is well-designed, accessible, and unopinionated. The problem is that when AI generates components, and most of those components are shadcn/ui by default, teams end up in weird situations. A company might spend six months building their own design system, and then an engineer asks Claude to build a button, and Claude returns a shadcn component that doesn't match your system at all. The developer can see both exist, and they have to pick. Often, they pick the AI-generated one because it's already there.

I've seen this happen twice in the last three months. Teams are fragmenting their component landscapes because AI keeps suggesting the most statistically common library, not the one that makes sense for their project.

The tools are waking up to this

The good news is that people are starting to build answers. Figma announced their MCP Server (Code to Canvas) in February 2026, creating a bridge between Claude and design files. There's also the AIDesigner MCP Server, which reads your project's framework, component library, and CSS/Tailwind tokens directly. The goal is to feed AI context it actually needs.

This is progress, but it's early. Most development still happens without these bridges. Addy Osmani wrote about his AI coding workflow, and even he has to spend time coaching the AI about his project's constraints. It shouldn't take a staff engineer to make AI work within your design system.

The deeper issue Ted Tate described is that AI agents don't consider the big picture of projects. They mix styles, libraries, and methodologies without understanding why those boundaries exist. A design system is nothing but boundaries and the reasons for them.

This is why design systems matter more now, not less

I think there's a temptation to believe that AI will make design systems obsolete. If code is auto-generated anyway, why have all these rules? Why maintain a library? Why enforce consistency?

The opposite is true. When 65% of your codebase is machine-written, design systems become the only thing standing between you and chaos.

AI is genuinely useful for generating boilerplate. I'm not anti-AI. I use it every day. But AI without constraints is just random code that happens to be syntactically correct. Design systems are the constraints. They're the shared language that makes machine-generated code and human-written code coexist in the same project without creating a nightmarish Frankenstein codebase.

The real work of design system maintainers is shifting. It's no longer just about documentation and components. It's about building systems that AI can't ignore. That means:

Explicit typing that makes prop errors obvious. Strong TypeScript definitions that catch hallucinations before they reach production.

Accessible-by-default components. WCAG 2.1 AA compliance became mandatory April 24, 2026 for US government web content. AI doesn't know accessibility rules. Your design system has to embed them so deeply that AI can't generate a button that fails WCAG without TypeScript screaming.

Clear, constraint-based APIs. Every prop should feel inevitable. Every option should be validated. If your design system has 47 possible values for a color prop, and your API doesn't narrow that down through TypeScript unions, AI will invent new ones.

Tooling that shares context. If your build tooling can export design tokens, component APIs, and architectural rules in a format that AI can read, the next generation of Claude and ChatGPT and whatever comes after can actually understand what you've built.

The real test is coming

Vite 8 with Rolldown (a Rust bundler) arrived in March 2026 with 10-30x faster builds, and it's hitting 65M weekly downloads. Build speed is becoming less of a constraint. That means more iteration. More code. More AI generation.

The companies that will win in the next two years aren't the ones that fight AI generation. It's the ones that make AI generation work within their design system. That requires maintainers who think like architects, not just engineers. It requires systems that are opinionated enough to enforce themselves.

We're not at the point where AI generates all code yet. We're at the point where it's worth thinking seriously about what happens when it does. If you're building a design system today, you're not building it for the developers on your team. You're building it for the machines that are going to generate code on their behalf.

That changes everything about how you design.