Kategorie: Erklärer

Ein Entwickler sitzt an seinem Arbeitsplatz und tippt eine Freitextabfrage in ein Chatfeld: „Plan mir ein Wochenende in Porto, das wetterfest ist.“ Der Bildschirm zeigt keinen klassischen Antworttext, sondern eine neu zusammengesetzte Seite: eine Überschrift, ein Wetter-Widget, eine Tagesplanung und eine Packliste – alles in einem sauberen Dashboard-Arrangement, das der Entwickler nie manuell designt hat. Er klickt kurz durch die Elemente, überprüft die Daten und nickt. Die Oberfläche ist zur Laufzeit aus einer KI-Abfrage entstanden – ein Beispiel für Generative UI.

In einem Tech-Talk bei Pixelmatters im Juli 2026 hat sich ein Entwickler und Designer genau dieser Frage gewidmet: Wie verändert Generative UI die Art, wie wir Software bauen und nutzen? Seine Präsentation trägt den Titel „Eliminating the Wall of Text“ und zeigt anhand praktischer Demos, wie KI-generierte Schnittstellen die klassische Chat-Antwort – diesen endlosen Textblock – durch dynamische, interaktive Elemente ersetzen. Er betont dabei, dass es nicht nur um das Design einzelner Widgets geht, sondern um eine grundlegende Verschiebung: Die Benutzeroberfläche wird nicht mehr statisch im Voraus definiert, sondern entsteht im Moment, basierend auf dem, was der Nutzer wirklich will. Das klingt futuristisch, doch die Bausteine dafür existieren bereits.

Drei Domänen der Generativen UI: vom Design-Tool bis zur Laufzeit

Wenn von „Generative UI“ die Rede ist, schwingt schnell die einfache Formel mit: „KI erzeugt eine Benutzeroberfläche.“ Doch diese Definition greift zu kurz, wie er in seinem Vortrag klarstellt. Er unterscheidet drei klar getrennte Einsatzgebiete. Erstens: die KI-gestützte Generierung von UI-Designs in Tools wie Figma oder Claude Design – hier entstehen statische Layouts, die dann von Menschen weiterverarbeitet werden. Zweitens: die Erzeugung von Web-Code über Chatbots wie ChatGPT, die komplette Apps ausspielen, und drittens: die dynamische, serverbasierte Generierung von Interfaces zur Laufzeit, also genau das, was in den Demos gezeigt wird.

Der Fokus des Vortrags liegt auf der dritten Kategorie – der Schnittstelle zwischen Server und Interface. Er erinnert daran, dass heutige Large Language Models noch zu groß sind, um direkt im Browser zu laufen; erst wenn das in Zukunft auf Geräten möglich ist, werde sich eine ganz neue Ära auftun. Bis dahin bleibt die Architektur zentral: Der Server berechnet, was der Nutzer braucht, und schickt strukturierte Daten an den Client, der sie in UI-Elemente übersetzt. Diese Trennung ist essenziell, um Sicherheit und Performance zu gewährleisten.

Die Textwand fällt: Wie Generative UI User-Interfaces lebendig macht

Der offensichtlichste Nutzen Generativer UI liegt in der Überwindung der „Wall of Text“, die in herkömmlichen KI-Chats dominiert. Wenn du einem Chatbot eine komplexe Frage stellst – etwa nach den besten Restaurants in einer fremden Stadt oder den wichtigsten Schritten für ein Projekt – bekommst du oft eine ellenlange Antwort, die du selbst parsen musst. Die neuen Ansätze zeigen, wie das anders geht: Gemini integriert Google Maps-Karten direkt in die Chatantwort, Claude erzeugt interaktive Flashcards für Lerninhalte. Diese ephemeren UI-Elemente – Karten, Kalender, Formulare, Diagramme – werden im Moment generiert und passen sich exakt der Intention des Nutzers an. Er erklärt, dass wir zunehmend weniger „Textwände“ und mehr dynamische Oberflächen sehen werden, die direkt auf die jeweilige Anfrage zugeschnitten sind.

Das hat auch einen praktischen Vorteil: Der Nutzer muss nicht mehr zwischen Chat und anderer App wechseln. Die UI kommt direkt in den Dialog, ist sofort interaktiv und braucht keine manuelle Konfiguration. Statt eine lange Liste von Restaurants zu lesen, bekommst du eine Karte mit Markierungen, Filtern und Bewertungen – alles direkt an deine Anfrage gekoppelt. Er nennt das „Intent-basierte UI“: Die Oberfläche wird von der Absicht des Nutzers gesteuert, nicht von einem starren Layout.

Die geschäftliche Dimension: Vom Feature-Overload zur Super-App

Aber Generative UI ist mehr als nur ein nettes Gimmick für Chat-Erlebnisse. Der Autor bringt eine unternehmerische Perspektive ins Spiel: Jede erfolgreiche digitale Plattform muss eine wachsende Anzahl an Funktionen und Integrationen verwalten – von der eigenen App bis zu Drittanbieterdiensten wie Airbnb oder OpenTable. Jede neue Integration multipliziert die Komplexität der UI-Entwicklung. Wenn du also ein Produkt mit vielen Features, Integrationen und Skalierung hast, wirst du irgendwann an Ressourcen- und Zeitgrenzen stoßen – und damit deine Wettbewerbsfähigkeit verlieren. Hier sieht er einen Ausweg in der „Super-App“-Idee: eine Plattform, die alles abdeckt, um das UI-Problem zu vereinfachen. Als Beispiel führt er WeChat an, das bereits 2017 seine Mini-Programme einführte, um die riesige Nutzerbasis ohne die Notwendigkeit nativer Apps zu bedienen.

WeChat Mini-Programme bedienen heute schätzungsweise eine Milliarde Nutzer – für Shopping, Essensbestellungen, Terminbuchungen, Fahrradverleih, Flugverfolgung, Cloud-Dokumente und sogar Steuererklärungen. Er merkt an, dass dieser Ansatz in China früh notwendig war, weil die Infrastruktur- und Produktdesign-Herausforderungen mit der Skalierung zunahmen. Im Westen hingegen setzt man zunehmend auf KI-Chatbots als Einstiegspunkt: Statt QR-Codes oder App-Stores werden freie Texteingaben zur Intention. Der Schlüsselbegriff dabei ist „Intent“: Jede Anfrage erfordert eine flexibel angepasste UI, und genau hier kommt Generative UI ins Spiel. Ohne diesen Intent-basierten Einstieg, so weist er darauf hin, würden westliche Apps vermutlich in QR-Code-Scans versinken.

