Wenn Software so lange lebt wie das Problem

Der größte Teil der Software, die nützlich sein könnte, wird nie gebaut.

Nicht weil sie technisch unmöglich wäre, sondern weil das Problem zu klein ist. Ein Werkzeug, das Daten für eine Migration ordnet, einen Stapel Verträge prüft oder einen zweiwöchigen Vorgang koordiniert, kann viele Stunden sparen und trotzdem kein Softwareprojekt rechtfertigen. Es zu entwerfen, zu entwickeln, bereitzustellen und zu warten kostet mehr, als mit mehreren Tabellen zu leben.

Codegenerierung verschiebt diese Grenze. Wenn eine funktionierende Oberfläche nicht mehr wochenlange Arbeit erfordert, können Anwendungen entstehen, die nie zu Produkten werden müssen. Sie werden für ein Ziel geschaffen, leben so lange wie dieses Ziel und werden danach aufgegeben.

Allmählich spricht man von Single-Use-Apps, Disposable Apps oder kurzlebiger Software. Der Begriff ist noch nicht gefestigt. Die dahinterstehende Frage ist es wert: Wenn das Erstellen von Software nicht mehr der teure Teil ist, welche Software sollte dann noch dauerhaft sein?

Software musste sich auf Dauer lohnen

Klassische Softwareentwicklung geht von einer vernünftigen Erwartung aus: Eine Anwendung muss oft genug genutzt werden, damit sich der Aufwand für ihre Entwicklung auszahlt.

Deshalb versuchen Produkte, viele Anwendungsfälle abzudecken. Sie bieten Konfiguration, Berechtigungen, Importfunktionen, Anleitungen und Oberflächen für unterschiedliche Zielgruppen. Diese Allgemeingültigkeit verteilt die Kosten auf Tausende Menschen und mehrere Jahre, zwingt aber jeden Nutzer dazu, sein Problem an das Werkzeug anzupassen.

Ein einmaliger Bedarf fällt aus dieser Rechnung heraus. Braucht ein Team während einer Migration eine ganz bestimmte Ansicht, quetscht es diese meist in Excel, kombiniert mehrere Werkzeuge oder beantragt eine interne Entwicklung, die vermutlich nie Priorität bekommt.

Einmalanwendungen kehren die Rechnung um. Sie fragen nicht, wie viele Jahre die Software leben wird, sondern ob der Wert der gelösten Aufgabe höher ist als die Kosten, sie jetzt zu erzeugen. Das Ergebnis wegzuwerfen ist keine Verschwendung mehr, wenn der Neubau weniger kostet als das Erlernen, Konfigurieren und Warten eines allgemeinen Werkzeugs.

Im August 2025 verwendete Anish Acharya den Ausdruck Disposable Software für kleine persönliche Anwendungen, die zuvor wirtschaftlich nicht sinnvoll gewesen wären. Dabei ging es nicht um besonders neuartigen Code. Neu war, dass ein Werkzeug wertvoll sein konnte, ohne skalieren, Geld verdienen oder überleben zu müssen.

Unter demselben Namen stecken drei verschiedene Ideen

Ein Teil der Verwirrung entsteht dadurch, dass sehr unterschiedlich funktionierende Systeme gleichermaßen als generierte App bezeichnet werden.

Die unmittelbarste Variante besteht darin, eine konventionelle Anwendung zu erzeugen und später zu verwerfen. Ein Modell schreibt das anfängliche HTML, JavaScript oder Backend. Das Ergebnis lässt sich wie jede andere Software ausführen, untersuchen und verändern. Seine Lebensdauer ist bewusst kurz, nicht weil es keinen Code gäbe.

Einen Schritt weiter geht die generative Benutzeroberfläche. Statt immer mit Text zu antworten oder eine vorab entworfene Ansicht zu zeigen, baut das System eine zur Anfrage passende Darstellung: eine Tabelle, einen Simulator, ein Diagramm oder eine Kombination aus Steuerelementen. Google stellte diese Richtung als Generative UI vor und begann Ende 2025, sie in Gemini und über Dynamic View im KI-Modus der Suche zu testen.

Hier wird nicht unbedingt ein Produkt erzeugt, das jemand behalten wird. Erzeugt wird die beste Form, mit einer Antwort zu interagieren.

Die dritte Variante ist wesentlich radikaler: Das Modell verkörpert das Verhalten der Anwendung, während ein Mensch sie benutzt.

Anthropic untersuchte diese Idee mit Imagine with Claude. In diesem Versuch gab es vor Beginn keine vollständig vorbereitete Funktionalität. Claude baute die Software in Echtzeit und passte sie mit jeder neuen Interaktion an. Ein Teil dieser Arbeit tauchte später in einer stärker begrenzten Form wieder auf: als interaktive Diagramme und Visualisierungen innerhalb eines Gesprächs.

Mirage, ein Prototyp von Daniel Mewes, entfernt fast die gesamte Anwendung. Das Modell erzeugt das HTML einer Ansicht. Klickt jemand auf eine Schaltfläche, erhält es diese Interaktion und erzeugt die nächste Ansicht. Es gibt keine dauerhafte Geschäftslogik, die den Übergang bestimmt. Das Modell stellt sich vor, was geschehen sollte.

In einer Demonstration können alle drei Ansätze gleich wirken. Technisch sind sie es nicht. Im ersten wird Software erzeugt. Im zweiten wird eine Oberfläche auf vorhandenen Fähigkeiten erzeugt. Im dritten versucht das Modell, selbst die Software zu sein.

Ein Fall, in dem die Idee tatsächlich sinnvoll ist

Nehmen wir eine Infrastrukturmigration. Einige Tage lang muss das Team ein Cloud-Inventar, einen Kostenexport und eine Liste der Verantwortlichen zusammenführen. Es soll Ressourcen ohne Eigentümer finden, Abhängigkeiten gruppieren und einen Maßnahmenplan erstellen.

Eine dauerhafte Anwendung für diesen Prozess müsste künftige Anbieter, andere Datenschemata und unzählige Ausnahmen unterstützen. Daraus würde ein umfangreiches Produkt. Der aktuelle Vorgang ist jedoch klar begrenzt: drei bekannte Quellen, ein kleines Team und ein eindeutiges Ergebnis.

Eine Single-Use-App könnte für genau diese Daten einen Prüfbereich schaffen, passende Filter anbieten und den endgültigen Plan exportieren. Nach der Migration ist die Oberfläche nutzlos. Das bereinigte Inventar, die Entscheidungen und das Änderungsprotokoll sind es nicht.

Dieser Unterschied ist entscheidend. Die Anwendung darf vorübergehend sein; die Wahrheit, die sie verarbeitet, sollte es nicht sein.

Das Muster passt, wenn eine Aufgabe Anfang und Ende hat, die Daten kontrolliert sind, Fehler erkannt werden können und ein Ergebnis außerhalb des Werkzeugs erhalten bleibt. Es passt weniger gut, wenn das Programm selbst das führende System sein, Hunderte Nutzer koordinieren oder schwer umkehrbare Aktionen ausführen muss.

Die plausibelste Architektur ist keine halluzinierte App

Die robusteste Form dieser Idee trennt eine dauerhafte von einer temporären Ebene:

Ziel + Kontext
        ↓
für die Aufgabe erzeugte Oberfläche
        ↓
erlaubte Aktionen und Komponenten
        ↓
dauerhafte APIs, Regeln und Daten

Das Modell entscheidet, welche Informationen in diesem Moment hilfreich sind und welche Steuerelemente gebraucht werden. Es entscheidet nicht allein, wie eine Rechnung berechnet wird, wer eine Zahlung genehmigen darf oder wo der Verlauf gespeichert wird. Diese Aufgaben bleiben bei konventionellen Diensten.

Man könnte es stabiler Kern, wegwerfbare Oberfläche nennen.

Diese Trennung löst mehrere Probleme gleichzeitig. Die Daten überleben die Sitzung. Berechtigungen hängen nicht vom Prompt ab. Wichtige Aktionen können geprüft und protokolliert werden. Die Oberfläche kann sich verändern, ohne dass das System, das die Wahrheit enthält, neu erzeugt werden muss.

Sie erklärt auch das wachsende Interesse an deklarativen Ansätzen. A2UI, im Dezember 2025 von Google als offenes Projekt vorgestellt, erlaubt es einem Agenten, eine Oberfläche durch strukturierte Daten zu beschreiben. Die Hostanwendung übersetzt diese Beschreibung in Komponenten, die sie bereits kennt.

Das Modell kann eine Tabelle, eine Auswahl oder ein Formular anfordern, ohne beliebiges JavaScript senden zu müssen. Das Produkt behält die Kontrolle über Gestaltung, Barrierefreiheit und verfügbare Aktionen. Dieser Ansatz ist weniger frei als die Erzeugung beliebigen Codes, aber gerade diese Einschränkung macht ihn für den Produktiveinsatz vernünftiger.

Das schwierige Problem ist nicht das Zeichnen der Oberfläche

Eine Demonstration generativer Oberflächen konzentriert sich meist auf den Moment, in dem etwas Visuelles erscheint. Dieser Teil lässt sich am einfachsten zeigen und vermittelt am stärksten den Eindruck von Neuheit. Das Risiko liegt jedoch woanders.

Der entscheidende Aufwand beginnt, sobald die Oberfläche etwas Reales tun soll:

• Zustand über Sitzungen hinweg erhalten;
• Nutzer und Berechtigungen unterscheiden;
• bei denselben Daten dieselbe Berechnung liefern;
• einen Ausfall des Modells überstehen;
• erklären, welche Aktion ausgeführt wurde und warum;
• Informationen rückgängig machen oder wiederherstellen können;
• auch bei Veränderungen zugänglich und verständlich bleiben.

Ein Gesprächskontext ist keine Datenbank. Eine plausible Vorhersage ist kein Zustandsübergang. Eine überzeugende Oberfläche beweist nicht, dass die angezeigten Daten aus der richtigen Quelle stammen.

Mirage macht diese Grenzen sichtbar, weil der Prototyp nicht versucht, sie zu verbergen. Er verliert seine Daten, sobald die Sitzung endet, kann Informationen unerwartet verändern und scheitert schließlich, wenn der Kontext voll ist. Als Experiment ist das nützlich: Es zeigt, wie weit ein Modell Software simulieren kann. Als Architektur zeigt es auch, warum Simulation nicht genügt.

Generierung senkt die Kosten der ersten Version. Vertrauen, Integration und Betrieb haben weiterhin einen anderen Preis.

Was wir wahrscheinlich zuerst sehen werden

Die nächste Veränderung wird nicht das Verschwinden von Anwendungen sein. Verschwinden werden zunächst einige ihrer festen Ansichten.

Produkte mit wertvollen Daten und APIs werden für jede Aufgabe andere Ansichten bauen können. Ein Finanzsystem kann sein Hauptbuch und seine Berechtigungen unverändert lassen und zugleich eine eigene Oberfläche erzeugen, um eine Abweichung zu untersuchen. Eine Betriebsplattform kann alle nötigen Bedienelemente für einen konkreten Vorfall in einer Ansicht zusammenführen und diese nach Abschluss wieder entfernen.

Auch Software für den internen Long Tail wird zunehmen: Abstimmungen, Migrationen, Prüfungen und vorübergehende Prozesse, die nie einen Platz auf der Roadmap rechtfertigten. Sie werden die Kernsysteme nicht ersetzen. Sie werden darauf aufbauen, um den besonderen Abschnitt zu lösen, der heute in einer Tabelle endet.

Manche dieser Werkzeuge werden mit einem ausdrücklichen Ablaufdatum entstehen. Am Projektende werden ihre Zugangsdaten widerrufen, das Ergebnis archiviert und die Bereitstellung gelöscht. Damit Software wirklich vorübergehend ist, müssen es auch ihre Infrastruktur und Zugänge sein – nicht nur ein verlassenes Repository.

Auch die Produktarbeit wird sich verlagern. Statt ausschließlich Oberflächen zu entwerfen, müssen Teams den Raum gestalten, in dem das Modell sie zusammensetzen darf: welche Komponenten existieren, welche Aktionen erlaubt sind, welche Daten verlässlich sind und welche Zustände niemals erzeugt werden dürfen.

Dauerhaftes wird wertvoll bleiben

Eine stabile Oberfläche schafft Erinnerung. Nachdem wir sie mehrmals benutzt haben, wissen wir, wo jede Funktion liegt, was beim Anklicken geschieht und wie wir den Ablauf einer anderen Person erklären. Diese Vorhersehbarkeit ist bei häufigen und kritischen Aufgaben wertvoll.

Für jede Sitzung ein anderes Erlebnis zu erzeugen hat ebenfalls Kosten. Es verursacht Verzögerungen, erschwert den Support und vervielfacht die Kombinationen, die geprüft werden müssten. Manchmal ist das beste Formular dasselbe Formular wie immer, weil Millionen Menschen bereits wissen, wie es funktioniert.

Single-Use-Apps bedeuten nicht das Ende gewarteter Software. Sie erweitern den Bereich, in dem es sich lohnt, etwas zu bauen. Probleme, die zu klein, kurz oder spezifisch für ein Produkt sind, können eine eigene Oberfläche bekommen.

Das Web organisierte einen großen Teil der Software um Seiten. Mobilgeräte organisierten sie um Anwendungen. Die generative Oberfläche schlägt vor, einen Teil um Absichten zu organisieren: Zuerst entsteht der Bedarf, dann die Form der Interaktion.

Darunter werden weiterhin Systeme gebraucht, die nicht improvisieren. Die Frage lautet nicht, ob Software dauerhaft oder wegwerfbar sein soll, sondern was das System noch wissen muss, wenn die Oberfläche nicht mehr existiert.

Quellen

• Anish Acharya: Disposable Software
• Anthropic: Vorstellung von Imagine with Claude
• Anthropic: interaktive Visualisierungen in Claude
• Google Research: Generative UI
• Google Developers: Vorstellung des A2UI-Projekts
• Google Cloud: Ansätze für generative Benutzeroberflächen
• Daniel Mewes: Mirage, eine Ansicht nach der anderen halluziniert