Design system e agenti AI: 6 regole di governance per il 2026

Un design system leggibile dalle macchine è un design system pubblicato come dati strutturati (token, un manifest dei componenti, regole d'uso) che gli agenti AI di sviluppo interrogano attraverso un'interfaccia come un server MCP. Così le interfacce che generano usano i componenti e le decisioni che il team ha già approvato. Quando a leggerlo sono gli agenti, il design system si comporta come un'API: ha utenti che non possono chiedere a un collega, non intuiscono le intenzioni e sbagliano a ogni modifica non documentata.

Il tema riguarda chi gestisce un design system e ha cominciato a vedere Cursor, Claude Code o Copilot scrivere schermate con i suoi componenti. Gli strumenti sono arrivati in fretta. Il server MCP di Figma passa agli agenti variabili, componenti e collegamenti di Code Connect. Storybook genera un manifest JSON dei componenti per il suo server MCP. Google Labs ha pubblicato DESIGN.md come formato aperto. La governance era pensata per lettori umani e non ha tenuto il passo. Vediamo cosa cambia e le sei regole che applichiamo.

Cosa cambia quando a leggere il design system è un agente?

Un lettore umano colma i vuoti. La designer che trova due tonalità dello stesso blu chiede qual è quella in uso. Lo sviluppatore che vede una prop deprecata in Storybook legge la nota e va avanti. Un agente non fa né l'una né l'altra cosa. All'AI Design Systems Conference 2026 i relatori hanno indicato come primo errore il disallineamento della documentazione: quando documentazione, token e componenti dicono cose diverse, l'agente prende la prima fonte che trova, secondo il resoconto degli interventi pubblicato da Into Design Systems. Nello stesso resoconto Romina Kavcic stima che la sola manutenzione occupi dal 30 al 40% del tempo di un team di design system.

Ne derivano tre conseguenze.

• Il disallineamento finisce nel prodotto. Un'incoerenza che prima costava un commento in revisione ora compare in ogni schermata generata da un agente.
• La prosa perde contro la struttura. Una nota d'uso dentro un paragrafo è un consiglio per una persona e rumore per un modello che cerca un campo.
• Ogni modifica ha utenti che non vedi. Prompt, file di regole e contesti salvati in una decina di editor dipendono da nomi che qualcuno potrebbe cambiare un martedì qualsiasi.

Di cosa è fatto un design system leggibile dalle macchine nel 2026

Di quattro parti, ognuna con un formato che si è assestato nell'ultimo anno.

• Token. Il Design Tokens Community Group ha pubblicato la prima versione stabile della specifica, la 2025.10, il 28 ottobre 2025. Definisce un formato JSON indipendente dai fornitori, con alias, temi e una proprietà $deprecated che un tool o un agente può leggere.
• Manifest dei componenti. Storybook genera dei manifest, oggetti JSON che elencano ogni componente con props, storie e documentazione, e li serve agli agenti attraverso il suo server MCP. Storybook la presenta come funzione in anteprima, e lo schema del manifest non è ancora un'API pubblica stabile.
• Contesto di design. Con il server MCP di Figma gli agenti leggono variabili, componenti e screenshot di un file, e Code Connect collega ogni componente Figma al componente di codice che lo implementa.
• Regole e motivazioni. DESIGN.md, rilasciato come open source da Google Labs, mette i token in un front matter YAML e le ragioni delle scelte in prosa Markdown. Lo schema dichiara ancora la versione "alpha". I file AGENTS.md portano allo stesso modo le istruzioni del repository.

Murphy Trueman ha fatto il conto: la stessa decisione di design oggi può stare in cinque posti, e nella maggior parte dei team non è chiaro chi sia responsabile della parte letta dagli agenti. È qui che manca la governance.

Il formato conta?

Sì, e ci sono i dati. Diana Wolosin di Indeed ha estratto 77 componenti dalla documentazione MDX e ha lanciato 1.056 prompt su otto configurazioni MCP. Con il Markdown ogni query costava circa 30.000 token, copriva l'82% delle risposte e produceva allucinazioni. Con i metadati JSON le risposte erano più precise, con l'80% di token in meno e un costo annuo circa cinque volte più basso, come riporta Into Design Systems. La regola pratica che ne esce: i dati strutturati (props, varianti, dimensioni, valori ammessi) vanno in JSON; le motivazioni restano in prosa, per quando il modello ha bisogno del perché.

Le sei regole di governance

1. Una sola fonte, tutto il resto generato

Per ogni tipo di decisione si sceglie una fonte e il resto si genera da lì. I valori dei token stanno nel file JSON in formato DTCG; le variabili Figma, le custom property CSS, il front matter di DESIGN.md e i riferimenti ai token nel manifest escono dalla build. Le API dei componenti stanno nel codice, e il manifest si ricava dal codice e dalle sue storie. Un file che un agente legge e una persona modifica a mano prima o poi diverge, e l'agente continua a fidarsene. Nei file scritti a mano resta solo quello che non si può ricavare: l'intenzione, i compromessi, i casi in cui un componente è la scelta sbagliata.

2. Versionare la parte letta dagli agenti come un'API pubblica

Il versionamento semantico vale anche per ciò che leggono gli agenti, insieme al pacchetto. Rinominare un token, togliere una variante o cambiare i valori ammessi di una prop è una modifica major per un agente, anche quando il risultato visivo resta identico, perché file di regole e prompt citano il nome vecchio. Prima si depreca, poi si rimuove, e il sostituto va scritto nei dati: una stringa $deprecated sul token con il nome del successore, un campo deprecated sul componente che rimanda a quello nuovo. Gli agenti leggono i campi. Il changelog raramente arriva fino a loro.

3. Un solo responsabile per la parte letta dagli agenti

Nella descrizione di Trueman i token tendono a restare al team di design system e AGENTS.md all'ingegneria, mentre la configurazione MCP di Figma resta a chi l'ha installata. Se nessuno risponde dell'insieme, nessuno si accorge che il manifest ha smesso di rigenerarsi tre release fa. Una persona o un team approva ogni modifica a ciò che leggono gli agenti, con la revisione che si dà a una modifica di un'API pubblica. Il modello di governance per un design system con molti progetti consumer vale anche qui, tale e quale: gli agenti sono un consumer in più, il più letterale di tutti.

4. Scrivere le regole d'uso come dati

"Usa il pulsante distruttivo solo per le azioni irreversibili" è una frase. {"intent": "destructive", "use_when": "the action cannot be undone", "requires": "confirmation dialog"} è una regola che un agente può verificare. Ogni regola che ha una risposta sì o no esce dalla prosa ed entra nei campi: quando usarlo, quando non usarlo, cosa serve accanto, con cosa sostituirlo. La prosa resta per le scelte che chiedono giudizio. I team che seguono già una convenzione rigorosa di naming dei token hanno fatto metà del lavoro, perché il nome porta già l'intenzione.

5. Decidere cosa può modificare un agente

Ormai gli agenti propongono anche modifiche ai design system: aggiornamenti dei token, correzioni alla documentazione, nuove storie. Va messo per iscritto quali modifiche può fare un agente e a quali condizioni. Una suddivisione presentata alla conferenza: correzione automatica per le modifiche a basso rischio, come errori di lint ed etichette di accessibilità; pull request in bozza per valori dei token e descrizioni; solo suggerimenti per nuove API dei componenti, modifiche incompatibili e decisioni di governance. In GitHub gli agenti che lavorano sul design system Primer possono aprire una issue ma non fare il merge del codice, secondo lo stesso resoconto.

6. Testare quello che producono gli agenti, a ogni release

Un design system si testava al proprio confine: il componente viene visualizzato, supera i controlli di accessibilità. Con gli agenti il confine si sposta sul risultato. Si tiene un insieme fisso di prompt (una pagina di impostazioni, una tabella prezzi, un empty state) e lo si lancia sulla parte letta dagli agenti a ogni release. Nell'interfaccia generata si cercano componenti che non esistono, valori esadecimali scritti a mano e props fuori dai valori ammessi. Il server MCP di Storybook va già in questa direzione: l'agente scrive le storie di ciò che ha generato e ci fa girare test di interazione e di accessibilità. Con un controllo in CI che fallisce quando manifest, token e codice non coincidono, il component drift emerge come build fallita prima di comparire in una schermata generata.

Come si presenta su un solo componente

Prendiamo un Button con una prop variant che prima ammetteva danger e ora usa destructive. Con una governance pensata per le persone, il cambio di nome esce con una riga nel changelog e un codemod. Con una governance da API, nella stessa release cambiano quattro cose:

1. Il codice continua ad accettare danger per una versione major e lo segna come deprecato nei tipi.
2. Il manifest, rigenerato dal codice, elenca danger come deprecato e indica destructive come sostituto.
3. Il token button.danger.background porta "$deprecated": "Use button.destructive.background".
4. Parte la suite di prompt, e ogni schermata generata che scrive ancora danger non supera il controllo.

Il cambio di nome costa un pomeriggio in più. In cambio nessun agente continua per mesi a generare il nome vecchio da un contesto superato.

Quando non vale ancora la pena

Un team con un solo prodotto, pochi componenti e nessun agente che scrive interfacce ricava poco da manifest e suite di prompt. Il costo è reale: pipeline per generare i file, una revisione per ogni modifica ai metadati, una suite di test da mantenere. Due segnali dicono che è il momento: gli agenti generano già schermate nel codice, oppure il design system serve più di un prodotto. In entrambi i casi la parte letta dagli agenti esiste comunque, che qualcuno la governi o no, e il lavoro descritto qui costa meno che rimediare a quello che produce senza regole. Abbiamo trattato il passaggio dal design al codice nella guida al server MCP di Figma e il lato dell'interfaccia in progettare la UI per gli agenti AI.