From Reusable to Regeneratable: Rethinking the Shared UI Component Library

For most of the last decade, one piece of advice went almost unquestioned inside any growing engineering organization and that was to build a company-wide component library. If you put your buttons, modals, data grids, and form controls into one versioned package, then every team inherits consistency, accessibility, and speed. It felt built into our DNA; reusability is good for consistency and speed.

This idea is worth revisiting in 2026. The advice was good previously, but the conditions that made one shared library the obvious call have since changed. When a coding agent can produce a styled, more-or-less accessible component in little time, keeping one canonical library for a whole company buys less than it once did. For many organizations, the shared library is now needed less. What is worth centralizing is the design system, the tokens, the guidelines, and the tests, but not the shipped component code.

This centralization is something with which we have hands-on experience at Griffiths Waite. We have spent most of the last decade building shared UI’s in React, maintaining component libraries and design systems across large enterprise clients. We have seen the benefits libraries can bring, and now we are starting to rethink what the future of component libraries and design systems look like.

What the Library Was Really For

A shared library always bundled four separate promises into one artifact:

• Reuse, so nobody builds a date picker for the fifth time.
• Consistency, so one team's button, table, or form control behaves like the next team's, which is very important for consistent experiences.
• Encoded expertise, so accessibility, keyboard handling, the unique cases specific to an organization, and the awkward edge cases are solved once, by people who care.
• A single source of truth, so a brand change lands everywhere from one place.

Out of the four, only two actually need shipped code. Consistency and source-of-truth belong with a design system and its design tokens, the shared color, type, and spacing values a component merely references. Reuse and encoded expertise are what justified the package itself, which are exactly the parts AI can now help with.

Maintenance Is the Real Bill

The initial build of a library was always time consuming, whether it was built during a Sprint Zero or as a dedicated project, but the expensive part of a shared library is never the first release. It is the decade afterwards. Once consumers start using it you have a bunch of applications you are now supporting and needing careful considerations when making changes.

In a piece on abstraction ownership at daisyUI, they outline:

Every line of code you own, is a line you have to maintain, test, fix, and update.

This assertion is why in any abstraction, following guidelines like Avoid Hasty Abstractions (AHA) can be beneficial, because abstracted code needs to be maintained and often the cost of maintenance is not worth the abstraction. Choosing what to abstract is becoming even more important when writing or rewriting code is easier and cheaper than it ever has been.

A heavily upvoted Hacker News thread, which looks into how you can roll out an internal UI component library, received a comment from someone who suggested avoiding component libraries; his company was on its second attempt to roll one out:

Internal UI component libraries are expensive to produce and maintain – they're much more complex than your average CRUD app and 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.

When adoption spreads from one product team into others, ownership becomes tricky, maintainers are pulled into other delivery work, priorities clash between consumers, and teams building against it produce every multiple variants of a component when they need only two or three. You end up having to run the library as a fully fledged project with backlogs, alignment sessions, and planning, all of which is overhead, the tax you keep paying for years after the first release.

We have experienced this problem first-hand at Griffiths Waite running shared libraries across large, multi-team environments. Once a library is adopted widely, dependency management becomes a balancing act, keeping multiple versions of components aligned so the single source of truth doesn't quietly fragment as teams drift onto different versions. Upgrade rollouts are difficult when shared components wrap specific third-party libraries. Bumping or swapping out those dependencies is difficult to untangle. Every consumer has to be migrated in step rather than at its own pace. Even a well-intentioned change can ripple into every consuming app, so versioning and communication end up mattering as much as the code, and a component tends to accumulate more variants than any single consumer needs. The entire shared library only stays healthy with clear, sustained ownership, which is exactly the attention that slips when maintainers are pulled onto other delivery work.

This sustained ownership doesn’t make shared libraries worthless. A company-wide library is a product with a roadmap, support load, deprecation policy, and a team. Starve that team and within a couple of release cycles every downstream project is patching around a library nobody owns.

Regeneration Became Cheaper Than Reuse

Reuse won for many years and the reason is clear. Rebuilding was slow and error-prone, so writing one good implementation and spreading the cost across every consumer was obviously the smart move. Generative AI changes this set of problems. When the implementation cost is less, the focus can shift higher to the areas that drive the need for centralized design systems in the first place.

Marco Kotrotsos, in an essay he titled The Death of the Component Library, describes how Tailwind's own paid-component business was undercut by its own ubiquity: Because Tailwind is so heavily represented in training data, "when developers need a Tailwind component, they don't visit the documentation. They prompt. The AI generates the code directly". The standardization a library sells turned out to be the very thing that made the library redundant as a way to ship code.

Denis Uraev frames this change as a move from reusable to regeneratable code. Keep the specification, regenerate the implementation when you need it, and lean on tests that let agents "verify correctness independently". A 2026 technical report on component-based development for AI coding makes the same case from the research side, describing tooling that helps agents "inspect, modify, test, debug, and regenerate code fragments".

