Generative UI: quando l’AI smette di scrivere testo e inizia a comporre interfacce

Quando facciamo una domanda a un chatbot, ci aspettiamo una risposta testuale. Magari ben formattata, magari in markdown, magari con qualche emoji. Ma pur sempre testo: piatto, statico, identico per qualsiasi tipo di contenuto. Che tu chieda il meteo, un confronto tra prodotti o l’andamento di un titolo in borsa, la forma della risposta non cambia mai.

La Generative UI rompe esattamente questo schema. L’AI smette di essere un generatore di paragrafi e diventa un orchestratore di interfacce: sceglie quale componente mostrare, lo popola con i dati giusti e lo fa apparire in streaming, mentre sta ancora ragionando.

In questo articolo vediamo cos’è la Generative UI e come funziona davvero sotto il cofano, con il codice di un progetto reale che ho costruito per esplorarla: tre demo progressive — base, interattiva e agentica — e, come banco di prova estremo, Generative Adventure: un gioco di ruolo testuale in cui l’AI fa da game master e l’intera interfaccia è generata turno dopo turno.

01Cos’è la Generative UI

La Generative UI è un pattern architetturale in cui un modello linguistico non produce la risposta finale, ma decide quale componente dell’interfaccia renderizzare e con quali dati. Il modello riceve un catalogo di componenti disponibili — descritti come “tool” con uno schema tipizzato — e per ogni richiesta dell’utente sceglie il tool più adatto, generando i parametri che lo popolano.

È importante chiarire subito cosa la Generative UI non è: l’AI non scrive HTML, non inventa CSS, non genera codice React al volo. Sarebbe fragile, incoerente e un incubo per la sicurezza. I componenti sono pre-costruiti, versionati e approvati da chi sviluppa: fanno parte del design system come qualsiasi altro componente dell’applicazione. L’AI si limita a selezionarli e parametrizzarli.

La metafora che uso più spesso: tu sei il direttore creativo, definisci gli strumenti e il loro suono. L’AI è il direttore d’orchestra: decide quale strumento far suonare, quando e con quale spartito. Ma non può inventarsi strumenti che non esistono.

I vantaggi rispetto a un chatbot testuale sono concreti:

• Coerenza visiva: ogni risposta usa componenti del design system, con lo stesso stile del resto dell’app.
• Type-safety: i dati passano attraverso schemi validati — se il modello genera parametri fuori contratto, la risposta viene rifiutata prima di toccare la UI.
• Interattività: un componente può avere bottoni, grafici animati, stati — cose che il testo non potrà mai avere.
• Controllo: l’AI non può “uscire dai binari”, perché i binari sono il catalogo di tool che le hai dato.
• Accessibilità: se i componenti sono accessibili (semantica, ARIA, contrasto), lo è automaticamente ogni risposta generata.

02Come funziona sotto il cofano: tool, schemi, streaming

Il meccanismo alla base è il tool calling (o function calling): la capacità dei modelli moderni di rispondere non con testo libero ma con una chiamata strutturata a una funzione, completa di argomenti in JSON. La Generative UI è “semplicemente” tool calling in cui ogni tool corrisponde a un componente React.

Nel mio progetto uso Vercel AI SDK con il modello Claude di Anthropic, e Zod per definire gli schemi. Ecco un tool reale, quello della card meteo:

import { tool } from 'ai';
import { z } from 'zod';

export const showWeather = tool({
  description:
    'Mostra una card meteo per una città. Usare per domande su tempo, ' +
    'clima, temperatura, meteo. NON usare per dati finanziari o prodotti.',
  inputSchema: z.object({
    city: z.string().describe('Il nome della città'),
    temperature: z.number().describe('Temperatura in gradi Celsius'),
    condition: z.string().describe('Condizione meteo: Soleggiato, Nuvoloso, Piovoso...'),
    humidity: z.number().min(0).max(100).describe('Percentuale di umidità'),
    wind: z.number().min(0).describe('Velocità del vento in km/h'),
  }),
  execute: async (input) => input,
});

