Runway hat ein System namens Solaris angekündigt und bezeichnet es als erstes Modell einer neuen Kategorie, die das Unternehmen Interface World Models nennt. Der Ansatz unterscheidet sich grundlegend von allem, was in der Frontend-Entwicklung üblich ist: Es wird kein Code ausgeführt, der eine Oberfläche aufbaut. Stattdessen erzeugt das Modell die Benutzeroberfläche Bild für Bild, während man sie bedient.

Anders gesagt: Was auf dem Bildschirm erscheint, ist keine gerenderte Anwendung mit Buttons, Zustandsverwaltung und Datenanbindung, sondern eine fortlaufend generierte Bildfolge, die auf Eingaben reagiert. Ein Klick ist dann kein Event, das eine Funktion auslöst, sondern ein Signal, aus dem das Modell den nächsten plausiblen Bildschirminhalt ableitet.

Warum der Begriff World Model hier auftaucht

Der Ausdruck World Model – also Weltmodell – stammt aus der KI-Forschung und beschreibt Systeme, die eine interne Vorstellung davon aufbauen, wie sich eine Umgebung auf Aktionen hin verändert. Bekannt geworden ist das Prinzip durch Modelle, die spielbare Videosequenzen erzeugen: Man steuert, und das Modell errechnet den nächsten Frame, ohne dass dahinter eine klassische Spiel-Engine läuft.

Solaris überträgt diese Idee auf Software-Oberflächen. Die "Welt", die das Modell simuliert, ist eine Anwendung: Menüs, Formulare, Listen, Detailansichten. Das ist konsequent gedacht, verschiebt aber auch das Problem. Eine Spielszene darf abweichen, ohne dass etwas kaputtgeht. Eine Rechnungsübersicht darf das nicht.

Was daran für Projekte interessant ist

Der naheliegendste Nutzen liegt beim Prototyping. Klickdummies – also durchklickbare Attrappen einer Anwendung ohne echte Funktion – sind heute entweder statische Bildstrecken in einem Design-Tool oder bereits handgebauter Code. Beides kostet Zeit, und beides wird bei jeder Änderung erneut angefasst.

Ein Modell, das Oberflächen im Betrieb erzeugt, könnte diesen Schritt verkürzen: Konzepte wären begehbar, bevor eine Komponentenbibliothek existiert. Für Workshops, für die Abstimmung mit Fachabteilungen und für frühe Nutzertests ist das ein realer Vorteil, weil Diskussionen über Wortmodelle und Wireframes oft an unterschiedlichen Vorstellungen scheitern.

Interessant ist der Ansatz außerdem als Explorationswerkzeug. Wer mehrere Interaktionsideen gegeneinander stellen will, kann Varianten schneller sichtbar machen als über gebaute Oberflächen. Der Wert liegt dabei im Verwerfen, nicht im Behalten.

Wo die Grenzen liegen

Runway hat Solaris vorgestellt; belastbare Aussagen über Qualität, Latenz, Auflösung oder Kosten im Dauerbetrieb lassen sich daraus nicht ableiten. Unabhängig davon ergeben sich aus dem Prinzip selbst mehrere Einschränkungen, die man beim Einordnen mitdenken sollte.

  • Determinismus. Geschäftsanwendungen müssen bei gleicher Eingabe gleich reagieren. Ein generatives Modell liefert plausible, nicht garantierte Ergebnisse. Für ein Freigabe- oder Buchungsverfahren ist das keine tragfähige Grundlage.
  • Datenwahrheit. Eine generierte Tabelle zeigt Zahlen, die aussehen wie Daten. Ohne Anbindung an führende Systeme sind sie erfunden. Das ist im Prototyp harmlos und im Produktivbetrieb ein Haftungsthema.
  • Wartbarkeit. Ein Frame-Strom hinterlässt kein Artefakt, das ein Team weiterentwickeln, versionieren und testen kann. Genau das ist aber der Zweck von Code.
  • Barrierefreiheit. Screenreader und Tastaturnavigation setzen semantische Struktur voraus – Beschriftungen, Rollen, Fokusreihenfolge. Ein Bild hat davon nichts.
  • Nachvollziehbarkeit. Prüfbarkeit, Protokollierung und Fehleranalyse verlangen definierte Zustände. Ein generiertes Interface bietet sie nicht von sich aus.

Wie man das heute sinnvoll einsetzt

Der pragmatische Weg ist eine klare Trennung: Generative Oberflächen dort, wo etwas gezeigt und diskutiert werden soll – gebauter Code dort, wo etwas verlässlich funktionieren muss. In der Praxis heißt das, die Grenze bewusst zu ziehen.

  1. Frühe Phase: Ideen und Interaktionsmuster generativ durchspielen, Entscheidungen dokumentieren, Ergebnisse als Anforderungen festhalten.
  2. Übergang: Aus dem, was überzeugt hat, echte Komponenten ableiten – mit Design-System, Zuständen, Fehlerfällen und Testabdeckung.
  3. Umsetzung: Datenanbindung, Rechte, Protokollierung und Barrierefreiheit im Code lösen, nicht im Bild.

Wichtig ist die Erwartungssteuerung im Projekt. Ein flüssig bedienbarer generierter Prototyp wirkt weiter fertig, als er ist. Wenn Auftraggeber daraus ableiten, die Anwendung sei zu neunzig Prozent gebaut, entstehen Konflikte über Budget und Termine, die nichts mit der Technik zu tun haben. Prototypen sollten deshalb als solche gekennzeichnet und ihre Reichweite ausgesprochen werden.

Eine Verschiebung, keine Ablösung

Was sich abzeichnet, ist eine Verschiebung im Werkzeugkasten, kein Ende der Frontend-Entwicklung. Aufwand wandert von der Herstellung erster sichtbarer Ergebnisse hin zur Präzisierung von Anforderungen, zur Architektur und zur Qualitätssicherung. Wer Oberflächen billig erzeugen kann, muss umso genauer entscheiden, welche davon gebaut werden – und warum.

Für Web- und Softwareprojekte bedeutet das konkret: Generative Interfaces sind kurzfristig vor allem ein Beschleuniger in der Konzeptphase und für Abstimmungen, nicht ein Ersatz für die Umsetzung. Wer sie einsetzt, sollte den Übergang von Prototyp zu wartbarem Code von Anfang an planen, damit aus einem überzeugenden Bild kein technisches Versprechen wird, das niemand halten kann. Beobachten lohnt sich – die Entscheidung über Produktivsysteme fällt weiterhin bei Code, Daten und Verantwortlichkeiten.

Quellen