Tutorial de Gemini 3 Flash: crea un UI Studio con function calling

La mayoría de las demos de generadores de paneles con IA siguen el mismo patrón: el usuario pasa un prompt, el modelo genera un gran bloque de código de interfaz y luego el usuario invierte el resto del tiempo arreglando layouts rotos, estados que faltan y componentes a medio conectar.

Este tutorial propone otra vía. Vamos a construir UI Studio, una fábrica de paneles basada en llamadas a herramientas donde Gemini 3 Flash coordina 100 componentes de UI como herramientas invocables. 

En lugar de escribir un único archivo gigante de React, Flash encadena pasos pequeños y estructurados: crear una barra de navegación, añadir filtros, vincular datos a una tabla, generar gráficos de insights y exportar un único archivo JSON UISpec. Ejecuta un proceso paso a paso mientras la UI se actualiza al completar cada fase.

Al final, tendrás una app tipo estudio capaz de generar múltiples plantillas de panel (clasificación de feedback de clientes, pipeline de ventas, gestión de incidencias SRE, control de gasto financiero, embudo de analítica de producto y más) e iterar en segundos a otro modo de vista, tema, etc. 

Nota: esta demo es una base: ajusta los prompts para alinearlos con tus objetivos y preferencias de salida.

Si quieres aprender más sobre cómo crear agentes de IA en el ecosistema de Google, te recomiendo el curso Building AI Agents with Google ADK. También te recomendamos nuestra guía de Gemini 3.8 Flash.

¿Qué es Gemini 3 Flash?

El modelo Gemini 3 Flash de Google está diseñado para flujos agentic centrados en la velocidad, donde no buscas una única respuesta perfecta, sino un bucle de iteración corto: construir, inspeccionar, retocar y reconstruir. Flash replica el razonamiento de Gemini 3 Pro con latencia, eficiencia y coste de nivel Flash, lo que lo hace ideal para apps interactivas de alta frecuencia. 

Fuente: Gemini 3 Flash DeepMind 

Dos aspectos que hacen a Flash especialmente útil para apps constructoras como UI Studio:

• Está pensado para ejecutar numerosos pasos estructurados de forma fiable, en vez de entregar una única respuesta completa.
• También admite salidas estructuradas, function calling, ejecución de código y búsqueda como herramienta, lo que nos permite mantener toda la cadena determinista e inspeccionable.

En teoría, Gemini 3 Flash (preview) admite 1 M de tokens de entrada y 64 K de salida, muy útil cuando el rastro de build y el UISpec crecen. 

Arquitectura de Gemini 3 Flash 

Gemini 3 Flash es el modelo para flujos agentic de la familia Gemini 3, ajustado para aplicaciones de baja latencia y alto rendimiento en las que necesitas iteraciones rápidas, uso de herramientas y planes multi‑paso. Estas son algunas características clave:

• Niveles de razonamiento (thinking_level): Gemini 3 Flash expone un ajuste thinking_level (minimal, low, medium, high) que permite equilibrar latencia/coste vs profundidad. Es perfecto para builds de UI donde la mayoría de pasos son rutinarios, pero algunos requieren más planificación.
• Uso de herramientas: el uso de herramientas en Gemini 3 está pensado para bucles multi‑paso en los que el modelo emite llamadas a herramientas, las ejecutamos, devolvemos resultados y continúa hasta completar el turno. Es justo lo que queremos para un studio que se actualiza en tiempo real mientras avanza el build.
• Firmas de pensamiento: Gemini 3 usa firmas de pensamiento cifradas para preservar el contexto de razonamiento entre turnos. El bucle de herramientas debe devolverlas exactamente como llegaron o el function calling puede fallar (error de validación 4xx/400), incluso con thinking_level="minimal".
• Multimodalidad: Gemini 3 Flash acepta texto, código, imágenes, audio, vídeo y PDFs como entrada. En Vertex AI, podemos ajustar media_resolution para equilibrar coste multimodal vs latencia e incluso devolver salidas multimodales de herramientas cuando necesitamos más control.

Ejemplo con Gemini 3 Flash: crea un panel en UI Studio

En esta sección, construiremos UI Studio a partir de un único prompt usando Gemini 3 Flash. La app compone UIs mediante llamadas a herramientas y genera un JSON UISpec exportable.

