Il design è il codice

Come la logica degli automi cellulari rimodellerà i sistemi di design agentici e perché il futuro dello sviluppo web potrebbe essere già scritto in semplici regole

Sta avvenendo una trasformazione profonda all'incrocio tra design system, intelligenza artificiale e teoria della computazione. Un cambiamento così radicale da mettere in discussione ciò che intendiamo per "design" nell'era degli agenti autonomi.

Per decenni abbiamo trattato design e codice come discipline separate: il design come regno della creatività umana e del giudizio estetico, il codice come traduzione meccanica di quelle idee in una forma eseguibile. Ma ora che gli agenti AI assemblano sempre più spesso le interfacce in autonomia, consumano i design system come infrastruttura leggibile dalle macchine e generano codice a partire da token semantici, ci avviciniamo a un punto di convergenza che richiama un'idea ben più antica della teoria della computazione.

Quale idea? Il design è il codice.

Non è solo uno slogan efficace. È il riconoscimento che potremmo avviarci verso un mondo in cui i design system funzionano come automi cellulari: regole semplici da cui nascono comportamenti complessi ed emergenti. Un mondo in cui la distinzione tra "progettare" qualcosa e "programmarlo" si dissolve del tutto. Dove gli agenti autonomi non si limitano a usare i design system, ma ne sono l'espressione in azione.

Questo articolo esplora i legami profondi tra automi cellulari, comportamento emergente e futuro dei design system agentici. Ripercorreremo le basi teoriche, dalle macchine autoreplicanti di von Neumann agli sciami di agenti AI di oggi.

Vedremo come Drupal e le moderne piattaforme CMS stanno integrando l'AI attraverso moduli come Schema.org Blueprints e Drupal AI. E rifletteremo su cosa significhi tutto questo per designer, sviluppatori e per il futuro della creazione di prodotti digitali.

Automi cellulari e la logica dell'emergenza

La bellezza delle regole semplici

Nel 1970 il matematico John Conway introdusse il Gioco della vita, un "gioco senza giocatori" destinato a diventare uno dei sistemi più studiati della teoria della computazione. Le regole sono di una semplicità disarmante:

1. Ogni cellula viva con meno di due vicini vivi muore (isolamento)
2. Ogni cellula viva con due o tre vicini vivi sopravvive
3. Ogni cellula viva con più di tre vicini vivi muore (sovrappopolazione)
4. Ogni cellula morta con esattamente tre vicini vivi torna in vita (riproduzione)

Da queste quattro regole, espresse in una manciata di condizioni binarie, emerge un universo sorprendente di complessità. I glider attraversano griglie infinite. Gli oscillatori pulsano con ritmi perpetui. I cannoni sparano flussi di pattern nello spazio cellulare. E, cosa ancora più notevole, il Gioco della vita è stato dimostrato Turing-completo: tutto ciò che si può calcolare con un algoritmo si può, in linea di principio, calcolare all'interno della semplice griglia di Conway.

Figura 1: il Gosper Glider Gun nel Gioco della vita di Conway. Questo schema produce un flusso continuo di glider, a dimostrazione di come regole semplici possano generare una complessità infinita che si autoalimenta.

Questa è la prima lezione degli automi cellulari: la complessità non è un prerequisito per un comportamento complesso. Regole semplici, applicate in modo coerente su un substrato, possono dare origine a schemi e comportamenti che nessuno ha programmato esplicitamente.

I Langton's Loops e l'autoreplicazione

Nel 1984 Christopher Langton spinse questo principio ancora più in là con i suoi anelli autoreplicanti, un automa cellulare che dimostrava veri principi di vita artificiale. A differenza del Gioco della vita di Conway, che mostra una complessità emergente, i Langton's Loops mostrano una riproduzione.

emergente. Ogni anello è formato da un confine ciclico che racchiude un "genoma" codificato negli stati delle celle. Questo genoma scorre di continuo lungo l'anello e fuoriesce attraverso un braccio di costruzione, che edifica un anello figlio nell'arco di 151 passi temporali. A lavoro finito, il figlio si separa dal genitore e entrambi continuano a replicarsi.