Qui c’è più di quanto sembri. Lo schema Zod ha un doppio ruolo: da un lato valida a runtime i parametri generati dal modello (se humidity arriva a 140, la chiamata viene rifiutata); dall’altro, ogni .describe() diventa documentazione che il modello legge per capire come usare il tool. Lo schema è contemporaneamente il contratto e il manuale d’istruzioni.

Nota anche la descrizione del tool: “NON usare per dati finanziari o prodotti”. I vincoli negativi espliciti sono uno dei trucchi più efficaci quando i tool nel catalogo crescono: aiutano il modello a disambiguare tra componenti simili.

Lato server, la route API è sorprendentemente compatta. Si passa il registro dei tool a streamText e si restituisce lo stream alla UI:

import { anthropic } from '@ai-sdk/anthropic';
import { streamText, convertToModelMessages } from 'ai';
import { tools } from '@/lib/tools';

const SYSTEM_PROMPT = `Sei un assistente dimostrativo per una web app sulla Generative UI.
Hai a disposizione tools per mostrare componenti React invece di rispondere con testo.
Usa SEMPRE i tools appropriati invece di rispondere con testo quando disponibili.
Per i dati meteo, finanziari e prodotti, genera dati mock realistici e plausibili.
Rispondi in italiano.`;

export async function POST(req: Request) {
  const { messages } = await req.json();

  const result = streamText({
    model: anthropic('claude-haiku-4-5'),
    system: SYSTEM_PROMPT,
    messages: await convertToModelMessages(messages),
    tools,
  });

  return result.toUIMessageStreamResponse();
}

Lato client, l’ultimo pezzo del puzzle è il dispatcher: un componente che riceve le “parti” del messaggio in streaming e mappa ogni tool call sul componente React corrispondente. Nel progetto lo chiamo ToolRenderer:

export const ALL_TOOL_TYPES = [
  'tool-showWeather',
  'tool-showProducts',
  'tool-showStock',
  'tool-showInfo',
  'tool-showText',
  'tool-showComparison',
  'tool-showRecipe',
  'tool-showNews',
  'tool-showOptions',
  'tool-showChart',
  'tool-showTimeline',
  'tool-showPersona',
] as const;

// Ogni tool call in streaming viene instradata al componente giusto:
// 'tool-showWeather'  -> <WeatherCard {...input} />
// 'tool-showProducts' -> <ProductGrid {...input} />
// Mentre gli argomenti sono in arrivo, si mostra uno <Skeleton />.

Il flusso completo, dall’inizio alla fine: l’utente scrive un messaggio → il modello sceglie un tool e ne genera gli argomenti → Zod li valida → lo stream arriva al client → il dispatcher monta il componente React, che nel frattempo mostrava uno skeleton di caricamento. Tutto in streaming: il componente “si materializza” man mano che il modello scrive.

03La demo base: dodici tool, dodici componenti

La prima demo del progetto è una chat con un catalogo di dodici tool, ognuno mappato su un componente diverso: meteo, griglia prodotti, grafico azionario con sparkline, card informativa, tabella di confronto, ricetta, notizie, grafici (barre, linee, torta), timeline animata, profilo con radar chart e una card testuale di fallback.

La cosa interessante è osservare la scelta del modello. Se chiedo “com’è il tempo a Milano?”, non ricevo la frase “oggi a Milano ci sono 22 gradi”: ricevo una WeatherCard con temperatura, umidità, vento e condizione. Se chiedo “i migliori laptop per programmare”, arriva una ProductGrid con sei prodotti, prezzi, brand e rating. Se chiedo “la storia di internet in cinque tappe”, una TimelineCard animata. Stessa chat, tre interfacce completamente diverse.

Che tempo fa a Milano?

Un dettaglio pratico: tutti i dati sono mock generati dal modello — niente API meteo o finanziarie esterne. Per una demo è perfetto: il punto non è l’accuratezza del dato ma il meccanismo di orchestrazione. In produzione, la funzione execute di ogni tool è esattamente il posto dove chiamare le API vere: il modello fornisce i parametri della richiesta, il server recupera i dati reali, il componente li renderizza.

C’è anche un tool di fallback, showText, per saluti, conferme e risposte brevi che non meritano un componente dedicato. Persino quello è parametrizzato: ha un “tono” visivo (neutro, positivo, avviso, informativo) che cambia colore alla card. Anche il testo semplice, in Generative UI, è un componente.