A grandes rasgos, la app final hará lo siguiente:

• Mostrar un catálogo de plantillas como clasificación de feedback de clientes, embudo de analítica de producto, pipeline de ventas y más.
• Permitir que el usuario haga clic en Start Build para lanzar un bucle de construcción por llamadas a herramientas donde Flash compone el panel paso a paso.
• Renderizar el panel generado en modo vista previa junto a un inspector de UISpec y un rastro de ejecución.
• Exportar la especificación final del panel como JSON.
• Permitir iteraciones rápidas con prompts sencillos como densidad compacta, modo oscuro, ordenación por riesgo de SLA por defecto o cambiar a kanban.

Resumen del prompt

En esta sección veremos el prompt usado para construir el UI Studio en Google AI Studio con Gemini 3 Flash. En lugar de generar un panel de una vez, Flash actúa como el cerebro del estudio: coordina llamadas a herramientas, valida y repara salidas, y produce un único artefacto renderizable. 

Este es el prompt que utilicé para la 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.

El objetivo del prompt es imponer un bucle de construcción predecible para que Gemini 3 Flash se comporte como un builder, no como un chatbot. Para ello, el prompt debe incluir:

• Un objetivo explícito de uso de herramientas en el primer build, normalmente de 30 a 80 llamadas, para que Flash divida la UI en muchos pasos pequeños de construcción de componentes en lugar de generar una salida única y grande.
• Un bucle obligatorio de validación y reparación hasta que la especificación pase, garantizando que el UISpec final sea renderizable y evitando estados rotos.
• Actualizaciones tipo patch durante la iteración para conservar los IDs de componentes y evitar reconstrucciones completas. Así la UI se mantiene estable entre ediciones y las iteraciones son rápidas.
• Un contrato de UISpec a alto nivel que cubra tema, layout, componentes, bindings, workflows, estados, catálogo de plantillas, agentes y traza. Esto da a Flash un formato objetivo estricto para que cada build produzca un artefacto estructurado y consistente.
• Un catálogo de plantillas y la asignación de agentes especialistas, de modo que cada tipo de panel parta de valores por defecto como layout, knobs y componentes preferidos, y Flash pueda repartir el trabajo entre planificación, construcción y validación.

Funciona porque el modelo entrega un único UISpec estructurado que puedes validar, corregir con pequeños parches y actualizar rápido sin reconstruir toda la UI.

Resumen del proyecto

Aunque Gemini 3 Flash genera toda la base de código de esta demo, ayuda entender la responsabilidad de cada archivo. Hay una separación clara entre la UI del Studio, la vista previa del panel y la capa de API de Gemini. Cuando sabes dónde viven los dos bucles de IA, el resto del repositorio se sigue con facilidad.

Este es el flujo general de cómo la app UI Studio invoca a Gemini 3 Flash y renderiza el panel generado:

• Al cargar la app, App.tsx abre la vista del Studio y obtiene el catálogo inicial de plantillas, el registro de herramientas, el catálogo de componentes y la lista de agentes desde mockData.ts.
• La selección de plantilla se gestiona totalmente en estado del cliente por ahora, así que aún no se dispara ninguna solicitud a Gemini.
• Cuando haces clic en Start Build, la app limpia el rastro de la ejecución anterior, cambia a estado de "construcción" y empieza a actualizar las tarjetas de agentes y los eventos de traza para hacer visible el progreso.
• Tras las actualizaciones escalonadas de UI, la app realiza la solicitud principal de build mediante services/geminiService.ts.
• La respuesta JSON del modelo se convierte en un UISpec, se guarda en el estado y la UI cambia al modo Preview.
• En la vista previa, el panel generado se renderiza con componentes estándar de React como tablas, filtros e insights.
• PreviewDrawer.tsx actúa como panel inspector para ver el JSON de UISpec y estadísticas básicas del build.
• Un segundo bucle de Gemini vive dentro de DetailDrawer.tsx y se ejecuta a nivel de fila individual.
• Cuando un usuario abre un elemento de feedback y solicita ayuda de IA, analyzeFeedback() y suggestResolution() en geminiService.ts llaman de nuevo a Gemini para producir una clasificación estructurada y acciones recomendadas.
• En conjunto, la app ejecuta dos pipelines: uno para construir la especificación del panel y otro para asistir a los usuarios dentro del panel.

