Components an agent can reason about
By Allan Leone on
Spotify rebuilt their component architecture into independent layers so an AI has less to hold in its head at once. It is the most practical design system idea I have heard this year.
The talks from this year's AI design systems track have been circulating, and the one that stuck with me is Spotify's. Their Encore team separated foundations, styles and behaviours into independent layers, and the reason given was not purity. It was that smaller, separable layers create smaller context bubbles for a model to reason about.
That reframing is useful. We have argued about component architecture for a decade using words like coupling and reuse. Here is a new and completely concrete constraint: how much of this does something have to read before it can correctly produce one button.
Monolithic components are context hogs
A component that fuses layout, visual style, state and behaviour into one file is a component you cannot ask a narrow question about. To change the padding, a model loads the animation logic and the accessibility wiring too. It burns context on irrelevance and it has more surface on which to go wrong.
Split those concerns and a question about spacing reads spacing. This is the same argument as separation of concerns, with a measurable cost attached for the first time.
The evaluation part is the bit people skip
The other half of what Spotify described is a custom evaluation framework that runs prompts against several models and compares the generated components both visually and in code. That is a test suite for your design system's legibility.
Almost nobody has this. Teams publish an MCP server or a documentation site, assume agents can now use the system, and never check. The check is not complicated: ask three models to build five known components from your documentation, and look at what comes back.
- If they all get it wrong the same way, your documentation is wrong.
- If they disagree with each other, your documentation is ambiguous.
- If they invent a prop that does not exist, you have a naming problem.
This is just good documentation with a harsh reviewer
Everything that makes a design system readable to an agent makes it readable to a new designer in their first week. Predictable names. One obvious way to do the common thing. Constraints stated rather than implied by the examples.
The difference is that the new designer will ask you in Slack when the documentation fails them, and quietly patch the gap with a guess. The model does not ask. It produces confident output built on the gap, and you find out in review. It is a less forgiving reader, which turns out to be useful.
Tags: design, ai, engineering