Generatives UI-Design: Das praktische Handbuch für 2026

Der Bildschirm, den Sie 2026 ausliefern, existiert möglicherweise erst, wenn der Nutzer ihn anfordert. Das ist die Grundidee von generativen Benutzeroberflächen (GUIs) und verändert das Wesen von Design grundlegend.

Dieses Dokument ist ein praktisches Handbuch für GUIs. Es definiert den Begriff, benennt die vier in der Produktion eingesetzten Architekturen, stellt ein Mustervokabular bereit, benennt die häufigsten Fehlerquellen und beschreibt die neue Stellenbeschreibung für Designer, die relevant bleiben wollen. Es ist bewusst meinungsstark.

Der Hype hat genug Anbieterseiten hervorgebracht. Was Designer jetzt brauchen, sind Prinzipien, die auch nach der nächsten Modellversion Bestand haben.

Was generative Benutzeroberflächen eigentlich sind

Generative Benutzeroberflächen erstellen sich zur Laufzeit selbstständig anhand der Nutzerabsicht. Das System verfügt über ein Vokabular an Grundelementen, ein Modell, das deren Zusammensetzung bestimmt, und einen Vertrag, der festlegt, welche Zusammensetzungen zulässig sind. Der Nutzer tippt, spricht oder klickt. Die Benutzeroberfläche entsteht.

Das Gegenteil von generativem UI ist das Design, das wir seit zwei Jahrzehnten verwenden: Jeder Bildschirm ist ein statisches Artefakt, das im Voraus erstellt und als fester Ablauf ausgeliefert wird. Generatives UI ersetzt keine statischen Bildschirme. Es deckt den Bereich ab, in dem Nutzer eine bestimmte Antwort und nur wenig Interaktivität erwarten. Der langweilige Mittelteil der meisten Produkte, wo Nutzer eine spezifische Antwort und ein wenig Interaktivität wünschen, wird zu einer generierten Oberfläche anstatt zu einem Pfad in Ihrer Sitemap.

Ein hilfreicher Test: Wenn dieselbe Frage von zwei Nutzern sinnvollerweise zwei unterschiedliche Layouts rechtfertigen könnte, ist diese Oberfläche ein Kandidat für generatives UI. Wenn die Antwort immer eine nach Datum sortierte Liste von Bestellungen ist, ist sie es nicht.

Warum dies erst 2026 und nicht 2022 geschieht

Drei Dinge mussten gleichzeitig erfüllt sein: Modelle mussten so gut strukturierte Ausgaben erzeugen, dass sie Tools aufrufen und gültige Komponentenstrukturen anstelle von Absätzen ausgeben konnten. Frameworks mussten eine Möglichkeit bieten, diese Strukturen in eine laufende Anwendung zu streamen. Komponentenbibliotheken mussten sich zu Vokabularen entwickeln, mit denen ein Modell tatsächlich arbeiten konnte.

Bis Anfang 2026 sind alle drei Technologien Realität. Version 0 integriert Komponenten in Ihre Codebasis, die bereits mit shadcn und Ihren Tokens kompatibel sind. Mit dem AI SDK (Brand2) können Sie Komponenten (Brand5) von einem Server streamen, sobald das Modell sie generiert. Artifacts (Brand8) rendert ein eigenständiges interaktives Programm innerhalb eines Chat-Beitrags.

Canvas (Brand11) behandelt das Dokument und die zugehörige Benutzeroberfläche als eine einzige bearbeitbare Fläche. Bolt und Same.new erzeugen lauffähige Anwendungen aus einer Eingabeaufforderung. Tools von (Brand6) und der Composer von Cursor ermöglichen es Agenten, auf strukturierte Systeme zuzugreifen und Schnittstellen für diese zu generieren.

Keines dieser Produkte ist identisch. Sie belegen, dass die Grundlage endlich existiert und die Diskussion um generative Benutzeroberflächen sich nun nicht mehr mit der Frage nach deren Funktionsfähigkeit, sondern mit der Frage nach der optimalen Entwicklung befassen kann.

Die vier Architekturen im Produktiveinsatz

Die meisten generativen Benutzeroberflächen im Produktiveinsatz lassen sich in vier Kategorien einteilen. Treffen Sie Ihre Wahl bewusst, denn sie schränkt Ihr Designsystem, Ihre Evaluierungen und Ihr Latenzbudget ein.