Die drei Kategorien der Generativen UI: Static, Declarative, Open-ended

Um das Potenzial zu strukturieren, stellt der Vortrag drei Kategorien entlang der Generationsachsen vor – also dem Maß an Freiheit, das das Modell bei der UI-Erstellung erhält. Sie sind nicht strikt getrennt, sondern können sich mischen. Die erste Kategorie nennt sich „Static/Controlled“. Hier bleibt die Kontrolle weitgehend beim Entwickler: Die App besitzt bereits eine Reihe von vordefinierten Komponenten und Layouts, und die KI liefert nur noch die Daten bzw. Auswahlparameter. Ein Beispiel: Eine Liste von Unterkünften auf einer Website wird gefiltert nach „Parks & Natur“ – das geht ohne KI per SQL. Aber wenn ein Nutzer „Zeig mir coole Cafés, die heute geöffnet sind, mit besserer Bewertung als 4,5“ eintippt, dann kann eine KI diese Anfrage verstehen und die bestehenden Karten und Filter neu zusammenstellen. Die Oberfläche bleibt dabei im Design-System, aber die Zusammenstellung ist dynamisch.

In der zweiten Kategorie, „Declarative“, geht es einen Schritt weiter. Hier beschreibt das Modell die gewünschte UI in einem strukturierten Format – meist JSON – und ein Renderer auf dem Client setzt diese in echte Komponenten um. Er zeigt eine Demo einer Reiseplanungsseite: Der Nutzer tippt „Plane ein wetterfestes Wochenende von Paris nach Porto“ und die KI erzeugt nicht nur eine Antwort, sondern eine komplette Seite mit Einführungsabsatz, Flugschätzung, Wetterwidget, Tagesplänen und Packliste – in einem Dashboard-Layout, das sie selbst gewählt hat. Diese Spezifikationen laufen über Protokolle wie A2UI und AG-UI, die eine Maschine-zu-Menschen-Kommunikation auf UI-Ebene ermöglichen. Er betont, dass solche Spezifikationen wie „Regeln“ sind, die von SDKs ausgeführt werden – also Executoren.

Die dritte Kategorie, „Open-ended“, ist die freieste: Die KI generiert direkt HTML, CSS und JavaScript, das im Browser ausgeführt wird. Das birgt jedoch erhebliche Sicherheitsrisiken. Aus diesem Grund nutzt man dafür oft sandboxed iframes oder serverbasierte Hosting-Lösungen. Er zeigt, dass dieser Ansatz durchaus für interne Dashboards oder Reporting-Tools brauchbar ist, aber für öffentlich zugängliche Apps nicht empfehlenswert. Stattdessen empfiehlt er, auf die declarative Variante zu setzen, gerade wenn man Sicherheit und Flexibilität vereinen möchte.

Praktische Umsetzung: Werkzeuge, Protokolle und die Zukunft

Wie setzt man Generative UI konkret um? Er demonstriert zwei Flows: einen static/controlled und einen declarative. Im ersten nutzt er einen agentic Backend-Framework wie Mastra, LangGraph oder ADK, kombiniert mit dem AI SDK für das Streaming von Chat-Nachrichten. Der Nutzer schickt eine Anfrage, die der Agent versteht, ruft ein Tool auf, das in der App die Daten filtert und zurückgibt, und dann rendert das Frontend basierend auf diesem Tool-Result die passende vorgefertigte Komponente – z.B. „EmptyMatch“ oder „PlaceCard“. Das ist eine sanfte Migration, weil das Design-System unverändert bleibt.

Im declarative Flow geht es weiter: Der Agent generiert eine Spezifikation in A2UI, die eine Baumstruktur von Komponenten beschreibt. Diese wird über AG-UI als Event an den Client geschickt, der sie mit einem Renderer wie CopilotKit interpretiert. CopilotKit bietet drei Pakete: Runtime für den Server, React-Core für den Browser und einen A2UI-Renderer für die Komponenten-Katalogisierung und das Rendering. Damit werden komplexe UI-Änderungen zur Laufzeit möglich, ohne dass man für jeden Fall manuell Code schreiben muss. Er fasst zusammen: „Wenn Code billig ist, delegieren Menschen die Erstellung an KI und konzentrieren sich auf höhere Anforderungen wie Spezifikationen.“ Höhere Abstraktionsebenen bedeuten mehr Flexibilität und Interoperabilität – und das könnte langfristig der entscheidende Vorteil sein.

Was bedeutet das für die Praxis? Generative UI könnte den Entwicklungsaufwand für komplexe Anwendungen deutlich reduzieren, besonders bei rapiden Prototypen oder datengetriebenen Interfaces. Statt jeden Zustand im Voraus zu definieren, reicht es, die Regeln festzulegen und die KI die Zusammenstellung übernehmen zu lassen. Das ist keine bloße Zukunftsmusik, sondern eine konkrete Erweiterung des Werkzeugkastens, die bereits jetzt verfügbar ist – auch wenn sie noch in den Kinderschuhen steckt. Die nächsten Jahre werden zeigen, ob sich die Spezifikationen wie A2UI durchsetzen und ob WeChat-ähnliche Super-Apps im Westen Fuß fassen. Sicher ist: Die Textwand wird bald genauso antiquiert wirken wie das Faxgerät.

Quelle: boda.sh

Ein Terminalfenster öffnet sich. Ein Befehl wird eingegeben. Innerhalb weniger Sekunden entsteht ein neues Feature: eine Aufgabenliste, eine grafische Oberfläche oder ein kompletter Musik-Editor. Das passiert nicht im Entwicklungs-Team, sondern auf dem Rechner eines einzelnen Nutzers – auf dessen eigenen Wunsch. Das macht bb, eine agentic IDE, die sich während der Nutzung selbst erweitert.

