Kategorie: Erklärer

95 Sicherheitsberichte über 32 Produkte und Konfigurationen ergeben ein eindeutiges Bild: Jede getestete NAT-Implementierung ist verwundbar. Der unabhängige Forscher Malcolm Stagg präsentierte auf der Black Hat USA 2026 die Angriffsklasse NatJack. Sie manipuliert die Verbindungsverwaltung von Network Address Translation (NAT) direkt. Aktive Verbindungen lassen sich entführen, DNS-Antworten vergiften und Denial-of-Service auslösen. Klassische IP-Spoofing-Angriffe oder Zugriff auf den Broadcast-Domänen-Bereich sind nicht nötig.

Wenn du ein Netzwerk betreibst, solltest du genau hinschauen. NatJack funktioniert gegen Windows, Linux und macOS gleichermaßen – obwohl diese Systeme keinen gemeinsamen NAT-Codebase haben. Das deutet auf ein grundlegendes Designproblem hin, nicht auf einen einzelnen Programmierfehler.

Stell dir NAT wie eine Hausverwaltung vor, die alle Briefe für ein Mehrfamilienhaus an einer Adresse annimmt und dann an die Wohnungen weiterleitet. Die Hausverwaltung prüft nicht, ob ein Absender wirklich der ist, der er zu sein behauptet. Sie vertraut darauf, dass niemand böswillig handelt. Genau diese Vertrauenslücke macht NatJack aus.

Die Vertrauensannahme in NAT

NAT entstand in den frühen 1990er-Jahren als Übergangslösung gegen die IPv4-Adressknappheit. Mehrere Geräte teilen sich eine öffentliche IP-Adresse, intern verwenden sie private Adressen. Die Spezifikationen, die dieses Verhalten festlegten, gingen von einer friedlichen Umgebung aus. Stagg erklärt, dass diese Annahme tief in den RFCs verankert ist und bis heute fortbesteht.

Die Unter-Spezifikation erlaubt es der NAT, Verbindungen anhand von Quell- und Zieladressen sowie Ports zu verfolgen. Die dabei entstehende Tabelle, die Connection Tracking Table, ist das Herzstück von NAT. Sie hält fest, welches interne Gerät mit welchem externen Ziel kommuniziert und welche temporären Ports zugeordnet wurden. Wer die Kontrolle über diese Tabelle erlangt, kann praktisch jede Verbindung durch den NAT-Punkt umleiten.

Die Sicherheitslücke ist nicht neu. 2010 zeigte Samy Kamkar mit NAT Pinning, wie sich NAT-Verhalten manipulieren lässt. 2020 folgte NAT Slipstreaming, das das Application Level Gateway (ALG) ausnutzte. Diese Angriffe erforderten aber entweder eine Interaktion des Opfers oder den Einsatz von ALG-Diensten. NatJack umgeht diese Hürden: Es greift direkt auf die Connection Tracking Table zu, benötigt keine ALG-Unterstützung und genügt eine aktive Verbindung, die das Opfer bereits aufgebaut hat.

Layer-2-Isolationen wie VLAN-Segmentierung oder Switch-Port-Isolation bieten keinen Schutz. Die Angriffe finden auf Ebene 3 und 4 statt – in der Vermittlungs- und Transportschicht – und richten sich gegen die gemeinsame NAT-Infrastruktur. Selbst wenn du deine Netzwerksegmente strikt trennst, bleiben alle Geräte, die dieselbe NAT verwenden, verwundbar.

Vier Techniken, ein gemeinsamer Kern

NatJack umfasst vier verschiedene Angriffsvarianten, die alle auf derselben Schwachstelle beruhen: der fehlenden Überprüfung von Paketen, die die NAT-Tabelle verändern können. Stagg hat diese Techniken dokumentiert und veröffentlicht.

Die erste Technik ist die TCP-Verbindungsentführung. Der Angreifer sendet manipulierte Pakete, die eine laufende Verbindung in den Zustand „geschlossen“ versetzen. Dafür nutzt er den RFC-1337-Mechanismus namens TIME-WAIT Assassination. Der Zustand lässt sich mit wenigen Paketen erreichen, ohne auf ein normales Timeout zu warten. Anschließend ersetzt der Angreifer den Tabelleneintrag der Verbindung durch einen eigenen, sodass die Kommunikation über ihn umgeleitet wird. So kann er Daten abfangen oder sich in die Verbindung einschleusen.

Die zweite Technik ist die DNS-Antwort-Vergiftung. NatJack fängt UDP-DNS-Antworten ab, die durch die NAT laufen, und verändert sie. Das Opfer erhält gefälschte IP-Adressen für angefragte Domains, was zu Phishing oder Weiterleitungen auf Malware-Server führen kann. Der Angriff bleibt für den Nutzer unsichtbar: Die DNS-Antworten kommen ja von der NAT, der Browser ahnt nicht, dass sie manipuliert wurden.