1. LLM-gerenderte Komponenten. Das Modell wählt aus einem festen Komponentenvokabular Ihrer Codebasis aus und erzeugt einen typisierten Baum. Das Vercel AI SDK-Muster. Vorhersagbar, markenkonform, einfach zu evaluieren, begrenzt durch den Umfang Ihrer Bibliothek.

2. Strukturierte Tool-Aufrufe. Das Modell ruft ein Tool auf, das strukturierte Daten zurückgibt, die dann von einem statischen Layout gerendert werden. Die meisten Chat-Produktfunktionen funktionieren so: mit einer festen Oberfläche und dynamischen Inhalten. Kostengünstig, sicher, aber in der Flexibilität eingeschränkt.

3. Codegenerierung auf Abruf. Das Modell generiert Code für die Benutzeroberfläche, beispielsweise mit Mustern wie Claude Artifacts, v0, Bolt, Same.new und ChatGPT Canvas im Code-Modus. Maximale Reichweite, maximales Risiko, am schwierigsten markenkonform und zugänglich zu halten.

4. Hybride. Die interessanteste Kategorie, in der die meisten anspruchsvollen Produkte landen. Eine bewährte statische Benutzeroberfläche, ein Vokabular aus LLM-gerenderten Komponenten für den dynamischen Bereich und eine Code-Generierung als Ausweg für seltene Sonderfälle.

Wenn Sie nicht wissen, welche Architektur Sie verwenden, verwenden Sie die falsche.

So wählen Sie die richtige Architektur

Drei Fragen entscheiden über die Architektur.

| Frage | LLM-gerendert | Tool-Aufrufe | Code-Generierung | Hybrid |

|---|---|---|---|---|

| Ist Markenkonsistenz entscheidend? | Stark | Sehr stark | Schwach | Stark |

| Benötigt die Oberfläche neue Layouts? | Manchmal | Fast nie | Ja | Ja |

| Können Sie eine Generierungsverzögerung von wenigen Sekunden tolerieren? | Nein | Nein | Oft ja | Gemischt |

| Was ist zuerst fehleranfällig? | Kompositionsfehler | Falscher Inhalt | Fehlerhafter Code | Bereichsfehler |

LLM-gerenderte Komponenten sind für die meisten Teams die richtige Standardlösung. Codegenerierung ist sinnvoll, wenn die Oberfläche wirklich einmalig ist, wie z. B. eine benutzerdefinierte Analyse oder ein schnell erstellter Prototyp, und der Benutzer versteht, dass er einen Entwurf sieht. Tool-Aufrufe eignen sich für Fälle, in denen das Layout feststeht und nur die Daten dynamisch sind. Hybride Lösungen sind das Ergebnis nach zwölf Monaten Produktivbetrieb.

Die Mustersprache: Was Designer tatsächlich entwerfen

Generative Benutzeroberflächen ersetzen nicht die Designarbeit. Sie verlagern sie. Das Ergebnis ist ein Vokabular, kein Bildschirm.

Ein funktionierendes Vokabular besteht aus fünf Ebenen.

1. Primitive. Die atomaren Komponenten, die das Modell verwenden darf. Karte, Tabelle, Diagramm, Formular, Liste, Bild, Sprechblase, Codeblock. Jede benötigt typisierte Eigenschaften, die das Modell erfüllen kann.

2. Intent-Slots. Benannte Bereiche, die das Modell basierend auf der Benutzerabsicht füllt. „Zusammenfassung“, „Beweise“, „Maßnahme“, „Folgemaßnahmen“. Slots schränken die Komposition ein, ohne sie zu fixieren.

3. Fallback-Zustände. Jedes primitive Element benötigt einen eleganten leeren, ladenden, teilweisen und abgelehnten Zustand. Das Modell erzeugt alle vier Zustände ständig. Gestalten Sie sie als erstklassige Artefakte.

4. Wiederherstellungsmöglichkeiten. Direktes Bearbeiten, Regenerieren, „Zeig mir eine andere Version“, Rückgängig. Generative Schnittstellen sind wie Dialoge, und Dialoge brauchen eine Zurück-Funktion.

5. Zitierung und Quellcode-UI. Woher die Daten stammen, wann sie abgerufen wurden und wie zuverlässig das System ist. Ohne diese Informationen wirkt eine generative Benutzeroberfläche wie ein selbstsicherer Lügner. Mit ihnen wirkt dieselbe Ausgabe ehrlich.