@_ymichael startete bb als persönliches Projekt. Inzwischen ist daraus eine Open-Source-Community-Plattform geworden, die Tausende nutzen. Der Autor des ursprünglichen Artikels war von Anfang an dabei. Er beschreibt, dass bb für ihn Funktionen bietet, die kein anderer Agent-Orchestrator zuvor geschafft hat. Warum also diese IDE? Dutzende ähnlicher Tools existieren.

Das Prinzip: Software, die sich an dich anpasst

Software war früher ein starres Produkt. Ein Team entwickelte eine Lösung für ein Problem, verkaufte sie an möglichst viele Kunden. Nutzer mussten sich mit den eingebauten Funktionen arrangieren. Diese Annahme, dass Skaleneffekte Standardlösungen effizienter machen als Eigenentwicklung, hält nicht mehr. Software wird billiger, Tools modularer, und Anwender erwarten eine Lösung, die exakt auf ihre Arbeitsweise zugeschnitten ist.

Hier setzt bb an. Die IDE bietet solide Basisfunktionen: eine klare Timeline, die alle Agenten-Aktivitäten protokolliert, und die Möglichkeit, mit verschiedenen Coding-Agenten zu arbeiten – von Codex über Claude Code bis Cursor. Du nutzt deine eigenen API-Zugänge und Abonnements, keine versteckten Kosten. Das eigentliche Alleinstellungsmerkmal ist die Erweiterbarkeit. Jeder Nutzer kann die IDE anpassen, ohne tief in interne Strukturen einzugreifen.

Von der Standardoberfläche zur persönlichen Arbeitsumgebung

Beim ersten Start zeigt bb eine fast leere Oberfläche: eine leere Leinwand mit Threads links. Diese Schlichtheit ist gewollt. Was danach kommt, hängt von den Anforderungen des Nutzers ab. Der Autor berichtet, dass er in kurzer Zeit eine eigene Benutzeroberfläche zusammenstellte – mit Linear-ähnlicher Projektansicht, eigenen Menüs und angepassten Farben. Das ist kein Spielzeug, sondern ein ernsthaftes Arbeitswerkzeug.

Wer mit herkömmlichen IDEs arbeitet, kennt das Gefühl, an den Funktionen des Herstellers zu scheitern. Man nimmt, was man bekommt, und kämpft mit Workarounds. Bei bb ist das anders: Du beschreibst, was du brauchst, und die IDE setzt es um. Eine einfache Anfrage an den Agenten genügt; er generiert den Code und integriert ihn in die bestehende Struktur. Das erinnert an Plugins – nur dass der Plugin-Entwickler wegfällt. Die IDE wird zum Handwerker, der sich selbst Werkzeuge baut.

Was die Community bereits gebaut hat: Beispiele aus der Praxis

Die Erweiterungsmöglichkeiten sind nicht nur theoretisch. Die Community nutzt bb bereits für verschiedene Funktionen. Ein Task-Management-System ist direkt in die IDE eingebettet: Du kannst Issues anlegen, filtern und an Agenten delegieren, die sie automatisch lesen und bearbeiten. Ein anderer Nutzer hat Tiling-Management entwickelt, das Threads in einer zweidimensionalen Fläche anordnet – ideal für parallele Arbeitsstränge.

Das automatisierte Code-Review-System ist beeindruckend. Eine GitHub-Webhook verbindet bb mit einem Repository, überwacht neue Pull-Requests, lädt sie herunter, lässt einen Agenten den Code prüfen und testet ihn End-to-End mit Codex und Computer-Use-Technologie. Das ist ein vollautomatischer Qualitätsprozess ohne menschliches Eingreifen. Auch für kreative Nutzer gibt es etwas: Ein Markdown-Editor mit Obsidian-ähnlicher Vault-Struktur verwaltet Notizen und Dokumente, in denen sowohl Nutzer als auch Agenten schreiben können. Der Autor verfasst den ursprünglichen Artikel sogar in diesem Editor.

Ein exotisches Beispiel ist eine digitale Audio-Workstation (DAW) in bb. Ein Nutzer erstellte eine Oberfläche, um Samples hochzuladen, und promptet Agenten, Code zu generieren, der über die Strudel-Umgebung Musik produziert. bb ist nicht auf Coding beschränkt. Jede Software, die mit Code erstellt werden kann, lässt sich prinzipiell integrieren. Die Grenze ist die eigene Vorstellungskraft.

Open Source und volle Kontrolle: Die technische Basis

bb ist ein Open-Source-Projekt unter der MIT-Lizenz. Du kannst den gesamten Quellcode einsehen, modifizieren und für eigene Zwecke nutzen – ohne Lizenzgebühren oder Einschränkungen. Die Architektur ist modular aufgebaut. Viele der standardmäßigen Funktionen wie „Ask User Question“-Tool, Side Chat, Cron-Jobs, Inline-Vorschauen und Fernzugriff sind selbst als Plugins realisiert. Das unterscheidet bb von anderen Agent-Orchestratoren, die ihre Funktionen als geschlossene Module implementieren.

Die offene Struktur verbessert die Interoperabilität. bb unterstützt alle gängigen Coding-Agenten über das Agent Client Protocol (ACP). Du kannst Codex, Claude Code, Cursor und andere Tools parallel verwenden und über eine einheitliche Oberfläche steuern. Das funktioniert mit deinen eigenen Abonnements, also ohne zusätzliche Kosten. Wenn ein Agent nicht standardmäßig unterstützt wird, schreibst du selbst eine Anbindung – die Doku ist offen, die Community hilft.

Der Autor sagt, er kann nach bb nicht mehr zu einem Tool zurückkehren, das er nicht verändern kann. Das spiegelt ein wachsendes Bedürfnis nach Souveränität in der Softwareentwicklung. Warum sollte man sich mit den Standardabläufen eines kommerziellen Produkts abfinden, wenn man in wenigen Minuten eigene Anpassungen erstellen lassen kann? Die Mühelosigkeit, mit der bb sich erweitert, setzt neue Maßstäbe für das Verhältnis zwischen Nutzer und Werkzeug.

Was das für die Zukunft von Entwicklungstools bedeutet

bb ist mehr als ein weiterer Eintrag in der Liste der KI-gestützten IDEs. Es zeigt, wie Software in Zukunft gebaut wird: nicht als fertiges Produkt, sondern als Grundgerüst, das sich durch die Anforderungen der Nutzer weiterentwickelt. Das Modell der „Self-Building Software“ könnte sich als Standard etablieren, gerade wo KI-Agenten immer leistungsfähiger werden.

Für Entwickler bedeutet das einen Paradigmenwechsel: Statt sich an vorgegebene Funktionen anzupassen, formst du die IDE zu deinem persönlichen Assistenten. Die Effizienzgewinne sind enorm, denn du sparst Zeit, die du sonst mit Workarounds oder Warten auf Feature-Updates verbringst. Es erfordert Umdenken: Du musst nicht mehr alles selbst programmieren, aber du musst wissen, was du willst. Präzise Anforderungen zu formulieren wird wichtiger als das Beherrschen bestimmter Syntaxen.

bb ist als Open-Source-Projekt verfügbar, direkt von GitHub oder über getbb.app. Wer neugierig ist, sollte einen Blick riskieren. Die Einstiegshürde ist niedrig: Du klonst das Repository, startest bb und fragst die IDE, was sie als Nächstes einbauen soll. Diese Erfahrung, ein Werkzeug zu besitzen, das sich auf Zuruf erweitert, ist schwer in Worte zu fassen – sie muss man selbst gemacht haben. Wer Wert auf individuelle, anpassbare Software legt, findet in bb mehr als nur ein Tool. Es ist eine Einladung, die Grenzen einer IDE zu testen.

Quelle: sawyerhood.com

Du hast eine Funktion mit einer gehosteten LLM-API gebaut. Sie funktioniert einwandfrei, bis die Rechnung der Finanzabteilung auf deinem Tisch landet. Sie hat sich innerhalb eines Quartals verdreifacht, weil jeder neue Nutzer zusätzliche Token verbraucht. Gleichzeitig weist dein Security-Team darauf hin, dass Kundendaten in jedem Prompt an den API-Anbieter übertragen werden. Im nächsten Standup kommt die Frage: Sollten wir nicht einfach unsere eigenen GPUs kaufen? Die intuitive Antwort „Own-Hardware ist immer günstiger“ ist meistens falsch. Denn das Selbsthosten von LLM-Inference bringt nicht nur Einsparungen, sondern auch versteckte Kosten und neue Verantwortung.

Drei Wege, ein Modell zu betreiben

Bevor wir über Kosten sprechen, müssen wir die drei Betriebsmodelle klar voneinander trennen. Die Hosted-API ist wie ein Restaurant: du bestellst ein Gericht, bekommst es serviert und zahlst pro Portion. Der Managed Deployment ist ein privater Koch, der in deiner Küche arbeitet und die Zutaten von dir bekommt. Das Self-Hosting ist die komplette eigene Küche mit eigenem Herd, Kühlschrank und Personal – du kontrollierst alles, musst aber auch alles selbst organisieren.

Bei einer Hosted-API sendest du Text an einen Anbieter wie OpenAI oder Anthropic und bekommst Text zurück; du zahlst pro Token, ohne dich um Infrastruktur zu kümmern. Der Managed Deployment läuft in deiner eigenen Cloud-Tenancy, aber der Anbieter betreibt GPUs und Serving-Software – deine Daten bleiben bei dir, aber du mietest weiterhin Rechenleistung. Beim Full Self-Hosting besitzt du die GPUs, betreibst die Serving-Engine und übernimmst jede Schicht des Stacks – maximale Kontrolle, aber auch maximale Verantwortung. Die Wahl zwischen diesen Optionen wird von vier Faktoren bestimmt: Volumen, Datenhoheit, verfügbarer Expertise und dem Zugang zu den Modellen selbst.

Die vier Kräfte, die deine Entscheidung bestimmen

Der erste Faktor ist das Datenvolumen. Wie viele Tokens verarbeitest du täglich? Unter einer Million Tokens pro Tag ist die API fast immer die günstigste Lösung – du zahlst nur für die tatsächliche Nutzung und musst keine teuren GPUs anschaffen. Der zweite Faktor ist die Datenhoheit. Wenn deine Daten gesetzlich nicht dein Netzwerk verlassen dürfen – etwa im Gesundheitswesen oder bei Finanzdiensten –, fällt die Hosted-API sofort aus. Dann ist entweder Managed Deployment oder Self-Hosting Pflicht, unabhängig von den Kosten. Der dritte Faktor sind deine Mitarbeiter: Hast du jemanden, der sich um GPUs kümmert, CUDA-Fehler nachts um 2 Uhr fixt und die Latenz überwacht? Ein einzelner MLOps-Ingenieur kostet laut Glassdoor im Schnitt 160.000 Dollar pro Jahr – mehr als die Hardware selbst. Der vierte Faktor ist der Modellzugang: Nur wenige Modelle werden als offene Gewichte veröffentlicht. Die stärksten Modelle wie GPT-5 oder Claude Opus sind Closed-Weights – sie existieren nur als API. Das bedeutet: Die beste Leistung, die du auf eigener Hardware erreichen kannst, ist die eines Open-Weight-Modells. Für Aufgaben, die die Intelligenz eines Frontier-Modells erfordern, wirst du also immer eine API brauchen, egal wie viel du selbst hostest.

Die vier Faktoren wirken in einer festen Reihenfolge. Zuerst prüfst du die Datenhoheit – ein Compliance-Verbot überschreibt jedes Kostenargument. Dann schaust du, ob du ein Ops-Team hast: Wenn nicht, bleibt nur Managed Deployment. Erst danach stellt sich die Volumenfrage: Ab etwa zwei Millionen Tokens pro Tag kann sich die eigene Hardware amortisieren. Zuletzt kommt die Modellzugangs-Beschränkung, die jeden Plan ändern kann. Diese Reihenfolge führt die meisten Unternehmen zu einem Kompromiss: einer hybriden Strategie.

Der Krossover-Punkt: Wann lohnt sich die eigene Hardware?

