Griffiths Waite would move shared UI spending from component code to design tokens and tests

The essay's case starts by taking a library apart. A shared component package, the authors write, bundled four promises into one artifact: reuse, consistency, encoded expertise and a single source of truth ^[4]. They assign consistency and source of truth to the design system and its tokens, defined as "the shared color, type, and spacing values a component merely references" ^[5]. That leaves reuse and encoded expertise as the case for shipped code, and the authors say those are the parts AI can now help with ^[6]. They also argue that models left to their defaults converge on a bland average, so an opinionated design system becomes a differentiator ^[11].

The cost they want to stop paying is upkeep. The essay says "the expensive part of a shared library is never the first release. It is the decade afterwards." ^[7] It quotes a daisyUI piece on abstraction ownership: "Every line of code you own, is a line you have to maintain, test, fix, and update." ^[8] A Hacker News commenter whose company was on its second attempt at an internal library wrote that such libraries "require skilled, disciplined people to actually pull off, as you have to think years into the future and have as little staff rotation as possible." ^[9]

Tokens propagate values. Change a spacing token and every component that references it picks up the new value ^[5]. A regenerated component gets that only if it references the token and does not hard-code the number. Token-conformance tests are how the authors propose to check it ^[10]. Tokens do not hold behavior, though. Keyboard handling, accessibility and an organization's own edge cases were the encoded-expertise promise ^[14]. Fix a keyboard bug in a shared widget and every consumer gets the fix on upgrade. In regenerated copies, each copy keeps its own version of the bug until a test catches it.

The authors put their exceptions where I would. They keep curated shared code for accessibility, genuinely hard widgets and cross-team functional consistency ^[12]. Their own description of agent output is "a styled, more-or-less accessible component" produced "in little time" ^[13]. I would accept more-or-less on an internal settings page, and not on a form a screen reader user has to complete.

Verification carries the rest of the plan. The essay says regenerated code must be verified before anyone trusts it, with visual-regression, accessibility and token-conformance tests ^[10]. Its premise is a model "pointed at a solid design system" ^[2]. The library's old promise was that nobody builds a date picker for the fifth time ^[15]. Under this plan a model builds it the fifth time and the suite checks it five times. For the recommendation to transfer, the design system has to be complete enough to generate from, and the suites have to catch what a library team used to catch in review. The essay draws on Griffiths Waite's work maintaining component libraries and design systems for large enterprise clients ^[1]. It does not report defect rates or test escapes for regenerated components.