Gemini 3 Flash Tutorial: Baue ein UI Studio mit Function Calling

Die meisten Demos für KI-Dashboard-Builder folgen demselben Muster: Du gibst einen Prompt ein, das Modell spuckt einen riesigen Batzen UI-Code aus, und du verbringst den Rest der Zeit damit, kaputte Layouts, fehlende Zustände und halb angebundene Komponenten zu reparieren.

Dieses Tutorial geht einen anderen Weg. Wir bauen UI Studio, eine Dashboard-Fabrik auf Basis von Tool-Aufrufen, bei der Gemini 3 Flash bis zu 100 UI-Komponenten als aufrufbare Tools koordiniert. 

Anstatt eine einzige große React-Datei zu schreiben, führt Flash kleine, strukturierte Schritte sequenziell aus: eine Navbar anlegen, Filter hinzufügen, Daten an eine Tabelle binden, Insight-Charts erzeugen und eine einzelne UISpec-JSON-Datei exportieren. Dabei läuft ein Schritt-für-Schritt-Prozess, während sich die UI nach jedem Schritt aktualisiert.

Am Ende hast du eine Studio-ähnliche App, die mehrere Dashboard-Vorlagen generieren kann (Customer Feedback Triage, Sales Pipeline, SRE Incident Command, Finance Spend Tracker, Product Analytics Funnel und mehr) und mit wenigen Handgriffen schnell zu anderem Ansichtsmodus, Thema und mehr iteriert. 

Hinweis: Dieses Demo ist ein Fundament. Du kannst die Prompts gerne verfeinern, damit sie besser zu deinen Zielen und gewünschten Outputs passen.

Wenn du mehr darüber lernen willst, wie man KI-Agenten im Google-Ökosystem baut, schau dir den Kurs Building AI Agents with Google ADK an. Empfehlenswert ist auch unser Leitfaden zu Gemini 3.8 Flash.

Was ist Gemini 3 Flash?

Googles Modell Gemini 3 Flash ist auf agentische Workflows mit maximaler Geschwindigkeit ausgelegt, bei denen du nicht eine einzige perfekte Antwort willst, sondern eine enge Iterationsschleife aus Bauen, Prüfen, Anpassen und Neuaufbau. Flash imitiert die Gemini 3 Pro-Reasoning-Fähigkeiten mit Flash-typischer Latenz, Effizienz und Kosten – ideal für interaktive Apps mit hoher Frequenz. 

Quelle: Gemini 3 Flash DeepMind 

Zwei Eigenschaften machen Flash für Builder-Apps wie UI Studio besonders relevant:

• Es ist dafür ausgelegt, zahlreiche strukturierte Schritte zuverlässig auszuführen, statt eine einzelne, umfassende Antwort zu liefern.
• Es unterstützt außerdem strukturierte Outputs, Function Calling, Codeausführung und Suche als Tool – so bleibt die gesamte Pipeline deterministisch und überprüfbar.

Theoretisch unterstützt Gemini 3 Flash (Preview) 1 Mio. Input-Tokens und 64 K Output-Tokens – hilfreich, wenn Build-Trace und UISpec groß werden. 

Gemini 3 Flash Architektur 

Gemini 3 Flash ist das agentische Workflow-Modell der Gemini-3-Familie, getunt für Anwendungen mit niedriger Latenz und hohem Durchsatz, in denen schnelle Iterationen, Tool-Nutzung und mehrstufige Pläne gefragt sind. Wichtige Merkmale sind:

• Reasoning-Level (thinking_level): Gemini 3 Flash bietet die Einstellung thinking_level (minimal, low, medium, high), die sich zwischen Latenz/Kosten und Tiefe austarieren lässt. Ideal für UI-Builds, bei denen viele Schritte Routine sind, einige aber mehr Planung brauchen.
• Tool-Nutzung: Die Tool-Nutzung von Gemini 3 ist für mehrstufige Schleifen ausgelegt: Das Modell emittiert Tool-Aufrufe, wir führen sie aus, geben die Ergebnisse zurück, und es macht weiter, bis der Turn abgeschlossen ist. Genau das brauchen wir für ein Studio-UI, das sich beim Build in Echtzeit aktualisiert.
• Thought Signatures: Gemini 3 verwendet verschlüsselte Thought Signatures, um den Reasoning-Kontext über Turns hinweg zu bewahren. Die Tool-Schleife muss sie exakt wie empfangen zurückgeben, sonst kann Function Calling scheitern (4xx/400 Validierungsfehler) – selbst bei thinking_level="minimal".
• Multimodalität: Gemini 3 Flash akzeptiert Text, Code, Bilder, Audio, Video und PDFs als Eingaben. Auf Vertex AI können wir media_resolution anpassen, um zwischen multimodalen Kosten und Latenz zu tauschen – und bei Bedarf sogar multimodale Tool-Outputs zurückgeben, wenn wir mehr Kontrolle brauchen.

