Who maintains taste in a design system when every contributor can generate "good enough" components themselves?

The shift

Producing a plausible, on-brand-looking component goes from scarce specialist output to abundant — any contributor can prompt one into existence in minutes. Judging whether that component is the right abstraction, holds up under reuse, and deserves a permanent place in the system stays scarce; AI is fluent at generating surface conformity, not at deciding what's worth keeping.

The axioms

• Consistency required routing everyone through one team's build queue. That queue was the only place components got made, so it doubled as the only place they got reviewed — a scarcity of production capacity, not of judgment.
• The design system team's authority came from being the only ones who'd built enough components to see the patterns. Scarce repeated exposure to edge cases produced their pattern-recognition; nobody else had logged the reps.
• Contributors deferred to the system because they couldn't produce a credible alternative on their own. Scarce authoring skill outside the core team kept the system the path of least resistance.
• A shared library stayed coherent because there were few enough components that one team could hold the whole thing in their heads. Scarce volume of components made centralized mental oversight tractable.

Invalid axioms

1. Centralized build queues are the mechanism that keeps the system consistent. The queue was a proxy for scarce production capacity, not a real judgment gate — it worked by accident, because slow output meant only a few things needed reviewing at once. Now that any contributor can generate a component that clears visual QA, gating by "who has time to build it" stops filtering anything meaningful. Habit-trap: teams keep routing requests through the design system team's backlog as the quality control, when it was only ever a capacity control.
2. Contributors defer to the system because they can't build an alternative themselves. That deference was compliance born of inability, not conviction. Once everyone can self-serve a component that looks fine, the system only holds people if its taste is visibly better than what they'd generate alone — deference has to be earned continuously, not assumed by default.
3. A small number of components means the core team can hold the whole system in their heads. Generation volume is no longer bounded by who can build things, so the library's growth rate stops tracking headcount. Habit-trap: staffing and review cadence still sized for a world where components trickled in one at a time.

Unchanged axioms

1. Someone has to decide which abstraction is the right one, not just which one works today. A generated component can function correctly and still be the wrong pattern — duplicating an existing primitive, encoding a one-off need as a general rule, or solving a problem the system already solved differently. Telling "functions" from "belongs" is judgment on a case that doesn't reduce to a rule; that's the taste question, and it doesn't get easier because drafts got cheaper.
2. Someone has to be accountable when a component metastasizes across the product. Once a "good enough" component ships into ten other teams' surfaces, unwinding it is expensive and political. A model that helped generate it isn't the one who answers for the fallout — a named owner still has to be willing to say no, deprecate, or force a migration.
3. Trust in the system depends on a track record, not on any single component being well-made. Contributors adopt shared components because past ones held up, not because today's output looks polished. That trust is built by a person or team's accumulated calls being right over time — it can't be generated, only earned, and AI-assisted output doesn't inherit it automatically.

New axioms

1. Every contributor can now produce a plausible variant, so the system faces volume it was never built to review. When building was slow, drift was slow too. Now drift can happen in parallel across every team simultaneously — the problem shifts from "how do we produce enough good components" to "how do we catch bad ones before they compound," at a scale manual review wasn't sized for.
2. "Good enough" is a moving, silent bar with no natural checkpoint. A contributor's generated component can clear every visible bar — matches tokens, passes lint, looks right in isolation — while still being wrong in ways only surface after three more teams build on it. Nobody has to decide it's acceptable; it just ships, because the friction that used to force a conversation is gone.
3. The system needs a way to encode taste as something checkable at the point of generation, not just after the fact. If judgment is the scarce resource, the open problem is whether it can be front-loaded — into constraints, examples, or review criteria sharp enough to catch a bad abstraction before it's built — rather than re-applied by a human on every artifact after the fact.

Where it breaks

Teams still route "is this allowed in the system" through the old build-queue reflex (INVALID #1) at exactly the moment volume has outstripped what that queue can inspect (NEW #1) — the gate that used to work by accident because little came through it now has ten times the throughput and the same headcount. And contributors who no longer need to defer because they can self-serve (INVALID #2) are shipping components that pass every visible check while still being the wrong abstraction (NEW #2) — the system has no mechanism left that catches "looks right, isn't" once the deference that used to force a second opinion is gone.

ai-axioms.vercel.app/axioms/product-design/design-systems-taste-ai-axioms