Source: https://aiprimetech.io/de/blog/ui-open-source-ai/ Juni 14, 2026 · 8 Min. · Open Source # Ui: Eine Detailanalyse des angesagten KI-Projekts für Entwickler (2026) A Von [AI Prime Tech](https://aiprimetech.io/de/) · KI-unterstützt ## Ui: Eine Detailanalyse des angesagten KI-Projekts für Entwickler (2026) Um 2:17 Uhr morgens funktionierte das Modell einwandfrei. Das Produkt nicht. Wir hatten einen Assistenten mit abrufgestützter Generierung, der fundierte Antworten in etwa 1.8 Sekunden bei p95 lieferte, Tokens sauber streamte und ordentliche Evaluierungswerte erzielte. Doch die Benutzeroberfläche drumherum bremste das Team aus: Chatblasen waren uneinheitlich, Quellenangaben schwer zu überblicken, Ladezustände sprangen hin und her, die seitliche Einstellungsleiste störte die Tastaturnavigation, und jede „schnelle UI-Korrektur“ mündete in eine weitere Debatte über das Designsystem. Das ist das technische Problem, das shadcn-ui/ui gut löst: nicht „KI intelligenter machen“, sondern die Produktoberfläche rund um KI-Systeme leichter entwickeln, selbst verwalten und anpassen zu können. Das GitHub-Repository shadcn-ui/ui hat sich zu einem der wichtigsten Open-Source-UI-Projekte für Teams entwickelt, die moderne Webanwendungen einschließlich KI-Produkten erstellen. Es beschreibt sich selbst als „eine Sammlung ansprechend gestalteter, barrierefreier Komponenten und eine Plattform zur Verteilung von Code“, mit Unterstützung für bevorzugte Frameworks und Themen rund um base-ui, components, laravel, nextjs, radix-uiund react. Die Kernidee ist verblüffend einfach: Statt eine geschlossene Komponentenbibliothek als Abhängigkeit zu installieren und mit ihren Abstraktionen zu kämpfen, kopieren Sie den Quellcode der Komponenten in Ihr Projekt. Sie haben die Kontrolle darüber. Sie können ihn bearbeiten. Sie können löschen, was Sie nicht benötigen. Dieses Modell ist für KI-Anwendungen besonders wichtig, denn die UI ist nicht nur Dekoration. Sie ist die Steuerungsebene für Prompts, Tools, Traces, Uploads, Quellenangaben, Freigaben, Streaming-Ausgaben, Fehlerbehebung und menschliches Feedback. ## Das technische Problem: KI-Apps brauchen schnell eine produktionsreife UI Die meisten Teams, die KI-Anwendungen entwickeln, unterschätzen den Umfang der UI. Aus einer „einfachen Chat-App“ wird normalerweise: - Ein Nachrichtenverlauf mit Streaming - Bedienelemente für Prompts und Systemanweisungen - Modellauswahl zwischen GPT, Claude, Gemini, Llama, Qwen, DeepSeek, Kimi oder internen Endpunkten - Dateiupload und Parsing-Status - Anzeige der abgerufenen Quellen - Prüfung von Tool-Aufrufen - Bereiche für Evaluierung und Debugging - Authentifizierungs- und Abrechnungszustände - Freigabeabläufe mit menschlicher Prüfung - Fehlerbehandlung für Ratenbegrenzungen, Zeitüberschreitungen, Kontextüberschreitungen und Sicherheitsfilter Das Backend mag gedanklich anspruchsvoller sein, aber das Frontend muss die Unübersichtlichkeit auffangen, die Nutzer tatsächlich spüren. Traditionelle Komponentenbibliotheken helfen, verursachen aber oft andere Kosten: - Sie sind von Abstraktionen auf Paketebene abhängig, die Sie nicht ohne Weiteres ändern können. - Überschreibungen von Styles werden fragil. - Barrierefreiheit ist nur teilweise abgedeckt, sofern Sie die zugrunde liegenden Basiskomponenten nicht verstehen. - Sie liefern mehr Code aus als nötig. - Ihre App sieht zunehmend wie jede andere App aus, die dieselbe Bibliothek verwendet. shadcn-ui/ui verfolgt einen anderen Ansatz: Komponenten sind kein Laufzeitprodukt, das Sie konsumieren, sondern Quellcode, den Sie übernehmen. In der Praxis verändert das das Wartungsmodell. Wenn die Schaltflächenabstände in Ihrem KI-Prüfworkflow nicht stimmen, bearbeiten Sie components/ui/button.tsx. Wenn Ihr Befehlsmenü Kennzeichnungen für die Modelllatenz benötigt, ändern Sie es direkt. Wenn Ihre Quellenkarte Abrufbewertungen oder Dokumentabschnitte anzeigen soll, haben Sie die Kontrolle über das Markup. Das klingt unspektakulär, bis Sie jede Woche eine maßgeschneiderte KI-Benutzeroberfläche ausliefern müssen. ## Was shadcn-ui/ui tatsächlich ist Das Projekt lässt sich am besten als zwei miteinander verbundene Dinge verstehen: - Eine Komponentensammlung - Eine Plattform zur Codeverteilung Die Komponentensammlung bietet wiederverwendbare UI-Bausteine: Schaltflächen, Dialoge, Karten, Eingabefelder, Tabellen, Menüs, Seitenpanels, Formulare, Befehlspaletten und ähnliche Grundelemente, die in modernen Webanwendungen vorkommen. Das Verteilungsmodell macht sie ungewöhnlich. Statt so vorzugehen: ``` npm install some-ui-library ``` und Komponenten mit undurchsichtiger Implementierung aus node_moduleszu importieren, fügt ein typischer shadcn/ui Workflow die Quelldateien der Komponenten Ihrer Anwendung hinzu: ``` npx shadcn@latest init npx shadcn@latest add button card dialog input textarea ``` Anschließend importieren Sie aus Ihrem lokalen Projekt: ``` import { Button } from "@/components/ui/button" import { Card, CardContent, CardHeader, CardTitle, } from "@/components/ui/card" ``` Der Unterschied ist architektonischer, nicht kosmetischer Natur. Die Komponente wird Teil Ihrer Codebasis. Sie können sie untersuchen, refaktorieren, an Ihre Design-Tokens anpassen oder in die Konventionen Ihres Frameworks einbinden. Das Ökosystem des Projekts hat häufig Berührungspunkte mit React, Next.js, Radix UI, Hilfsklassen im Stil von Tailwind CSS und Framework-Integrationen. Zu den Repository-Themen gehört auch Laravel, was den umfassenderen Anspruch widerspiegelt: Es geht nicht nur um eine Sammlung von React-Komponenten, sondern um einen Ansatz zur Codeverteilung für wiederverwendbare UI über verschiedene Anwendungs-Stacks hinweg. ## Architektur: Komponenten im eigenen Quellcode statt Laufzeitabstraktion Am klarsten lässt sich die Architektur erklären, indem man die Grenzen der Verantwortlichkeit vergleicht. | Ansatz | Speicherort der Komponenten | Anpassungsmodell | Aktualisierungsmodell | Am besten geeignet für | Traditionelles UI-Paket | node_modules | Props, Themes, Überschreibungen | Paketaktualisierung | Standardisierte Anwendungen mit begrenzten Anpassungen | Headless-Grundelemente | node_modules plus Anwendungs-Markup | Verhalten selbst zusammenstellen | Paketaktualisierung | Teams mit fundierter Frontend-Expertise | shadcn/ui Stil | Ihr Quellcodebaum | Komponentencode direkt bearbeiten | Erneut hinzufügen, Unterschiede vergleichen oder manuell aktualisieren | Produktteams, die Geschwindigkeit und Kontrolle benötigen | Vollständig individuelles Designsystem | Ihr Quellcodebaum/Ihre Pakete | Vollständige Kontrolle und Verantwortung | Interner Prozess | Große Organisationen mit Designsystem-Teams shadcn-ui/ui liegt zwischen einer Komponentenbibliothek und einem Starterkit für ein Designsystem. Sie erhalten funktionsfähige Komponenten, ohne dass der Anspruch besteht, diese Komponenten müssten unverändert bleiben. Ein gängiger Stack sieht so aus: ``` app/ chat/ page.tsx components/ ai/ model-picker.tsx message-list.tsx citation-card.tsx tool-call-panel.tsx ui/ button.tsx card.tsx dialog.tsx input.tsx sheet.tsx textarea.tsx lib/ ai/ stream.ts models.ts retrieval.ts ``` Die entscheidende Grenze ist components/ui. Das sind generische Grundelemente. Ihre KI-spezifischen Oberflächen liegen darüber in components/ai. Eine bewährte Regel für die Praxis: - components/ui: generisch, wiederverwendbar, unspektakulär - components/ai: produktspezifische KI-Interaktionsmuster - lib/ai: Modellrouting, Streaming, Retrieval, Tool-Ausführung - app/: Framework-Routing, Server-Aktionen, Seitenkomposition So verhindern Sie, dass die UI-Grundelemente zu einem Sammelbecken für modellspezifisches Verhalten werden. ## Ein realistischer Workflow: Eine Konsole zur Prüfung von KI-Ergebnissen entwickeln Angenommen, Sie entwickeln eine interne Konsole zur Prüfung von KI-Ergebnissen für Supporttickets. Das Backend durchsucht frühere Tickets per Retrieval und erstellt Antwortvorschläge mit einem Modell wie GPT-5.5, Claude Sonnet 4.6, Gemini 3 oder einem Endpunkt für ein offenes Modell. Das Frontend muss Folgendes anzeigen: - Das Kundenticket - Den generierten Entwurf - Die abgerufenen Belege - Eine Konfidenzanzeige - Eine Aktion zur Freigabe durch einen Menschen - Eine Modellauswahl zur Fehlersuche Fügen Sie zunächst die zentralen UI-Komponenten hinzu: ``` npx shadcn@latest init npx shadcn@latest add button card badge textarea select separator skeleton ``` Definieren Sie anschließend Ihre Modellkonfiguration explizit. Verstecken Sie diese nicht in UI-Beschriftungen. ``` // lib/ai/models.ts export type ModelId = | "gpt-5.5" | "claude-sonnet-4.6" | "gemini-3" | "qwen" | "deepseek" export const models: Array<{ id: ModelId label: string contextHint: string }> = [ { id: "gpt-5.5", label: "GPT-5.5", contextHint: "General reasoning and agentic workflows", }, { id: "claude-sonnet-4.6", label: "Claude Sonnet 4.6", contextHint: "Long-form drafting and coding workflows", }, { id: "gemini-3", label: "Gemini 3", contextHint: "Multimodal and general assistant tasks", }, { id: "qwen", label: "Qwen", contextHint: "Open-model route", }, { id: "deepseek", label: "DeepSeek", contextHint: "Open-model route", }, ] ``` Stellen Sie nun das Prüfungspanel aus lokalen UI-Komponenten zusammen: ``` import { Badge } from "@/components/ui/badge" import { Button } from "@/components/ui/button" import { Card, CardContent, CardHeader, CardTitle, } from "@/components/ui/card" import { Textarea } from "@/components/ui/textarea" type Evidence = { title: string snippet: string score?: number } export function TicketReviewCard({ ticket, draft, evidence, isStreaming, }: { ticket: string draft: string evidence: Evidence[] isStreaming: boolean }) { return ( AI Draft Review
Customer ticket

{ticket}

{isStreaming ? "Generating" : "Draft ready"}