Si te interesan otros archivos clave del proyecto para entender cómo está cableada la demo, aquí tienes más detalle:

Directorio raíz

Estos archivos definen la configuración del proyecto, los contratos de tipos y los datos semilla que hacen la demo consistente y ejecutable.

• package.json: Define dependencias y scripts: React, Recharts y el SDK @google/genai, junto con scripts de desarrollo como vite, build y preview.
• tsconfig.json: Contiene la configuración del compilador TypeScript para React y la resolución del bundler. Mantiene el proyecto tipado sin emitir TS compilado en desarrollo.
• vite.config.ts: Configuración de Vite para dev y build, incluido el puerto y el wiring de entornos. Mapea GEMINI_API_KEY a process.env.API_KEY para que el SDK GenAI lo lea en el build del navegador.
• metadata.json: Metadatos de la app usados por AI Studio para el hosting. Asignan nombre, descripción y permisos requeridos.
• types.ts: Actúa como capa de contrato para toda la app: define tipos para plantillas, agentes, herramientas, filas de feedback y la forma de UISpec para que UI y salidas del modelo se mantengan consistentes.
• mockData.ts: Contiene datos semilla para la experiencia de Studio y Preview. Define el catálogo de plantillas, el roster inicial de agentes, el registro de herramientas y filas de feedback ficticias para que la UI funcione incluso antes de cualquier llamada al modelo.

Servicios (services/)

Esta capa contiene la integración con Gemini y gestiona todas las llamadas al modelo y sus respuestas estructuradas.

• geminiService.ts: Incluye tres llamadas principales: la función orchestrateBuild() para generar un UISpec, y las funciones analyzeFeedback() y suggestResolution() para alimentar la asistencia de IA.
• Nota: orchestrateBuild() apunta actualmente a gemini-3-pro-preview, mientras que las otras dos usan gemini-3-flash-preview. Cámbialo si quieres que toda la demo funcione solo con Flash.

Componentes del Studio (components/)

Estos componentes de React renderizan la UI del builder y la vista previa del panel generado, incluido el inspector de JSON y los flujos de detalle.

• StudioHeader.tsx: Renderiza la cabecera del Studio y el CTA para iniciar el build. Refleja el estado del build para que el usuario vea cuándo se está ejecutando la pipeline.
• TemplateCatalog.tsx: Muestra tarjetas de plantillas y permite elegir qué panel construir. La selección actualiza el estado local en App.tsx.
• AgentPanel.tsx: El panel de agentes muestra "agentes especialistas" como tarjetas de estado. En esta demo, la progresión del estado la provocan actualizaciones escalonadas en App.tsx para hacer visible el flujo.
• ToolPanel.tsx: Ayuda a renderizar la lista del registro de herramientas desde mockData.ts. Es el contenedor de UI para mostrar disponibilidad y contadores de llamadas.
• ComponentPanel.tsx: Representa la idea de "componentes como herramientas" y es el lugar natural para añadir más adelante interruptores de permitir/denegar.
• PreviewDrawer.tsx: Permite ver el JSON de UISpec y estadísticas básicas, haciendo depurable el rastro del build.

• Topbar.tsx: Contiene la navegación superior del panel y la barra de búsqueda. Demuestra cómo los controles a nivel de panel conviven con los knobs del studio.
• Sidebar.tsx: Gestiona la navegación lateral izquierda del panel renderizado.
• FilterBar.tsx: Actúa como franja de filtros para segmentar los datos de feedback. 
• FeedbackTable.tsx: La vista de tabla principal para elementos de feedback; al hacer clic en una fila se selecciona y se abre la experiencia del cajón de detalle.
• DetailDrawer.tsx: Invoca analyzeFeedback() y suggestResolution() y muestra la salida del modelo en la pestaña de IA.
• InsightsSection.tsx: Ayuda a renderizar gráficos y la vista de resumen de insights usando Recharts.

Aquí tienes un breve vídeo demo que recorre todo el flujo de UI Studio, incluida la selección de plantilla, el flujo de Start Build y la vista previa del panel generado: