Method note
Teaching an AI a design system it has never read
A design system is the set of rules that make every screen look like it belongs. A human infers them. An AI does not.
The problem
Prototyping directly in code with AI, a problem surfaced almost immediately: it wrote code outside the design system. A table imported from Material here, a blue that isn't in the palette there. Not because it designed badly, but because the system's rules were written down nowhere. They lived in the designers' heads.
Ask an assistant for a table: it produces a generic one, sound in itself, but full of conventions the system forbids. My work was to write those rules down so it would respect them.
Design system × AI: the problem in one image
Making implicit rules explicit
Demonstrated on « Nimbus », a fictional design system I created to illustrate the principle without disclosing the Thales one.
Nimbus · before / after
When the AI reaches for the generic default
Ask an assistant for a table and you get a generic « Material » table, outside the system. Toggle to compare, and hover (or tap) a numbered marker to see why.
AI import · Material · outside the system
- Round avatars: the system wants them square. And a blue that doesn't exist in the palette.Row 04-AActiveA status pill instead of the house badge.
- Row 12-CPending
- Row 07-BError
See the rule as the machine reads it
RULE action-hierarchy
max_primary_per_view: 1 # une seule action attendue
secondary: outline # jamais seule, accompagne un primary
tertiary: text-only # faible emphase, non bloquante
enforce: on_generate, on_review
RULE no-foreign-table
forbid:
- elevation > 0 # Nimbus est plat : bordures uniquement
- color: outside(tokens) # pas de bleu Material hors palette
- avatar.shape: circle # avatars carrés à coins arrondis
- pagination: default # utiliser le composant Nimbus
- status: chip # statut = badge point-coloré + libellé
on_violation: block, explainThe pipeline
Writing the rules down isn't enough: you first have to decide which ones carry authority. The existing documentation was sufficient for human designers, but left too much implicit for an agent. Every silent area had to be settled before it could be encoded.
Design system → AI skills pipeline
Click a step to see its key decision.
A five-step pipeline, in order: Existing documentation, Governance, Translation into skills, Coded prototypes, Client demos. A return arc then feeds what was learned in the client demos back into governance and the translation into skills, in a continuous improvement loop.
Iterative improvement: learnings fed back into Governance and Translation into skills.
System
Existing documentation
The starting point: documentation that was sufficient for human designers, but left too many rules implicit for an AI agent.
The structure of the pipeline is real; the precise rules and prompts of the skills remain internal to Thales.
What it produced
The skills — rule files the AI reads before generating code — save roughly four hours per ideation cycle, measured across four projects. A first team has adopted them, and extending to others is planned. A developer joined the version aimed at developers; the two of us maintain it.
The limit
You can only encode rules that already exist. Wherever the design system was silent, the AI kept producing defaults that had to be settled by hand.
So the next piece of work isn't writing more skills. It's filling the blind spots in the system itself — and going through an AI had this unexpected merit: it made visible everything the design system wasn't saying.