Die App als Bauanleitung: Wem gehört die UX, wenn Software auf dem Gerät entsteht?

Kurzfassung: Wenn Code fast nichts mehr kostet, könnten Hersteller künftig keine fertigen Apps mehr ausliefern, sondern eine Bauanleitung: eine Spezifikation, aus der das Gerät die App lokal baut. Damit wandert die Kontrolle über die UX vom Hersteller zuerst zur Plattform und im nächsten Schritt zum Nutzer, der ein persönliches UX-Theme mitbringt. Spec-Driven Development, Generative UI und erste Experimente von Betriebssystem-Anbietern zeigen, dass das kein Science-Fiction ist. Die eigentliche Frage ist eine Machtfrage: Wem gehört die Umgebung, in der UX entsteht?

Vor Kurzem brauchte ich auf einmal einen Überblick über meine Liquidität bis Anfang nächsten Jahres. Früher hätte ich dafür eine Excel-Tabelle aufgemacht. Diesmal habe ich Claude beschrieben, was ich haben will und warum, und Claude hat den Rest gemacht. Kurz darauf lief ein Werkzeug, das genau meine Frage beantwortet. Niemand hat es entworfen, niemand hat es getestet, niemand hat es ausgeliefert. Es war einfach da, zugeschnitten auf meinen Zweck.

Ich habe lange als Entwickler gearbeitet, dann als Product Owner, heute forsche ich zu UX. In jeder dieser Rollen war klar, wer die Oberfläche macht: der Hersteller. In diesem Moment war das nicht mehr klar. Und die Frage ließ mich nicht los: Wenn das für ein kleines Werkzeug geht, warum nicht für jede App? Und wenn die App erst auf meinem Gerät entsteht, wer entscheidet dann, wie sie sich bedient?

Was folgt, ist ausdrücklich ein Gedankenexperiment und keine Prognose. Aber eines, für das es erstaunlich viele Belege gibt.

Code kostet nichts mehr

Die Kosten für Code sinken doppelt. Zum einen in Geld: Was früher Wochen dauerte, dauert heute „eine Stunde oder weniger“, schreibt Anish Acharya von Andreessen Horowitz in seinem Essay Disposable Software. Sein Beispiel: Niemand hätte früher tausend Zeilen Code geschrieben, nur um Fotos mit drei Personen zu teilen. Heute lohnt sich auch Software mit winzigem Nutzen.

Zum anderen sinken die Kosten in Bildung. Programmieren zu können ist keine Eintrittshürde mehr. Wie schnell das geht, habe ich im Beitrag über Personal Software beschrieben: Eine Studierendengruppe baut in einer halben Stunde einen eigenen Shop über fremden Shopify-Shops, ein Projekt, das sie im ersten Semester noch aus Zeitgründen abbrechen musste.

Wenn Code billig wird, verschiebt sich, was wertvoll ist. Sean Grove von OpenAI hat das in seinem Vortrag The New Code zugespitzt. Code mache nur etwa 10 bis 20 % des Werts aus, den Entwickler liefern, der Rest sei strukturierte Kommunikation. Den generierten Code zu behalten und den Prompt wegzuwerfen, sei so, als würde man den Quellcode schreddern und das Binary versionieren. Sein Satz: „It's the source specification that's the valuable artifact.“

Unter dem Namen Spec-Driven Development wird daraus gerade eine Arbeitsweise. Die Spezifikation ist die dauerhafte Quelle, der Code ein Ableitungsprodukt.

Die These: Ausgeliefert wird die Bauanleitung

Denken wir das zu Ende. Wenn die Spezifikation das Wertvolle ist und der Code jederzeit neu erzeugt werden kann, warum sollte ein Hersteller dann noch Code ausliefern?

Meine These: Hersteller liefern künftig eine Bauanleitung statt eines Binarys. Die Bauanleitung beschreibt, was die App können soll, welche Daten sie braucht, welche Regeln gelten und welche Dienste sie aufruft. Das Gerät baut daraus die App, kompiliert sie und betreibt sie lokal.