Die dritte Technik ist ein Denial-of-Service-Angriff auf die NAT-Tabelle selbst. Der Angreifer sendet massenhaft Verbindungsanfragen oder Pakete mit gefälschten Adressen und füllt die Tabelle, bis keine neuen Verbindungen mehr aufgebaut werden können. Das betrifft nicht nur das einzelne Gerät, sondern alle Geräte hinter derselben NAT. Ein einziges bösartiges Gerät kann das gesamte Netzwerk lahmlegen.

Viertens gibt es die Verbindungs-Port-Identifikation. Der Angreifer findet heraus, welchen externen Port die NAT einem aktiven Datenstrom zugewiesen hat. Diese Information ist die Grundlage für die anderen drei Angriffe – ohne den korrekten Port lassen sich die Tabelleneinträge nicht gezielt manipulieren. Die Identifikation selbst ist nicht schädlich, dient aber als Aufklärungsphase.

Alle vier Techniken sind kombinierbar. Ein Angreifer kann zuerst den Port einer Verbindung ermitteln, dann die Verbindung beenden, den Tabelleneintrag übernehmen und anschließend gefälschte DNS-Antworten einschleusen. Das geht in Sekundenschnelle und erfordert keine besonderen Privilegien – lediglich die Möglichkeit, Pakete durch dieselbe NAT zu senden.

Herstellerreaktionen: Uneinheitlich und teils enttäuschend

Stagg meldete die Schwachstellen an dreizehn Hersteller. Die Antworten fielen sehr unterschiedlich aus. Das Linux-Kernel-Team wies den Bericht zunächst mit den Worten „total bogus“ zurück, wie Stagg in einem Interview berichtete. Er war überrascht und enttäuscht, doch später änderte sich die Lage: Auf Anfrage von Microsoft hin wurde der Fehler im Linux-Kernel behoben, um Azure Kubernetes Service zu unterstützen. Dafür erhielt die Schwachstelle die CVE-2026-63913.

Auch Microsoft selbst war betroffen: Die Windows-NAT-Implementierung für Hyper-V erhielt die CVE-2026-56181. Der Patch wurde im Rahmen eines regulären Sicherheitsupdates ausgeliefert. Andere Anbieter wie Cisco und Apple bewerteten die Ergebnisse jedoch nicht als Sicherheitslücken. Cisco verwies auf dokumentierte Mitigationsmaßnahmen für seine Produkte, Apple auf die Annahme, dass lokale Netzwerke feindlich sein können und End-to-End-Verschlüsselung wie TLS den Schaden begrenzt.

Stagg merkt an, dass Verschlüsselung tatsächlich hilft, aber sie kann nicht alles verhindern. Ein Angreifer, der eine Verbindung entführt, kann den verschlüsselten Datenstrom nicht lesen, aber er kann die Verbindung abrupt beenden oder blockieren. Das führt zu einem Denial-of-Service auf Anwendungsebene. Zudem sind nicht alle Protokolle standardmäßig verschlüsselt, und auch verschlüsselte Verbindungen können durch die Manipulation der NAT-Parameter unterbrochen werden.

Die unterschiedlichen Reaktionen zeigen, wie uneinheitlich die Branche mit Designfehlern umgeht. Einige Hersteller erkennen das Problem an und liefern Patches aus, andere sprechen von „Design-Limitationen“ und verweisen auf Best-Practice-Empfehlungen. Für dich als Netzwerkbetreiber bedeutet das: Du kannst dich nicht darauf verlassen, dass dein NAT-Gerät von Haus aus sicher ist. Du musst selbst aktiv werden.

Schutzmaßnahmen: Was Netzwerkbetreiber jetzt tun können

Auch ohne vollständige Patches gibt es mehrere konkrete Schritte, die das Risiko deutlich reduzieren. Stagg nennt in seinem Vortrag eine Reihe von Empfehlungen, die du direkt umsetzen kannst.

Überwache deine Netzwerk-Infrastruktur auf Auffälligkeiten. Dazu gehören eine vollständige oder fast volle NAT-Tabelle, ungewöhnliche Paketfluten über weite Portbereiche, die gleiche IP-Adresse an zwei physischen Standorten oder anomale SYN- und RST-Paketfolgen. Solche Anzeichen deuten darauf hin, dass ein Angreifer versucht, die Verbindungstabelle zu manipulieren.

