A design system has always been an organisational system for deciding how change travels. It sets what is stable, what can vary, who may change what, how exceptions are handled, and how the cost of inconsistency becomes visible. The component library is the part people see. The rest has mostly lived in culture: review rituals, office hours, a contribution model, the goodwill of the team that maintains it, and a great deal of judgement nobody wrote down because people could always ask.
Coding agents change where that judgement lives. Once tools generate, modify and review interface work from the system’s own files, the organisational system gets written down, and every governance question receives a mechanical answer whether or not anyone chose it.
The system as instruction
I run design systems this way now. In the design organisation I lead, the source of truth is a set of version-controlled context files, and a coding agent builds tokens, components and patterns from them. On a client project with a robotics company, the second phase ran with no design files at all, and the prototypes were the code.
Working like this makes literal what used to be figurative. A design decision becomes a commit, with an author, a date, a diff and, when the team is disciplined, a reason. Decision rights become merge rights. Deprecation becomes deletion, because a pattern that stays in the agent’s context will keep being reproduced whatever the documentation says about it. An exception included as an example becomes a default, since the tool has no way to tell the case the team tolerated from the case it endorsed. A stale context file preserves an old decision long after the people who made it have moved on.
People have always gone to the system to find things. Tools now go to it to learn what good work looks like, and that is a larger responsibility.
Where drift goes now
Drift has always been the slow enemy of a design system: the local fork, the detached component, the one-off that becomes three. Generated work changes its speed and its disguise.
Agents are most reliable at the lowest level of the system. Tokens are explicit, and components have contracts. Patterns are harder, because a pattern encodes when to use something, and the when is the part teams most rarely write down. An agent asked to assemble a screen from well-documented components and thinly documented patterns will improvise the composition, and improvised composition looks coherent. It uses the right colours, the right type and the right buttons, arranged in ways the system never sanctioned. A reviewer moving quickly sees familiar parts and passes the whole.
This is plausible inconsistency at speed, and it can make the first months of an agent-shaped workflow look like a success. Output rises before coherence does. The cost arrives later, as review load, accessibility issues reproduced at scale, duplicated logic, and interfaces that are recognisably on brand and still outside the system.
Every migration has a dip, where teams slow down before they speed up. Generated work can hide the dip, which makes it more dangerous. The response is the familiar one, made stricter. Sequence the change. Remove hybrid states quickly, because an agent given old and new patterns side by side will faithfully reproduce both. Treat stale instruction as debt.
Governance becomes literal
The governance questions are the old ones with sharper edges. Who owns the context? Who decides what an agent may generate without review, and which kinds of work must come back to a person? How does a deprecated pattern leave the tool’s working memory, and how would anyone know it had? How are accessibility, content and interaction rules tested in what the tools actually produce?
Teams used to answer these through habit and conversation. In a code-first system the answers sit in repository permissions, review rules, test suites and the contents of a folder. That is an advantage, because governance becomes inspectable: anyone can see who can change what, and when it last changed. It also removes the comfortable ambiguity that let a design organisation postpone decisions. A team that has never agreed who owns a pattern finds out, the first time an agent reproduces it badly, that the repository has already decided for them.
Whether it holds
Counting components and documentation pages shows whether a system is maintained. Whether it holds shows in the work: how often generated interfaces reuse approved components, how often they invent patterns the system already has, whether deprecated patterns still appear in agent output, how much review effort stands between generated work and acceptance, and whether accessibility issues are falling or being reproduced faster. The sharpest measure is the question a reviewer asks before approving: was this accepted because it was right, or because it was fast?
The question a design system now has to answer is what it will teach the next person, or tool, to do by default. With agents in the loop, carrying a system means writing down the judgement that used to travel by conversation, deciding who owns it, and noticing when it goes stale. That is organisational work, and it is done in files.
Conway’s observation that systems mirror the communication structures of the organisations that build them sits under all of it, as does the socio-technical tradition that runs from Trist and Bamforth onward. Atomic design, in Frost, gave the field its hierarchy of parts, and Curtis’s writing on design-system team models and governance treated the system as an organisational product. Design tokens, introduced at Salesforce and now being standardised by the W3C Design Tokens Community Group, made design decisions machine-readable before agents arrived to read them. A fast-growing practitioner conversation about design systems for coding agents is under way, and this joins it.
What this piece adds is the shift in kind: agent-readable context turns a system’s governance from culture into mechanics, so decisions an organisation had avoided making get made for it by whatever its repository happens to contain.