Oltre i componenti: come cambia la UI quando la genera un modello (e non solo il dev)

Negli ultimi anni abbiamo visto un’accelerazione brutale: prima il flusso era “copio-incolla un componente React, lo aggiusto, ripeto”; poi siamo passati a modelli capaci di generare schermate complete con interazioni sensate e attenzione all’accessibilità. A quel punto la domanda non è più se un modello sappia costruire UI, ma come vogliamo che lo faccia — e quali garanzie servono per portare quel risultato in un prodotto reale.

Il tema interessante, oggi, non è soltanto dove vive l’interfaccia (dentro un agente “super-app”, dentro il tuo prodotto, dentro un client che integra servizi esterni). È soprattutto come viene generata: con componenti predefiniti? con una descrizione strutturata? oppure con markup e logica creati sul momento?

Qui sotto trovi i tre approcci principali che stanno emergendo, con i relativi trade-off.

---

1) UI a componenti statici: tool call → props → render

È la versione più vicina al frontend tradizionale.

• L’agente invoca un tool (o un endpoint)
• Il tool ritorna dati/parametri
• Il client assembla e renderizza componenti già esistenti

In pratica è uno schema simile a quello che abbiamo sempre usato: qualcuno “a monte” prepara dati e il client li monta su UI nota. Anche quando la fonte è un agente, il rendering resta vincolato a un catalogo di componenti che hai già nel prodotto.

Pro

• Affidabilità alta: UI deterministica
• Accessibilità e design system sotto controllo
• Debug più semplice: lo spazio di variabilità è nei dati

Contro

• Flessibilità bassa: l’agente può solo “colorare dentro le righe”
• Personalizzazione limitata alle varianti previste

È un buon punto di partenza, ma non risolve il desiderio di UI davvero dinamiche.

---

2) UI dichiarativa: l’agente scrive JSON, il client compone

Qui l’agente non decide quale componente chiamare, ma costruisce una descrizione dell’interfaccia (spesso JSON): layout, gerarchie, contenuti, parametri. Poi un renderer traduce quella descrizione in componenti reali.

Il dettaglio importante: anche qui i componenti restano predefiniti (quindi coerenti con design system e accessibilità), ma l’agente guadagna molta più libertà nel combinare struttura e contenuto.

Questo modello è parente stretto di ciò che viene spesso chiamato server-driven UI: la “pagina” non è hardcoded nel client, ma arriva come struttura dati che il client sa interpretare.

Pro

• Ottimo equilibrio: creatività controllata
• Stabilità: catalogo componenti governato dal team
• Personalizzazione spinta senza rigenerare l’app

Contro

• Sei comunque vincolato al catalogo: ciò che non esiste non può apparire
• Serve progettare bene:
  • schema/versioning
  • fallback
  • validazione
  • mapping tra JSON e componenti

Se oggi dovessi scegliere un approccio “da produzione” per UI guidate da agenti, questo è spesso quello più sensato: dinamico, ma con guardrail.

---

3) UI pienamente generativa: il modello produce markup (e talvolta logica)

All’estremo opposto c’è l’approccio più “wow”: il modello genera direttamente HTML/CSS (e spesso anche JS) per presentare dati e flussi.

È molto utile quando l’obiettivo è consumare informazioni in modo visuale (dashboard al volo, report, spiegazioni interattive, prototipi). L’interfaccia diventa quasi “usa e getta”: viene generata per quella specifica richiesta, poi si passa oltre.

Pro

• Libertà totale: non sei limitato a un catalogo
• Velocità di iterazione altissima
• Ottimo per visualizzazioni ad-hoc e prototipi

Contro (quelli che contano davvero)

• Costo: generare UI “da zero” continuamente può essere caro
• Incoerenza: senza vincoli, ogni render può variare (layout, pattern, stile)
• Familiarità: gli utenti vogliono ritrovare le cose dove se le aspettano
• Sicurezza: se generi ed esegui codice (JS), devi sandboxare e limitare in modo serio

Questo approccio non è “sbagliato”, ma è difficile da rendere un’interfaccia di prodotto stabile. Brilla in contesti dove l’output è temporaneo o dove la UI è un artifact che serve soprattutto a capire, esplorare, decidere.

---

Il punto: la UI non è solo output, è collaborazione

C’è un aspetto che spesso viene sottovalutato: la UI generata non dovrebbe essere soltanto una pagina mostrata all’utente, ma uno spazio di lavoro condiviso tra umano e agente.

Quando puoi:

• spostare elementi
• annotare
• modificare un diagramma
• fare “aggiustamenti” manuali
• e poi chiedere all’agente di adattarsi a quelle modifiche

…non stai più “guardando” una UI. Stai co-progettando con un sistema.

Questa idea sposta il focus dal “render perfetto” alla ciclicità dell’interazione: il valore arriva quando l’interfaccia diventa un canvas dove l’agente e la persona iterano insieme.

---

Implicazione pratica per chi fa frontend oggi

Se stai costruendo UI con agenti (o prevedi di farlo), la decisione cruciale non è “componenti sì o no”, ma quali vincoli vuoi imporre e dove.

• Se ti serve solidità di prodotto: UI dichiarativa + catalogo componenti è la base più pragmatica.
• Se ti serve esplorazione veloce: UI generativa è potente, ma trattala come artifact, non come superficie primaria.
• Se vuoi il salto di qualità: investi in collaborazione (stato condiviso, editing, feedback loop), non solo in generazione.

Sintesi

La “fine dell’era dei componenti” non significa buttare via componenti e design system. Significa riconoscere che, con i modelli, la UI può diventare una funzione del contesto: generata, adattata e negoziata in tempo reale. Il futuro credibile non è una UI che cambia casualmente a ogni prompt, ma un sistema che bilancia creatività e controllo — e che rende la collaborazione uomo-agente la nuova interazione primaria.