Zahlen helfen, das Bild zu konkretisieren. Unter einer Million Tokens pro Tag ist die API kostentechnisch klar überlegen. Zwischen einer und zwei Millionen ist es ein echtes Kopf-an-Kopf-Rennen. Ab zwei Millionen Tokens pro Tag beginnt sich der Kauf eigener GPUs zu rechnen – vorausgesetzt, deine Workloads benötigen tatsächlich Frontier-Modelle. Ein Beispiel: Wenn du 10 Millionen Tokens pro Tag durch die günstigste OpenAI-Stufe (!gpt-5.4-nano) jagst, landest du bei einer API-Rechnung von nur ein paar hundert Dollar pro Monat. Dagegen kostet eine ständig laufende, gemietete H100 mit vier Dollar pro Stunde fast 2.900 Dollar monatlich – plus Personalkosten. Der Krossover-Punkt von zwei Millionen gilt also nur für teure, hochwertige Modelle. Arbeitest du mit kleinen, schlanken Modellen, wird sich Self-Hosting womöglich nie amortisieren, weil die API so günstig bleibt.

Der Trick liegt oft in der Bündelung: Drei interne Anwendungen mit jeweils 700.000 Tokens pro Tag ergeben zusammen 2,1 Millionen – damit wird die eigene Hardware profitabel, obwohl keine einzelne Anwendung es wäre. Die Fixkosten der GPU werden über mehrere Abteilungen verteilt. Wer über die Zehn-Millionen-Marke kommt, amortisiert die Hardware in der Regel innerhalb von sechs bis zwölf Monaten. Aber Vorsicht: Diese Rechnung funktioniert nur, wenn du die genannten Kosten der Menschen und des Betriebs nicht vergisst.

Die versteckten Kosten: MLOps, Strom und Hardware

Die offensichtlichen Kosten sind die GPUs selbst – sagen wir 30.000 Dollar für einen H100 oder ein Paar RTX 3090er. Doch die eigentlichen Kostentreiber liegen woanders. Da ist der MLOps-Ingenieur, der das System wartet, denn selbst erfahrene Teams verbringen Monate damit, Serving-Engines wie vLLM zu konfigurieren und Latenzspitzen zu bekämpfen. Sein Gehalt übersteigt den Hardwarepreis um ein Vielfaches. Dazu kommen Stromkosten: Eine High-End-GPU zieht unter Last 450 bis 575 Watt – das macht etwa 50 bis 65 Euro pro Monat pro Karte, selbst wenn sie nur im Leerlauf läuft. Und ein Modell muss in den VRAM passen. Grob brauchst du 0,5 Gigabyte pro Milliarde Parameter bei 4-Bit-Quantisierung; ein 70B-Modell benötigt also 35 bis 40 Gigabyte – mehr, als eine Consumer-Karte bietet. Wenn das Modell auf die CPU ausweicht, wird die Generierung 10 bis 100 Mal langsamer, was wiederum die Antwortzeiten ruiniert.

Hinzu kommt die Frage der Serving-Kapazität. Ein einzelner Server mit vLLM kann laut Forschern rund 19-mal mehr Durchsatz als eine naive Einrichtung schaffen und hält dabei P99-Latenzen unter 100 Millisekunden bei 128 parallelen Anfragen. Das erfordert jedoch Fachkenntnis. Wer nur eine handvoll interner Nutzer bedient, kommt mit einfacheren Tools aus, aber das ist selten der Fall. Die meisten Teams unterschätzen, wie viel Engineering-Zeit in den Betrieb fließt – und diese Zeit ist das teuerste Gut im ganzen Projekt.

Die Hybrid-Strategie: das Beste aus beiden Welten

Wegen dieser Komplexität landen die erfolgreichsten Implementierungen fast immer auf einem Hybridmodell. Die Idee ist simpel: Jede Anfrage wird danach beurteilt, wie sensibel ihre Daten sind und wie viel Rechenleistung sie benötigt. Einfache, repetitive und datenkritische Aufgaben – Klassifikation, Datenextraktion, Verarbeitung von personenbezogenen Dokumenten – erledigt ein lokal gehostetes Open-Weight-Modell. Seltene, aber intellektuell anspruchsvolle Aufgaben, bei denen die Antwortqualität über Leben und Tod des Geschäfts entscheidet, gehen an eine Frontier-API. Diese Aufteilung spart Teams, die sie umgesetzt haben, 40 bis 70 Prozent der Kosten im Vergleich zu einem reinen API-Setup – manchmal sogar mehr.

Der Vorteil der Hybridstrategie ist, dass sie keine Entweder-oder-Entscheidung erzwingt. Du kannst mit der API starten, dann schrittweise eigene Hardware hinzufügen und die Verteilung im Laufe der Zeit optimieren. Die beiden Systeme ergänzen sich: Die API deckt die Spitzen ab, wenn das lokale System überlastet ist, und das lokale System schützt sensible Daten vor externen Zugriffen. So bleibt die Compliance gewahrt, ohne dass du auf die beste Modellqualität verzichten musst.

Einordnung: Wann welche Entscheidung richtig ist

Zusammengefasst ergibt sich eine klare Faustregel. Hosted APIs sind für den Einstieg ideal: Sie sind schnell implementiert, skalieren automatisch und bieten Zugang zu den stärksten Modellen. Managed Deployments sind die Lösung für regulierte Branchen, die Datenkontrolle brauchen, aber keine eigene Ops-Kompetenz aufbauen wollen. Full Self-Hosting lohnt sich nur, wenn dein Volumen konstant hoch ist – über zwei Millionen Tokens täglich – und du die Rechenleistung über mehrere Anwendungen verteilen kannst. Wenn du jedoch nur gelegentlich intelligente Textverarbeitung brauchst und keine strengen Datenschutzauflagen hast, wirst du mit einer API auch langfristig günstiger fahren.

Entscheidend ist, die Kosten nicht nur anhand der Rechnung zu beurteilen. Die Modelle werden immer besser, die API-Preise fallen tendenziell, und die eigene Hardware wird von Software-Updates überholt. Der Reiz des Selbsthostens liegt nicht im Sparen – es liegt in der Unabhängigkeit und Kontrolle. Aber Kontrolle hat ihren Preis, und der ist bei LLMs besonders hoch. Deshalb lautet die Empfehlung: Starte mit einer API, überwache deine Token-Nutzung, und wenn dein Volumen die zwei Millionen pro Tag überschreitet, prüfe die Hybridstrategie. So bleibst du flexibel und zahlst nie mehr als nötig – und du vermeidest die 2-Uhr-CUDA-Fehler, die dein Team unnötig beschäftigen würden.

Quelle: theaiengineer.substack.com

Ein KI-Chatbot schreibt fehlerfreien Code, löst Mathematik-Olympiaden und besteht Jurastudium-Examen. Doch wenn derselbe Agent deine Rechnungskontrolle automatisieren oder Kundentickets sortieren soll, braucht er nach zehn Schritten deine Hilfe. Das nennt man die „gezackte Grenze“ der KI – Fähigkeiten, die sich nicht gleichmäßig über alle Aufgaben verteilen. Während Coding-Agenten wie Claude Code oder Codex inzwischen echte Arbeit ohne menschliche Aufsicht erledigen, hinkt die Enterprise-Welt deutlich hinterher. Laut Stanfords KI-Index 2026 setzen nur einstellige Prozentzahlen aller Unternehmen KI-Agenten produktiv ein. Eine Studie von Stanford, Berkeley und IBM zeigt: 68 Prozent aller eingesetzten Agenten schaffen nicht mehr als zehn Schritte, bevor ein Mensch eingreifen muss. Woran liegt das? Die kurze Antwort: KI-Agenten zuverlässig zu machen, ist ein fundamental anderes Problem als die reine Fähigkeit eines Modells. Vier Faktoren erklären die Kluft: Varianz, Benchmark-Qualität, agentspezifische Fehler und Alignment. Die ersten beiden sind die größten Bremsklötze.

Das Varianz-Problem: Ein exponentielles Risiko

Stell dir vor, du baust ein Haus aus Karten. Jede Karte hat eine kleine Wahrscheinlichkeit, dass sie beim Auflegen verrutscht – sagen wir 10 Prozent. Eine einzelne Karte zu platzieren, ist kein Problem. Aber je höher der Turm wird, desto wahrscheinlicher kippt das Ganze irgendwann. Genau so funktioniert ein KI-Agent. Er führt nacheinander Schritte aus, um eine Aufgabe zu lösen: ein Dokument lesen, einen Datenbankeintrag abrufen, eine API aufrufen, eine E-Mail formulieren. Wenn jeder Schritt zu 90 Prozent klappt, gelingt eine 10-Schritte-Aufgabe nur noch zu 34 Prozent (0,9 hoch 10). Bei 20 Schritten sinkt die Erfolgsrate auf 12 Prozent, bei 30 Schritten auf 4,2 Prozent. Du kannst die Einzelschritt-Wahrscheinlichkeit auf 99 Prozent erhöhen – nach 30 Schritten bleiben nur noch 74 Prozent Gesamterfolg. Diese Rechnung vereinfacht die Realität, denn Fehler in einem Schritt verschlechtern den Kontext für alle folgenden Schritte. Andererseits können Agenten aus Fehlern lernen oder durch Absicherungen korrigiert werden. Aber das Grundprinzip bleibt: Je mehr Schritte, desto schneller bricht die Zuverlässigkeit ein. Dieses Phänomen nennt sich Intrarun-Varianz – die Unsicherheit innerhalb eines einzelnen Durchlaufs. Nun startet ein Agent eine Aufgabe nicht nur einmal, sondern hunderte Male. Die Varianz zwischen verschiedenen Durchläufen nennt sich Interrun-Varianz. Und hier zeigen Messungen ein ernüchterndes Bild.

Pass^k: Was dein Agent wirklich kann

Wie misst man Zuverlässigkeit? Zwei Kennzahlen helfen: pass@k und pass^k. Pass@k fragt: Wenn ich die Aufgabe k-mal ausführe, schafft es mindestens ein Versuch? Das ist die Obergrenze des Könnens – die beste Antwort, die ein Agent liefern kann. Pass^k fragt strenger: Wenn ich die Aufgabe k-mal ausführe, schafft sie jeder einzelne Versuch? Das ist die Untergrenze – die Zuverlässigkeit, auf die du in der Produktion zählen kannst. Ein Beispiel aus dem τ³-Benchmark (ein Branchenstandard für Kundenservice-Agenten): Das Modell gpt-5.2 erreicht pass^1 von 25,5 Prozent im Banking-Bereich. Bei pass^4 – also alle vier Versuche müssen bestehen – fällt das auf 13,4 Prozent. Teils fällt die Leistung auf die Hälfte. Und das beim modernsten Frontier-Modell. Die Grafik zeigt: Bei gpt-4o auf τ-bench liegt die Obergrenze bei etwa 95 Prozent, die Untergrenze bei etwa 30 Prozent. Der Agent könnte also fast alles lösen – aber nicht konsequent. Warum nicht einfach mehrmals laufen lassen und das beste Ergebnis nehmen? Bei Coding-Agenten funktioniert das, weil Tests dir sagen, ob der Code richtig ist. Aber bei den meisten Agentenaufgaben fehlt dieser automatische Beweis. Ein Kundenservice-Agent kann nicht viermal eine Rückerstattung veranlassen und dann die beste Lösung aussuchen – die Aktion wirkt in der Welt, und falsche Versuche haben echte Konsequenzen. Diese Varianz verzerrt auch deine Messung des Agenten. Ein einzelner Benchmark-Lauf ist wie ein einziger Wetterbericht: Er sagt dir wenig über das Klima. Damit zum nächsten Problem: den Datensätzen.

Wenn die Messlatte selbst schief ist

