Here's the failure mode I keep seeing: a team spends two weeks debating whether a CardWithAvatar is a molecule or an organism. They update the Figma library, they update Storybook, they write the documentation. Then a product requirement comes in that needs a tooltip on the avatar. The hierarchy can't accommodate it. They either break the abstraction or ship a one-off. Either way, the two weeks were wasted.
This is what happens when a teaching metaphor becomes an operating model.
Roger Wong's recent writeup surfaces a sharp observation from B. Prendergast on atomic design: teams that internalize atoms/molecules/organisms too literally end up "arguing about whether a card with an avatar and a label is a molecule or an organism." That conversation, Prendergast notes, "is a tax. It doesn't produce better components. It produces friction." The hierarchy becomes the product instead of the product becoming the product.
Atomic design solved a real problem when it arrived — it gave designers and engineers a shared language for component composition at a time when most teams were copy-pasting buttons across seventeen screens. That was the unlock. The problem is that the unlock got confused with the destination.
The Abstraction Worth Keeping Is Composability, Not Classification
Strip atomic design down to its actual insight and you get one rule: components compose up from smaller components. There are no required levels between the smallest useful unit and a full page. Whether something is a molecule or an organism is a naming problem, not a design problem.
Prendergast's conclusion is blunt: "Nobody ships a better product because they correctly identified a component as an organism instead of a molecule."
This is where flat, composition-first APIs have a structural advantage. The pattern that's actually won in practice — and the one that Radix UI, Reach UI, and Ariakit all popularized — is compound components: <Select>, <Select.Trigger>, <Select.Content>, <Select.Item>. The parent coordinates behavior; the consumer arranges the parts. No hierarchy to classify. No taxonomy to maintain.
The Honcho glossary entry on compound components puts the tradeoff cleanly: "a single <Select> is fine until someone needs to add a tooltip to a trigger or wrap content in a layout. Compound components let consumers compose freely without forcing the system to anticipate every shape." That last clause is the whole argument. A hierarchical system has to anticipate. A flat composition system doesn't.
Why shadcn/ui Became the Default
The market has already voted on this. shadcn/ui — built on Radix primitives, styled with Tailwind, structured so you copy components directly into your codebase rather than installing a dependency — has become the de facto foundation for new React projects. Dualite's 2026 library comparison reports that headless libraries now represent 70% adoption growth in 2025, and that the styled component model "lost significant ground to the headless and copy-paste approaches."
That's not a coincidence. It's the predictable result of a philosophy that prioritizes ownership over abstraction. When you copy a Button into components/ui/button.tsx, it's your button. You modify it, extend it, compose it. No version conflicts, no black box, no taxonomy to honor.
Sascha Becker's analysis of LLM default stacks adds another data point: ask Claude, DeepSeek, v0, or Lovable to build a React app and the output is overwhelmingly Next.js + Tailwind + shadcn/ui. AI coding tools have standardized on it because it's what the most-starred, most-forked, most-referenced React projects use. The training data converged on composition-first architecture before most design system teams finished their atomic design documentation.
The Signal That Tells You Which Situation You're In
None of this means hierarchy is always wrong. If your team is new to component-based thinking, atomic design's scaffold is still a reasonable on-ramp. Use it to introduce the concept. Just don't park there.
The signal to watch for: are your taxonomy conversations producing better components, or just better-classified ones? If your team is spending time on naming conventions and Storybook category structure rather than on API contracts and composability, the hierarchy has become the work instead of supporting it.
The real test, as Prendergast frames it, is whether people can "understand it, trust it, use it, and extend it without breaking it." A flat composition API passes that test more reliably than a layered hierarchy — not because hierarchies are intellectually wrong, but because they create maintenance surface that compounds over time while delivering diminishing returns on developer velocity.
The abstraction to keep is composability. The rest is bookkeeping.