Die Forschung hat dafür bereits Begriffe. Deepak Babu Piskala unterscheidet in Spec-Driven Development: From Code to Contract drei Stufen: spec-first, spec-anchored und spec-as-source. Bei der dritten Stufe ist die Spezifikation die einzige Quelle, aus der Code erzeugt wird. Mark Marron und Earl T. Barr gehen mit A-JIT noch weiter. Sie beschreiben Anwendungen als Verbund aus Code, Laufzeitumgebung und eingebettetem KI-Agenten, der wie ein JIT-Compiler arbeitet: Er spezialisiert „Logik, Workflows und Tool-Schnittstellen auf die konkreten Bedürfnisse des Endnutzers“ und kann fehlende Funktionen zur Laufzeit selbst bauen.

Wichtig ist die Abgrenzung zu Generative UI, wie wir sie heute kennen. Wenn ein Chatbot eine Antwort als interaktive Karte statt als Text ausgibt, ist das eine generierte Oberfläche für eine einzelne Anfrage. Die These hier reicht weiter. Sie betrifft die ganze App: Navigation, Abläufe, Fehlerbehandlung, Einstellungen. Nicht die Antwort wird generiert, sondern das Produkt.

Und damit ändert sich die Frage, die mich als UX-Forscher interessiert. Wenn die App erst auf dem Gerät entsteht, wer legt dann fest, wie sie sich bedient?

Stufe 1: Die Plattform übernimmt die UX

Die naheliegende erste Antwort: die Plattform. Apple, Google und Microsoft bauen die App aus der Bauanleitung nach ihren eigenen Regeln. Jede App sieht aus und bedient sich wie das System. Konsistenz, Barrierefreiheit und Sicherheit liegen zentral an einer Stelle, statt in tausenden Apps jeweils neu und unterschiedlich gut gelöst zu werden.

Ein frühes Muster dafür gibt es schon. Googles A2UI ist ein Protokoll, mit dem ein KI-Agent eine Oberfläche beschreibt, ohne sie selbst zu programmieren. A2UI ist „ein deklaratives Datenformat, kein ausführbarer Code“. Der Client hält einen Katalog geprüfter, freigegebener Komponenten vor, und der Agent darf nur anfordern, was in diesem Katalog steht. Gerendert wird mit den nativen Komponenten des Clients. Das ist Stufe 1 im Kleinen: Der Agent sagt, was gebraucht wird, die Plattform entscheidet, wie es aussieht.

Auch auf Betriebssystem-Ebene gibt es erste Experimente. Nothing, einer der ersten Smartphone-Hersteller mit diesem Ansatz, hat im September 2025 Playground vorgestellt, ein Werkzeug, mit dem Nutzer per Prompt kleine Apps bauen, die als Essential Apps auf dem Telefon laufen. Gründer Carl Pei begründet das so: „With breakthroughs in AI, we believe that operating systems will change and become more personal.“ Bisher sind das vor allem Widgets für den Homescreen, keine vollwertigen Apps. Aber die Richtung ist gesetzt.

Für Hersteller hat Stufe 1 eine harte Konsequenz. Wenn die Plattform die Oberfläche baut, verkaufen sie keine Oberfläche mehr, sondern Fähigkeiten: eine API, Daten, Abwicklung. Chris Loy bringt es in AI makes interfaces disposable auf den Punkt: „The only durable part of your product is the service layer.“ Das Frontend, in das UX-Teams heute den Großteil ihrer Arbeit stecken, wird zur Verhandlungsmasse.

Stufe 2: Das persönliche UX-Theme

Stufe 1 löst ein Problem und schafft ein neues: Die Plattform baut für einen gedachten Durchschnittsnutzer. Das ist dieselbe Massenware wie heute, nur zentraler. Die spannendere Frage ist, was passiert, wenn ich der Plattform sage, wie ich arbeiten will.

Ich nenne das ein persönliches UX-Theme. Gemeint sind nicht Farben und Schriften, das kann jedes Design-Theme. Ein UX-Theme beschreibt Interaktionslogik:

• Bestätigung: Will ich bei jeder Löschung gefragt werden oder lieber ein Rückgängig-Knopf?
• Automatik: Soll die App Vorschläge nur anzeigen oder direkt ausführen?
• Informationsdichte: Eine ruhige Ansicht mit wenigen Elementen oder alles auf einen Blick?
• Navigation: Tabs, Suche, Tastaturkürzel oder Sprache?

Die Plattform wendet dieses Profil auf jede App an, die sie aus einer Bauanleitung baut. Meine Banking-App, mein Kalender und mein Ticket-Shop verhalten sich dann nach denselben Regeln, nämlich meinen.

Spannend wird es, wenn Gruppen Themes teilen. Ein Theme für ältere Menschen mit großer Schrift, wenigen Optionen pro Bildschirm und ausführlichen Bestätigungen. Eins für Power-User mit hoher Dichte und Tastatursteuerung. Eins für Menschen mit motorischen Einschränkungen, mit großen Zielflächen und ohne Drag-and-drop.

Dass das funktioniert, ist seit fast zwanzig Jahren belegt. Krzysztof Gajos und Kollegen haben mit SUPPLE Oberflächen automatisch aus einer abstrakten Beschreibung und einem Fähigkeitsprofil erzeugt. In ihrer CHI-Studie von 2008 waren Menschen mit motorischen Einschränkungen mit den generierten Oberflächen 26,4 % schneller und machten 73 % weniger Fehler als mit den Standardoberflächen der Hersteller, und sie bevorzugten sie deutlich. Die ausführliche Fassung von 2010 zeigt, dass Geschwindigkeit, Genauigkeit und Zufriedenheit signifikant steigen.

Jakob Nielsen ordnet das historisch ein. In Individualizing UX beschreibt er fünf Stufen immer engerer Zielgruppen: Zielgruppe, Personas, Customization, Personalisierung und schließlich Individualisierung. Mit Generative UI erzeuge der Computer „eine völlig neue Oberfläche für jeden Nutzer“. Den Unterschied zwischen Customization und Personalisierung macht er an einer Frage fest, die auch hier die zentrale ist: Wer ist es, der die Oberfläche verändert?

Bleibt die praktische Frage, wie ein UX-Theme entsteht. Niemand füllt gern einen Fragebogen mit fünfzig Präferenzen aus. Yi-Hao Peng, Jeffrey Bigham, Jason Wu und Kollegen zeigen in Efficient Personalization of Generative User Interfaces einen eleganten Weg: Sie beschreiben neue Nutzer als Mischung bereits bekannter Nutzer, statt sie gegen ein festes Raster von Designkriterien abzufragen. Mit nur acht Beispielen sagten sie Präferenzen besser vorher als ein allgemeines Sprachmodell, und in einer Studie mit zwölf neuen Designern gewann ihr Verfahren 60 % der Vergleiche. Übertragen heißt das: Ein UX-Theme muss man nicht von Grund auf definieren. Man startet mit dem Theme einer Gruppe und passt es an.

Was das für UX als Disziplin bedeutet

Wenn die Oberfläche bei jedem Nutzer anders entsteht, verschiebt sich unsere Arbeit. Kate Moran und Sarah Gibbons von der Nielsen Norman Group beschreiben das als Weg „from designing interfaces to designing outcomes“ (Generative UI and Outcome-Oriented Design). Wir gestalten weniger einzelne Screens und definieren mehr Ziele, Regeln und Profile. Menschen, so Moran und Gibbons, müssen der generierten Oberfläche Leitplanken geben.

Dass generierte Oberflächen gut genug sein können, zeigt eine Studie von Google Research. Im zugehörigen Paper bevorzugten Bewerter generierte Oberflächen in 82,8 % der Vergleiche gegenüber einer Markdown-Antwort. Von Menschen gestaltete Websites lagen aber weiter vorn: 1.756 gegenüber 1.711 Elo-Punkten. Gutes Design ist also nicht überflüssig, es wandert nur an eine andere Stelle.

Die drei Stufen im Vergleich:

	Heute	Stufe 1: Plattform	Stufe 2: Nutzer
Was wird ausgeliefert?	Fertige App	Bauanleitung	Bauanleitung
Wer bestimmt die UX?	Hersteller	Plattform	Nutzer über UX-Theme
Stärke	Markenerlebnis, Kontrolle	Konsistenz, Barrierefreiheit	Passung zum Einzelnen
Risiko	Massenware	Machtkonzentration	Vorhersagbarkeit, Support
Arbeit von UX-Teams	Screens gestalten	Regeln und Komponenten definieren	Ziele, Profile und Messung definieren

Ich will die Einwände selbst stellen, denn sie sind durchaus berechtigt.

Spec ist auch Code. Eine Spezifikation, die präzise genug ist, dass eine Maschine daraus zuverlässig eine App baut, ist faktisch Code in einer höheren Sprache. Die Frage verschiebt sich dann nur: Wie viel UX muss in der Bauanleitung stehen? Steht zu wenig drin, ist die App beliebig. Steht zu viel drin, hat der Hersteller die Oberfläche wieder in der Hand.

Vorhersagbarkeit. Wenn jede Generierung anders ausfällt, leidet die Erlernbarkeit. Wer ruft beim Support an, wenn niemand dieselbe App sieht wie die Person am anderen Ende? Ein UX-Theme muss deshalb stabil sein: einmal gebaut, bleibt die App, bis ich etwas ändere.

Testbarkeit und Haftung. Wie testet man eine Oberfläche, die jeder anders sieht? Und wer ist verantwortlich, wenn die lokal gebaute App einen Fehler macht: der Hersteller der Bauanleitung, die Plattform oder das Modell?

Dazu kommt eine Frage, die mich seit dem Beitrag über UX und Usability beschäftigt. Ein UX-Theme, das nur Klicks und Bestätigungen regelt, optimiert Usability. Wo bleiben Freude, Stolz und Vertrauen, wenn jede Oberfläche aus denselben Regeln entsteht?

UX wird von einem Produktmerkmal zu einer Eigenschaft der Umgebung. Wir sollten jetzt klären, wem diese Umgebung gehört.

Fazit: Die offene Machtfrage

Am Ende stehen zwei sehr unterschiedliche Zukünfte. In der einen baut die Plattform jede App nach ihren Regeln. Das ist konsistent, barrierearm und sicher, und es gibt Apple und Google noch mehr Kontrolle, als sie heute schon haben. Hersteller werden zu API-Lieferanten, Nutzer zu Gästen in einer Umgebung, die ihnen nicht gehört.

In der anderen bringen Nutzer ihr UX-Theme mit, und die Plattform setzt es nur um. Das ist die Richtung, die Ink & Switch mit Malleable Software beschreiben: Anpassung soll „am Ort der Nutzung passieren, nicht durch Entwicklungsteams in fernen Konzernen“. Stattdessen, so Geoffrey Litt und Kollegen, hätten wir Geräte bekommen, die „weit weg gebaut, versiegelt und unveränderlich“ sind.

Ich halte die zweite Zukunft für die wünschenswerte. Nicht, weil jeder sein eigenes Theme bauen will, sondern weil die Frage, wer die Regeln setzt, eine Frage digitaler Souveränität ist. Technisch ist beides bald möglich. Entscheiden wird es sich daran, wer die Formate für Bauanleitungen und UX-Themes definiert, und ob sie offen sind.

Deshalb meine Fragen an dich: Welches UX-Theme würdest du für dich definieren? Und würdest du die Kontrolle lieber der Plattform geben oder selbst behalten? Schreib es mir, zum Beispiel auf LinkedIn. Und wenn du solche Gedankenexperimente regelmäßig lesen willst, abonniere meinen Newsletter.