Aktiviere den IP-Source-Guard an deinen Routern und Firewalls. Diese Schutzfunktion blockiert Pakete mit gefälschten Quelladressen, was viele NatJack-Varianten erschwert. Zusätzlich solltest du unvertrauenswürdige Geräte in separate Subnetze oder VLANs auslagern und die Verbindungsanzahl pro Client begrenzen – Stagg empfiehlt einen Wert von unter 10.000 gleichzeitig aktiven Verbindungen. Eine solche Begrenzung verhindert, dass ein einzelner Client die NAT-Tabelle überfluten kann.

Prüfe, ob dein NAT-Gerät sogenannte „Loose Connection Tracking“ oder „Port Preservation“ verwendet. Diese Modi erhöhen den Komfort für Anwendungen, schwächen aber auch die Sicherheit. Wenn möglich, deaktiviere sie und verwende striktes Adress- und Port-Mapping. Bei Containern solltest du den Netzwerkzugriff für unvertrauenswürdige Workloads einschränken: keine root-Rechte, keine Standard-Capabilities, und deaktiviere das Netzwerk für Container, die nicht zwingend erreichbar sein müssen.

In Cloud-Umgebungen gilt dieselbe Logik: Halte vertrauenswürdige und unvertrauenswürdige Workloads strikt getrennt, und nutze für Serverless-Funktionen dedizierte öffentliche IPs, anstatt sie über einen gemeinsamen NAT-Gateway laufen zu lassen. Stagg weist darauf hin, dass eine der Angriffsvarianten auch zwischen verschiedenen Subnetzen funktioniert, also eine Trennung auf Subnetzebene nicht ausreicht. Die Isolation muss auf NAT-Ebene erfolgen.

Die Lektion aus NatJack: Historische Annahmen neu bewerten

NatJack ist mehr als nur eine weitere Sicherheitslücke. Es zeigt, wie sehr sich die Bedrohungslandschaft verändert hat, während unsere Netzwerktechnik in den 1990er-Jahren stehen geblieben ist. Die Annahme, dass alle Geräte hinter einer NAT vertrauenswürdig sind, war vielleicht einmal vertretbar – in Zeiten, in denen Netzwerke aus wenigen Rechnern bestanden, die von derselben Administration kontrolliert wurden. Heute jedoch verbinden sich unzählige IoT-Geräte, Gastnotebooks, Smartphones und Cloud-Workloads über denselben NAT-Punkt. Jedes dieser Geräte könnte bereits kompromittiert sein oder böswillig agieren.

Die Tatsache, dass NatJack auf allen drei Betriebssystemfamilien funktioniert, ohne dass der Code geteilt wird, unterstreicht den systemischen Charakter des Problems. Es handelt sich nicht um einen einzelnen Fehler, sondern um ein grundlegendes Vertrauensmodell, das der heutigen Realität nicht mehr standhält. Sicherheitsarchitekten müssen sich daher von der Vorstellung verabschieden, dass eine NAT automatisch Schutz bietet. Sie ist eine Adressumsetzung, keine Firewall.

Für dich als Entscheider im Netzwerk bedeutet das: Du musst deine Sicherheitslösungen auf mehreren Ebenen implementieren. Verschleiere die interne Struktur nicht durch NAT allein, sondern setze zusätzlich auf robuste Firewall-Regeln, Intrusion-Detection-Systeme und eine konsequente Segmentierung. Und überprüfe regelmäßig die Designannahmen deiner Infrastruktur. Was vor zwanzig Jahren sicher war, kann heute ein Einfallstor sein.

Stagg fasst es treffend zusammen: Man dürfe sich nicht auf die historischen Designentscheidungen verlassen, sondern müsse die Bedrohungsmodelle von heute anwenden. NatJack ist ein Weckruf – und eine Chance, die Sicherheitsarchitektur endlich an die Realität anzupassen.

Quelle: networkworld.com

„Keines dieser Tools erinnert sich an deine Kunden, deine Markenregeln oder die Entscheidung von letztem Dienstag.“ Dieser Satz stammt aus einem Praxisbericht von jemandem, der eine Agentic Experience Design Practice in einem großen Studio leitet. Er beschreibt die Realität der meisten Design-Teams: Drei oder vier KI-Tabs offen, keiner hat Kontext. Du tippst dieselben Hintergründe immer wieder neu und wunderst dich, warum der Workflow sich anfühlt wie ein Glücksspielautomat. Genau hier setzt Claude Cowork an, das Anthropic am 12. Januar 2026 als Research Preview für macOS startete und später auf Windows, Web und Mobile ausrollte.

Der Autor des Reports, im Original als „Working Field Guide“ bezeichnet, hat das Tool wochenlang im Studio getestet. Seine Kernaussage: Cowork ist kein Chatbot mit hübscherer Oberfläche. Es ist ein Agent, der deine Ordner öffnet, Quellen liest, Code ausführt, den Browser steuert und dir am Ende eine fertige Präsentation, Tabelle oder ein Dokument liefert – während du dich mit den eigentlichen Designfragen beschäftigst. Ob dieser Anspruch hält, was er verspricht, zeigen konkrete Prompts, Dateistrukturen und Sicherheitseinstellungen.

