For twenty years a design system has been a kit. Components, tokens, a documentation site, and a Figma library that someone keeps mostly in sync.
The value was reuse. Build the button once, use it four hundred times, stop arguing about padding. That value is now close to zero.
A machine can produce a button in a second. It can produce a whole settings screen in a minute, and the output will look fine. If your design system exists to save people from rebuilding components, you have opened a bicycle shop next to a train station.
The value has not disappeared. It has moved, and where it moved to is the more interesting question.
From vocabulary to grammar
Most teams describe their design system as a shared language. That is half right, and the missing half is the important one; a vocabulary is a list of words. Card, button, badge, primary... Almost every design system is a very good vocabulary with a website attached.
A grammar is different. A grammar tells you which sentences are valid. It rejects things. This pairing is not allowed. That spacing value does not exist. A dialogue with no way out is not a screen, it is a trap. None of that lives in your component list. It lives in the heads of a few senior people, in review comments, and in a shared sense of what looks right.
People absorb a grammar by working alongside each other. Years of experience. The design eye that gives you that "hunch". Software does not. Give a machine a vocabulary and no grammar and it will produce confident nonsense, because nothing in the system ever told it no.
So the theory shifts. A design system stops being a library of parts. It becomes a model of constraints that happens to ship parts.
What design as data means
Design as data is the practice of moving design intent out of documents and into structure a machine can read and check.
A component stops being a file with a page of documentation attached. It becomes a record of what it is made of, how it may be configured, which states it must handle, and what it owes the person using it. The code becomes one rendering of that record. The design file is another. The documentation is a third. None of them is the source of truth, because the structure is.
That change sounds administrative. It is not. A documentation site can only tell you what exists. A structured design system can answer questions. Which screens still use something we retired. Which parts of the product have no error state. Whether a proposed layout is even legal before anyone builds it.
A design system you can query is a different asset to a design system you can browse.
Review the plan, not the building
The second shift is about when review happens – ask a machine for a screen and it gives you code. You then review the code, which is slow, and by the time you find the problem the structure is already set. The better move is to insist on something in between: a short, readable description of what the interface is composed of, before any of it is built.
That description is cheap to read, cheap to reject, and cheap to check automatically. It is the difference between reviewing a floor plan and reviewing a finished building.
Most of the current excitement about design systems and AI is really excitement about this. The plumbing matters far less than whether the rules travelled through it.
What it changes for the people?
- Designers move upstream, not out. If a machine can compose from the system, the scarce skill becomes defining the system: what the constraints are, which tensions the product has to hold, what good looks like when nobody is watching. That is design at a higher altitude, and there is more of it, not less.
- Review changes shape. You stop checking pixels one screen at a time and start settling rules once, then holding every screen to them. A rule agreed in the model holds everywhere, forever. A rule agreed in a critique holds once.
- Design operations becomes coordination. Someone has to own the constraints, the quality bar, and the question of which decisions software is allowed to make on its own. That is a real job, and most organisations do not have anyone doing it yet.
Speed is not the constraint any more – judgement is.
When a system can produce fifty screens in an afternoon, the expensive failure is fifty screens that are all subtly wrong in the same way. Automation multiplies whatever you give it, including a bad decision.
So the answer is not to take people out of the loop. It is to put them at the point where their judgement compounds: on the constraints, on anything a customer will touch, on anything you cannot undo. Automate the enforcement. Keep the approval human.
This is how we build at CodeFish. Our design system is treated as structured data with rules attached, our teams work with AI on the composition, and a person signs off every screen that reaches a customer. It is why we can move quickly on client work without the quality drifting screen by screen.
The components were never the asset. The constraints were.
