Iniziare con la Generative UI

La prima volta che ho visto un modello trasmettere in streaming un grafico funzionante in una finestra di chat — non la descrizione di un grafico, il grafico stesso, filtrabile e in tempo reale — ho provato la stessa piccola scossa che avevo sentito la prima volta che usai fetch() nella console del browser. Qualcosa che avevo sempre sviluppato come un compito UI separato si era appena condensato in una singola chiamata al modello.

Questa condensazione è l'argomento di questo articolo. La Generative UI non è un nuovo framework; è uno spostamento nel punto in cui si trova il confine tra "output del modello" e "superficie del prodotto." Di seguito: cos'è, quando conviene, quando non conviene, e come costruirne la versione più piccola e onesta da soli.

Cos'è la Generative UI?

La Generative UI è un paradigma in cui i sistemi AI producono componenti interattivi di interfaccia utente — non solo testo — come output. Invece di restituire una stringa markdown che dice "ecco un grafico dei tuoi dati," un sistema Generative UI restituisce un vero componente grafico interattivo che gli utenti possono filtrare, ordinare ed esplorare.

Una distinzione utile: un chatbot che renderizza markdown non è Generative UI. Un modello che seleziona, parametrizza e trasmette in streaming un componente React tipizzato da un catalogo è Generative UI. La differenza sta nel fatto che l'LLM produca testo che il livello di visualizzazione formatta, oppure intento strutturato che un runtime UI trasforma in un componente.

Perché è importante

I chatbot tradizionali restituiscono testo. La Generative UI restituisce interfacce. Questa distinzione è rilevante perché:

• Densità informativa più alta — un componente ben progettato comunica più di paragrafi di testo
• Manipolazione diretta — gli utenti interagiscono con l'output, non si limitano a leggerlo
• Azioni contestuali — i componenti generati possono includere pulsanti, form e flussi di lavoro

Come iniziare

Per costruire la tua prima applicazione Generative UI hai bisogno di tre cose:

1. Un framework che supporti lo streaming di componenti UI — il primitivo streamUI del Vercel AI SDK è l'implementazione di riferimento
2. Un set di componenti pre-costruiti che l'AI può comporre (il tuo design system, o un sottoinsieme curato)
3. Un LLM che comprende il tuo schema di componenti — qualsiasi modello moderno con function calling funziona; lo schema conta più del modello

// Esempio: definire uno strumento che restituisce un componente UI
import { z } from 'zod'

const tools = {
  showWeather: {
    description: 'Display weather information for a city',
    parameters: z.object({
      city: z.string(),
      unit: z.enum(['celsius', 'fahrenheit']),
    }),
    // Nota: `async` qui è corretto — aspettiamo fetchWeather all'interno.
    // Se vuoi fare lo *streaming* parziale della UI (skeleton → caricato), cambia
    // la firma in `generate: async function*` e usa `yield` per gli JSX intermedi.
    generate: async ({ city, unit }) => {
      const data = await fetchWeather(city, unit)
      return <WeatherCard data={data} />
    },
  },
}

La mossa non ovvia è alla riga 3: lo schema dei parametri è ciò che il modello vede. Nomi, descrizioni ed enum nello schema Zod fanno lavoro di prompt engineering che lo vogliate o meno. Tratta lo schema come parte del prompt, non come parte del sistema di tipi.

Per gli engineering manager: roadmap di adozione e ROI

Se stai valutando la Generative UI per un team piuttosto che per un progetto personale, la domanda non è "è figo il demo" — è "in quale punto della curva conviene."

Fase 1 — Singola superficie ad alto valore (1 ingegnere, 2–4 settimane). Scegli un unico flusso adiacente alla chat dove gli utenti attualmente escono verso una dashboard (analytics, risultati di ricerca, "mostrami il mio..."). Distribuiscilo dietro un flag. Metrica di successo: tasso di sostituzione del vecchio flusso, non l'engagement.

Fase 2 — Catalogo di componenti (2 ingegneri, 1–2 mesi). Promuovi un piccolo sottoinsieme del tuo design system (5–15 componenti) a strumenti richiamabili dal modello, con contratti congelati e snapshot test. Il catalogo è il vantaggio competitivo del prodotto — i concorrenti possono copiare l'interfaccia chat; non possono copiare la tua libreria di componenti tipizzati e specifici per il dominio.

Fase 3 — Rollout multi-superficie (team completo). La Generative UI diventa uno dei target di rendering tra i vari. SSR, mobile e flussi agente-agente consumano tutti gli stessi contratti di componente.

Dove si vede il ROI (e dove no): il ROI è reale quando l'alternativa è una UI su misura costosa per query (strumenti BI, dashboard operativi, schermate di configurazione con input combinatori). Il ROI non è reale quando gli utenti hanno già una UI statica perfettamente funzionante per il compito — aggiungere un LLM davanti a un form funzionante è quasi sempre una perdita netta in latenza, affidabilità e costo.

Competenze del team effettivamente necessarie: un ingegnere fluente nel tuo framework frontend + nel tool calling LLM, un designer a proprio agio con il pensiero component-API (non screen-thinking), e un PM capace di scrivere descrizioni di strumenti precise. Non hai bisogno di ingegneri ML.

Per gli ingegneri senior: pattern in produzione

L'esempio Vercel AI SDK sopra è il "hello world." Tre cose che incontrerai in produzione e che il quickstart non ti insegnerà:

1. Il catalogo è un contratto, non un suggerimento. Una volta che un componente è richiamabile dal modello, le sue props fanno parte di una API pubblica. Si applica la disciplina delle breaking change. Versiona gli schema dei tuoi componenti, esegui snapshot test contro output rappresentativi del modello, e tratta lo schema drift come un release-blocker.

2. Streaming UI ≠ streaming testo. Con streamUI puoi emettere prima un componente skeleton e sostituirlo con la versione caricata quando i dati arrivano. La trappola: i componenti renderizzati lato server tramite React Server Components non hanno accesso allo state client-only. Decidi subito se ogni componente è "solo RSC," "solo client," o "ibrido con un handoff chiaro." Mescolarli senza una regola produce hydration mismatch difficili da debuggare.

3. I modi di fallire sono diversi. Una UI tradizionale fallisce quando il server fallisce. Una Generative UI fallisce quando (a) il modello sceglie il componente sbagliato, (b) il modello allucinare un valore di prop che lo schema accetta ma il componente non riesce a renderizzare, o (c) il modello va in loop tra due strumenti. Hai bisogno di: telemetria sulle distribuzioni delle tool call, un componente "fallback" sentinella per intenti non parsabili, e un limite fisso sulla profondità delle tool call per turno.

Per specifiche di livello produzione sull'ecosistema Vercel + Tambo + Thesys C1, vedi la nostra guida completa alla Generative UI.

Limiti e quando NON usare la Generative UI

Sezione sull'onestà, perché è qui che molti team bruciano il primo trimestre:

• Flussi latency-sensitive. Una chiamata al modello aggiunge 200–2.000 ms prima del primo byte di UI. Se gli utenti si aspettano risposte in <100 ms (ricerca durante la digitazione, validazione dei form), la Generative UI è il layer sbagliato.
• Correttezza ad alto rischio. Dichiarazione dei redditi, dosaggio medico, transazioni finanziarie. Il contratto del componente garantisce un rendering, non la correttezza dei dati al suo interno. Una tool call errata è comunque una risposta sbagliata.
• Compiti con una forma fissa e nota. Se ogni utente vede gli stessi cinque campi, costruisci semplicemente un form. Il costo della Generative UI è giustificato solo quando la forma dell'output varia significativamente tra le query.
• Team piccoli senza design system. La Generative UI moltiplica il valore di una buona libreria di componenti ed espone in modo impietoso la sua assenza. Se il tuo frontend è su misura pagina per pagina, costruisci prima il design system.
• Superfici UI regolamentate. Audit WCAG, interfacce di dispositivi medici FDA, qualsiasi cosa che richieda una UI congelata per la compliance. Il punto stesso della Generative UI è che l'interfaccia cambia per ogni query — questo è una caratteristica, non un bug, ed è incompatibile con "questa schermata deve apparire esattamente così nel 2031."

Una verifica utile: se non riesci a rispondere a "come sarebbe la UI statica se la costruissimo semplicemente?", allora non hai ancora capito abbastanza bene il problema perché un LLM ti aiuti.

Prossimi passi

• Leggi la nostra guida completa alla Generative UI per l'architettura di produzione, i confronti tra runtime e l'ecosistema più ampio
• Prova lo strumento di analisi SWOT per vedere la Generative UI in azione su un flusso reale
• Consulta la documentazione del Vercel AI SDK per il riferimento streamUI
• Esplora i nostri servizi se hai bisogno di aiuto per implementare la GenUI nel tuo prodotto