Der Unterschied zwischen Chat, Code und Cowork

Die mentale Landkarte für Cowork ist überraschend schlicht: Es gibt drei Oberflächen, aber dasselbe Sprachmodell. Der gewöhnliche Claude-Chat antwortet Zug um Zug und produziert Text, den du dann selbst in Aktionen übersetzt. Er kann nicht direkt auf deine Dateien zugreifen. Claude Code lebt im Terminal und der IDE: Es plant, verändert Code über ein Repository, führt Befehle aus, und du prüfst die Diffs. Es ist für Software-Auslieferung gebaut. Cowork schließlich sitzt im selben Zuhause wie der Chat, aber statt zu antworten, führt es aus.

Du beschreibst ein Ergebnis, und Cowork erstellt einen Plan, zerlegt die Arbeit in Teilaufgaben, führt diese in einer isolierten Umgebung aus, koordiniert parallele Arbeitsstränge und liefert Dateien, die du in der Vorschau prüfen und herunterladen kannst. Die Formel, die der Autor seinem Team mitgibt: Im Chat sagt dir Claude, wie du die Aufgabe machst. In Cowork macht Claude die Aufgabe. Dieser Unterschied ist das gesamte Produkt.

Diese Unterscheidung ist auch für dich als Designer relevant, weil sie den Arbeitsfluss fundamental verändert. Du wechselst vom Formulieren einer Anfrage zur Steuerung eines Prozesses. Du wirst vom Tippenden zum Dirigenten. Der Autor vergleicht das mit dem Schritt vom Interface-Design zum Agent-Design: Früher haben wir Bildschirme gestaltet, dann Erlebnisse, und jetzt gestalten wir Agenten.

Warum die Nutzungsdaten für Designer relevant sind

Die Zahlen sprechen für sich. Anthropic hat in einem Blogbeitrag 1,2 Millionen Sitzungen aus mehr als 600.000 Organisationen analysiert, gesammelt zwischen dem 11. und 31. Mai 2026. Die größte Kategorie war Geschäftsprozesse und Betrieb mit 33,4 Prozent. Inhaltserstellung und Copywriting landete auf Platz zwei mit 16,4 Prozent – also Entwürfe, Präsentationen, Posts und Vorschläge. Softwareentwicklung machte nur 8,7 Prozent aus, gefolgt von DevOps mit 7 Prozent, Forschung mit 6,4 Prozent und Datenanalyse mit 5,8 Prozent.

Anthropic nennt die dominante Nutzung „die Arbeit rund um die Arbeit“. Für ein Designteam ist das exakt die Steuer, die deine abrechenbaren Stunden auffrisst: die Decks, die Audits, die Synthese, die Übergabedokumente. Der Autor berichtet, dass genau diese Aufgaben in seinem Studio bisher oft übersprungen wurden, wenn der Zeitplan eng wurde. Mit Cowork werden sie jetzt ausgeführt, weil der Agent sie abnimmt.

Technisch läuft Cowork in der Beta standardmäßig remote. Die Agentenschleife und die Code-Ausführung passieren in einem isolierten, temporären Sandbox auf den Servern von Anthropic. Jede Sitzung bekommt ihre eigene Sandbox, die beim Start erstellt und beim Ende zerstört wird. Sitzungen und Dateien werden in deinem Claude-Konto gespeichert. So kannst du eine Aufgabe auf dem Laptop starten, sie vom Telefon aus beobachten und die Ergebnisse später abrufen, selbst wenn der Laptop zu ist. Geplante Aufgaben laufen sogar ganz ohne angeschlossenes Gerät. Für den Zugriff auf lokale Dateien nutzt Cowork die Claude-Desktop-App.

Die Einrichtung: Berechtigungsmodi und Anweisungen

Die technische Hürde ist niedrig. Du brauchst einen kostenpflichtigen Plan (Pro, Max, Team oder Enterprise), die Desktop-App für macOS oder Windows, und eine Internetverbindung während der Sitzung. Die Installation selbst ist ein Kinderspiel: Die App von claude.com/download holen, anmelden, und dann im Nachrichtenfeld statt „Chat“ die Option „Cowork“ wählen. Der schwerere Teil ist die Konfiguration, und die meisten Leute ignorieren sie – das ist ein Fehler.

