← Blog
Unser Journal9 Min. Lesezeit

Das Granularitätsproblem in GenUI: Wo sollte die LLM-Generierung aufhören?

Notizen aus dem Aufbau von AirJellys GenUI-Engine — und warum mehr Freiheit für das LLM das Ergebnis schlechter machte.

Translated by AI

Dieser Blogbeitrag stammt aus unserer praktischen Erkundung der GenUI-Engine im AirJelly-Projekt. Wir haben nicht mit Theorie begonnen. Wir begannen mit einem Experiment, das ehrlich gesagt ziemlich frustrierend war: Warum wurde das Ergebnis schlechter, als wir dem LLM mehr Freiheit bei der Generierung der UI gaben?

01 · Hintergrund

Warum GenUI ernsthafte Aufmerksamkeit verdient

Bevor wir ins Detail gehen, lohnt es sich, klar zu machen, warum GenUI ein ernsthaftes Engineering-Problem ist und nicht nur ein Demo-Trick. In Generative Interfaces for Language Models verglich das SALT-NLP-/Stanford-Team die Nutzerpräferenzen zwischen GenUI und traditionellem textbasiertem Chat. Die Erkenntnis ist klar: Wenn ein KI-System strukturierte, informationsdichte Inhalte vermitteln muss, kann eine dynamisch generierte Oberfläche weit besser sein als eine Textwand.

Die GenUI-Welle beschleunigte sich zwischen 2023 und 2025, weil zwei Bedingungen gleichzeitig reiften: LLMs wurden deutlich besser in der Codegenerierung, und Komponenten-Ökosysteme wie shadcn/ui und Radix wurden stabil genug, um darauf aufzubauen. Sobald diese Bedingungen gegeben waren, entstanden ganz natürlich Tools — Vercel v0 ist eine der repräsentativsten industriellen Umsetzungen.

02 · Der Ausgangspunkt

Wir ließen das LLM frei improvisieren, und das Ergebnis wurde schlechter

Auf dem Branch feat/genui-real-content-experiment führten wir eine Reihe von Vergleichen durch. Der alte Ansatz hatte ein festes Layout und einheitliche Komponenten — poliert und vorhersehbar. Der neue Ansatz machte das Layout flexibler, aber die Optik wurde unordentlich und die Komponentenstile inkonsistent.

Das widersprach unserer Intuition. Je mehr Freiheit wir dem Modell gaben, desto weniger Kontrolle hatten wir, und desto schlechter wurde die visuelle Konsistenz. Das Gen-UI-Lang-Paper macht denselben Punkt: Bittet man ein LLM um rohes HTML oder JSX, ist die Ausgabe verbose, fragil und leicht zu brechen. Das ist kein Problem der Prompt-Qualität — es bedeutet, dass wir das LLM auf eine Granularität geschoben haben, auf der es nicht seine beste Leistung bringt.

03 · Die Kernspannung

Ein struktureller Widerspruch in GenUI

Durch das Experiment identifizierten wir einen internen Widerspruch, der im Grunde auf jedes GenUI-System zutrifft.

Je mehr Freiheit das LLM hat, desto schwieriger ist visuelle Konsistenz zu garantieren. Je stärker die Einschränkungen sind, desto weniger bedeutsam wird GenUI.

Das ist eine strukturelle Spannung im Paradigma, kein Bug einer einzelnen Implementierung. Jedes GenUI-System muss irgendwo zwischen diesen beiden Kräften seinen Stand finden. Die Frage wird also sehr konkret: Wo sollte die Generierungsgrenze des LLM liegen?

04 · Das Feld

Bestehende Wahl der Granularität

Bevor wir uns auf unsere eigene Antwort festlegten, hilft ein Blick darauf, wie andere dieselbe Frage angegangen sind.

Vercel v0 — Generierung bis hinunter zum Komponentencode

v0 lässt das LLM ganz nach unten gehen und vollständigen React-Komponentencode generieren. Seine visuelle Konsistenz kommt aus dem semantischen Token-System von shadcn/ui — es lagert die Konsistenz an das Theme der Bibliothek aus. Der Preis: Die Generierungslogik wird eng an das Komponenten-Ökosystem gekoppelt, sodass ein Wechsel weg vom Stack shadcn/ui + Next.js + Vercel echte Reibung erzeugt.

Eine typische Form von Komponentencode im v0-Stil
<Card className={cn("flex flex-col",
  plan.recommended && "border-primary shadow-lg scale-105"
)}>

Der arXiv-Ansatz — eine strukturierte Zwischendarstellung

Der SALT-NLP-/Stanford-Ansatz fügt eine strukturierte Zwischendarstellung zwischen natürlicher Sprache und UI-Code ein, auf zwei Ebenen: ein übergeordneter Interaktionsfluss (ein gerichteter Graph aus Nutzerpfaden und Aufgabenphasen) und untergeordnete endliche Zustandsautomaten (Zustände und Ereignisreaktionen jeder Komponente). Die endgültige Ausgabe ist weiterhin HTML, CSS und JavaScript — die Darstellung ist eine Leitplanke, nicht das Ziel.

Gen-UI-Lang — Definition einer UI-Intent-Ebene

Gen-UI-Lang entwirft eine eigene DSL, sodass das LLM nur strukturierte Knotenbeschreibungen ausgibt. Die Knotenstruktur ist explizit, flach und konsistent — genau das, was LLMs zuverlässig generieren. Im Vergleich zur direkten HTML-Generierung berichtet es von einer Reduktion des Token-Verbrauchs um 65,3 % bei gleichzeitig verbesserter Stabilität, und es kann aus derselben Beschreibung nach HTML, React JSX oder Gradio rendern.

Eine UI-Intent-Beschreibung in Gen-UI-Lang
genui(
  row(
    text("Sales Overview"),
    btn("Load", on_load=lambda: get_graph(2001, 2002))
  ),
  chart(type="line", data="sales_q4"),
)
05 · Unsere Wahl

Stopp auf der Ebene der Produktsemantik

Alle drei Ansätze schieben das LLM nach oben, weg von der Rendering-Ebene. Sie unterscheiden sich nur darin, wo sie stoppen. Wir entschieden uns, höher zu stoppen als jeder von ihnen: auf der Ebene der Produktsemantik.

Das LLM gibt keine generischen UI-Knoten wie row oder btn aus. Es gibt Produktkonzepte aus — „Dies ist eine Aufgabenübersichtskarte, hohe Informationsdichte, gespeist aus dem heutigen Kalender.“ Welche Komponente gerendert wird und wie sie angeordnet wird, entscheidet vollständig die Komponentenbibliothek — nicht das LLM.

01Die direkte Lehre aus unserem Fehlerfall

Sobald wir die Generierungsfreiheit des LLM lockerten, wurde das visuelle Ergebnis schlechter. Je näher das LLM an die Rendering-Ebene heranrückt, desto höher werden die Kosten seiner Zufälligkeit.

02Die Analogie zu Browser-Rendering-Engines

Browser lassen Seiten-JavaScript nicht direkt Pixel kontrollieren. Sie akzeptieren eine kontrollierte DOM-Beschreibung, und die Engine entscheidet über die Pixel. Eine GenUI-Engine sollte genauso funktionieren.

03Die Zuverlässigkeit strukturierter LLM-Ausgaben

OpenAI führte 2024 Structured Outputs ein, speziell um Formatdrift zu bekämpfen. Je näher die Ausgabe an der Rendering-Ebene liegt, desto höher sind die Kosten von Formatierungsfehlern.

04Der langfristige Bedarf an einer austauschbaren Komponentenbibliothek

Stoppt man auf der Ebene der Produktsemantik, wird die Komponentenbibliothek zu einem austauschbaren Rendering-Backend — tausche morgen das Designsystem aus, ohne die semantische Ebene anzufassen.

06 · Eine unbestätigte Richtung

Zweirundige Generierung

