Your coding agent does not know what your buttons looked like last sprint. It generates from the prompt in front of it and the file it can see, every time. Whenever I look at a design system now, I stop asking whether it is consistent and start asking whether an agent can read it without guessing.
Speed without memory
[A product design and development agency] published a piece recently with one phrase in it worth stealing. Speed without memory.
Not a study, not a benchmark. Just a good name for the thing. Cursor does not know what your buttons looked like last sprint. Claude Code does not know your spacing scale. Figma Make does not know which modal variant your team standardized on six months ago.
Each tool generates from the prompt and the immediate context. Not from accumulated product decisions.
So every AI assisted screen is a fresh guess unless something in the repo remembers on the tool's behalf.
That reframes what the system is for. On a team where agents write UI, a design system is not a consistency project. It is the memory layer. Tokens are the memory an agent reads, parity keeps the two copies honest, and governance is the write policy.
What the memory layer is made of
Four parts, held together. Not four parts sitting in the same folder.
Tokens. A component library. Coded components with design to code parity. Documentation plus governance.
The failures are almost always partial. A library with no governance. Tokens with no parity. Documentation that says what a component is and never what it is for.
The one I see fail most is parity. Teams build the library, ship the coded components, then let the two drift because nothing checks them against each other.
A partial system reads as working right up until a generator uses it. A person reading the library fills the gaps from memory. An agent does not have that memory, which is pretty much the whole point of this post.
Name tokens for what they do, not where they sit
This is the tactical core and it is smaller than it sounds.
A token named for its position in a scale carries no meaning an agent can act on. Neutral 400 tells a model nothing about when to reach for it. A token named for its job does. Surface secondary tells it something it can use.
Into Design Systems wrote up a talk by a design systems team at [a large collaborative whiteboard company] that hit the same wall from the other direction. Their first test was building a toolbar out of system elements only, and it came back confidently wrong.
The cause was naming. Into Design Systems says an icon labeled for text styles actually meant font styles, and a background token that had already been replaced was still pickable with no signal that it was deprecated.
Their fix was not a refactor. The write up says the icon and token architecture would have taken months to rework, so they expanded the metadata instead. A visual description, a use case, and a category per icon, with the do not use rule written into the description itself. Something along the lines of: represents font style like serif or sans serif, do not use to represent text style like bold or italic.
Re running the same prompt produced correct output.
That is one publication's write up of a team describing its own work, so take the specifics as reported rather than tested. The shape holds either way. The model was not the problem. A name written five years ago was the problem.
Parity is what keeps the two copies honest
Design to code parity stops being a nice to have the moment a generator can produce something that passes review while using the wrong values.
Three shapes of drift, in the order they usually arrive.
Token drift. A generated screen is close enough to pass. Nobody catches a value two steps off the scale, because nobody reviews values. They review screenshots.
Component multiplication. A second card component lands in production. Then a third. Each one generated by somebody who could not find the first.
Handoff collapse. A generated flow ships with tokens that do not match the coded components at all, and now the design file and the repo describe two different products.
Parity is the check that catches all three, and it only counts if it runs automatically. A parity rule a human runs on Fridays is a rule that stops existing in week three.
Governance is the write policy
Short one, stated as a rule.
If tokens are the memory an agent reads, governance is what decides who gets to write to that memory and what happens to a value that got replaced.
A deprecated token that is still pickable, with no signal, is a lie the system tells every consumer. Human or not.
Deprecation is not a note in a changelog. It is a state the tooling has to carry.
The audit pass I actually run
Here is the discipline underneath all of it, and I got it from doing UX audits the slow way.
Before you log a bug against the app in front of you, layer trace it. Ask whether the bug lives at the design system level.
If it does, fix it there. The fix cascades to every consuming app for free.
Fix it at the leaf and you will see the same bug in a different component next week, filed by a different person, as a new ticket.
Most UI bugs I find on a consuming app are really design system bugs wearing a costume. You only catch them in a structured pass, because in normal work everybody files against the screen in front of them. The screen is the part they can see.
That habit was worth having before agents showed up. It is worth more now, because a generated component inherits the source of truth exactly as written, including the parts that are wrong.
The pass to run on Monday
Short and runnable. Twenty minutes.
Open one screen that was generated in the last two weeks.
Check every visual value against a token. Color, spacing, radius, type.
For each miss, ask three questions in this order. Does the token exist. Is it named for its job or for its place in a scale. Is the deprecated version still reachable.
Then fix at the layer the answer points to. Missing token, add it. Badly named token, write the metadata before you refactor, because metadata ships this week and a refactor does not. Reachable deprecation, make it unreachable.
Run that on one screen and you will know inside twenty minutes whether your system is memory or decoration.
The checklist version of this pass, with the naming rules written out, goes to The Production Layer at timurtek.com.
Your agent remembers exactly as much as you wrote down. Nothing else survives the session.