Der Autor betont: Es gibt drei Berechtigungsmodi. „Manual“ (früher „Ask before acting“) bedeutet, dass Claude vor jeder Aktion stoppt und um Genehmigung bittet. Du prüfst jeden Schritt. Das ist der sicherste Modus, aber auch der langsamste. „Auto“ lässt Claude weiterarbeiten und jede Aktion selbst auf Sicherheit prüfen. Es blockiert Dinge wie Datenabfluss oder Prompt-Injection, fragt aber nicht nach. Dieser Modus verbraucht mehr Nutzungskontingent, weil die Prüfungen Rechenzeit kosten. „Skip“ schließlich fragt gar nicht erst – die gefährlichste Option, die du nur verwenden solltest, wenn du jedem File, Connector und App vollständig vertraust.

Die Empfehlung des Autors für sein Studio ist klar: Manual bei allem, was eine Nachricht als dich versendet, Geld berührt oder in ein Kundensystem schreibt. Auto bei interner Synthese und Entwürfen in einem abgegrenzten Ordner. Skip fast nie. Dazu kommen zwei Ebenen von Anweisungen: globale Instruktionen unter Einstellungen > Cowork, die für jede Sitzung gelten – dort beschreibst du, wer du bist und wie du schreibst. Und Ordner-Instruktionen, die projektbezogenen Kontext mit einem bestimmten lokalen Ordner verbinden.

Ein wichtiger Hinweis aus dem Bericht betrifft eine Klausel in den globalen Instruktionen: „Frag nach, wenn du etwas nicht weißt.“ Ohne diese explizite Anweisung neigt das Modell dazu, Lücken mit selbstbewusster Fiktion zu füllen. Der Autor nennt das den „Auslassventil-Effekt“ und bezeichnet ihn als nicht verhandelbar.

Drei konkrete Workflows, die den Unterschied zeigen

Der beste Einstieg ist nicht Dateiorganisation, sondern eine Aufgabe, die den Unterschied zwischen Chat und Agent beweist. Lege einen Ordner mit rohen Forschungsmaterialien auf den Desktop und schreibe in Cowork: „Analysiere alle Dateien in diesem Ordner. Identifiziere die wiederkehrenden Themen, zähle, wie oft jedes Thema in separaten Sitzungen auftaucht, und zitiere die wichtigsten Originalaussagen wörtlich. Erstelle FINDINGS.md im selben Ordner.“ Das ist der entscheidende Test: Chat würde dir eine Zusammenfassung geben, wenn du Text einfügst. Cowork liest jede Datei selbst, zählt über Sitzungen hinweg, behält die Zitate wörtlich bei und schreibt die Datei auf die Festplatte. Nach dem Lauf solltest du die Zitate gegen ein Transkript prüfen – diese Verifikation ist laut Autor Pflicht.

Der zweite Workflow koppelt Cowork mit der Claude-Erweiterung für Chrome. Der Browser navigiert und sammelt, Cowork kompiliert. Du beschreibst ein Thema, zum Beispiel die Preisstruktur eines Mitbewerbers, und Cowork öffnet die relevanten Seiten, extrahiert die Daten und führt sie in einer Tabelle zusammen. Eine Warnung: Cowork respektiert zwar deine Netzwerk-Ausgangsberechtigungen, aber diese gelten nicht für Web-Fetch, Websuche oder den Browser. Web-Fetch läuft serverseitig und ist auf Suchergebnisse und geteilte URLs beschränkt. Behandle alles, was der Browser berührt, als potenzielle Quelle von Prompt-Injection und wechsle die ersten Male in den Manual-Modus.

Der dritte Workflow ist die Interview-Synthese. Der Autor nutzt Cowork für die Auswertung von Nutzerinterviews. Die eingegebene Anweisung lautet zusammengefasst: „Synthetisiere alle Interviews in diesem Ordner. Gruppiere die Aussagen nach Themen. Zähle, wie oft jedes Thema vorkommt, mit direktem Zitat als Beleg. Markiere Aussagen mit niedriger Konfidenz und weise explizit auf widersprüchliche Belege hin. Exportiere als Excel-Datei mit mehreren Tabs, einem Tab pro Thema, mit einer Zusammenfassung und den genannten Risiken.“ Die ausgegebene Excel-Datei ist keine CSV mit Korrekturbedarf, sondern eine Tabelle mit funktionierenden Formeln und mehreren Registerkarten. Die Zeilen „niedrige Konfidenz markieren“ und „widersprüchliche Belege notieren“ sind die Schutzmechanismen gegen eine zu glatte Erzählung.

Diese drei Beispiele zeigen das Muster: Du ersetzt die mühsame manuelle Synthese durch einen Agenten, der systematisch arbeitet. Der Autor bezeichnet dies als „die Form des Agent-Designs: Du schreibst keine Prompts, du entwirfst eine dauerhafte Betriebsprozedur, die ein Agent ausführt und bei Bedarf eskaliert.“

Skills: Das Gedächtnis, das du nicht kanntest

Der heimliche Star von Cowork sind Skills. Prompts sind einmalige Anweisungen, Skills sind dauerhafte Anweisungen. Ein Skill ist ein Ordner mit einer SKILL.md-Datei, die YAML-Frontmatter (Name und Beschreibung) und Markdown-Instruktionen darunter enthält. Claude liest die Beschreibung, um zu entscheiden, wann der Skill automatisch geladen wird, oder du rufst ihn mit einem Slash-Befehl auf. Skills folgen dem offenen Agent-Skills-Standard und funktionieren sowohl in Cowork als auch in Claude Code.

Für Designer ist das die Hebelwirkung, die fast niemand ausnutzt. Wenn du zum Beispiel einen Skill „handoff-spec“ anlegst, der beschreibt, wie eine Übergabe-Spezifikation in deinem Hausformat auszusehen hat, dann produziert Claude auf Kommando eine vollständige Spezifikation, ohne neu eingewiesen zu werden. Der Autor gibt ein konkretes Beispiel: Der Skill enthält Platzhalter für „Design-Kontext“, „Nutzerfluss“, „Zustände“, „Barrierefreiheit“ und „offene Fragen“. Er enthält zwei wichtige Klauseln: Nicht zutreffende Zustände müssen begründet werden, und nicht verifizierbare Kontraste gehen in die offenen Fragen statt in eine falsche Erfolgsmeldung. Diese beiden Zeilen machen den Unterschied zwischen einer Spezifikation, der du vertraust, und einer, die du Zeile für Zeile nachprüfen musst.

Die Erstellung eines Skills ist einfacher als gedacht. Du kannst die SKILL.md von Hand schreiben oder Claude mit „/skill-creator“ ein Interview führen. In der macOS-App kannst du sogar eine Aktion aufzeichnen: Du führst eine Aufgabe auf dem Bildschirm aus, während du sie kommentierst, und Claude schlägt daraus einen Skill vor. Die Video- und Audiodaten werden nicht gespeichert, nur Screenshots bleiben in der Aufgabe. Weitere sinnvolle Skills aus der Praxis, die der Autor erwähnt: ein Marken- und Sprachleitfaden, der festhält, was die Marke ist, was sie nicht ist und warum; ein Kritik-Vorbereitungs-Skill, der dasselbe Design-Entscheidung für Peer, Produktmanager und VP unterschiedlich einrahmt; und ein Forschungsplan-Template-Skill.

Die beste Praxis bleibt: ein Skill sollte fokussiert sein, eine präzise Beschreibung haben und mindestens ein Beispiel enthalten. Der Autor warnt vor Overengineering: „Wenn die Instruktion länger ist als die Ausgabe, vereinfache.“ Anthropic pflegt auf GitHub Beispiel-Skills als Vorlagen.

Wo es schmerzt: Ehrliche Grenzen

So überzeugend die Workflows klingen, der Bericht verschweigt die Haken nicht. Sicherheit ist das offensichtliche Thema. Die Remote-Sandbox-Architektur bedeutet, dass deine Dateien auf Anthropic-Servern verarbeitet werden. Zwar ist die Sandbox isoliert und wird nach der Sitzung zerstört, aber du musst dir bewusst sein, was du dort ablegst. Vertrauliche Kundendaten, die unter NDA stehen, gehören nicht in eine Cowork-Sitzung ohne vorherige Freigabe durch die Rechtsabteilung.

Das zweite Risiko ist die fremde Umgebung. Der Autor erzählt von einem Test, bei dem Cowork Daten aus einer unzuverlässigen Quelle zu einem kohärenten Bericht verarbeitete und dabei fehlerhafte Zahlen übernahm. Er hätte die Ursprungsdaten gegenprüfen müssen. Das passiert, wenn du dem Agenten zu viel Vertrauen schenkst, ohne die „Frag nach“-Klausel zu verankern.

Der dritte Punkt ist die Nutzungsgrenze. Auto-Modus verbraucht doppelt so viele Credits, weil jede Aktion einer Sicherheitsprüfung unterliegt. Wenn du viele lange Synthese-Aufgaben hast, kann dein Kontingent schneller aufgebraucht sein als gedacht. Die geplanten Aufgaben laufen zwar unabhängig vom Gerät, aber sie zählen gegen dasselbe Budget.

Schließlich die Integration: Cowork funktioniert reibungslos mit Claude in Chrome, aber die Interaktion mit anderen Browser-Erweiterungen oder Desktop-Apps ist begrenzt. Der Zugriff auf lokale Dateien erfolgt über die Desktop-App, und du musst explizit Ordner freigeben. Das ist ein Sicherheitsgewinn, aber auch eine Reibung im Alltag.