04La demo interattiva: l’AI propone i prossimi passi

La seconda demo aggiunge un tool speciale: showOptions. Invece di limitarsi a rispondere, l’AI propone i possibili passi successivi come bottoni cliccabili. Chiedi informazioni su un viaggio? Sotto la risposta compaiono opzioni come “Mostrami i voli”, “Cosa vedere”, “Budget giornaliero”. Un click e la conversazione prosegue su quel binario.

Sembra un dettaglio, ma cambia la natura dell’interazione: da conversazione libera a navigazione guidata generata dinamicamente. È il modello che, contestualmente, decide quali strade ha senso offrire — una specie di information architecture just-in-time. L’utente non deve più indovinare cosa chiedere: sceglie tra percorsi pertinenti.

L’AI ci consiglia un piatto asiatico, il Pad Thai

Questo pattern è il ponte tra il chatbot e l’interfaccia tradizionale: il flusso resta conversazionale, ma i punti di decisione tornano ad essere elementi di UI concreti, cliccabili, accessibili da tastiera. Per molti utenti è un’esperienza più comoda del prompt libero.

05La demo agentica: componenti concatenati in multi-step

La terza demo alza la posta: il modello può chiamare più tool in sequenza nella stessa risposta. Con Vercel AI SDK basta una riga: stopWhen: stepCountIs(5) — il modello può fare fino a cinque passi di ragionamento e tool calling prima di fermarsi.

import { streamText, convertToModelMessages, stepCountIs } from 'ai';

const result = streamText({
  model: anthropic('claude-haiku-4-5'),
  system: SYSTEM_PROMPT,
  messages: await convertToModelMessages(messages),
  tools,
  stopWhen: stepCountIs(5), // fino a 5 step di tool calling concatenati
});

Il risultato è visibile a occhio nudo. Chiedi “fammi un’analisi completa di Apple come investimento” e il modello ragiona: per rispondere bene servono il grafico del titolo, un confronto con i competitor e una sintesi. Così chiama showStock, poi showComparison, poi showInfo — e i tre componenti compaiono in pagina uno dopo l’altro, in streaming, componendo una piccola dashboard generata su misura per la domanda.

Visitare Crema(CR) in una giornata, ecco cosa fare secondo l’AI.

Qui si vede il salto concettuale: non stiamo più parlando di “una domanda, una card”. Il modello sta facendo composizione di interfaccia: decide quanti componenti servono, di che tipo, in che ordine. È il layout di una pagina di risposta, progettato al volo da un LLM dentro vincoli che abbiamo definito noi.

06Generative Adventure: un GDR testuale orchestrato dall’AI

E ora la parte più folle del progetto. Le demo mostrano il pattern, ma volevo un banco di prova che lo stressasse davvero: uno scenario dove l’AI deve orchestrare molti componenti coordinati tra loro, mantenere uno stato coerente nel tempo e reagire a input imprevedibili. La risposta è stata costruire un gioco di ruolo testuale completo: Generative Adventure — The Last Dev.

La premessa narrativa

Sei un dev freelance del 2050. GENERATIVE, un’AI malevola che ha preso il controllo della rete, ti considera l’ultima minaccia rimasta e ti esilia indietro nel tempo: 1° marzo 1889, Milano. Hai con te tre oggetti: un laptop al 3% di batteria, un mouse wireless senza ricevitore (quindi perfettamente inutile — il gioco lo sa e ci ironizza sopra) e una tastiera meccanica. Hai sette turni per accumulare abbastanza conoscenza tecnologica da tornare nel 2050 e sconfiggere GENERATIVE.

Il tono è un misto di cyberpunk noir e dungeon crawler, con l’ironia amara di un dev che cerca di spiegare il Wi-Fi a un fabbro dell’Ottocento. La narrazione è in seconda persona, al presente, in italiano — e tutta l’estetica è da terminale CRT anni ’80: font monospace, verde fosforo su nero, scanline in overlay ed effetti glitch nei momenti drammatici. Tutto in CSS puro.

Schermata del prologo del gioco “Generative Adventure - The Last Dev”

