Was wäre, wenn ein Betriebssystem seine Apps selbst baut?

Ich habe in letzter Zeit einige KI-Tools ausprobiert, um mir UI-Komponenten, Landing Pages und Ähnliches generieren zu lassen. Die Ergebnisse waren ehrlich gesagt erschreckend gut.

Gleichzeitig arbeite ich viel mit KI-Agenten, vor allem mit Coding-Agenten. Und da ist mir etwas aufgefallen: Diese Agenten nutzen ganz normale Kommandozeilen-Befehle. Sie suchen damit nach Dateien, legen neue an, lesen Logs. Und wenn es für ein Problem kein passendes Werkzeug gibt, schreiben sie sich einfach ein eigenes Skript, führen es aus und schmeißen es danach wieder weg.

Das fand ich spannend. Der Agent installiert nicht vorher zehn Tools, nur für den Fall, dass er sie mal braucht. Er baut sich genau das, was er gerade braucht, und räumt danach wieder auf.

Und dann kam mir die Frage: Warum machen wir das eigentlich nur für Agenten? Warum nicht auch für Menschen?

Die Idee

Stell dir ein Betriebssystem vor, das nur das Nötigste mitbringt. Eine Basis, damit es läuft, und eine grafische Oberfläche. Keine vorinstallierten Apps, kein Ordner voller Programme, die man vor drei Jahren einmal benutzt hat.

Stattdessen sagst du dem System einfach, was du gerade erledigen willst, und es baut dir die passende Anwendung dafür. Wenn du fertig bist, verschwindet sie wieder.

Damit meine ich kein Betriebssystem, das Treiber und Hardware neu erfindet. Darunter kann ganz normal Linux laufen. Mir geht es um die Schicht, mit der der Nutzer arbeitet: Die fühlt sich an wie ein Betriebssystem, aber sie bringt keine Apps mit, sondern baut sie bei Bedarf.

Ein Beispiel

Ich starte mein System und schreibe: „Erfasse die folgende Einkaufsliste: Eier, Milch, Brot, Obst und Gemüse.“

Das System erzeugt mir eine kleine Anwendung mit genau dieser Liste. Ich kann die Einträge ändern oder neue hinzufügen. Mehr braucht es in dem Moment nicht.

Am nächsten Tag fällt mir ein, dass noch Käse fehlt. Ich sage „Füge Käse zur Einkaufsliste hinzu“, und das System baut keine neue App, sondern nimmt die bestehende Liste und ergänzt sie. Wenn der Einkauf erledigt ist, brauche ich die App nicht mehr. Sie kann weg.

Genau das ist für mich der Kern: Anwendungen entstehen, wenn sie gebraucht werden. Sie werden weiterverwendet oder erweitert, solange sie nützlich sind. Und sie verschwinden, wenn die Aufgabe erledigt ist.

Wer steuert das Ganze?

Wenn man das zu Ende denkt, braucht so ein System etwas, das im Hintergrund alles zusammenhält. Bei einem klassischen Betriebssystem ist das der Kernel. Er entscheidet, welches Programm wann laufen darf, wie viel Speicher es bekommt und worauf es zugreifen darf.

In meiner Vorstellung gibt es so etwas hier auch, nur eben für KI. Ich nenne es mal einen KI-Kernel. Der Linux-Kernel darunter bleibt, wie er ist. Der KI-Kernel sitzt eine Ebene höher und übernimmt für die generierten Apps die Rolle, die der klassische Kernel für normale Programme hat. Er versteht, was der Nutzer will, und entscheidet, welches Modell und welche Werkzeuge dafür nötig sind. Er prüft, was eine App darf und was nicht. Und er kümmert sich darum, dass Apps wiederverwendet oder wieder aufgeräumt werden.

Ich bin nicht der Erste

Ganz ehrlich: Ich bin mit dieser Idee nicht allein, und erfunden habe ich sie auch nicht. Es gibt schon Projekte, die in eine ähnliche Richtung gehen. Spannend finde ich, wie unterschiedlich sie das Ganze angehen.

LLM OS ist am nächsten an meiner Vorstellung. Es ist ein Open-Source-Betriebssystem, das ohne eine einzige vorinstallierte App startet. Jede Anwendung wird aus einem Prompt generiert. Die KI schreibt dafür Code, und damit der keinen Schaden anrichten kann, läuft jede App abgeschottet in einer Sandbox und darf nur das, was man ihr vorher erlaubt hat.

vibeOS geht einen anderen Weg. Es beschreibt sich selbst als KI-natives Betriebssystem, in dem Claude Code den Rechner steuert, von der Hardware bis zur Oberfläche. Hier bekommt also ein Coding-Agent sehr viel Kontrolle, und die Apps, die auf dem Bildschirm erscheinen, sind Code, den dieser Agent schreibt. Wer das nicht direkt auf seinem Rechner laufen lassen will, kann eine Docker-Version nutzen.

Auch Google arbeitet daran, nur eben nicht als Betriebssystem: Mit „Dynamic View“ in Gemini wird für eine Anfrage eine passende Oberfläche gestaltet und programmiert.

So unterschiedlich diese Ansätze sind, eins haben sie gemeinsam: Am Ende schreibt die KI Code. Wie gut man diesen Code absichert, ist dann die große Frage.

Es gibt auch den umgekehrten Weg, bei dem eine KI eine Oberfläche nur beschreibt, statt Code zu schreiben. Google hat dafür zum Beispiel ein offenes Format namens A2UI veröffentlicht. Das ist aber für Oberflächen innerhalb bestehender Apps gedacht, nicht als Grundlage für ein ganzes System.

Und genau da setzt meine Idee an: Was, wenn ein ganzes System so funktioniert? Wenn die KI gar keinen Code schreiben darf, sondern nur beschreiben?

Die Frage, die mich am meisten beschäftigt

Die KI-Tools vom Anfang erzeugen Code. Das funktioniert gut, solange ein Entwickler davorsitzt und sich das Ergebnis anschaut. Bei den Coding-Agenten ist es genauso: Ich sehe, welches Skript der Agent schreibt, und kann eingreifen, wenn etwas komisch aussieht.

Aber was ist mit jemandem, der einfach nur eine Einkaufsliste will? Der kann generierten Code nicht prüfen. Und er sollte das auch nicht müssen.

Deshalb glaube ich, dass so ein System keinen beliebigen Code erzeugen und ausführen darf. Mein Ansatz ist ein anderer: Die KI schreibt keinen Code, sondern beschreibt die Anwendung in einem festen Format. Welche Felder gibt es, welche Buttons, welche Aktionen? Diese Beschreibung wird geprüft, und erst dann macht das System daraus eine echte Oberfläche.

Ich stelle mir das wie ein neues, leeres Haus vor. Es bringt nur bestimmte Werkzeuge mit und einen Handwerker. Ich sage dem Handwerker: Bau mir einen Esstisch für mein Abendessen. Nach dem Essen kann der Tisch wieder weg, oder ich behalte ihn. Nur eins kann der Handwerker nicht: sich eigene Werkzeuge schmieden. Gebaut wird mit dem, was im Haus ist.

Wer schreibt dann den Code?

Weiterhin Menschen, nur eben einmal und nicht für jede App neu. Und oft muss man dafür nicht mal bei null anfangen: Läuft die Oberfläche zum Beispiel mit Webtechnik, könnte das System auf fertige Komponenten wie die von shadcn zurückgreifen.

Alle erlaubten Bausteine stehen in einer Art Katalog, einer Registry, und die KI darf nur daraus wählen. Fehlt ein Baustein, schreibt ein Entwickler ihn einmal, trägt ihn ein, und ab dann kann die KI ihn nutzen.

Das ist weniger flexibel als freier Code, aber genau das ist der Preis für die Kontrolle.

Wo ich gerade stehe

Das Ganze ist im Moment vor allem eine Vision. Ein fertiges Betriebssystem gibt es nicht, und ich weiß ehrlich gesagt auch nicht, ob am Ende eins daraus wird.

An einem Teil davon arbeite ich aber gerade: an der Frage, wie eine KI Oberflächen beschreiben kann, ohne Code zu schreiben. Darüber schreibe ich im nächsten Post mehr.