Claude Cowork ist kein Wundermittel, sondern ein Werkzeug, das bestimmte monotone Wissensarbeit radikal beschleunigt. Die größte Verschiebung liegt nicht in der Technik, sondern in der Denkweise. Du steigst um vom Formulieren von Anfragen zum Gestalten von Prozessen. Der Autor fasst es so zusammen: „Wir haben gelernt, Interfaces zu gestalten, dann Erlebnisse, und jetzt gestalten wir Agenten.“ Für Designer bedeutet das: Die Fähigkeit, klare Ziele zu definieren, Kontext zu setzen und Ergebnisse zu verifizieren, wird wichtiger als das Tippen selbst. Cowork ist kein Ersatz für Urteilsvermögen – es ist ein Verstärker für die Arbeit, die du ohnehin tun wolltest.

Quelle: nervegna.substack.com

Viele denken, KI-Agenten arbeiten am liebsten isoliert in eigenen Interfaces, umgeben von Konsolenausgaben und Widgets. Doch das Gegenteil ist wahr: Ihre Wirkung entfalten sie dort, wo Entscheidungen fallen und Teams gemeinsam an Aufgaben wachsen. Das neue Channels SDK von CopilotKit schließt diese Lücke. Es bringt beliebige KI-Agenten in Slack, Microsoft Teams und andere Kollaborationsplattformen – mit nativer, interaktiver Oberfläche und vollständiger Kontrolle über Tools und Geschäftslogik.

Stell dir vor, du arbeitest in einem Team, das von Montag bis Freitag in Slack lebt. Plötzlich kann dich ein KI-Kollege aktiv unterstützen – er liest Kontext, ruft Tools auf, rendert Diagramme und fragt um Erlaubnis, bevor er kritische Aktionen ausführt. Das Channels SDK macht das möglich. Es ist ein Open-Source-Werkzeug, das die Kommunikationslücke zwischen modernen Agenten-Frameworks und den Plattformen schließt, auf denen täglich tausend Nachrichten ausgetauscht werden.

Warum native Integration mehr ist als nur ein Chatbot

Ein KI-Agent, der nur in einem eigenen Fenster läuft, ist wie ein exzellenter Berater, der niemals an Besprechungen teilnimmt. Er weiß alles, aber niemand fragt ihn. Das Channels SDK ändert das: Es verbindet Agenten mit Plattformen wie Slack, Microsoft Teams und Discord über den offenen AG-UI-Standard. Der Agent versteht Textnachrichten, Konversationskontext, Dateien, Streams und interaktive Elemente wie Buttons oder Dropdowns.

Der Clou: Ein einmal beschriebenes Element wird automatisch in das Block-Kit von Slack, Adaptive Cards von Teams und die spezifischen Komponenten anderer Plattformen übersetzt. Du bekommst keine generische Web-View, sondern ein Interface, das sich nahtlos in die gewohnte Arbeitsumgebung einfügt. Der Agent kann damit nicht nur antworten, sondern auch Entscheidungen visualisieren, Diagramme rendern oder einen Genehmigungsschritt einbauen – alles direkt im Chat.

Das SDK ist framework-agnostisch. Ob LangGraph, CrewAI, Mastra, Pydantic AI oder Googles ADK – jede AG-UI-kompatible Agenten-Factory lässt sich anschließen, ohne dass sich am Lebenszyklus des Channels etwas ändert. Für den schnellen Start liefert CopilotKit einen eingebauten Agenten mit. Die Freiheit der Wahl bleibt.

So einfach bringst du einen Agenten in Slack oder Teams

Der Weg zur Live-Schaltung ist kurz. Du brauchst Node.js 22+, eine CopilotKit Intelligence-Instanz (gehostet oder selbst gehostet) und einen langlaufenden Node-Prozess. Die Installation läuft über zwei npm-Pakete: @copilotkit/channels und @copilotkit/runtime. Letzteres enthält die Brücke zur Intelligenz-Schicht und zu deinem eigenen Agenten.

Der Code folgt einem klaren Muster: Du erstellst einen Channel, definierst eine Funktion, die deinen Agenten pro Thread instanziiert, und registrierst einen Listener, der eingehende Nachrichten verarbeitet. Deine Geschäftslogik bleibt vollständig bei dir – das SDK übernimmt nur die Translation zwischen Plattform-Events und AG-UI-Messages. Ein Beispiel aus der Dokumentation zeigt, wie der interne BuiltInAgent mit einem einzigen Aufruf eingebunden wird. Auch jede andere Factory passt problemlos.

Wer Zeit sparen will, nutzt npx copilotkit@latest channels setup. Das startet eine geführte Einrichtung, die deinen Coding-Agenten selbstständig durch die Konfiguration führt. API-Keys und Secrets bleiben in deiner .env-Datei. Wer es manuell macht, findet in der README eine detaillierte Schritt-für-Schritt-Anleitung mit allen nötigen Befehlen und einem lauffähigen Beispielskript. Nach zehn Minuten ist dein Agent in deinem Slack-Kanal aktiv.

Was hinter der Kulisse passiert – die Architektur im Schnelldurchlauf

Channels folgt einer simplen Grundlogik: Jeder Turn läuft nach demselben Schema ab. Eine Person schreibt eine Nachricht in Slack oder Teams. Diese wird an CopilotKit Intelligence übertragen, die den Event an deinen langlaufenden Channels-Prozess weiterleitet. Dort führt der eingebundene Agent über AG-UI Aktionen aus, ruft Tools auf und erzeugt eine Antwort. Die Intelligence übernimmt das Rendering als native Plattform-UI und schickt sie zurück in den Chat.

Die Trennung der Verantwortlichkeiten bleibt klar: Du betreibst deinen Agenten, deine Tools, deine Modell-Credentials und deine Business-Logik. CopilotKit Intelligence verwaltet die Plattform-Credentials, den Eingang, die Zustellung sowie Health-Checks und Reconnects. Das SDK steht unter MIT-Lizenz – du kannst es nach Belieben erweitern. Für Enterprise-Nutzer ist die Intelligenz-Schicht selbsthostbar.

Diese Architektur ist resilient. Wenn Plattformen ihre APIs ändern, sorgt die Intelligence-Schicht für die Anpassung – dein Code bleibt stabil. Du fokussierst dich auf das, was deinen Agenten ausmacht, anstatt dich um Platform-Quirks zu kümmern.

OpenTag als Referenz: Ein echter Agent im On-Call-Betrieb

CopilotKit verweist auf OpenTag, eine Open-Source-Anwendung für On-Call-Triage. Dieser Assistent nimmt Störungsmeldungen an, analysiert Logs, spricht mit Dateien und erstellt generative UI – alles direkt in Slack oder Microsoft Teams. Bevor er in Linear oder Notion schreibt, bittet er einen Menschen um Freigabe. Diese menschliche Kontrolle ist ein Kernfeature von Channels: Der Agent kann Aktionen ausführen, aber kritische Schritte pausieren und einen Button in den Chat schalten.

OpenTag ist als Lernvorlage konzipiert. Du kannst den kompletten Quellcode studieren – von der Python-LangGraph-Agentenüber AG-UI bis zum produktionsreifen Node-Laufzeitprozess. So siehst du, wie Datei-Uploads, generative UI und Genehmigungs-Workflows in der Praxis implementiert sind. Das ist kein Spielzeug-Example, sondern ein robustes Setup mit echten Fehlerprüfungen und sauberer Trennung zwischen Agent und Runtime.

Die Einstiegshürde ist niedrig. Du kannst deinen Coding-Agenten durch die Setup-Skills führen oder dich an den manuellen Schritten orientieren – beides wird durch die Dokumentation gut abgedeckt. Der schnellste Weg in die Praxis führt über npx copilotkit@latest channels setup, das dir den kompletten Zyklus von der Konfiguration bis zur Live-Schaltung abnimmt.

Warum das die Zukunft der KI-Assistenz verändert

Die Botschaft hinter Channels ist einfach: Agenten sollen nicht mehr in exotischen Interfaces leben, sondern dort, wo Menschen ohnehin arbeiten. Die Integration in Slack und Teams ist nicht nur Komfort – sie verändert die Dynamik. Ein Agent, der in jedem Channel mitlesen und auf Ansprache reagieren kann, wird zum echten Teammitglied. Er kann Kontext aus vergangenen Gesprächen ziehen, Vorgänge anstoßen und Rückfragen stellen, ohne dass jemand zwischen UI und Chat wechseln muss.

Genehmigungsschritte direkt im Chat sind ein entscheidender Baustein für Vertrauen. Nicht der Agent entscheidet allein, sondern er legt dir die Fakten vor und wartet auf deinen Klick. Das schafft eine Balance zwischen Automatisierung und Kontrolle – genau das, was Unternehmen für den produktiven Einsatz brauchen.

Das SDK ist offen. Jeder kann eigene Adapter für weitere Plattformen schreiben oder bestehende Agenten über AG-UI anbinden. Die Konkurrenz zwischen Frameworks spielt keine Rolle mehr – solange sie AG-UI sprechen, integrieren sie sich nahtlos. Das ist ein Standard, der die Fragmentierung der Agentenlandschaft überwinden hilft.

Was bleibt, ist die Frage nach dem Betrieb. CopilotKit Intelligence ist als Cloud-Dienst verfügbar, aber auch selbsthostbar. Damit ist die Lösung für streng regulierte Umgebungen geeignet. Die Kombination aus offenem SDK, klarer API und flexibler Hosting-Option sichert dem Projekt einen festen Platz in der KI-Infrastruktur von morgen.

Quelle: github.com

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

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