Atomic design in the agent era: which parts still hold

Atomic design proposed that interfaces be understood as a hierarchy: atoms (a label, an input, a button), molecules (a search form), organisms (a site header), templates (page-level layout without content), and pages (a template with real content in it).

It is worth remembering the context. In 2013, most front-end work was page-based. Designers delivered comps of individual pages; developers built individual pages; the same button existed in eleven slightly different forms and nobody had a name for the problem. Atomic design gave teams a shared vocabulary and, more importantly, an argument that interfaces should be composed from a system rather than drawn page by page.

That argument won completely. Every component-based framework, every design system, and every token layer in current use assumes it. When people say atomic design is dead, what they usually mean is that its conclusion became the default and its terminology became optional — which is what winning looks like for a methodology.

The five levels are not equally useful, and pretending they are is where teams lose time. Sorted by how much argument each one causes per unit of value:

The molecule row is not a nitpick. Ask five engineers whether a card with an image, a title and a button is a molecule or an organism and you will get a forty-minute conversation with no downstream consequence. Any taxonomy level whose boundary cannot be decided quickly and does not change what anyone builds is overhead.

There is a stronger critique than "the labels are fussy", and it comes from a team that had the resources to implement atomic design properly and chose not to.

Airbnb's design team published that instead of relying on individual atoms, they treated components as elements of a living organism — each with a function and personality, defined by a set of properties, able to coexist and to evolve or die independently. Their stated benefit was avoiding a complicated network of interconnected parts.

That is a real trade, not a preference:

Neither column is correct in general. A single-platform web product with one codebase gets real value from maximal reuse and can absorb the propagation risk. A system spanning four platforms cannot, because the atom tree has to be reproduced identically in each and it will not be. Airbnb had four platforms.

Here is the part that is genuinely new, and it cuts in an unexpected direction.

Atomic design's primary contribution was a shared vocabulary. It let a designer, an engineer and a product manager point at the same thing and mean the same thing. A coding agent does not need that. It already knows what a button, a card, a nav bar and a data table are, in enormous detail, across every framework you might use. The naming problem atomic design solved is not one an agent has.

What an agent lacks is entirely elsewhere:

The bottom three rows are empty on the left, and that is not a criticism of the methodology — it was never trying to fill them. It is a reason not to expect it to help with the current problem.

We sampled 299 DESIGN.md files written to give agents design guidance, and the emptiness shows up there too. 76% contain no prohibitions of any kind. 86% specify colours as raw hex with no semantic role. 57% define no distinctive motifs. 44% contain no concrete size value anywhere, and 54% rely on at least one vague adjective — "clean" in 39%, "modern" in 36%.

A file organised impeccably by atoms, molecules and organisms and containing none of that will produce a well-structured generic interface. The taxonomy was never the binding constraint.

Not a new taxonomy. The useful move is to keep the compositional discipline — which everyone already has — and add the layers atomic design never covered.

1. 1

   Keep the hierarchy, drop the argument

   Primitives, components, layouts. Three levels, decidable instantly. If your team already agrees on atoms/molecules/organisms and it costs nothing, keep it — the labels are not the problem, the arguing is.

2. 2

   Define components by contract, not composition

   Write down required elements, optional elements and properties. "A card requires a title and supporting text, optionally an image, a badge and a footer action." That statement survives any implementation, including one written by an agent in a framework you did not anticipate.

3. 3

   Add the constraint layer

   The list of things that are never done. No gradients, no shadow elevation, no font weight above 600, no colour outside the token set. This is the layer that changes generated output most and the layer most systems do not have.

4. 4

   Add the intent layer

   What the design is for and who reads it. A dense tool for people who live in it all day and a marketing page someone scans for forty seconds need opposite decisions, and no component hierarchy encodes which one you are.

Step two is worth expanding, because it is the part that transfers best to agent-written code. A contract is satisfiable by any implementation; a composition tree can only be satisfied by reproducing the tree. When the implementer is a model that may reach for a different structure than you would, a contract holds and a tree does not.

## Card

Required: title, supporting text
Optional: image, badge, footer action
Contains its own bottom divider; hidden when last in a list.

Padding 16px. Radius 12px. Border 1px --border-subtle.
Never uses a drop shadow — elevation is a surface step.
Never uses the accent colour for its border or background.

Nine lines, and every one of them is checkable. Note how much of it is prohibition. That ratio is the difference between a spec and a description.

No, and the framing is unhelpful. Atomic design made an argument that interfaces are composed systems. That argument is now so thoroughly accepted that it is invisible — it is baked into React, into every design tool, into every design system published since. You cannot discard it, because you are already inside it.

What has expired is the idea that the taxonomy is the deliverable. A system organised into five named levels and containing no constraints, no roles and no statement of intent is a filing scheme. It will produce consistent, well-structured, entirely interchangeable interfaces, which was never the goal.

The work that remains is the work atomic design deliberately left out: deciding what your design is for, what it refuses to do, and writing both down somewhere the thing building your interface will actually read.