Figura 2: il Langton's Loop nella sua configurazione iniziale. L'informazione genetica circola nell'anello e guida la costruzione degli anelli figli attraverso il braccio che si estende.

"Se una macchina autoriproducente è possibile all'interno di un automa cellulare, allora la vita stessa potrebbe essere realizzabile dalle macchine."

- Christopher Langton, "Studying Artificial Life with Cellular Automata" (1986)

Le implicazioni sono profonde. I Langton's Loops dimostrano che l'autoreplicazione non richiede la complessità delle cellule biologiche né le capacità di costruzione universale del progetto originale di von Neumann. Richiede soltanto:

• Un insieme di regole semplici e locali
• Un meccanismo per codificare le istruzioni
• Un processo con cui quelle istruzioni vengono eseguite

Le regole sono l'organismo. Il progetto è il codice.

Nel 1999 Hiroki Sayama introdusse gli evoloops, varianti che incorporano la dissolvibilità strutturale e le interazioni fenotipiche, rendendo possibili mutazioni spontanee e dinamiche evolutive. Questi anelli evolvono attraverso collisioni fisiche dirette durante la replicazione, con variazioni del genotipo, una maggiore diversità morfologica e una complessità che cresce di generazione in generazione. A differenza della replicazione fissa di Langton, gli evoloops mostrano mutazioni ereditabili senza alcun intervento esterno.

Regola 110 e calcolo universale

L'esplorazione degli automi cellulari elementari condotta da Stephen Wolfram culminò in una scoperta sorprendente: la Regola 110, una delle sole 256 regole possibili per il tipo più semplice di automa cellulare unidimensionale, è in grado di eseguire un calcolo universale.

La Regola 110 può essere definita completamente indicando l'esito per ciascuna delle otto possibili combinazioni di una cella e dei suoi due vicini. Eppure questa regola banalmente semplice, otto decisioni binarie, è in grado di simulare una macchina di Turing universale.

Figura 3: l'automa cellulare Regola 110. Nonostante la definizione semplice, la Regola 110 mostra un comportamento di Classe 4, cioè schemi complessi che non sono né del tutto stabili né del tutto caotici, e se ne è dimostrata la Turing-completezza.

"Per fare calcolo universale non serve nulla che somigli a una CPU completa. Basta questa piccola regola."

- Stephen Wolfram, "A New Kind of Science"

Nel 2004 Matthew Cook pubblicò una dimostrazione del fatto che la Regola 110, con un particolare schema di sfondo che si ripete, è Turing-completa. La dimostrazione mostra che la Regola 110 può emulare i sistemi di tag ciclici, i quali a loro volta possono emulare qualsiasi macchina di Turing. Tra gli 88 automi cellulari elementari unici possibili, la Regola 110 è l'unica per cui la Turing-completezza sia stata dimostrata direttamente.

Il Principio di Equivalenza Computazionale proposto da Wolfram suggerisce qualcosa di ancora più radicale: i sistemi che superano una soglia minima di complessità sono sostanzialmente equivalenti nelle loro capacità di calcolo. Un cervello umano, un sistema meteorologico e la Regola 110 sono, in un senso profondo, computazionalmente equivalenti.

La metacella 0E0P: la vera autoreplicazione

Nell'ottobre 2018 Adam P. Goucher completò la costruzione della metacella 0E0P, uno schema del Gioco della vita di Conway capace di vera autoreplicazione. A differenza delle metacelle precedenti, che richiedevano la presenza di copie preesistenti nelle vicinanze, la metacella 0E0P può costruire copie di sé stessa partendo da zero, compreso il proprio nastro di istruzioni.