Wenn ein Designer nicht erklären kann, was jede Ebene des Vokabulars in seinem Produkt beinhaltet, existiert das Vokabular noch nicht, und das Modell spekuliert nur öffentlich.

Intent Slots in der Praxis

Die meisten Teams überspringen die Intent Slots und bereuen es später. Betrachten Sie sie als die neuen Wireframes.

Ein Slot ist ein benannter, typisierter Bereich mit Regeln, was dort platziert werden kann. „Primäre Antwort“ akzeptiert beispielsweise eine Callout-Nachricht, eine Tabelle oder ein Diagramm, aber niemals ein Formular. „Vorgeschlagener nächster Schritt“ akzeptiert beispielsweise einen Button oder eine Karte mit einem Call-to-Action (CTA), aber niemals einen langen Absatz.

Das Modell wird in seiner Systemabfrage über die Slots informiert, genauso wie Sie einen Junior-Designer briefen würden. Das Frontend rendert die Slots in einem stabilen Layout-Raster, sodass die Oberfläche wie ein einheitliches Produkt wirkt, selbst wenn sich der Inhalt ständig ändert.

Das Ergebnis wirkt wie eine gestaltete Benutzeroberfläche, die sich zufällig anpasst, anstatt wie ein generiertes Durcheinander, das zufällig gerendert wird. Dieser Unterschied ist entscheidend.

Fehlerquellen und wie Sie diese vermeiden

Generative Benutzeroberflächen weisen spezifische, wiederholbare Fehler auf. Benennen Sie diese jetzt oder entdecken Sie sie in der Produktion wieder.

• Halluzinierte Benutzeroberfläche. Das Modell erfindet einen funktionslosen Button, einen leeren Tab oder eine willkürliche Zahlentabelle. Dem können Sie mit strengen Komponentenverträgen, serverseitiger Validierung jedes generierten Baums und deaktivierten Zuständen für alle Steuerelemente entgegenwirken, deren Handler nicht konfiguriert ist.

• Latenzangst. Der Benutzer starrt auf einen Ladekreis, während das Modell berechnet. Streamen Sie Teilergebnisse, reservieren Sie Layoutplatz vor dem eigentlichen Inhalt und zeigen Sie die Absicht des Modells („Erstellung einer Vergleichstabelle“) an, bevor die Daten geladen werden.

• Unendliche Canvas-Falle. Code-Generierungsoberflächen wirken grenzenlos und sind letztendlich unbrauchbar. Begrenzen Sie den Canvas. Zeigen Sie dem Benutzer im Voraus, welche Ausgaben möglich sind. Ein Raster mit Startvorschlägen ist immer besser als ein leeres Textfeld.

• Einseitige Modellbindung. Ein auf die Eigenheiten eines Anbieters abgestimmtes Vokabular funktioniert nicht mehr, sobald Sie das Modell wechseln. Schreiben Sie Komponentenverträge, die jedes vernünftige Modell erfüllen kann, und führen Sie Ihre Evaluierungen mit mindestens zwei Anbietern durch, bevor Sie das Produkt veröffentlichen.

– Konversationsamnesie. Die Benutzeroberfläche vergisst, was sie gerade generiert hat. Speichern Sie generierte Artefakte als eigenständige Objekte, die Benutzer benennen, speichern, teilen und wieder aufrufen können. ChatGPT Canvas hat dies richtig gemacht. Die meisten reinen Chat-Produkte machen es falsch.

Die Teams, die nachhaltige generative Benutzeroberflächen entwickeln, behandeln diese Probleme von Anfang an als Architekturprobleme und nicht als Fehler, die in der Qualitätssicherung behoben werden müssen.

Wie man eine generative Benutzeroberfläche evaluiert

Sie können eine generative Benutzeroberfläche nicht wie eine statische Seite überprüfen. Die Ausgabe ist kein einzelnes Artefakt, sondern eine Verteilung.

Eine funktionierende Evaluierung besteht aus drei Ebenen. Die erste Ebene ist eine deterministische Rubrik, die als Code auf jeden generierten Baum angewendet wird: Wurden im Modell nur zulässige Komponenten verwendet? Entsprachen die Intent-Slots? Wurde ein Zitat eingefügt, wenn das Schema dies erfordert? Wurde ein Steuerelement ohne zugehörigen Handler ausgeführt?