If a team can quickly generate the components it needs from a shared design system and a well-defined prompt, a central package it has to version, publish, and upgrade is worth far less. Consistency still holds, because the design system now carries it.

Centralize the Rules, Generate the Parts

To be clear, this approach asks for more discipline, not less. It just moves that discipline from the code to the rules. The center of gravity moves from a shared code artifact to a shared set of constraints, which are still artifacts.

Start with the design system and its tokens as the single source of truth. Teams already treat tokens this way, running one definition through tooling like Style Dictionary to produce CSS, iOS, and Android values. Tokens are cheap to keep alive and they are exactly the kind of structured input a model handles well.

Then move on to machine-readable guidelines. Design-system teams are already feeding models persistent rules (e.g., token usage and accessibility requirements) kept in a versioned directory beside the code, then running audit prompts to catch hardcoded values and contrast failures. These guidelines form the new component library, so instead of code, you receive the core instructions.

Engineering principles, the sort captured in plain language to provide opinionated defaults with conscious deviation, keeping one definition and zero drift across generated and hand-written code, and treating accessibility as non-negotiable, are exactly the persistent constraints a model needs before it writes anything. Griffiths Waite has a good example of this approach, a principle library covering a wide range of engineering rules that manage component simplicity, developer experience, and accessibility. It is the first thing we would now point a coding agent at. Kept as a searchable, discipline-organized library rather than tribal knowledge, these libraries become reusable input for every regeneration.

The combination of design system, tokens, component instructions, and engineering principles are the specification with which an agent generates components. Each project generates what it needs against those rules, tuned to its own framework version, while skipping the components it will never use instead of dragging around an entire library.

With regeneration from designs, we are already relying on this approach in our projects at Griffiths Waite; we use the Figma MCP server and have found it remarkably accurate at generating UI directly from Figma designs. We combine this use with the skills we created and added to our projects to encode our engineering best practices and keep the generated code aligned to our standards rather than whatever a model would produce by default.

The final step is verification. How can you trust the generated code? Visual-regression tools including Chromatic, Percy, and Playwright diff a component against an approved baseline and catch the wrong shade of blue or the four-pixel padding drift that unit tests miss. The Playwright CLI can work for this problem. It is possible for the agent to compare the build against a Figma design via the MCP server and perform screenshot comparison testing between the two to ensure they align. The same tool can assert that regenerated markup still matches the required accessibility structure, while computed-style checks can confirm color, spacing, and type resolve to tokens.

Change Control Moves Up the Stack

If the rules are now the product, the question is how you version them. With a shared library, change control lived in the shipped code. A release is published with a new version, consumers bump a dependency and migrate, with semantic versioning (SemVer) signaling how much would break. With regeneration, the shipped code is disposable, so versioning moves up to the artifacts from which every regeneration reads.

The engineering skills, the crosscutting principles to include accessibility, component simplicity, and developer experience, can be versioned on their own cadence separately to the component library. These skills should sit across all of the codebases and be managed independently.

The component rules, the design system, tokens, and per-component instructions, can be versioned similar to the code package before. Each bundle carries everything an agent needs to build a component autonomously, including links to the Figma MCP server and the current designs, so regeneration and screenshot verification draw from one pinned source of truth rather than a design file that has drifted ahead of the spec. Keeping this bundle up to date and aligned with correct versions in Figma, as well as being versioned correctly, is important.

When a version bumps, projects and teams can choose to regenerate the affected components and run the testing suite to verify; they could also instruct their agents to only update what has changed, rather than regenerating the whole component. Also, if a project wants to version the actual built components in its own repo, it still can.

The Sea of Sameness Raises the Value of an Opinionated System

As regeneration becomes a more common way to build UI, a new problem comes to the surface: Everything starts to look the same. This issue has been seen before with component libraries like Material UI. Models learn from the public web, so "a modern, clean landing page" returns the statistical middle of the training data, which is about as average as design becomes. In a post "Why AI-generated design all looks the same", Curio's write-up explores the problem. A model "learns the center of that distribution, not its edges". The more vague the prompt, the more average the result.

The Northeast Times recently reported that two startup founders arrived at separate meetings with decks built in Anthropic's Claude Design tool and that a designer said it appeared to be "generated by the same company", down to the matching four-rectangle layouts and centered text. Developers already have a name for the phenomenon, the "Sea of Sameness", as builders like Lovable, v0, and Base44 pump out the same "Tailwind Blue", the same purple-to-cyan gradients, and the same card grids.

In a lot of work the defaults are being set by AI recommendations often reaching for tech like Next.js, Tailwind, and shadcn/ui. When everyone shares the tool, the framework, and the component defaults, uniform output is common.

A 2026 Tilburg University study titled "Does Generative AI Make Us Think Alike? A Systematic Review and Meta-Analysis of Homogenization Effects in Human-AI Co-Creation" found that:

Results reveal a small but statistically significant homogenization effect associated with AI use, robust across sensitivity analyses and not explained by publication bias. Moderator analyses indicate that homogenization is task-sensitive, with stronger effects in semantically constrained ideation tasks than in minimally constrained divergent thinking tasks.

A separate study on ideation in 2024 found people "produce less semantically distinct ideas with ChatGPT" than with an alternative tool. This is a measured property of how the models behave, not a passing mood.

The homogenization is task-sensitive and is most seen on semantically constrained prompts, such as a bare "modern landing page", which is exactly where a strong system does the most to pull output off the average. It is precisely why the design system matters more, not less. A strong, opinionated design is the lever that pulls a model off its average. The advice from people fighting slop is to fix the visual constraints "before you generate anything", handing the model real tokens, layout structure, and style direction instead of adjectives like "modern" and "clean" that every style in the training set already claims. What separates your regenerated UI from the others is how specific and opinionated the system behind it is.

On Whether Sameness Really Matters

McKinsey’s Business Value of Design study tracked three hundred publicly listed companies over five years (from December, 2012 to December, 2017) across medical technology, consumer goods, and retail banking, scoring each on its McKinsey Design Index (MDI) drawn from more than two million pieces of financial data and a hundred thousand design actions. Its top-quartile MDI performers outpaced their industry counterparts by thirty-two percentage points on revenue growth and fifty-six percentage points on total returns to shareholders over the period. Generic work erodes credibility with buyers who can tell the difference. The homogenization research shows the convergence is measurable rather than anecdotal. For anything brand-facing, vanishing into the crowd has a cost.

Familiarity, though, is not automatically a failure. Jakob's Law reminds us that people spend most of their time on other sites, so conventional, well-understood layouts lower cognitive load and often help rather than hurt. Even where brand distinctiveness doesn’t matter as much, an internal admin panel or an ops tool, as examples, the quality of the experience still does. A clear, efficient interface lowers cognitive load, cuts task time and errors, and lifts adoption and retention of the tools teams use every day. The real line runs between brand distinctiveness, which some surfaces can skip, and experience quality, which none can. A strong system delivers the second cheaply, which is why even critics frame the issue as sameness and when it matters. Much of the uniformity is lazy, under-specified prompting rather than a hard ceiling, so better inputs fix it. The longer trajectory may run the other way entirely, towards generative UI that tailors itself to each user.

So govern regeneration rather than resisting it. Make the system genuinely opinionated, with a real type scale, color system, spacing rhythm, and motion, rather than a lightly reskinned default.

Where a Shared Library Still Wins

The best case for keeping a curated shared library, argued well by Telerik, holds up in places. Accessibility is the strongest of them. As they note, "AI code generating tools do not excel at accessibility", and AI-generated UI is often inaccessible by default. The fix for these issues is architectural. As they put it: "instead of relying on every prompt to produce correct primitives, use libraries that encode accessibility into their API contracts". Keyboard handling, focus management, and ARIA semantics are exactly the encoded expertise you lose the moment you regenerate carelessly.

There is a reference-material point, too. AI "cannot generate from nothing". A well-known library gives it thousands of consistent examples to lean on, which tends to beat bespoke code assembled over years by different developers using different tools. Someone still has to review the output. Configuring a trusted component is a smaller, safer diff than reading a two-thousand-line hand-rolled one.

A 2026 paper, Software Reuse in the Generative AI Era, warns that blindly trusting generated code is "conceptually not all that different from cargo cult development", and that "reuse based on assets that have not been proven to be fit for purpose or designed with reuse in mind can lead to serious quality issues".

Verification Is Important

The accessibility and quality worries are really arguments for verification. Encoded expertise does not have to live in distributed component code; it can live in the design system, in accessibility acceptance tests, and in a small set of genuinely hard primitives you keep curated. The cargo-cult warning is really just a demand that regeneration be tested rather than trusted. Where AI accessibility is weak, gate it behind automated checks and keep the handful of widgets (data grids, comboboxes, date pickers) as shared, human-audited code.

So the move is to split shared code three ways:

• Regenerate the high-volume, low-risk surface: layout, typography, buttons, cards, and simple forms; these items are cheap to make, easy to verify against tokens, and expensive to maintain centrally for what they are.
• Curate and share the few components where accessibility and behavior are genuinely hard and the cost of getting them wrong is high.
• Keep central the design system, the tokens, the guidelines, and the test suites, because those are what actually deliver consistency and are cheap to keep alive.

So, Build One or Not?

Before you build or keep a shared component library, you should be able to say which of its four jobs (i.e., reuse, consistency, encoded expertise, and source of truth) a strong design system plus tests cannot do more cheaply.

For a lot of organizations, especially those without a properly funded platform team, the path now points somewhere leaner with one canonical design system, machine-readable guidelines, per-project regeneration, hard verification against the system, and only the genuinely difficult components kept as shared, audited code. The design system does not disappear in that world; instead, it matters more. The shared library is the part that shrinks. For teams without a platform group to fund it, that is not a loss worth mourning.