Beim Debuggen der komplexen Komponente GenUIPager stellten wir fest, dass ein einzelner LLM-Durchlauf Schwierigkeiten hatte, Inhaltsqualität und Layoutqualität gleichzeitig zu optimieren. Das führte uns zu einer zweirundigen Architektur — als Hypothese.

Hypothese zur zweirundigen Generierung
First-round LLM:  content orchestration + page-structure decisions
                  (product semantics layer)
      ↓
Second-round LLM / component library:  concrete rendering decisions

Die Motivation ist vernünftig: Inhaltsorchestrierung und Rendering sind zwei unterschiedliche kognitive Aufgaben, und sie in einen einzigen Durchlauf zu zwingen, kann dazu führen, dass sie sich gegenseitig stören.

Aber wir müssen ehrlich sein: Das ist nur eine Hypothese, und wir haben sie nicht vollständig validiert.

Sie steht hier, weil sie auf eine Richtung hinweist, die es wert ist, erkundet zu werden — nicht weil sie eine gesicherte Schlussfolgerung ist.

07 · Die Landkarte

Eine Trade-off-Karte der Granularitätsentscheidungen

Keine Granularitätsentscheidung ist universell richtig. Sie hängt von der Toleranz des Produkts gegenüber visueller Inkonsistenz ab, von der erwarteten Lebensdauer der Komponentenbibliothek und davon, wie strukturiert der generierte Inhalt ist.

AnsatzWohin das LLM ausgibtWie Konsistenz garantiert wirdBibliothek austauschbar?Geeignete Szenarien
Vercel v0Komponentencode-EbeneSemantische Tokens von shadcn/uiNein, eng gekoppeltSchnelles Prototyping innerhalb des Vercel-Ökosystems
Gen-UI-LangAllgemeine UI-Intent-EbeneMulti-Target-RendererJa, framework-agnostischFramework-übergreifendes Prototyping, effizienzorientierte Workflows
arXiv-AnsatzHTML / CSS / JSStrukturierte Zwischendarstellung als LeitplankenKommt darauf anSzenarien mit hoher Interaktionskomplexität
AirJellyEbene der ProduktsemantikKomponentenbibliothek besitzt das Rendering vollständigJa, austauschbarAnwendungen mit hohen Anforderungen an die Konsistenz der Produkt-UI

Wenn das Produkt eine geringe Toleranz gegenüber visueller Inkonsistenz hat, sollte die Granularität höher liegen, näher an der Produktsemantik. Wenn die Komponentenbibliothek sich wahrscheinlich weiterentwickelt oder ersetzt wird, erst recht höher. Und wenn der generierte Inhalt stark strukturiert ist, eignet es sich besser, ihn auf einer höheren Ebene semantisch zu beschreiben.

Quellen

Quellen & weiterführende Literatur

Abschluss

Die Granularität ist die zentrale Designentscheidung in GenUI.

Die größte Erkenntnis ist nicht, dass wir die richtige Antwort gefunden haben. Sie ist, dass wir die Frage geklärt haben: Bei GenUI geht es nicht darum, das LLM die Benutzeroberfläche zeichnen zu lassen. Es geht darum, eine klare Aufteilung der Verantwortung zwischen dem LLM und dem Rendering-System zu gestalten.

Die Wahl der Granularität entscheidet darüber, wo diese Grenze gezogen wird – und wo die Grenze gezogen wird, entscheidet über die Wartbarkeit, die visuelle Stabilität und die Fähigkeit des Systems, sich langfristig weiterzuentwickeln.

Im Oktober 2025 veröffentlichte die W3C Design Tokens Community Group die stabile Spezifikation Design Tokens 2025.10 — ein Zeichen dafür, dass die Trennung von Semantik und Visualisierung zu einem Engineering-Standard wird. Das Granularitätsproblem in GenUI ist derselbe Trend, der sich in KI-generierten Interfaces zeigt.

Wir sind noch unterwegs. Wenn du etwas Ähnliches erkundest, würde ich mich freuen, mit dir zu sprechen.

Mehr vom AirJelly-Team →