Diese Prüfungen sind entweder bestanden oder fehlgeschlagen. Sie werden bei jeder Änderung an der Eingabeaufforderung, den Komponenten oder dem Modell ausgeführt. Bei einem Fehler wird die Darstellung der Oberfläche verweigert und ein sicherer Zustand wiederhergestellt. Behandeln Sie diese Prüfungen wie Integrationstests im Backend-Bereich – mit der gleichen Blockierungswirkung beim Deployment.

Die zweite Ebene ist eine stichprobenartige menschliche Überprüfung. Ein kleines Gremium, idealerweise bestehend aus einem Markendesigner und einem Fachexperten, bewertet wöchentlich zehn bis zwanzig generierte Ausgaben anhand einer Fünf-Punkte-Rubrik hinsichtlich Tonalität, Markenkonformität und Nützlichkeit.

Verfolgen Sie die Bewertung im Zeitverlauf. Sinkt die Bewertung, liegt eine Regression vor. Steigt sie, hat eine Änderung funktioniert – und Sie müssen wissen, welche.

Die dritte Ebene ist Feedback direkt im Produkt. Jede generierte Oberfläche wird mit einer positiven und negativen Bewertung sowie einem Freitextkommentar ausgeliefert. Leiten Sie dieses Feedback an das Team weiter, das für die jeweilige Sprache verantwortlich ist, und nicht an einen allgemeinen Feedback-Posteingang, wo es untergeht. Erfolgreiche generative UI-Produkte zeichnen sich dadurch aus, dass die Verantwortlichen in den ersten drei Monaten jeden Kommentar lesen.

So planen Sie ein Projekt für eine generative Benutzeroberfläche

Die meisten Projekte für generative Benutzeroberflächen scheitern in der Planungsphase, nicht in der Umsetzungsphase. Teams wählen eine Oberfläche, die zu wichtig, zu stark reglementiert oder zu komplex ist, und sechs Wochen später heißt es dann: „KI ist noch nicht ausgereift.“

Die ideale erste Oberfläche zeichnet sich durch drei Merkmale aus: Der Nutzer profitiert eindeutig von einer personalisierten Antwort, die statische Ausweichlösung ist akzeptabel, falls die Generierung fehlschlägt, und eine falsche Antwort lässt sich korrigieren, anstatt katastrophale Folgen zu haben.

Interne Dashboards erfüllen alle drei Kriterien. Antworten im Hilfecenter erfüllen alle drei Kriterien. Personalisierte Analysezusammenfassungen erfüllen alle drei Kriterien. Kontoerstellung, Zahlungsautorisierung und medizinische Beratung erfüllen keines davon.

Konzipieren Sie die Arbeit als Vokabular-Release, nicht als Feature-Release. Das Ergebnis ist nicht „Das generierte Dashboard wird im 3. Quartal veröffentlicht“, sondern „Das v1-Vokabular, die v1-Evaluierungssuite und die v1-generierte Oberfläche werden gemeinsam im 3. Quartal veröffentlicht. Jede v2-generierte Oberfläche in jedem Produkt verwendet danach dasselbe Vokabular.“ Betrachten Sie das Vokabular als Plattforminvestition. Nur so lässt sich der Aufwand für das Designsystem rechtfertigen, der tatsächlich erforderlich ist.

Die neue Aufgabe des Designers: Vokabulare, Evaluierungen und Intention

Generative UI verändert die Stellenbeschreibung des Designers stärker als jede andere Veränderung seit Responsive Design.

Die Arbeitseinheit verschiebt sich von Bildschirmen zu Systemen. Designer zeichnen nicht mehr jeden Zustand einzeln, sondern kuratieren die Grundelemente, Slots und Fallbacks, aus denen sich das Modell zusammensetzt. Die Figma-Datei dient als Referenz für das Vokabular, nicht mehr als Ziel der Arbeit.

Spezifikationen werden zu Evaluierungen. Eine generative Oberfläche kann nicht anhand eines einzelnen Mockups getestet werden, da dieselbe Eingabeaufforderung viele gültige Ergebnisse liefert.

Designer erstellen daher Bewertungskriterien: „Das Ergebnis muss ein Zitat enthalten, die Markenpalette verwenden, eine Folgeaktion vorschlagen und darf niemals ein Konkurrenzprodukt empfehlen.“ Diese Kriterien werden bei jeder Modellversion automatisiert ausgewertet. Die Designqualität wird messbar.

Die Dokumentation wird zu Eingabeaufforderungen. Die Systemeingabeaufforderung, die beschreibt, wie das Modell Ihr Vokabular zusammensetzen soll, ist nun ein Designartefakt. Sie wird versioniert, geprüft und ist in vielen Produkten der wichtigste Teil des Designtextes, den das Team verfasst.

