Design systems and AI slop

Any design system that relies on a community model, asks for contributions now in exchange for organizational benefits later. This is a tough trade against these new tools that are returning immediate value to the individuals, inside current sprint and existing reward loop. This makes contributions structurally harder unless incentivized.

Designers can now generate a view without touching any system artifacts. Engineers can prompt a new component into existence with or without consulting the system. The system isn’t abandoned in these cases, it’s not consulted.

Putting aside the adoption hit, the situation won’t respond to more components, better docs or demos. Let me elaborate.

The ‘inflow’ is everything that adds to the ‘stock’ of adoption. It’s natural to respond to drop in adoption with better inflows, as they are visible and can be pointed to: Components shipped, guidelines added, new stories in Storybook. These are discrete, complete units of work with a clear before and after. They feel like progress because they are measurable in a way that ‘outflows’ rarely are. Inflows feel within our control.

Outflows, on the other hand, tend to be invisible until they are catastrophic. You do not get a notification when a developer decides to prompt a component into existence rather than check the library. You do not get a log entry when a designer skips the token structure because mapping to it felt cumbersome. Outflows feel like they belong to someone else’s behaviour, sprint pressure, or decision to use Copilot instead.

It is now critical for the maintainers to decide what the system offers that AI tooling doesn’t (e.g., cross-platform parity, accessibility compliance, institutional memory). These decisions are made so that nobody has to make them again and ship value. ` New design system maintainers won’t be competing with sprint pressure, but with tools that make individual velocity feel enough.