Dieci tool per un game master

Dietro l’estetica c’è esattamente la stessa architettura delle demo: un registro di tool tipizzati e un dispatcher. Ma qui il catalogo è pensato per un game master. Dieci tool, ognuno un pezzo dell’interfaccia di gioco:

• showNarrative — il testo narrativo del turno, con effetto typewriter;
• showCharacterSheet — la scheda del personaggio con le cinque statistiche;
• showAsciiMap — la mappa del luogo in ASCII art, con le uscite disponibili;
• showGameChoices — il pannello delle scelte: bottoni più input a testo libero;
• showSkillCheck — la prova di abilità animata, con esito superato/fallito;
• showNPCEncounter — l’incontro con un personaggio, ritratto ASCII incluso;
• showInventory — l’inventario con oggetti acquisiti e persi;
• showJournalEntry — il diario delle scoperte tecnologiche;
• showHazardAlert — l’allarme critico quando una statistica scende troppo;
• showGameEnd — la schermata finale di vittoria o sconfitta.

Il system prompt impone anche un ordine di chiamata per ogni turno: prima la narrativa, poi la scheda aggiornata, la mappa, e sempre per ultime le scelte — così il giocatore legge cosa è successo prima di decidere cosa fare. È un contratto di sequenza, non solo di forma: anche l’ordine dei componenti fa parte del design.

Guardiamo il tool delle scelte, perché è quello dove game design e Generative UI si incontrano davvero:

export const showGameChoices = tool({
  description:
    'Shows the interactive choice panel for the player. ' +
    'ALWAYS call this LAST every turn. Provide 3–4 choices.',
  inputSchema: z.object({
    options: z
      .array(
        z.object({
          label: z.string().describe('Display text of the option (max 60 chars)'),
          value: z.string().describe('Value sent when option is selected'),
          blocked: z.boolean().optional()
            .describe('If true, this option is locked due to insufficient stats'),
          blockedReason: z.string().optional()
            .describe('Why this option is blocked, e.g. "CHARM < 30"'),
        })
      )
      .min(2)
      .max(4),
    allowFreeText: z.boolean()
      .describe('Always true — player can also type a free-text command'),
  }),
  execute: async (input) => input,
});

Notare i campi blocked e blockedReason: il modello può mostrare un’opzione bloccata se una statistica è troppo bassa — “Convinci il mercante” appare disabilitata con la motivazione “CHARM < 30”. E allowFreeText tiene aperta la porta dei comandi liberi, come nelle avventure testuali classiche: puoi ignorare i bottoni e scrivere “provo a smontare il mouse per recuperare il magnete”. Il game master improvvisa, ma dentro i binari dei tool.

Cinque statistiche e uno stato che vive nel modello

Il personaggio ha cinque statistiche, ognuna con una logica diversa: HP (la salute: se arriva a zero, muori nel 1889), CODE (la padronanza del laptop, che si degrada se il laptop si danneggia), CHARM (il carisma: parte bassissimo — sei un dev del 2050 che parla strano — e cresce interagendo con la gente dell’Ottocento), SANITY (la sanità mentale, erosa da traumi e paradossi temporali: a zero, finisci i tuoi giorni come “il mago delle macchine”) e TECHPOWER (la conoscenza accumulata per sconfiggere GENERATIVE: l’unica statistica che non scende mai).

Ad ogni turno il modello ricalcola le statistiche in base alle conseguenze della scelta e chiama showCharacterSheet con i valori aggiornati; le barre si animano verso i nuovi valori. Le azioni rischiose passano da showSkillCheck: una prova animata su una statistica, con esito visibile e conseguenze immediate. E quando HP o SANITY scendono sotto soglia, scatta showHazardAlert — un componente d’allarme che il modello sa di dover usare solo nei momenti critici.

Schermata di gioco con punti abilità del personaggio e la mappa di gioco

Sei finali possibili

La partita si chiude in uno dei sei esiti definiti nell’enum di showGameEnd: la vittoria piena se arrivi al settimo turno con TechPower ad almeno 70 (torni nel 2050 e distruggi GENERATIVE); la vittoria parziale tra 50 e 69 (sopravvivi, ma GENERATIVE sopravvive a metà); la sconfitta eroica tra 30 e 49 (cadi combattendo, ma lasci un virus nei suoi sistemi); la sconfitta sotto 30; la morte se HP arriva a zero nel 1889; e la follia se SANITY si azzera. Sei percorsi diversi, e ogni epilogo è scritto dal modello coerentemente con tutta la partita giocata.

Perché è Generative UI allo stato puro

Il punto che rende il gioco interessante come caso di studio è questo: nel frontend non c’è una sola riga di logica di gioco hardcodata. Non esiste un motore che calcola i danni, non esiste un albero di dialoghi, non esiste una mappa pre-disegnata. La narrativa, le regole, le conseguenze, gli esiti delle prove: vive tutto nel modello, guidato dal system prompt. I componenti React si limitano a renderizzare — con stile — quello che il game master decide.

Le demo dimostrano che l’AI può scegliere il componente giusto per una domanda. Il gioco dimostra qualcosa di più forte: che può sostenere un’esperienza interattiva lunga, coerente e con stato, orchestrando dieci componenti coordinati per decine di turni consecutivi, senza mai rompere il contratto tipizzato. Se il pattern regge un game master, regge una dashboard.

La storia avanza in modo coerente (e l’incontro con un personaggio)

07Limiti, sicurezza e accorgimenti pratici

La Generative UI non è gratis, e un articolo onesto deve dirlo. Le cose a cui prestare attenzione, dalla mia esperienza con questo progetto:

Il non-determinismo è strutturale. Alla stessa domanda il modello può rispondere con tool diversi in momenti diversi. Le descrizioni dei tool — con i vincoli negativi espliciti — riducono l’ambiguità ma non la eliminano. Se un flusso deve essere deterministico al 100%, non deve passare da un LLM: la Generative UI è per le superfici conversazionali ed esplorative, non per il checkout.

La validazione è anche sicurezza. Nel progetto ogni route valida il body con Zod, limita la dimensione del payload e applica rate limiting per IP. Quando l’input di un sistema è linguaggio naturale e l’output è interfaccia, il confine va presidiato da entrambi i lati: schemi in ingresso, schemi in uscita.

Latenza e costi vanno progettati. Ogni risposta è una chiamata a un LLM, e la modalità agentica ne può concatenare cinque. Le contromisure nel progetto: un modello veloce ed economico per l’orchestrazione (Claude Haiku — per scegliere un tool e generare parametri non serve il modello più potente), streaming per azzerare la latenza percepita, skeleton di caricamento mentre gli argomenti sono in arrivo e un tetto esplicito agli step.

Serve sempre un fallback. Ci sarà sempre una domanda che non mappa su nessun componente del catalogo. Un tool testuale di riserva come showText evita che il modello forzi il componente sbagliato pur di usarne uno — l’errore più tipico di un catalogo senza via d’uscita.

08Conclusione: l’interfaccia come vocabolario

La Generative UI non è magia, ed è proprio questo il suo pregio. È una decisione di design precisa: dare all’AI un vocabolario finito di componenti ben fatti, un contratto tipizzato per ognuno, e lasciarle il lavoro che sa fare meglio — capire l’intento e comporre la risposta giusta. Noi definiamo le parole, lei scrive le frasi.

Il percorso del progetto lo racconta bene: si parte da una card meteo, si arriva a un game master che orchestra dieci componenti coordinati mantenendo lo stato di una partita intera. In mezzo c’è sempre lo stesso identico pattern — tool, schema, dispatcher — che scala dalla demo di dieci minuti all’esperienza interattiva complessa.

E il tema è più grande del frontend: le interfacce che esponiamo alle AI — in entrambe le direzioni — stanno diventando un layer di progettazione a sé. Ne ho parlato dal lato opposto, quello dei siti che devono farsi leggere dagli agenti, nell’articolo su GEO e Navigazione Agentica di Google: due facce della stessa transizione.

Se vuoi sperimentare, il punto di partenza è piccolo: un tool, uno schema Zod, un componente. Il resto — il catalogo, la modalità agentica, magari un game master ambientato nella Milano del 1889 — viene da sé. È la parte divertente.