So sieht gutes Design in ausgelieferten Produkten aus

Einige Beispiele zur Veranschaulichung der Prinzipien, nicht als Empfehlung.

Das generative UI-Primitiv des Vercel AI SDK behandelt Komponenten als typisiertes Vokabular, das das Modell in einen serverseitig gerenderten Pfad einspeist. Der Vorteil: Markenkonsistenz und Vorhersagbarkeit. Die Kosten werden durch die von Ihnen entwickelte Bibliothek begrenzt.

Claude Artifacts demonstriert die bedarfsgesteuerte Codegenerierung innerhalb eines Chatverlaufs mit Persistenz und direkter Bearbeitung. Es zeichnet sich durch hohe Wiederherstellbarkeit und das Artefakt-als-Objekt-Muster aus. Es ist offenkundig, dass es sich um eine Entwurfsoberfläche und nicht um ein fertiges Produkt handelt.

ChatGPT Canvas ist ein Hybrid. Die Konversation liefert die Intention, die Canvas stellt ein stabiles, bearbeitbares Artefakt bereit, und das Modell kann entweder Text oder Code darin generieren. Die Erkenntnis ist, dass das Anheften generierter Inhalte an eine persistente Canvas die kognitiven Kosten der Arbeit mit einem Modell erheblich senkt.

v0 und Bolt sind für die Übergabe in die Produktion optimierte Codegenerierung. Sie beweisen, dass Fehler beherrschbar sind, wenn die Ausgabe an einen Entwickler zur Überprüfung übergeben wird, und nicht mehr tragbar sind, wenn die Ausgabe direkt einem Endbenutzer angezeigt wird.

Same.new zeigt, was passiert, wenn man die gesamte Anwendung als generiertes Artefakt behandelt. Nützlich für Prototyping, gefährlich für alles, was Last trägt. Tools von Anthropic und Cursors Composer deuten auf den nächsten Schritt hin, in dem Agenten die generierte Benutzeroberfläche in strukturierte Backends einbinden.

Das Muster ist bei allen gleich: Je generativer die Kernoberfläche, desto mehr müssen die umgebenden Funktionen leisten und desto stärker trägt das Designsystem die Verantwortung für Marke, Barrierefreiheit und Vertrauen. Generative Benutzeroberfläche ist nie nur das Modell selbst. Sie ist das Modell plus die vom Team dafür entwickelten Strukturen.

So starten Sie in diesem Quartal

Konkrete Schritte in der richtigen Reihenfolge, die jedes Produktteam sofort umsetzen kann.

1. Wählen Sie eine Oberfläche. Eine einzelne Funktion, bei der Nutzern aktuell eine statische Seite angezeigt wird, die idealerweise dynamisch sein sollte. Berichte, Dashboards, Empfehlungen und Zusammenfassungen eignen sich gut. Überspringen Sie den Checkout, die Authentifizierung und alle regulierten Prozesse.

2. Erfassen Sie das Vokabular. Listen Sie alle primitiven Komponenten Ihres Designsystems auf, die typisierte Eigenschaften (Props) und einen getesteten Zustand (leer/Laden/Fehler) besitzen. Falls die Liste weniger als zehn Einträge enthält, beheben Sie dies, bevor Sie etwas generieren.

3. Definieren Sie drei Intent-Slots. Das einfachste praktikable Layout ist „Antwort, Nachweis, nächster Schritt“. Verwenden Sie dieses Layout, bis Sie einen Grund finden, es nicht mehr zu verwenden.

4. Schreiben Sie eine Systemabfrage, die das Vokabular benennt. Keine Vibes. Komponentennamen, Eigenschaftentypen, Slot-Regeln und explizite Einschränkungen, was das Modell nicht erzeugen darf.

5. Erstellen Sie Evaluierungen, bevor Sie die Funktion erstellen. Fünf bis zehn Testabfragen mit jeweils einer Bewertungsmatrix. Führen Sie diese bei jeder Änderung an der Abfrage, den Komponenten oder dem Modell aus.

6. Veröffentlichen Sie die Funktion hinter einem Flag für zehn Prozent des Traffics mit einer Feedback-Funktion auf jeder generierten Oberfläche. Lesen Sie das Feedback im ersten Monat jeden Morgen.