Gemini 3 Flash Beispiel: Ein UI-Studio-Dashboard bauen

In diesem Abschnitt bauen wir das UI Studio aus einem einzigen Prompt mit Gemini 3 Flash. Die App setzt UIs über Tool-Aufrufe zusammen und liefert ein exportierbares UISpec-JSON aus.

Auf hoher Ebene wird die finale App Folgendes tun:

• Einen Vorlagenkatalog anzeigen, z. B. Customer Feedback Triage, Product Analytics Funnel, Sales Pipeline und mehr.
• Den Nutzenden per Klick auf Start Build eine Tool-Calling-Build-Schleife starten lassen, in der Flash das Dashboard Schritt für Schritt komponiert.
• Das generierte Dashboard im Preview-Modus rendern – neben einem UISpec-Inspektor und einem Execution-Trace.
• Die finale Dashboard-Spezifikation als JSON exportieren.
• Schnelle Iteration mit einfachen Prompts unterstützen, z. B. kompakte Dichte, Dark Mode, Standard-Sortierung nach SLA-Risiko oder Wechsel zu Kanban.

Prompt-Übersicht

In diesem Abschnitt schauen wir uns den Prompt an, mit dem das UI Studio in Google AI Studio mit Gemini 3 Flash gebaut wurde. Anstatt ein Dashboard in einem Rutsch zu erzeugen, agiert Flash als Gehirn des Studios. Es koordiniert Tool-Aufrufe, validiert und repariert Outputs und erzeugt ein einziges renderbares Artefakt. 

Hier ist der Prompt, den ich für dieses Demo verwendet habe:

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.

Ziel des Prompts ist es, einen vorhersagbaren Build-Loop zu erzwingen, damit Gemini 3 Flash wie ein Builder agiert – nicht wie ein Chatbot. Dafür sollte der Prompt enthalten:

• Ein klares Ziel für die Tool-Nutzung beim ersten Build – meist 30 bis 80 Tool-Aufrufe –, damit Flash die UI in viele kleine Komponenten-Schritte aufteilt statt einen großen Output zu erzeugen.
• Eine verpflichtende Schleife aus Validieren und Reparieren, bis die Spezifikation durchgeht – so ist die finale UISpec renderbar und fehlerhafte Zustände werden verhindert.
• Patch-basierte Updates während der Iteration, um Komponenten-IDs zu erhalten und Komplett-Neubauten zu vermeiden. Das hält die UI über Bearbeitungen hinweg stabil und macht Iterationen schnell.
• Einen klaren UISpec-Vertrag mit Theme, Layout, Komponenten, Bindings, Workflows, States, Vorlagenkatalog, Agents und Trace. So hat Flash ein striktes Ziel-Format und jeder Build liefert ein konsistentes, strukturiertes Artefakt.
• Einen Vorlagenkatalog und zugewiesene Spezialagenten, damit jeder Dashboard-Typ mit Defaults wie Layout, Knobs und bevorzugten Komponenten startet und Flash die Arbeit auf Planung, Aufbau und Validierung aufteilen kann.

Das funktioniert, weil das Modell eine einzige strukturierte UISpec ausgibt, die du validieren, mit kleinen Patches fixen und schnell aktualisieren kannst – ohne die gesamte UI neu zu bauen.

Projektüberblick

Auch wenn Gemini 3 Flash für dieses Demo den gesamten Code generiert, hilft es, die Verantwortlichkeiten der Dateien zu kennen. Es gibt eine klare Trennung zwischen der Studio-UI, dem Vorschau-Dashboard und der Gemini-API-Schicht. Wenn du weißt, wo die beiden KI-Schleifen leben, wird der Rest des Repos leicht nachvollziehbar.

So triggert die UI-Studio-App Gemini 3 Flash und rendert das generierte Dashboard auf hoher Ebene:

• Beim Laden der App öffnet App.tsx die Studio-Ansicht und zieht den initialen Vorlagenkatalog, Tool-Register, Komponenten-Katalog und die Agentenliste aus mockData.ts.
• Die Vorlagenauswahl läuft in dieser Phase komplett im Client-State, es wird noch kein Gemini-Request ausgelöst.
• Wenn du auf Start Build klickst, leert die App den vorherigen Run-Trace, schaltet in den „Building“-Status und aktualisiert Agenten-Karten und Trace-Events, damit der Fortschritt sichtbar ist.
• Nach den gestaffelten UI-Updates stellt die App die Haupt-Build-Anfrage über services/geminiService.ts.
• Die JSON-Antwort des Modells wird zu einer UISpec geparst, im State gespeichert, und die UI wechselt in den Preview-Modus.
• In der Vorschau wird das generierte Dashboard mit Standard-React-Komponenten wie Tabellen, Filtern und Insights gerendert.
• PreviewDrawer.tsx dient als Inspektorpanel, in dem du das UISpec-JSON und grundlegende Build-Statistiken einsehen kannst.
• Eine zweite Gemini-Schleife steckt in DetailDrawer.tsx und läuft auf Ebene einzelner Zeilen.
• Wenn ein Feedback-Item geöffnet und KI-Hilfe angefordert wird, rufen analyzeFeedback() und suggestResolution() in geminiService.ts Gemini erneut auf, um strukturierte Klassifikationen und empfohlene Maßnahmen zu erzeugen.
• Insgesamt laufen zwei Pipelines: eine zum Bauen der Dashboard-Spezifikation und eine zur Unterstützung der Nutzenden innerhalb des Dashboards.

Wenn du weitere Schlüsselelemente des Projekts verstehen willst, findest du hier zusätzliche Details:

Root-Verzeichnis

Diese Dateien definieren das Projekt-Setup, Typverträge und Seed-Daten, die das Demo konsistent und lauffähig halten.

• package.json: Definiert Dependencies und Skripte – zu sehen sind React, Recharts und das @google/genai-SDK – sowie Dev-Skripte wie vite, build und preview.
• tsconfig.json: Enthält die TypeScript-Compiler-Einstellungen für React und Bundler-Resolution. Hält das Projekt typsicher, ohne während der Entwicklung kompiliertes TS auszugeben.
• vite.config.ts: Vite-Dev- und Build-Konfiguration, inkl. Port-Setup und Environment-Wiring. Diese Datei mapped GEMINI_API_KEY auf process.env.API_KEY, damit das GenAI-SDK ihn im Browser-Build lesen kann.
• metadata.json: App-Metadaten für das Hosting in AI Studio: Name, Beschreibung und erforderliche Berechtigungen.
• types.ts: Wirkt als Vertragsschicht der gesamten App: Definiert Typen für Templates, Agents, Tools, Feedback-Zeilen und die UISpec-Struktur, damit UI und Modellausgaben konsistent bleiben.
• mockData.ts: Enthält Seed-Daten für Studio und Vorschau: Vorlagenkatalog, initiale Agentenliste, Tool-Register und Mock-Feedback-Zeilen – so funktioniert die UI auch ohne Model-Call.

Services (services/)

Diese Schicht enthält die Gemini-Integration – hier werden alle Model-Aufrufe und strukturierten Antworten verarbeitet.

• geminiService.ts: Drei Kernfunktionen: orchestrateBuild() zur Erzeugung einer UISpec sowie analyzeFeedback() und suggestResolution() für KI-Unterstützung.
• Hinweis: orchestrateBuild() zielt aktuell auf gemini-3-pro-preview, die beiden anderen Calls nutzen gemini-3-flash-preview. Wenn das gesamte Demo nur Flash verwenden soll, kannst du das tauschen.

Studio-UI-Komponenten (components/)

Diese React-Komponenten rendern die Studio-Builder-UI und die Dashboard-Vorschau – inklusive JSON-Inspektor und Detail-Flows.

• StudioHeader.tsx: Rendert den Studio-Header und die Build-CTA. Spiegelt den Build-Status wider, damit sichtbar ist, wann die Pipeline läuft.
• TemplateCatalog.tsx: Zeigt Vorlagenkarten und lässt Nutzende auswählen, welches Dashboard sie bauen möchten. Die Auswahl aktualisiert den lokalen State in App.tsx.
• AgentPanel.tsx: Zeigt „Spezialagenten“ als Statuskarten. In diesem Demo steuert App.tsx die Status-Fortschritte über gestaffelte Updates, um den Ablauf sichtbar zu machen.
• ToolPanel.tsx: Rendert die Tool-Registry-Liste aus mockData.ts. Platzhalter-UI, um Tool-Verfügbarkeit und Call-Counter anzuzeigen.
• ComponentPanel.tsx: UI-Darstellung von „Komponenten als Tools“ – der natürliche Ort, um später Allow/Deny-Toggles hinzuzufügen.
• PreviewDrawer.tsx: Ermöglicht die Ansicht des UISpec-JSON und Basisstatistiken – macht den Build-Trace debugbar.

• Topbar.tsx: Enthält die Top-Navigation und Suchleiste des Dashboards – zeigt, wie Dashboard-Controls neben Studio-Knobs existieren können.
• Sidebar.tsx: Steuert die Navigation über die linke Seitenleiste im gerenderten Dashboard.
• FilterBar.tsx: Dient als Filterleiste, um Feedback-Daten zu schneiden. 
• FeedbackTable.tsx: Haupttabelle für Feedback-Items; ein Zeilenklick selektiert und öffnet die Detail-Drawer-Experience.
• DetailDrawer.tsx: Ruft analyzeFeedback() und suggestResolution() auf und rendert die Modellausgabe im AI-Tab.
• InsightsSection.tsx: Hilft beim Rendern von Charts und der Zusammenfassungsansicht mit Recharts.

Hier ist ein kurzes Demovideo, das den kompletten UI-Studio-Workflow zeigt – inklusive Vorlagenauswahl, Start-Build-Flow und generierter Dashboard-Vorschau: