Tutorial su Gemini 3 Flash: crea una UI Studio con Function Calling

La maggior parte delle demo di builder di dashboard AI seguono lo stesso schema: l’utente inserisce un prompt, il modello genera un enorme blocco di codice UI e l’utente passa il resto del tempo a sistemare layout rotti, stati mancanti e componenti collegati a metà.

Questo tutorial adotta un approccio diverso. Costruiremo UI Studio, una fabbrica di dashboard basata su tool calling in cui Gemini 3 Flash coordina 100 componenti UI come strumenti richiamabili. 

Invece di scrivere un unico grande file React, Flash sequenzia piccoli passaggi strutturati come creare una navbar, aggiungere filtri, collegare i dati a una tabella, generare grafici d’analisi ed esportare un unico file JSON UISpec. Esegue un processo passo dopo passo mentre l’interfaccia si aggiorna al completamento di ciascun step.

Alla fine avrai un’app in stile studio capace di generare più template di dashboard (Smistamento feedback clienti, Pipeline di vendita, Comando incidenti SRE, Monitoraggio spese Finance, Funnel di analytics di prodotto e altro) e iterare rapidamente verso un’altra modalità di visualizzazione, tema e così via. 

Nota: questa demo è una base di partenza; sentiti libero di affinare i prompt per allinearli meglio ai tuoi obiettivi specifici e alle preferenze di output

Se vuoi approfondire la creazione di AI Agent nell’ecosistema Google, ti consiglio il corso Building AI Agents with Google ADK. Ti suggerisco anche la nostra guida a Gemini 3.8 Flash.

Che cos’è Gemini 3 Flash?

Il modello Gemini 3 Flash di Google è pensato per workflow agentici orientati alla velocità, in cui non cerchi una singola risposta perfetta, ma un ciclo di iterazione rapido come build, verifica, modifica e rebuild. Flash replica il ragionamento di Gemini 3 Pro con latenza, efficienza e costo da Flash, rendendolo ideale per app interattive ad alta frequenza. 

Fonte: Gemini 3 Flash DeepMind 

Due aspetti che rendono Flash rilevante per app di building come UI Studio sono:

• È progettato per eseguire numerosi passaggi strutturati in modo affidabile, invece di fornire una singola risposta onnicomprensiva.
• Supporta anche output strutturati, function calling, esecuzione di codice e ricerca come strumento, permettendoci di mantenere l’intera pipeline deterministica e ispezionabile.

In teoria, Gemini 3 Flash (preview) supporta 1M token in input e 64K token in output, utili quando il build trace e lo UISpec diventano grandi. 

Architettura di Gemini 3 Flash 

Gemini 3 Flash è il modello per workflow agentici della famiglia Gemini 3, ottimizzato per applicazioni a bassa latenza e alto throughput in cui servono iterazioni rapide, uso di tool e piani multi-step. Ecco alcune funzionalità chiave del modello:

• Livelli di ragionamento (thinking_level): Gemini 3 Flash espone un’impostazione thinking_level (minimal, low, medium, high) che consente di bilanciare latenza/costo vs profondità. È perfetta per i build UI in cui molti passaggi sono di routine, ma alcuni richiedono pianificazione più profonda.
• Uso degli strumenti: il tool use di Gemini 3 è progettato per loop multi-step in cui il modello emette chiamate agli strumenti, noi le eseguiamo, rimandiamo i risultati e il modello continua finché il turno è completo. È esattamente ciò che vogliamo per una UI di studio che si aggiorna in tempo reale durante il build.
• Firme di pensiero: Gemini 3 usa firme di pensiero criptate per preservare il contesto di ragionamento tra i turni. Il loop degli strumenti deve restituirle esattamente come ricevute, altrimenti il function calling può fallire (errore di validazione 4xx/400), anche con thinking_level="minimal".
• Multimodalità: Gemini 3 Flash accetta testo, codice, immagini, audio, video e PDF come input. Su Vertex AI possiamo regolare media_resolution per bilanciare costo multimodale vs latenza, e persino restituire output multimodali dagli strumenti quando serve un controllo più stretto.

Esempio con Gemini 3 Flash: costruisci una dashboard in UI Studio

In questa sezione costruiremo UI Studio a partire da un singolo prompt usando Gemini 3 Flash. L’app assembla le UI tramite chiamate a strumenti e produce un JSON UISpec esportabile.

A livello generale, l’app finale:

• Mostra un Catalogo template come Smistamento feedback clienti, Funnel di analytics di prodotto, Pipeline di vendita e altro.
• Permette all’utente di cliccare Avvia build per attivare un loop di build basato su tool calling in cui Flash compone la dashboard passo dopo passo.
• Renderizza la dashboard generata in Modalità anteprima, insieme a un inspector dello UISpec e a un execution trace.
• Esporta la specifica finale della dashboard come JSON.
• Supporta iterazioni rapide con prompt semplici come densità compatta, dark mode, ordinamento predefinito per rischio SLA o passaggio a kanban.

Panoramica del prompt

In questa sezione vedremo il prompt usato per costruire la UI Studio in Google AI Studio con Gemini 3 Flash. Invece di generare una dashboard in un colpo solo, Flash agisce come il cervello dello studio: coordina le chiamate agli strumenti, valida e ripara gli output e produce un singolo artefatto renderizzabile. 

Ecco il prompt che ho usato per questa demo:

SYSTEM / DEVELOPER PROMPT — Gemini 3 Flash (UI STUDIO ORCHESTRATOR)
You are UI_STUDIO_ORCHESTRATOR inside an app called “UI Studio”.
Goal: Build a reusable “dashboard builder studio” that can generate many different dashboards (Sales, Support, Ops, Finance, Product Analytics, etc.) by orchestrating 80–150 callable UI component tools (agents). 
Each UI component (navbar, cards, table, filters, auth, charts, drawers, modals, etc.) is represented as a tool/function that returns structured JSON. 
You must reliably sequence many tool calls and output a valid UISpec JSON that renders the Studio UI and the generated dashboards.
HIGH-LEVEL BEHAVIOR
UI Studio itself is a dashboard-like app (the “builder”), not just a single dashboard.
Users can select a dashboard type/template to build (e.g., “Customer Feedback Triage”, “Sales Pipeline”, “SRE Incident”, “Finance Spend”, “Product Analytics”).
The Studio exposes a catalog of components (count ~100) and a tool registry (count 80–150), plus specialized agents for different template families.
Gemini 3 Flash must:
Render the UI Studio builder UI
Provide template selection and “Start Build” for a chosen dashboard
Use different specialist agents for different dashboard templates
Assemble the requested dashboard via many component tool calls
Iterate rapidly based on feedback (A/B knobs)
ABSOLUTE RULES
TOOL-FIRST: Build everything via tools. Do not “describe” UIs in prose.
MANY CALLS: On first build, make 30–80 tool calls. This is expected.
STRUCTURED OUTPUT ONLY: Final response must be ONE valid JSON object (UISpec). No markdown or commentary.
VALIDATE + REPAIR: Always run validate_uispec and repair until ok=true.
CONSTRAINTS: Only call enabled tools and only instantiate allowed components (if lists are provided).
ITERATION: Patch minimal deltas using update tools; preserve stable IDs.
INPUTS YOU RECEIVE (RunContext)
The user (or the app) provides a JSON RunContext each run:
{
"studioGoal": string,
"selectedTemplate": string | null,
"requestPrompt": string,
"knobs": { ... },
"allowedComponents": string[],
"enabledTools": string[],
"availableTemplates": string[] | null,
"agents": [{ "name": string, "role": string, "specialty": string }]
}
Use this as the constraints. If missing, assume reasonable defaults and proceed.
TOOLS AVAILABLE (CONCEPTUAL)
You can call tools returning JSON. Only call tool names included in enabledTools.
set_agent_status(agentName, status, note) -> ok
emit_trace(eventName, payload) -> ok
list_templates() -> { templates: TemplateMeta[] }
choose_template(userIntent) -> { templateId, rationale }
define_data_model(domain, templateId, constraints) -> DataModel
compose_layout(layout_type, regions, responsive_rules) -> LayoutSpec
create_component(type, variant, region, intent, theme_tokens, data_contract, constraints) -> ComponentSpec
update_component(component_id, patch) -> ComponentSpec
bind_data(component_id, bindings) -> BindingSpec
define_workflow(name, steps, triggers) -> WorkflowSpec
validate_uispec(uispec) -> { ok: boolean, issues: Issue[] }
repair_uispec(uispec, issues) -> UISpec
create_ab_variant(base_uispec, knob_changes) -> { variants: [{name, uispec}], metricPlan }
save_template(templateId, uispec) -> ok
export_dashboard(uispec, format) -> { artifactRef }
UISPEC OUTPUT CONTRACT (STRICT)
Return ONE JSON object:
{
"app": { "name": "UI Studio", "description": string, "routes": [...] },
"theme": { "mode": "light"|"dark", "density": "compact"|"comfortable", "tokens": {...} },
"studio": {
"templateCatalog": TemplateMeta[],
"selectedTemplate": string|null,
"componentCatalog": { "count": number, "items": string[] },
"toolRegistry": { "count": number, "items": string[] },
"agents": [{ "name": string, "role": string, "specialty": string }]
},
"dataModel": DataModel,
"layout": LayoutSpec,
"components": ComponentSpec[],
"workflows": WorkflowSpec[],
"states": { "loading": {...}, "empty": {...}, "error": {...} },
"generatedDashboards": [
{ "templateId": string, "name": string, "uispecRef": string }
],
"abTests": [ ... ] // optional
}
UI STUDIO BUILDER UI (MUST INCLUDE)
The Studio UI must include:
A) Header + Hero Banner
Title “UI Studio”
Subtitle: “Build dashboards via function-calling components”
Buttons: “Start Build”, “Iterate”, “Export”
B) REQUESTS (cards like “Orders”)
Preset request cards (Easy/Intermediate/Difficult) for different dashboard types
“Add New Request” card
Each request card has Start + status
C) COMPONENTS panel (count ~100)
Searchable list of UI components (navbar, cards, table, filter, auth, charts, drawer, modal, etc.)
Allow/prefer/disable toggles (optional)
Shows count
D) TOOLS panel (count 80–150)
Searchable list of callable tools/functions
Shows call counters for the current run and “recently called”
Shows count
E) AGENTS panel
3–8 specialist agent cards (all powered by Flash, but role-separated):
Template Selector Agent (chooses dashboard template from user intent)
IA/UX Planner Agent (information architecture)
Data Modeler Agent (schemas + bindings)
Component Composer Agent (creates component specs)
Chart Builder Agent (insights widgets)
QA/A11y Gatekeeper Agent (validation + fixes)
Experimentation Agent (A/B variants + knobs)
Agent cards show status: Idle / Working / Waiting / Done
F) Preview Drawer
Tabs: Preview | UISpec JSON | Trace
Preview renders either the Studio or the generated dashboard spec
TEMPLATE SYSTEM (MUST INCLUDE)
Provide at least 8 templates in templateCatalog with metadata:
id, name, category, difficulty, primaryComponents, dataEntities, defaultKnobs
Examples:
customer_feedback_triage
sales_pipeline
support_ticket_ops
sre_incident_command
finance_spend_tracker
product_analytics_funnel
marketing_campaign_performance
inventory_warehouse_ops
Selecting a template should:
set selectedTemplate
populate default knobs
drive which specialist agents become active
drive which components/tools are preferred during build
A/B KNOBS (FIRST-CLASS)
Studio must support knob-driven iterations:
density: compact|comfortable
navigation: topbarOnly|leftRail
defaultSort: template-specific enum
viewMode: table|inboxList|kanban|gridCards
insightFocus: overviewFirst|triageFirst|trendsFirst
themeMode: light|dark
BUILD ALGORITHM
When user requests “create UI studio …” (this message), you must:
emit_trace("start_studio_build", {...})
set_agent_status(...) as you plan/build/validate
Create the UI Studio builder UI (sections A–F above) via MANY create_component calls
Define templateCatalog and agent roster
Implement template selection workflow:
choose_template from user intent
build_dashboard workflow that triggers component creation for the chosen template
Implement “Start Build” workflow:
picks template
defines dataModel
composes layout
creates components for the generated dashboard
validates + repairs
stores in generatedDashboards with uispecRef
validate_uispec and repair until ok
Output ONLY the UISpec JSON
ITERATION BEHAVIOR
If user later asks: “build a Sales dashboard” or “change to dark mode, compact density”:
update Studio state (selectedTemplate/knobs)
call update_component and rebuild only the generated dashboard region
re-validate and output updated UISpec JSON only
NOW EXECUTE
User intent: Create a UI Studio that can build numerous dashboards, with 100 UI components as callable tools/agents, dashboard selection, and specialist agents for different templates.
Start building immediately via tools, then output a single valid UISpec JSON.

L’obiettivo del prompt è imporre un loop di build prevedibile, così Gemini 3 Flash si comporta da builder, non da chatbot. Per questo, il prompt dovrebbe includere:

• Un obiettivo esplicito per l’uso degli strumenti al primo build, in genere 30–80 chiamate, così Flash scompone la UI in tanti piccoli passaggi di costruzione dei componenti invece di generare un unico grande output.
• Un ciclo obbligatorio di validazione e poi riparazione fino al superamento dei controlli per garantire che il UISpec finale sia renderizzabile e prevenga stati rotti.
• Aggiornamenti in stile patch durante l’iterazione per preservare gli ID dei componenti ed evitare rebuild completi. Questo mantiene la UI stabile tra le modifiche e rende le iterazioni rapide.
• Un contratto UISpec ad alto livello che copra tema, layout, componenti, binding, workflow, stati, catalogo template, agent e trace. Fornisce a Flash un formato target rigoroso, così ogni build produce un artefatto coerente e strutturato.
• Un catalogo di template e ruoli per agent specialisti, così ogni tipo di dashboard parte con predefiniti come layout, controlli e componenti preferiti, e Flash può suddividere il lavoro tra pianificazione, costruzione e validazione.

Funziona perché il modello produce un unico UISpec strutturato che puoi validare, correggere con piccole patch e aggiornare rapidamente senza ricostruire l’intera UI.

Panoramica del progetto

Anche se Gemini 3 Flash genera l’intero codebase per questa demo, è comunque utile capire di cosa si occupa ciascun file. C’è una chiara separazione tra la UI dello Studio, la dashboard di anteprima e il layer API di Gemini. Una volta capito dove vivono i due loop AI, il resto del repository diventa facile da seguire.

Ecco il flusso ad alto livello di come l’app UI Studio attiva Gemini 3 Flash e renderizza la dashboard generata:

• Al caricamento dell’app, App.tsx apre la vista Studio e recupera il catalogo template iniziale, il registro degli strumenti, il catalogo componenti e la lista agent da mockData.ts.
• La selezione del template è gestita interamente nello stato client in questa fase, quindi non viene ancora effettuata alcuna richiesta a Gemini.
• Quando clicchi Avvia build, l’app cancella il trace dell’esecuzione precedente, passa a uno stato di “building” e inizia ad aggiornare le card degli agent e gli eventi di trace per rendere visibile l’avanzamento.
• Dopo gli aggiornamenti di UI a stadi, l’app effettua la richiesta principale di build tramite services/geminiService.ts.
• La risposta JSON del modello viene analizzata in uno UISpec, salvata nello stato e la UI passa alla modalità Anteprima.
• In Anteprima, la dashboard generata viene renderizzata usando componenti React standard come tabelle, filtri e insight.
• PreviewDrawer.tsx funge da pannello inspector dove puoi visualizzare il JSON UISpec e statistiche basilari del build.
• Un secondo loop Gemini vive dentro DetailDrawer.tsx e gira a livello di singola riga.
• Quando un utente apre un feedback e richiede aiuto dell’AI, analyzeFeedback() e suggestResolution() in geminiService.ts richiamano di nuovo Gemini per produrre classificazioni strutturate e azioni raccomandate.
• Nel complesso, l’app esegue due pipeline: una per costruire la specifica della dashboard e una per assistere gli utenti all’interno della dashboard.

Se ti interessano altri file chiave del progetto per capire come è cablata la demo, ecco qualche dettaglio in più:

Directory root

Questi file definiscono il setup del progetto, i contratti di tipo e i dati seed che mantengono la demo coerente ed eseguibile.

• package.json: Definisce dipendenze e script: vediamo React, Recharts e l’SDK @google/genai, insieme a script di sviluppo come vite, build e preview.
• tsconfig.json: Contiene le impostazioni del compilatore TypeScript per React e la risoluzione del bundler. Mantiene il progetto type-safe senza emettere TS compilato durante lo sviluppo.
• vite.config.ts: Configurazione di Vite per dev e build, inclusi setup della porta e wiring degli environment. Mappa GEMINI_API_KEY in process.env.API_KEY, così il GenAI SDK può leggerla nel build per browser.
• metadata.json: I metadati dell’app sono usati da AI Studio per l’hosting. Forniscono nome, descrizione e permessi richiesti.
• types.ts: Funziona come layer di contratto per l’intera app: definisce i tipi per template, agent, tool, righe di feedback e la forma dello UISpec in modo che UI e output del modello restino coerenti.
• mockData.ts: Questo file contiene dati seed per l’esperienza Studio e Anteprima. Definisce il catalogo template, la rosa iniziale di agent, il registro strumenti e righe di feedback mock, così la UI funziona anche prima di qualsiasi chiamata al modello.

Services (services/)

Questo layer contiene l’integrazione con Gemini ed è dove vengono gestite tutte le chiamate al modello e le risposte strutturate.

• geminiService.ts: Ha tre chiamate principali: la funzione orchestrateBuild() per generare uno UISpec e le funzioni analyzeFeedback(), suggestResolution() per alimentare l’assistenza AI.
• Nota: orchestrateBuild() attualmente punta a gemini-3-pro-preview, mentre le altre due chiamate usano gemini-3-flash-preview, quindi potresti sostituirlo se vuoi che l’intera demo sia solo con Flash.

Componenti della Studio UI (components/)

Questi componenti React renderizzano la UI del builder dello Studio e l’anteprima della dashboard generata, incluso l’inspector JSON e i flussi di dettaglio.

• StudioHeader.tsx: Aiuta a renderizzare l’header dello Studio e la CTA per avviare il build. Riflette lo stato del build, così l’utente vede quando la pipeline è in esecuzione.
• TemplateCatalog.tsx: Mostra le card dei template e consente all’utente di selezionare quale dashboard costruire. La selezione aggiorna lo stato locale in App.tsx.
• AgentPanel.tsx: Il pannello Agent visualizza “agent specialisti” come card di stato. In questa demo, la progressione dello stato è guidata da aggiornamenti a stadi in App.tsx per rendere visibile il workflow.
• ToolPanel.tsx: Il Tool Panel aiuta a renderizzare la lista del registro strumenti da mockData.ts. È il placeholder UI per mostrare disponibilità degli strumenti e contatori delle chiamate.
• ComponentPanel.tsx: È la rappresentazione UI di “componenti come strumenti” ed è il luogo naturale per aggiungere in seguito toggle allow/deny.
• PreviewDrawer.tsx: Consente di visualizzare il JSON UISpec e statistiche di base, rendendo il build trace facilmente debuggabile.

• Topbar.tsx: Contiene la navigazione superiore della dashboard e la barra di ricerca. Dimostra come i controlli a livello di dashboard possano coesistere con i controlli dello studio.
• Sidebar.tsx: Gestisce la navigazione nella barra laterale sinistra per la dashboard renderizzata.
• FilterBar.tsx: Agisce come striscia di filtri usata per sezionare i dati di feedback. 
• FeedbackTable.tsx: È la vista tabellare principale per gli elementi di feedback; cliccando una riga si attiva la selezione e si apre il cassetto dei dettagli.
• DetailDrawer.tsx: Chiama analyzeFeedback() e suggestResolution() e renderizza l’output del modello nella scheda AI.
• InsightsSection.tsx: Aiuta a renderizzare grafici e la vista di insight riepilogativi usando Recharts.

Ecco un breve video demo che mostra l’intero workflow di UI Studio, inclusa la selezione del template, il flusso Avvia build e l’anteprima della dashboard generata: