Open three screens of a product that has been built fast for a year and you will find the same content presented three slightly different ways. Nobody designed it like that: it is product sprawl, and it comes from a gap in how teams work, in this case with design systems.
Brad Frost’s atomic design calls atoms the foundational building blocks that comprise all our user interfaces, and molecules relatively simple groups of UI elements functioning together as a unit. Using an atom from the design system is easy: a button, an input, a label. Building a molecule is hard. Someone has to decide what the group is, build it once, document it, and then maintain it as every page asks for something slightly different. So each team working on a page composes its own version directly from the atoms, declares it close enough, and ships.
Adding is what AI is good at
AI makes new things cheap. A new page, a new variant, a new component takes minutes, and a team that is measured on what it ships will take the minutes. Frost warned that many design systems fall into disrepair because the effort required to make updates is far too high, and that if every whim results in a brand new pattern, the system becomes a bloated and unwieldy Wild West. AI turns every whim into a new pattern at close to zero cost.
I have no measurement of UI sprawl caused by AI. The nearest numbers are from code. GitClear’s analysis of 211 million changed lines reports copy-pasted lines rising from 8.3% to 12.3% between 2021 and 2024, while refactored lines fell from 25% of changes to under 10%. That is one vendor’s analysis of code, not of interfaces, but it has the same shape: more adding, less tidying. DORA’s 2025 report describes AI as an amplifier that magnifies the strengths of high-performing organisations and the dysfunctions of struggling ones, and finds it improves delivery throughput while still increasing instability. Most of its respondents say code quality improved, so the effect is not uniform. It depends on what the organisation was already doing.
Gaps become chasms
Each variation is small: a different spacing, a different label, an empty state that behaves slightly differently. Then the gaps add up. Users have to relearn each page. The next feature has to pick which version to copy. Fixing it means touching pages that several teams own, and nobody owns the space between them.
Repair also needs more than adding does. Someone has to understand why the pages differ, decide which version is right, and change pages other people depend on. And the benefit is invisible: nothing new appears. Nobody is praised for the molecule that prevents a fifth variant. So the team builds something new instead, because new work has an owner, a demo, and a date. The mess is not decided. It accumulates, and the pile grows because repairing it is harder than adding to it.
The same reflex has a second face. A team that never defers anything builds everything, including things nobody uses. I argued for a metric that can say remove. This is why you need one: left alone, a product only grows. Like a tumor.
Friction helps
Dedicated spikes and week-long refactor sessions have helped my teams deal with the symptoms. But nothing short of changing how teams work and what they are rewarded for has helped enough. Something like hard blockers when people build their own version instead of using the molecule. A hard blocker means the review does not approve, or the build does not pass, a page that rebuilds a group the system already has. It is an annoyance by design. That is also why the incentives matter: if the team is rewarded only for what it ships, it will route around any blocker, and the rule has to count reuse as part of the work. Friction works here for the reason it worked in Positive Friction: the step that slows you down is doing a job.
Don’t do more. Do better.
A rule to test
Here is a rule, and I would like to hear about yours: reuse or retire. A new page or component can ship only if it uses an existing molecule, or it replaces a near-duplicate that gets retired in the same change. It makes the cost of adding visible at the moment someone chooses to add, which is where entropy wins today.
The rule needs an owner for the molecules, or it only moves the mess: someone has to be accountable for the library’s health. It will also slow some launches, and a product with one team and a handful of pages can carry a little drift for a while. Past that size, the slowdown is the point. Integration tax arrives later and elsewhere, as collisions between teams. Sprawl is the same bill paid inside one product, one small difference at a time.
Count how many ways your product shows the same thing, and fix one before you build another.
Leave a Reply