Scale AI wurde 2016 von Alexandr Wang und Lucy Guo gegründet – mit der Idee, dass Daten genauso wichtig sind wie Rechenleistung. Neun Jahre später ist das Unternehmen fast 30 Milliarden Dollar wert. Daten entscheiden über den Erfolg von KI-Systemen. Bei Agenten gilt das noch stärker, als man denkt. Selbst wenn du dein Modell nicht feinjustierst, trainierst du deinen Agenten durch dein Entwicklungsteam: Jede Prompt-Anpassung, jede Umstrukturierung des Workflows, jede Entscheidung, ein Experiment zu verwerfen, basiert auf dem Datensatz, den du zum Testen nutzt. Ein kaputter Datensatz führt zu kaputten Verbesserungen. Datensätze sind schwer sauber zu bekommen. Der τ-bench von Sierra – selbst ein Industriestandard – wurde zur verbesserten Version τ³ überarbeitet. Dabei mussten 53 von 164 Aufgaben korrigiert werden: über 30 Prozent wegen unmöglicher Bedingungen, widersprüchlicher Anweisungen oder falscher erwarteter Aktionen. WebArena, ein weiterer Benchmark, benötigte ähnliche Reparaturen. Nach der Korrektur sanken die Fehlalarme im Baseline-Agenten um 11 Prozent. Solche Fehler sind fatal: Wenn ein Drittel der Aufgaben falsch ist, kann ein korrekt arbeitender Agent schlechter abschneiden als einer, der zufällig die Fehler im Benchmark nachahmt. In der Praxis zeigt sich, dass Teams Monate damit verbringen, die falschen Zahlen zu optimieren – sie jagen Verbesserungen, die in der Produktion keine Wirkung zeigen.

Wie du trotzdem Zuverlässigkeit baust

Was also tun? Mess die Varianz explizit und erkenne sie an. Nutze pass^k als Kennzahl, nicht nur pass@k. Ein Agent, der eine Aufgabe in 90 Prozent der Fälle löst, ist anders zu bewerten als einer, der sie in 90 Prozent der Fälle einmal löst, wenn man ihm fünf Versuche gibt. Investiere in die Qualität deiner eigenen Evaluationsdaten. Ein Datensatz, der aus Produktionsdaten gespeist wird, muss kontinuierlich überprüft werden – nicht einmal bei der Erstellung. Implementiere Absicherungen und erlaube dem Agenten, Fehler zu erkennen und zu korrigieren. Ein Agent, der merkt, dass er eine falsche Annahme getroffen hat, und zurückfragt, ist zuverlässiger als einer, der stur weitermacht. Diese Probleme sind lösbar. Coding-Agenten zeigen den Weg: Sie haben klare, automatisch überprüfbare Ziele und Tests. Für allgemeine Aufgaben brauchen wir ähnlich klare Erfolgskriterien – und den Mut, Varianz nicht als Randerscheinung, sondern als Kernproblem zu behandeln.

Es geht nicht darum, KI-Agenten zu perfektionieren. Es geht darum, sie zuverlässig genug zu machen, um ihnen echte Verantwortung zu übertragen. Die Daten zeigen: Die Fähigkeit ist schon da – 95 Prozent der Probleme lassen sich mit dem richtigen Modell lösen. Was fehlt, ist Konsistenz. Und die erreichen wir nicht durch schlauere Modelle allein, sondern durch bessere Messung, bessere Daten und bessere Architektur. Das klingt unspektakulär – aber Vertrauen entsteht durch Nachweisbarkeit.

Quelle: jeremytian.substack.com

„Der schwierige Teil am kontinuierlichen Lernen ist nicht das Kontinuierliche, sondern das Automatische.“ Mit diesem Satz bringt der Entwickler Sean Goedecke ein Problem auf den Punkt, an dem die Branche seit Jahren arbeitet. Ein Sprachmodell bleibt für immer das, was es am Tag seiner Veröffentlichung war. Im Gespräch nimmt es zwar neue Informationen auf, aber nur so lange, wie das Kontextfenster reicht. Danach ist alles weg: keine Lernkurve, keine Erfahrung, die sich ansammelt. Sein Essay fragt, warum sich das so schwer ändern lässt.

Die Mechanik ist kein Problem

Das eigentliche Problem ist nicht die technische Umsetzung. Ein Modell während des Betriebs weiterzutrainieren ist durchaus möglich, indem man neue Daten durch die bestehende Trainingspipeline schickt. Derselbe Prozess wie beim ursprünglichen Training – nur live. Viele große Sprachmodelle werden intern ständig weiterentwickelt. Die neuesten GPT-Modelle nehmen vermutlich im Hintergrund laufend neue Daten auf und aktualisieren ihre Gewichte. Für die Öffentlichkeit stoppt dieser Prozess jedoch bei der Veröffentlichung. Die Modellgewichte sind eingefroren – aus gutem Grund. Sobald man den Lernprozess automatisiert, ohne menschliche Kontrolle, wird es gefährlich.

Lernen ohne Aufsicht führt oft in die Irre

Der Autor vergleicht das Training eines KI-Modells mit einem Glücksspiel. Trainierst du dasselbe Modell hundertmal mit denselben Daten, aber unterschiedlichen Zufallsauswahlen, erhältst du hundert verschiedene Modelle mit unterschiedlichen Fähigkeiten. Einige sind besser, einige schlechter – pure Lotterie. Man könnte meinen, mehr Daten und Rechenleistung führen automatisch zu einem schlaueren Modell. Ein Trugschluss. Training ist ein fragiler Prozess, der ständig menschlicher Eingriffe bedarf. Manchmal muss man einen Trainingslauf abbrechen, wenn er in eine Sackgasse gerät, oder Parameter anpassen, wenn das Modell in einem lokalen Minimum festhängt. Ein autonom lernendes Modell würde ohne diese Aufsicht mit der Zeit schlechter werden, nicht besser. Deshalb ist kontinuierliches Lernen im Sinne einer automatischen Gewichtsaktualisierung aktuell keine Option.

Fine-Tuning: Warum es nicht so einfach ist

