Vor einigen Tagen las ich einen Beitrag von Mircha Emanuel D’Angelo über den Tod der Benutzeroberfläche. Einer von der Sorte, die hängenbleibt. Ich las ihn, ich las ihn noch einmal, und dann begann ich, im realen Leben darauf zu achten: wie viel mentale Energie wir bloß darauf verwenden, uns zu erinnern, wo eine Sache erledigt wird, in welchem Tab, in welchem Menü, in welchem Produkt.
Und während ich versuchte einzuschlafen, wurde die Frage lästiger und interessanter zugleich: wenn die UI wirklich aufhört, das Zentrum der Software zu sein, was passiert mit dem Rest? Denn vielleicht stirbt nicht nur der Bildschirm. Vielleicht stirbt die Anwendung, wie wir sie kannten.
Stirbt die UI, fällt sie nicht allein
Wenn wir „App“ sagen, meinen wir meist ein recht klares Objekt. Es hat einen Namen, ein Icon, einen Platz im Dock, ein monatliches Abo, eine Persönlichkeit. Und vor allem hat es eine Grenze. Drinnen ist die Welt von Notion. Drinnen ist Jira. Drinnen ist Salesforce. Draußen ist alles andere.
Mir ist aufgefallen, dass diese Grenze oft nicht da ist, weil das Problem sie verlangt. Sie ist da, weil das Geschäftsmodell sie verlangt.
Ein großer Teil moderner Software ist als Gehege gebaut. Vielleicht nicht aus Bösartigkeit. Es war jahrelang einfach der einfachste Weg zu monetarisieren: nimm eine Reihe von Funktionen, packe sie zusammen, baue drumherum eine Oberfläche, die vertraut wird, leg die Daten des Nutzers hinein und sorge dafür, dass das Hinausgehen schmerzt.
Mircha zieht eine Parallele, die mir erhellend vorkommt: MCP-Server als „neue Unix-Programme“. Und wenn das stimmt, folgt eine andere, etwas unbequemere Konsequenz. SaaS-Anwendungen sehen von dort aus wie Mainframes. Große Monolithen, geboren in einer Zeit, in der Software-Distribution teuer war und der einzige Weg, sie zu verkaufen, darin bestand, Mauern zu bauen.
In einer Welt, in der ein Agent kleine, präzise Capabilities im Flug zusammensetzen kann, wird diese Mauer eher zum Hindernis als zum Schutz.
Die generative Oberfläche: nicht entworfen, beschworen
In Mirchas Beitrag gibt es eine Stelle, an der ich innehalten musste. Die Idee, dass die GUI vom Control Panel zum Display wird. Und ich fragte mich: und wenn sie weder das eine noch das andere ist?
Vielleicht wird die Oberfläche im nächsten Schritt flüchtig.
Wenn heute eine Designerin einen Bildschirm entwirft, geht sie einen Kompromiss ein. Sie sucht ein Layout, das für viele Menschen in vielen Kontexten „gut genug“ funktioniert. Das Ergebnis ist oft eine solide, kohärente, getestete Oberfläche — aber unausweichlich generisch. Sie muss allen dienen, also dient sie niemandem perfekt.
Mit einem Agenten dazwischen könnte dieser Kompromiss fallen.
Ich meine nicht „alles im Chat erledigen“, was eine bequeme Karikatur ist. Ich meine ein System, das aus deiner Absicht die für diesen Moment richtige Oberfläche erzeugt. Ein Formular, nicht generisch, sondern mit diesen Feldern, in dieser Reihenfolge, mit den sinnvollen Defaults für deinen Fall. Ein Dashboard, nicht standardisiert, sondern die Visualisierung, die eine konkrete Frage beantwortet, mit den nötigen Daten und keinem Lärm.
Diese UIs werden nicht gepflegt. Nicht versioniert. Brauchen keine Roadmap.
Sie werden beschworen und verschwinden danach.
Das Beunruhigende: das ist keine Science-Fiction mehr. Heute sehen wir bereits Modelle, die Komponenten, Seiten, kleine React-Artefakte in Echtzeit erzeugen. Roh, ja. Aber die Richtung ist schwer zu ignorieren.
Die Rolle der Designerin verschwindet dann nicht, sie häutet sich. Statt Bildschirme zu entwerfen, gestaltet sie generative Systeme. Designsysteme, Constraints, Patterns, Regeln. Eine Arbeit, die eher dem Bauen einer Grammatik gleicht als dem Zeichnen von Sätzen.
Der Agent als Betriebssystem
Eine andere Konsequenz, die mich nicht loslässt: vielleicht ist die richtige Metapher für den Agenten nicht „Assistent“. Es ist „Betriebssystem“.
Ein OS tut Dinge, die wir für selbstverständlich halten: es abstrahiert die Hardware, verwaltet Ressourcen, bietet eine einheitliche Oberfläche, lässt verschiedene Programme nebeneinander laufen und miteinander reden.
Der Agent macht etwas Ähnliches, eine Ebene darüber. Er abstrahiert die Dienste, verwaltet Kontexte, bietet eine einheitliche Oberfläche (die natürliche Sprache), orchestriert verschiedene Capabilities.
Wenn diese Metapher trägt, geschieht etwas fast Unausweichliches: der Agent wird die Plattform. Nicht weil alles „in“ dem Agenten lebt, sondern weil alles durch den Agenten geht. So wie heute keine Software ohne OS läuft, wird morgen kein Dienst ohne Agenten genutzt.
Und hier kommt der politische, ökonomische Teil, der vielleicht der heikelste ist. Wer den Agenten kontrolliert, kontrolliert den Zugangspunkt zur Software. Eine Position, die wir in der Geschichte schon gesehen haben, nur unter anderen Namen.
Und ich frage mich, ob wir die übliche Bahn vermeiden können. Jene, die Cory Doctorow Enshittification nennt. Erst ist alles nützlich und offen, dann wird es zur Rente, dann zur Maut.
Von der App zur Capability
Wenn die Anwendung an Sinn verliert, was bleibt?
Es bleibt die Capability.
Eine Capability ist eine atomare Funktion, über ein Protokoll exponiert, menschlich beschrieben, von einem Agenten aufrufbar. „Erstelle eine Rechnung.“ „Suche diesen Kontakt.“ „Fasse diese Tickets zusammen und nenne mir die Risiken.“ Das ist kein Produkt mit Marke und Layout. Es ist ein Baustein.
Sobald du in Bausteinen denkst, ändert sich auch die Ökonomie.
Heute zahlst du ein Abo für ein Bundle: hundert Funktionen, du nutzt zwanzig, der Preis gilt für alle. Morgen könntest du verbrauchsbasiert zahlen, Capability für Capability, im Moment des Bedarfs. Centbruchteile für eine einzelne, gut gemachte Aktion.
Das stürzt drei historische SaaS-Vorteile in die Krise:
Erstens, die Oberfläche als Lock-in. Gehört die Oberfläche dem Agenten, gehört sie nicht mehr dir.
Zweitens, die Daten als Gefängnis. Wenn die Daten in persönlichen Vaults mit granularen Berechtigungen liegen, verliert das Gehege seine Macht.
Drittens, das Bundle. Wenn der Agent für jedes Stück das Beste komponieren kann, wird das monolithische Paket weniger attraktiv.
Dann bleibt nur eines: die Qualität der Capability. Mach eine Sache, mach sie besser als alle. Unix als technische Philosophie, aber auch als Geschäftsmodell. Elegant, und ein wenig erbarmungslos.
Die neue Alphabetisierung
Eine weitere Idee aus Mirchas Beitrag scheint mir unterschätzt: „nicht mit der KI sprechen können“ als neue Form von Analphabetismus.
Jahrzehntelang nannten wir „digitale Alphabetisierung“ eine sehr spezifische Sache: Oberflächen bedienen können. Klicken, ziehen, in Menüs navigieren, Formulare ausfüllen. Wir haben Kurse, Zertifikate, Berufe darum herum gebaut.
Wenn der Agent die Hauptoberfläche wird, schrumpft all das.
Die zentrale Kompetenz wird eine andere — vielleicht eine eher menschliche als technische. Eine Absicht klar ausdrücken können. Kontext geben können. Ein Problem zerlegen können. Ein Ergebnis beurteilen und iterieren können.
Hier liegt ein Paradox, das mich fasziniert. Es gibt Menschen, die nie wirklich Excel gelernt haben, aber chirurgisch genau erklären können, was sie wollen. Und es gibt Power User, die vor einem Agenten nicht wissen, was sie fragen sollen.
Die Landkarte der Kompetenzen zeichnet sich neu.
Und ja, die Gefahr eines neuen Digital Divide ist real. Aber es liegt auch eine seltene Chance darin: zum ersten Mal liegt der Vorteil nicht im „Maschinensprache sprechen“. Er liegt darin, gut zu denken und zu kommunizieren.
Die europäische Überraschung: Compliance als Capability
Es gibt einen Teil dieser Geschichte, den wir in Europa meiner Ansicht nach nicht ignorieren können.
Während das amerikanische Narrativ Regulierung gerne als Bremse sieht, bauen wir hier ein Regelwerk auf, das genau die wunden Nerven einer Welt aus zusammensetzbaren Capabilities trifft: AI Act, Cyber Resilience Act, Product Liability Directive, EAA.
In einem System, in dem ein Agent drei Capabilities von drei Anbietern kombiniert, wird die Frage „wer haftet, wenn etwas schiefgeht?“ zur Sprengladung.
Wenn das Gesetz Nachvollziehbarkeit, Sicherheit, Audit Trail, Erklärbarkeit verlangt, hört Compliance auf, nur ein Kostenfaktor zu sein. Sie wird zur differenzierenden Capability.
Das SBOM als Reisepass des Bauteils. Das Log der Agentenhandlungen als Anforderung. Transparenz als Wettbewerbsvorteil.
Und hier liegt eine fast ironische Wendung: viele historische Forderungen der Hackerkultur — Offenheit, Accountability, Überprüfbarkeit — werden gerade Gesetz. Vielleicht baut Europa, weniger als zu bremsen, gerade die Vertrauensinfrastruktur, ohne die die Welt der Agenten in ernsthaften Unternehmen nicht trägt.
2030, ein ganz normaler Tag (vielleicht)
Ich versuche, einen normalen Tag zu skizzieren, ohne in Science-Fiction abzudriften.
Du hast keine „Apps“ mehr auf dem Telefon. Du hast einen Agenten. Du sprichst mit ihm, schreibst, machst vielleicht eine Geste. Er orchestriert verschiedene Dienste, und du siehst die Kulissen fast nie. Ähnlich wie du heute beim Öffnen einer Seite nicht an Microservices denkst.
Die Oberfläche, die du siehst, wurde für dich, in diesem Moment, erzeugt. In fünf Minuten existiert sie nicht mehr.
Handel wird zum Gespräch. „Ich brauche Trail-Schuhe, Budget 150 Euro, gemischtes Gelände, am liebsten Vibram-Sohle.“ Der Agent kennt Größe, Historie, Vorlieben, vertrauenswürdige Quellen. Er schlägt drei Optionen mit einem maßgeschneiderten Vergleich vor. Du wählst, fertig.
Im Büro Ähnliches. Die PM öffnet kein Jira, sondern fragt: „Wie stehen wir bei Alpha?“ und bekommt Status, Risiken, nächste Schritte. Der Vertrieb navigiert nicht das CRM, er fragt: „Welche Deals sind diese Woche gefährdet?“ und erhält ein Briefing. Die Entwicklerin beschreibt ein Verhalten, das System generiert, testet, deployt.
Daten liegen in einem persönlichen, verschlüsselten, portablen Vault. Capabilities verlangen granulare, widerrufbare Berechtigungen, alles wird geloggt. Jede Aktion erzeugt einen Audit Trail.
In dieser Welt liegt der Wert in zwei Dingen: guten Capabilities und Vertrauen.
Ein nötiger Realismus
Ist es unvermeidlich? Ich weiß es nicht.
Übergänge verlaufen nie linear. Es wird enorme ökonomische Widerstände geben. Das Enterprise bewegt sich mit fast geologischer Langsamkeit. Gewohnheiten ändern sich langsamer als Pressemitteilungen. Und es gibt echte technische Probleme: Zuverlässigkeit bei komplexen Aufgaben, Fehlerbehandlung in Kompositionsketten, Sicherheit, Kosten.
Aber die Richtung, die Mircha scharfstellt, scheint mir schwer zu ignorieren, weil zwei konkrete Kräfte sie tragen.
Auf der einen Seite die kognitiven Kosten klassischer Oberflächen, die mit jedem neuen SaaS wachsen.
Auf der anderen die Fähigkeit der Agenten, diese Kosten zu senken, die mit jeder Modelliteration wächst.
Wenn der Abstand zwischen beiden eine Schwelle überschreitet, wird der Übergang praktisch, nicht ideologisch. Und für manche Anwendungsfälle ist diese Schwelle vielleicht schon überschritten.
Mircha schließt mit der Frage, wer diese Zukunft mit welchen Werten baut. Ich nehme eine andere Frage mit, etwas persönlicher und etwas zynischer: wer wird den Mut haben, für diese Zukunft zu bauen, im Wissen, dass das bedeutet, das Modell zu zerlegen, das heute die Gehälter zahlt?
Denn das Dilemma ist am Ende nicht technisch. Es ist der Wille, die Gegenwart zu kannibalisieren.
Und die Zeit, sich zu entscheiden, ist vermutlich nicht unendlich.
Dieser Beitrag entstand aus der Lektüre von „La morte dell’interfaccia utente come la conosciamo“ von Mircha Emanuel D’Angelo. Wer ihn nicht gelesen hat: meiner Ansicht nach lohnt es sich, dort zu beginnen.
Was du mitnimmst
SaaS-Anwendungen sehen aus Sicht der MCPs aus wie Mainframes: Monolithen, geboren, um zu monetarisieren, als Distribution teuer war.
Der Agent ist kein Assistent, er ist Betriebssystem: wer ihn kontrolliert, kontrolliert den Zugang zur Software.
Der Wert wandert von der App zur Capability: mach eine Sache, mach sie besser als alle.
In Europa ist Compliance kein Kostenfaktor mehr, sondern eine differenzierende Capability: Nachvollziehbarkeit und Audit Trail als Wettbewerbsvorteil.
Das Dilemma ist nicht technisch: es ist der Wille, das Modell zu kannibalisieren, das heute die Gehälter zahlt.
Fragen & Antworten
Warum führt der Tod der UI zum Tod der Idee der App?
Weil die App als Objekt (Name, Icon, Dock, Abo, Persönlichkeit) nur Sinn ergibt, solange es eine Oberfläche gibt, die sie umgrenzt. Wenn die Oberfläche verschwindet — ersetzt durch KI-Agenten, die mit mehreren Diensten gleichzeitig sprechen — wird die Grenze der App vom Problem nicht mehr gefordert. Sie bleibt nur, weil das Geschäftsmodell sie verlangt: Funktionen einpacken, das Gehen schmerzhaft machen. Dieses Gehege hält ohne UI nicht.
Was sind MCP-Server in diesem Kontext?
Laut Mircha Emanuel D’Angelo die neuen ‚Unix-Programme’: kleine spezialisierte Dienste, die KI-Agenten nach Bedarf zusammensetzen. Sie ersetzen die großen SaaS-Anwendungen — die von dort aus betrachtet wie Mainframes der 70er aussehen — durch modulare Architekturen. Jeder MCP macht eine Sache gut, die Agenten komponieren mehrere Flows in natürlicher Sprache.
Was ändert sich für SaaS-Unternehmen, die heute von Abos leben?
Das strukturelle Problem: wenn der Nutzer mit einem KI-Agenten interagiert, der Funktionen aus zehn verschiedenen MCPs zusammensetzt, gehört der wahrgenommene Wert nicht mehr der App, sondern dem Agenten. Die App wird zur API-basierten Commodity, leicht ersetzbar durch den Wettbewerber, der einen besseren MCP exponiert. Das Pricing muss vom Zugang zur Oberfläche zum Zugang zu Daten oder zu atomaren Funktionen wandern. Das seat-based-Modell fällt als eines der ersten.
Was sollte ein SaaS-Produkt heute tun, um nicht entmittelt zu werden?
Drei Schritte: (1) Funktionen über MCP exponieren, bevor die Kunden danach fragen, nicht erst hinterher; (2) klar trennen, was austauschbare Infrastruktur ist und was verteidigbarer Wert (vertragliche Beziehungen, exklusive Daten, vertikale Expertise); (3) aufhören, in UI-Polish zu investieren, wenn diese UI aufhört, der Eingangspunkt zu sein. Jeder Sprint, der einen Button statt eines MCP-Endpoints hinzufügt, ist 2026 ein verlorener Sprint.
Der Autor