Questo risultato rappresenta una pietra miliare della vita artificiale: un sistema in grado di propagarsi attraverso un substrato computazionale usando soltanto regole locali. Il 23 novembre 2013 Dave Greene costruì il primo replicatore del Gioco della vita che crea una copia completa di sé stesso, nastro di istruzioni incluso, dimostrando che persino il semplice automa a due stati di Conway può sostenere una riproduzione illimitata.

I sistemi di design come substrati computazionali

Dall'Atomic Design al design agentico

La metodologia Atomic Design di Brad Frost, introdotta nel 2013, ha rivoluzionato il nostro modo di pensare i sistemi di design. Scomponendo le interfacce in atomi (elementi di base come pulsanti e campi di input), molecole (combinazioni semplici), organismi (sezioni complesse dell'interfaccia), template (layout di pagina) e pagine (implementazioni finali), l'Atomic Design ha offerto una struttura gerarchica per gestire la complessità.

Ma ecco la cosa notevole, a posteriori: l'Atomic Design incarnava già i principi degli automi cellulari senza riconoscerli esplicitamente.

"Quando il design system è noioso, designer e sviluppatori sono liberi di fare cose nuove, di risolvere problemi nuovi. Il design system si fa carico della noia, così che designer e sviluppatori non debbano farlo."

- Josh Clark, "The Most Exciting Design Systems Are Boring"

Nel febbraio 2023 Brad Frost scriveva di "Design Systems in the Time of AI":

"L'AI è un consumatore naturale dei design system... Il fatto è che gran parte del lavoro sui componenti di un design system è davvero meccanico e prevedibile. Usiamo già strumenti come PlopJS per generare il boilerplate di un componente che rispecchia la struttura del resto della libreria. Accoglierei volentieri l'aiuto dell'AI per produrre al posto mio un sacco di boilerplate ordinario."

- Brad Frost

La natura meccanica e prevedibile dei design system è esattamente ciò che li rende adatti a un funzionamento in stile automa cellulare. Quando le regole sono chiare, locali e applicate in modo coerente, gli agenti possono operare in autonomia, proprio come le cellule del Gioco della vita di Conway non hanno bisogno di un controllore centrale per produrre glider e oscillatori.

L'imperativo della leggibilità per le macchine

La Storybook MCP (Model Context Protocol) è un'iniziativa che rappresenta un'evoluzione cruciale in questa direzione. Annunciata alla fine del 2025, Storybook MCP offre agli agenti AI di programmazione metadati dei componenti leggibili dalle macchine, ricavati dalle configurazioni Storybook esistenti.

L'intuizione chiave è che gli agenti non hanno bisogno di codice grezzo o di documentazione visiva. Hanno bisogno di:

• Manifest dei componenti: metadati strutturati su ogni componente: props, varianti, associazioni ai design token ed esempi d'uso
• Nomi semantici: token ricchi di intento, come action.primary.confirm che trasmettono significato agli agenti, non solo valori
• Cicli di validazione: la capacità di eseguire i test, vedere i fallimenti e correggersi da soli

"Storybook MCP aiuta gli agenti a seguire i tuoi pattern e a superare i tuoi test. Offre loro due cose che non hanno mai avuto prima: metadati dei componenti leggibili dalle macchine e un ciclo iterativo per autocorreggere gli errori."

- Il team di Storybook

Storybook MCP include un ciclo di correzione autonomo. Permette agli agenti di eseguire i test dei tuoi componenti (di interazione e di accessibilità), vedere cosa fallisce e correggere da soli i propri bug. Lo sviluppatore deve intervenire solo dopo che i test sono passati. Basta fare da babysitter ai prompt.

Questa è esattamente l'architettura di un automa cellulare applicata al design: regole locali (le specifiche dei componenti), interazioni tra vicini (i pattern di composizione) e aggiornamenti iterativi (validazione e autocorrezione).

Il mio manifest dei componenti come genoma

Il paragone con i Loop di Langton diventa ancora più calzante se pensiamo a come funzionano i manifest dei componenti. Nel sistema di Langton, il "genoma" codificato nelle cellule che circolano contiene le istruzioni per costruire un nuovo loop. In un design system leggibile dalle macchine, il manifest del componente contiene le istruzioni per assemblare le interfacce.

Un manifest di componente potrebbe specificare:

{
  "name": "Button",
  "variants": ["primary", "secondary", "destructive"],
  "sizes": ["sm", "md", "lg"],
  "props": {
    "label": "string",
    "disabled": "boolean",
    "onClick": "function"
  },
  "tokens": {
    "background": "color.action.primary",
    "borderRadius": "radius.md",
    "padding": "space.3"
  },
  "constraints": [
    "Must have accessible contrast ratio",
    "Label required for non-icon buttons",
    "Minimum touch target 44x44px"
  ],
  "examples": [
    { "variant": "primary", "label": "Submit", "size": "md" },
    { "variant": "destructive", "label": "Delete", "size": "sm" }
  ]
}

Questo manifesto è al tempo stesso una specifica di progettazione e codice eseguibile, o meglio, le istruzioni da cui si può generare codice eseguibile. L'agente che usa questo manifesto non ha bisogno di capire l'estetica o l'esperienza utente nel senso umano del termine. Gli basta seguire le regole, combinare gli elementi nel rispetto dei loro vincoli e produrre output validi.

Sono d'accordo con Brad Frost sull'usare un formato yaml.

I componenti di Drupal usano il formato yaml. Qualcosa come

$schema: https://git.drupalcode.org/project/drupal/-/raw/HEAD/core/assets/schemas/v1/metadata.schema.json
name: Button
status: experimental
description: Use Bootstrap custom button styles for actions in forms, dialogs, and more with support for multiple sizes, states, and more.
props:
  type: object
  properties:
    html_tag:
      type: string
      title: The HTML tag to use for the button (button | a). Defaults to `button`.
      default: button
      enum:
        - button
        - a
    url:
      type: string
      title: URL Link
      description: URL link for the button when the HTML tag is an anchor link.
      $ref: "ui-patterns://url"
    color:
      type: string
      title: Color
      description: Bootstrap includes several predefined button styles, each serving its own semantic purpose, with a few extras thrown in for more control.
      default: ''
      enum:
        - ''
        - primary
        - secondary
        - success
        - danger
        - warning
        - info
        - dark
        - light
        - link
    outline:
      type: boolean
      title: Outline
      description: In need of a button, but not the hefty background colors they bring? Replace the default modifier classes with the .btn-outline-* ones to remove all background images and colors on any button.
      default: false
    size:
      type: string
      title: Size
      description: Bootstrap button size
      default: ''
      enum:
        - ''
        - btn-sm
        - btn-lg
    disabled:
      type: boolean
      title: Disabled
      description: Disabled button
      default: false
    button_utility_classes:
      type: array
      title: Utility Classes
      default: []
      items:
        type: 'string'
      description: An array of utility classes that can be used to add extra Bootstrap utility classes or custom classes to this component.
    attributes:
      type: object
      title: Attributes
      description: HTML attributes for the containing element.
      $ref: 'ui-patterns://attributes'
slots:
  content:
    type: string
    title: Content
    description: The content for the button
    minLength: 1
    examples:
      - Press
      - Submit now
      - Save
      - Login
      - Read more

Il design è il codice.

• Varianti
• Token
• Props

• Vincoli (potremmo aggiungerli ai componenti)

• Regole per gli slot (cosa può essere inserito negli altri slot, o cosa può essere inserito nel mio slot)

• Regole

• Esempi 

• Animazioni  ( Consentito o consigliato usarle )

Poi osserva e sperimenta il comportamento.

come in https://storybook.demo.varbase.vardot.com/?path=/story/atoms-button--primary 

I design token come variabili d'ambiente

I design token sono un altro tassello fondamentale. Negli automi cellulari, le celle reagiscono all'ambiente circostante, cioè agli stati delle celle vicine. Nei design system, i componenti reagiscono ai design token, i valori di contesto che determinano aspetto e comportamento.

Le architetture di token moderne usano più livelli:

• Token di base (core): Valori grezzi come color.blue.500: #3B82F6
• Token semantici: Riferimenti guidati dall'intento come color.action.primary: color.blue.500
• Token di componente: Applicazioni circoscritte come button.background.primary: color.action.primary

Quando un agente genera un componente Button, non ha bisogno di sapere che "primary" significa blu. Gli basta fare riferimento a button.background.primary e fidarsi del fatto che il sistema di token lo risolverà nel valore corretto. L'ambiente (il livello dei token) contiene l'informazione; il componente (la cella) deve solo reagire ad essa.

Strumenti come Tokens Studio si sono evoluti fino a trattare i design token come grafi computazionali con resolver: nodi che prendono decisioni semantiche su quali token di base usare in base al contesto. Così i design token passano da valori statici a sistemi dinamici basati su regole.

L'ecosistema Drupal e l'integrazione dell'AI

L'integrazione dell'AI nei sistemi di gestione dei contenuti (CMS) è un laboratorio perfetto per esplorare i principi del "design è codice". CMS come Drupal incarnano già i concetti fondamentali: tipi di contenuto strutturati, definizioni dei campi, relazioni e regole di composizione.

Non avrei mai pensato che si potesse dire una cosa del genere. Per me questo era lo stato dell'arte.

 Il computer definitivo che potremmo avere. Sviluppatori che sembrano arrivare dal futuro di Star Trek, e parlano al computer perché programmi al posto loro.

Agent Experience (AX) e il nuovo utente

Progettare per le macchine

All'inizio del 2025, Mathias Biilmann, CEO di Netlify, ha introdotto il concetto di "Agent Experience" (AX), una nuova disciplina che si occupa di come gli agenti AI interagiscono con prodotti e piattaforme.

Il cambiamento è radicale. Per decenni la UX (User Experience) ha ottimizzato per la cognizione, la percezione e il comportamento umani. La DX (Developer Experience) ha ottimizzato per gli sviluppatori che costruiscono software. L'AX riconosce che gli agenti stanno diventando i principali utenti dei sistemi digitali, e che hanno esigenze completamente diverse:

• Non si curano dell'estetica visiva: solo dati strutturati e analizzabili
• Non navigano le interfacce: chiamano le API e consumano i manifest
• Non leggono la documentazione come gli umani: hanno bisogno di un contesto leggibile dalle macchine
• Non esprimono giudizi soggettivi: seguono regole e vincoli

"Gli agenti di IA non sono persone: non si curano della dimensione di un pulsante, della leggibilità di un carattere tipografico, della bella palette di colori del tuo sito o delle animazioni appariscenti della tua app. Quindi, a cosa 'tengono' gli agenti di IA? È una domanda che oggi non ha una risposta concreta, ma che diventerà sempre più importante nei prossimi anni."

- Ricerca sull'AX

La risposta: regole chiare, comportamenti prevedibili, dati ben strutturati e cicli di feedback che permettano loro di verificare e correggere le proprie azioni.

La sfida della doppia interfaccia

Progettare per l'AX significa costruire due interfacce contemporaneamente:

1. Interfaccia uomo-agente: Il luogo in cui le persone supervisionano, approvano, modificano e guidano il comportamento dell'agente: il livello della "sala di controllo". Pensa a dashboard e code di approvazione, non a moduli e pulsanti.
2. Interfaccia agente-sistema: Il luogo in cui gli agenti interagiscono con API, database e strumenti: il livello "operativo". Deve essere robusta, ben documentata e ottimizzata per l'efficienza delle macchine.

Questo rispecchia l'architettura degli automi cellulari, in cui coesistono due prospettive distinte:

• La prospettiva locale: ogni cellula (agente) segue regole semplici basate sui suoi vicini immediati
• La prospettiva globale: emergono schemi complessi visibili solo su larga scala

"Il design dell'esperienza degli agenti (AX) dovrebbe garantire un'ottima usabilità per gli agenti e da parte degli agenti. Quindi, una grande AX porta a una grande esperienza utente (UX). Se l'agente di IA si imbatte in un processo difettoso, in un protocollo difettoso o anche solo in una terminologia incoerente tra i vari sistemi, non è in grado di portare a termine il compito. Per l'agente è un'esperienza negativa, che a sua volta si traduce in una cattiva esperienza per il cliente o il dipendente."

- Kat Holmes, Chief Experience Officer, Salesforce

Da UX ad AX: l'evoluzione del design digitale

Stigmergia e comunicazione indiretta

Uno dei concetti più potenti dell'intelligenza di sciame è la stigmergia: un coordinamento indiretto attraverso tracce lasciate nell'ambiente. Le formiche non si comunicano direttamente dove si trova il cibo; lasciano scie di feromoni che le altre seguono. L'ambiente diventa un mezzo di comunicazione.

Nei sistemi di design agentici, la stigmergia assume la forma di:

• Librerie di componenti condivise: gli agenti "vedono" quali componenti esistono e come sono stati usati
• Design token: valori semantici che codificano le decisioni di design come fatti dell'ambiente
• Documentazione dei pattern: esempi d'uso che fanno da scia di feromoni per gli agenti futuri
• Suite di test: regole di validazione che delimitano lo spazio degli output validi
• Cronologia Git: una traccia delle decisioni passate a cui gli agenti possono fare riferimento

Quando un agente genera un'interfaccia usando un componente, lascia delle tracce: nel codice, nella documentazione, nei pattern che stabilisce. Gli agenti futuri alle prese con compiti simili ne saranno influenzati, dando vita a una forma di intelligenza collettiva che nessun singolo agente possiede.

Pattern di design agentici

Andrew Ng e altri hanno individuato quattro pattern chiave per i sistemi di IA agentica:

1. Riflessione: l'IA valuta il proprio output e lo migliora in modo iterativo
2. Uso degli strumenti: l'IA interagisce con strumenti esterni, API e sistemi
3. Pianificazione:L'IA scompone i compiti complessi in sotto-compiti e li esegue in sequenza
4. Multi-agente: Più agenti specializzati collaborano su compiti complessi

Questi pattern corrispondono direttamente ai concetti degli automi cellulari:

Il design è il codice: una lettura più profonda

Cosa significa davvero «il design è il codice»

Quando diciamo «il design è il codice», avanziamo più affermazioni contemporaneamente:

1. Equivalenza semantica

Le decisioni di design, se codificate bene, diventano eseguibili. Un design token non è solo un valore: è un'istruzione. La specifica di un componente non è solo documentazione: è un programma. Quando gli agenti consumano questi artefatti, stanno eseguendo il design tanto quanto lo stanno implementando.

2. Capacità generativa

Così come la Regola 110 può calcolare qualsiasi cosa sia calcolabile, un design system sufficientemente completo può generare qualsiasi interfaccia valida. Il sistema contiene in potenza tutte le sue espressioni valide. Ciò che emerge dipende soltanto dalle condizioni iniziali (i requisiti) e dalle regole (i vincoli).

3. Complessità emergente

Le interfacce più sofisticate non nascono dall'alto verso il basso: emergono dall'applicazione coerente di regole semplici. Un pulsante ben progettato, usato con coerenza, produce un linguaggio visivo coeso senza che nessuno abbia pianificato esplicitamente quella coerenza.

4. Irriducibilità computazionale

Alcuni esiti di design non si possono prevedere senza eseguire davvero il sistema. Non puoi sapere che aspetto avrà un'interfaccia assemblata da un agente senza lasciare che sia l'agente ad assemblarla. È il principio di irriducibilità computazionale di Wolfram applicato al design.

5. Automodifica

Come gli evoloop che mutano durante la replicazione, i design system pronti per gli agenti possono evolvere attraverso l'uso. I componenti generati dagli agenti entrano a far parte della libreria che gli agenti futuri consumeranno. Il sistema impara, si adatta e cresce.

La metafora degli automi cellulari estesa

Oltre la metafora: una convergenza reale

Ma non è solo una metafora. La convergenza è reale e sta avvenendo adesso:

• Storybook MCP trasforma le librerie di componenti in istruzioni leggibili dalle macchine che gli agenti eseguono
• Model Context Protocol standardizza il modo in cui gli agenti accedono a strumenti e contesto, creando un substrato universale per le operazioni agentiche
• Le architetture multi-agente dividono il lavoro tra agenti specializzati (architetto, sviluppatore, revisore) che interagiscono secondo dei protocolli, come cellule con funzioni differenziate
• Cicli di autoriparazioneConsenti agli agenti di eseguire test, rilevare errori e iterare: gli stessi meccanismi di feedback che gli automi cellulari usano per far evolvere configurazioni stabili
• Schema.org Blueprints rendono le strutture dei contenuti leggibili dalle macchine e ricche di significato semantico
• Drupal AI offre l'infrastruttura necessaria agli agenti di IA per creare, modificare e gestire i contenuti in autonomia

Non consideriamo "il design è il codice" una posizione filosofica. Lo stiamo costruendo come infrastruttura tecnica.

Implicazioni e prospettive

Per i designer

Il ruolo del designer si sta trasformando da "creatore di rettangoli" a "definitore di regole". Come ha osservato Brad Frost:

"Designer e sviluppatori che vedono il proprio lavoro come creare rettangoli hanno molto di cui preoccuparsi. Ma designer e sviluppatori che vedono il proprio lavoro come risolvere problemi, e solo incidentalmente devono creare o maneggiare qualche rettangolo per risolverli, hanno meno da temere."

- Brad Frost

Nel futuro agentico, i designer:

• Definiranno i token semantici e le relazioni tra di essi
• Stabiliranno vincoli di composizione e pattern
• Creeranno regole di validazione che gli agenti dovranno soddisfare
• Cureranno e faranno evolvere le regole che governano l'emergenza
• Progetteranno i meccanismi di feedback che permettono l'autocorrezione
• Daranno forma alle "funzioni di fitness" che stabiliscono quali output sono accettabili

È design a un livello di astrazione più alto: si progettano le regole che producono i design, anziché i design stessi. Come definire le regole di un automa cellulare invece di disegnare ogni singola cella.

Per gli sviluppatori

Gli sviluppatori diventano architetti di sistemi di agenti. Come descrive Anthropic:

"Il settore dello sviluppo software ha mostrato un potenziale notevole per le funzionalità basate su LLM, con capacità che si sono evolute dal completamento del codice alla risoluzione autonoma dei problemi."

Gli sviluppatori dovranno:

• Creare interfacce leggibili dalle macchine tra agenti e sistemi
• Progettare cicli di feedback e meccanismi di validazione
• Costruire l'impalcatura entro cui si sviluppa il comportamento emergente
• Mantenere la supervisione umana come arbitro finale
• Definire i protocolli con cui gli agenti comunicano
• Implementare il "glue code" che collega i diversi sistemi di agenti

Per lo sviluppo web e le piattaforme CMS

L'integrazione dell'IA in piattaforme come Drupal indica un futuro in cui:

• I modelli di contenuto diventano consumabili dagli agenti grazie a standard come Schema.org
• I flussi editoriali diventano assistiti dagli agenti con stesura, moderazione e ottimizzazione basate sull'IA
• La ricerca si evolve dalla corrispondenza di parole chiave alla comprensione semantica grazie a embedding e database vettoriali
• La personalizzazione diventa autonoma con agenti che apprendono le preferenze degli utenti e adattano i contenuti in tempo reale
• Lo sviluppo accelera perché gli agenti generano componenti, test e documentazione

L'adozione dell'IA da parte dell'ecosistema Drupal, attraverso moduli come Drupal AI, Drupal Canvas, Schema.org Blueprints e l'integrazione con i provider di IA, dimostra che questo futuro è già in costruzione.

Per le organizzazioni

Il vantaggio competitivo andrà alle organizzazioni i cui design system sono più "pronti per gli agenti". I sistemi pronti per gli agenti offrono:

• Copertura completa degli stati e delle varianti dei componenti
• Nomi semantici che esprimono l'intento
• Documentazione e contesto leggibili dalle macchine
• Infrastruttura di validazione e test
• Vincoli chiari che delimitano lo spazio degli output validi
• API progettate per essere consumate dagli agenti (AX-first)
• Architetture di contenuti basate prima di tutto su Schema.org

Per il futuro dei prodotti digitali

Lo stato finale somiglia a un'ecologia digitale: innumerevoli agenti che operano secondo regole locali e producono interfacce emergenti che nessun designer o sviluppatore ha pianificato, ma che in qualche modo risultano coerenti perché le regole di fondo sono solide.

Non è così fantasioso come sembra. È esattamente il modo in cui funzionano i sistemi biologici, in cui crescono le città, in cui si muovono i mercati. La questione non è se arriveremo a questo stato, ma come affronteremo la transizione.

Conclusione: il codice è vivo

John von Neumann, il poliedrico studioso che inventò gli automi cellulari, era guidato da una domanda fondamentale: qual è la complessità minima necessaria per l'autoriproduzione? La sua risposta, il costruttore universale di von Neumann, dimostrò che l'autoreplicazione non richiede alcun macchinario biologico. Servono soltanto regole che codifichino la propria stessa applicazione.

Settant'anni dopo, scopriamo che lo stesso principio vale per i design system. Il requisito minimo per la generazione autonoma delle interfacce non è l'intelligenza artificiale generale né una creatività di livello umano. È un insieme di regole completo, coerente e leggibile dalle macchine, che gli agenti possano eseguire.

Quando i Loop di Langton si replicano su una griglia cellulare, non diciamo che i loop "progettano" nuovi loop. La replicazione è semplicemente ciò che le regole producono. Eppure il risultato, colonie in continua espansione di schemi autosimili, è innegabilmente generativo, creativo in un certo senso funzionale.

Quando gli agenti AI assemblano interfacce a partire dai componenti di un design system, seguendo token semantici e vincoli di composizione, fanno qualcosa di simile. La "creatività" non sta negli agenti, ma nelle regole che eseguono: regole progettate dagli esseri umani, che ora però operano in autonomia.

Siamo sulla soglia di una nuova era della creazione digitale. Gli agenti sono qui. I protocolli stanno prendendo forma. I design system stanno diventando il substrato di una vita artificiale.

Il design è il codice.
E il codice sta prendendo vita.

Articoli e progetti principali

• Design Systems in the Time of AI - Brad Frost
• Storybook MCP Sneak Peek - Storybook
• Introducing AX: Why Agent Experience Matters - Mathias Biilmann
• Building Effective Agents - Anthropic

Risorse su Drupal AI

• Drupal AI

• Modulo Schema.org Blueprints

   

Risorse sugli automi cellulari

• Conway's Game of Life Lexicon - circa 1500 figure
• A Working Turing Machine in Game of Life
• Langton's Loops - Wikipedia
• Rule Sets for Cellular Automata
• A New Kind of Science Online - Stephen Wolfram
• Cellular Automata - Nature of Code

Ho esplorato idee all'incrocio tra teoria computazionale, design system, intelligenza artificiale e sviluppo web.

 Le opinioni espresse sono esplorazioni speculative di tendenze emergenti, non previsioni di futuri certi.

Vedo che stiamo creando agenti AI che lavorano in un ciclo e interagiscono con altri agenti AI in ulteriori cicli.

Il design è il codice quando il sistema opera in un ciclo, come un ciclo vitale, all'interno di una tela e di un insieme di regole scelti.