Eine naheliegende Idee: ein LLM einfach auf die eigenen Daten feintunen. Wenn ich möchte, dass ein KI-Programmierer meine Codebasis versteht, könnte ich das Modell mit meinem Repository trainieren. Das funktioniert überraschend schlecht. Der Autor erinnert an den Hype um Fine-Tuning im Jahr 2023, der weitgehend verpufft ist. Selbst gezieltes Fine-Tuning auf eine spezifische Codebasis verleiht dem Modell kein echtes Verständnis für die Zusammenhänge. Warum das so ist, bleibt unklar. Vielleicht sind die Datensätze zu klein, um den riesigen Parameterraum zu verändern – wie ein paar Sandkörner, die eine Düne verschieben sollen. Oder Methoden wie LoRA dringen nicht tief genug in die internen Strukturen ein. Vielleicht müsste die Codebasis viel früher in den Trainingsprozess einfließen, bevor die Architektur des Modells festgelegt ist. So bleibt Fine-Tuning heute eine Enttäuschung – ein schlechtes Zeichen für alle, die hoffen, kontinuierliches Lernen bringe diese Fähigkeit nebenbei mit. Wenn man es nicht kontrolliert hinbekommt, kann man es nicht im Automatikmodus erwarten.

Sicherheit: Wenn der Gegner in die Gewichte schreibt

Ein weiterer Grund, warum kontinuierliches Lernen nicht als Produkt verfügbar ist, ist Sicherheit. Schon heute ist Prompt-Injection ein großes Problem: Ein bösartiger Text im Input kann ein Modell dazu bringen, unerwünschte Aktionen auszuführen. Bei kontinuierlichem Lernen würden Angreifer nicht nur den Kontext, sondern direkt die Gewichte des Modells manipulieren können. Ein Angreifer schleust über ein unscheinbares Trainingsbeispiel eine Hintertür ein, die erst Monate später aktiviert wird, wenn das Modell Zugriff auf sensible Systeme hat. Das wäre wie ein Virus, der sich in jeder neuen Version des Modells versteckt. Die großen KI-Labore haben jahrelang daran gearbeitet, ihre Modelle sicher und zuverlässig zu machen. Sie würden dieses Risiko niemals eingehen, indem sie jedem Kunden erlauben, eigene Trainingsläufe durchzuführen. Der Fall des Chatbots Tay von Microsoft, der nach wenigen Stunden durch Nutzerinteraktionen in einen rassistischen Hassbot verwandelt wurde, zeigt, wie schnell unkontrolliertes Lernen schiefgeht.

Das Upgrade-Dilemma

Auch abgesehen von Sicherheitsbedenken gibt es ein praktisches Problem: die Portabilität von Gelerntem. Trainierst du ein KI-Modell sechs Monate lang kontinuierlich an deiner Codebasis, sind alle Erkenntnisse in den Modellgewichten gespeichert. Nun erscheint die nächste Modellversion, die deutlich besser ist. Wie überträgst du das Gelernte? Du kannst die alten Gewichte nicht einfach übernehmen, denn die Architektur könnte sich geändert haben. Selbst ein LoRA-Adapter, der die Feinanpassung speichert, funktioniert nur, wenn das Basismodell kompatibel ist. Du stehst vor der Wahl: Bleibst du bei deinem alten, spezialisierten Modell, oder wechselst du zum neuen und verlierst wertvolles Wissen? Das erinnert an ein Unternehmen, das alle sechs Monate einen neuen Berater einstellt. Der neue Berater ist vielleicht smarter, aber er kennt deine Prozesse nicht. Nutzer werden sich sträuben, zu upgraden – schlecht für die Verbreitung neuer Modelle. AI-Unternehmen haben bereits heute Mühe, Nutzer zum Wechsel zu bewegen, wie die hartnäckige Anhängerschaft älterer GPT-Modelle zeigt. Kontinuierliches Lernen würde dieses Problem verschlimmern.

Warum ausgerechnet die Gewichte das Problem sind

Der Sicherheitsaspekt verdient einen genaueren Blick, weil er sich grundlegend von dem unterscheidet, was Entwickler heute kennen. Eine Prompt-Injection wirkt innerhalb einer Sitzung: Der Angreifer schmuggelt Text in den Kontext, das Modell tut etwas Unerwünschtes, und mit dem Ende der Sitzung ist der Spuk vorbei. Der Schaden bleibt begrenzt, weil er nirgends gespeichert wird.

Bei kontinuierlichem Lernen ändert sich genau das. Was ein Angreifer über präparierte Trainingsdaten in die Gewichte schreibt, bleibt dort – für jede künftige Sitzung und für jeden Nutzer desselben Modells. Eine so eingebaute Hintertür kann monatelang schlafen und erst dann auslösen, wenn ein bestimmtes Stichwort fällt und das Modell inzwischen Zugriff auf sensible Systeme hat. Der Autor hält das für deutlich beunruhigender als alles, was Prompt-Injection anrichten kann.

Das eigentlich Unangenehme daran: Es gibt keinen etablierten Weg, so etwas zu finden. Ein Modell lässt sich nicht wie eine Programmdatei auf Signaturen scannen. Man sieht Milliarden von Zahlen, denen nicht anzusehen ist, welches Verhalten in ihnen steckt. Dass selbst das kontrollierte Fine-Tuning seit den Diskussionen von 2024 nicht zuverlässig funktioniert, macht die Aussicht nicht besser: Was sich schon unter Aufsicht nicht sauber steuern lässt, gibt niemand freiwillig in den Automatikbetrieb.

Das Auto braucht weiterhin einen Fahrer

Das Ergebnis ist klar: Die eigentliche Hürde ist nicht die Kontinuität, sondern die Automatisierung. Wir wissen, wie man Modelle trainiert, aber nicht, wie man sie sicher und eigenständig trainieren lässt, ohne dass sie entgleisen. Modelltraining bleibt ein handwerklicher Prozess, der ständige Überwachung erfordert. Ein autonom lernendes System würde früher oder später in eine Sackgasse geraten und könnte sogar Schaden anrichten. Außerdem ist unklar, ob einfaches Zurückspulen von Nutzungsdaten tatsächlich zu echtem Verständnis führt – die Erfahrungen mit Fine-Tuning sprechen dagegen. Bis wir nicht lernen, Modelle automatisiert und zuverlässig zu verbessern, bleibt kontinuierliches Lernen eine Vision. Vielleicht träumen wir von einem Mitarbeiter, der aus Erfahrung klüger wird, aber im Moment haben wir nur einen eifrigen Azubi mit einem Notizblock, der jede Woche von vorne beginnt.

Quelle: seangoedecke.com