7. Entscheiden Sie sich für Ihr zweites Modell. Wählen Sie einen Backup-Anbieter und führen Sie dieselben Evaluierungen damit durch, bevor Sie sich auf das primäre Modell verlassen. Wenn eine Modellversion Ihre bestehende Benutzeroberfläche beeinträchtigt, benötigen Sie eine einfache Konfigurationsänderung, keine komplette Neuarchitektur.

Dies ist keine Theorie. Ein dreiköpfiges Team kann diesen Prozess in sechs Wochen durchlaufen und dabei mehr über generative Benutzeroberflächen lernen als in einem Jahr Lektüre.

Was dies für die nächsten drei Jahre bedeutet

Designer, die dies als Werkzeugzyklus betrachten, liegen falsch. Designer, die es als Kategoriewechsel sehen, sind zu früh dran.

Der statische Bildschirm wird nicht aussterben. Das Anmeldeformular der Web-App, die Einstellungsseite, der Checkout-Prozess – all das bleibt aus demselben Grund erhalten wie Autobahnen. Was sich ändert, ist der Bereich mitten in jedem Produkt, die Bereiche, in denen der Nutzer eine spezifische, gut präsentierte Antwort erwartet. Dieser Bereich wird generiert und macht den größten Teil der Oberfläche aus.

Designsysteme, die sich durchsetzen, werden diejenigen sein, die für zwei Lesergruppen geschrieben sind: Menschen und Modelle. Tokens mit eindeutigen Namen, Komponenten mit typisierten Eigenschaften, Dokumentation, die gleichzeitig als Eingabeaufforderung dient, Evaluierungen, die die Komposition so testen wie Unit-Tests die Logik. Die Teams, die bereits so arbeiten, gewinnen jedes Quartal weiter an Vorsprung. Die Teams, die immer noch pixelgenaue Figma-Dateien für Oberflächen ausliefern, aus denen ein Modell zusammengesetzt sein könnte, werden bald erfahren, wie sich die letzte Meile der Irrelevanz anfühlt.

Der tiefere Ansatz ist einfacher. Schnittstellen sind nicht länger das Ziel des Designs, sondern werden zu dessen Ergebnis. Das Handwerk des Designers entwickelt sich weiter, hin zu den Systemen, Rubriken und Vokabularen, die Schnittstellen erzeugen. Die Arbeit wird anspruchsvoller, die Auswirkungen größer, und die Designer, die das jetzt lernen, werden bis 2029 führend sein.

Das ist die Aufgabe. Wählen Sie diese Woche eine Oberfläche, liefern Sie ein Vokabular, schreiben Sie die Evaluierungen und legen Sie los.

hero: key: hero prompt: "Voxel illustration, isometric, soft pastel palette aligned with Brainy ink/paper aesthetic. Composition: a building made of components assembling itself in mid-air, with floating UI fragments (cards, charts, forms) snapping into a layout grid below. Editorial, calm, precise. The composition does not include any human figures." alt: "Voxel building made of UI components assembling itself mid-air" width: 1600 height: 900 inline-1: key: gen-ui-architectures prompt: "Voxel illustration showing four distinct architectures as four floating panels arranged in a 2x2 grid: LLM-rendered components, structured tool calls, code-gen-on-demand, and a hybrid panel showing parts of all three. Soft pastel palette. The composition does not include any human figures." alt: "Four floating voxel panels showing the four generative UI architectures" width: 1400 height: 900 inline-2: key: pattern-vocabulary prompt: "Voxel grid of UI primitives like card, table, chart, form, list, arranged neatly with subtle arrows showing how an LLM picks among them. Soft pastel palette, editorial. The composition does not include any human figures." alt: "Voxel grid of UI primitives with arrows showing model selection" width: 1400 height: 900 inline-3: key: failure-modes prompt: "Voxel illustration of broken or glitching UI: hallucinated buttons floating with no labels, a loading spinner stretched into infinity, an infinite scroll collapsing into a tangle. Soft pastel palette with a hint of chaos. The composition does not include any human figures." alt: "Voxel scene of broken generative UI with hallucinated and stuck states" width: 1400 height: 900 inline-4: key: how-to-start prompt: "Voxel illustration of a designer's desk: a small library of labeled components on a shelf, an eval rubric printed on a tablet, and a model card pinned to a board. Soft pastel palette, calm and methodical. The composition does not include any human figures." alt: "Voxel desk with component library, eval rubric, and model card" width: 1400 height: 900