Als ich clive gebaut habe, war die Grundidee trügerisch einfach: Geben Sie dem Agenten keine Liste von Werkzeugen. Geben Sie ihm eine Umgebung. Eine API ist ein Aufruf-Antwort-Primitiv. Sie rufen sie auf, sie gibt etwas zurück, der Zustand liegt woanders. Eine Umgebung bewohnt man. Sie betreten sie, handeln darin und verlassen sie anders, als Sie sie vorgefunden haben. Das Terminal war immer schon eine Umgebung. Clive setzt einfach ein LLM hinein. Seither denke ich darüber nach, was diese Einsicht außerhalb des Terminals bedeutet. Und ich glaube, sie führt an einen überraschenden Ort: den Browser-Tab.
Das Web sollte read/write sein
Tim Berners-Lee hat den Browser als Editor entworfen. Der erste Browser, WorldWideWeb, konnte Seiten erstellen und ändern, nicht nur lesen. Das Read/Write-Web war der Plan. Dann wurde das Web zum Verbreitungsmedium. Apps leben auf Servern. Die Bürger konsumieren sie. Wollen Sie etwas ändern, schreiben Sie ein Ticket. Wollen Sie etwas bauen, engagieren Sie einen Entwickler. Open Source hat das nicht ganz behoben. Der Code ist sichtbar, aber die Lücke zwischen „kann lesen“ und „kann ändern“ ist immer noch riesig. Die meisten, die Software benutzen, können sie nicht ändern. Die meisten, die sie ändern könnten, können sie trotzdem nicht deployen.
Das Ergebnis: ein Web voller Wissen, eingesperrt in Oberflächen, die Ihnen nicht gehören, auf Servern, die Sie nicht kontrollieren, betreut von Teams, die Sie nicht erreichen.
Was, wenn die Datei die Deployment-Einheit wäre?
HTML ist das am weitesten verbreitete Laufzeitformat der Geschichte. Jedes Gerät mit einem Browser kann es ausführen. Keine Installation. Kein Konto. Kein Server. Sie öffnen einfach die Datei. Simon Willison baut seit zwei Jahren HTML-Werkzeuge aus einer einzigen Datei, mittlerweile mehr als 150 Stück. Ein Changelog-Viewer für PyPI. Ein Explorer für Bluesky-Threads. Ein OCR-Werkzeug, das komplett im Browser läuft. Alle nach demselben Muster: eine .html-Datei, auf den Desktop ziehen, öffnen, fertig. Seine Beobachtung: Ein paar hundert Zeilen HTML sind das am leichtesten deploybare Format, das es gibt. Jedes gute LLM kann das lesen, verstehen und in Minuten von Grund auf neu schreiben. Dieser letzte Satz hat bei mir etwas aufgemacht.
Was, wenn sich die Datei selbst umschreiben könnte?
Die Architektur ist im Rückblick einfach:
one .html file
↓
on first open: the LLM generates the app, stores it in localStorage
↓
on every open after: localStorage loads into the browser via document.write
↓
⌘K: the LLM receives the entire current source, rewrites it, stores the new version
↓
the file has modified itself
Die Datei auf der Festplatte ist ein Seed aus 20 Zeilen, ein unveränderlicher Bootstrap. Wie gate.py in der Selbstmodifikations-Pipeline von clive ändert sie sich nie. Sie lädt nur, was gerade in localStorage liegt.
Alles andere (die UI, die Logik, die Daten, die Styles) lebt in localStorage['docuapp_src']. Der Agent ändert keine Daten in einer App. Er schreibt die App selbst um. Das ist etwas anderes, als eine App zu konfigurieren, ein Dashboard zu personalisieren oder Einstellungen zu ändern. Es ist eine ganz andere Ontologie. Die App ist kein festes Artefakt mit variablem Inhalt. Die App ist das, was der Agent bisher gemacht hat. Quellcode, Runtime und Editor sind dasselbe.
Der Zufall mit dem Null-Origin
Das hier klingt nach einem Problem, ist aber keines. Wenn Sie lokale HTML-Dateien über file:// öffnen, teilen sich alle denselben Origin: null. Das heißt, jede .html-Datei, die Sie lokal öffnen, nutzt denselben localStorage-Namespace.
Die erste Reaktion: ein Bug. Die Dokumente werden einander überschreiben.
Die zweite Reaktion, wenn man es eine Weile wirken lässt: Das ist ein lokaler Message Bus.
budget.html → writes localStorage['budget_data']
tracker.html → writes localStorage['tracker_data']
dashboard.html → reads both, renders a unified view
Kein Server. Kein Protokoll. Keine WebSockets. Der Browser löst window.addEventListener('storage', ...) aus, wenn ein anderer Tab localStorage ändert. Dokumente können in Echtzeit aufeinander reagieren.
Ein Ordner mit .html-Dateien ist insgeheim eine verteilte Anwendung. Das Dateisystem ist das Netzwerk. Der Browser ist die Runtime und der Message Bus.
Dieses Verhalten ist in modernen Browsern einheitlich, hängt aber so weit vom Browser ab, dass ich es als hackbares Substrat behandeln würde und nicht als Garantie, hinter der ein Standard steht. Darauf aufzubauen lohnt sich, aber ohne Fallback gehört es nicht in die Produktion.
Was daran wirklich neu ist
Apps aus einer einzigen Datei gab es schon. Selbstmodifizierende Systeme auch. Local-First-Apps auch. Codegenerierung im Browser auch. Neu ist: LLMs machen das Einzeldatei-Artefakt auf der Ebene der Absicht editierbar statt auf der Ebene der Syntax. Bisher mussten Sie ein Programm verstehen, um es zu ändern. Sie mussten wissen, welche Zeile zu ändern ist, welche Folgen das hat und wie die Teile zusammenhängen. Für seinen Benutzer war das Artefakt undurchsichtig.
Jetzt kann das Artefakt einen Satz entgegennehmen („mach den Text größer“, „füge ein Prioritätsfeld hinzu“, „ändere die Begrüßung auf Gemeinde Tulln“) und sich entsprechend umschreiben. Die Absicht des Benutzers ist die Schnittstelle. Der Quellcode ist ein Implementierungsdetail, das der Benutzer nie sieht. Das ist keine quantitative Verbesserung bestehender Werkzeuge, sondern ein anderes Verhältnis zwischen Menschen und Software.
reWritAble
Der Name entstand, als ich darüber nachdachte, was das eigentlich ist.
re: Es tut es noch einmal. Die Agentenschleife. Iteration. Selbstmodifikation über die Zeit.
write: nicht lesen, nicht konsumieren, sondern verfassen. Das Verb, das Berners-Lee im Sinn hatte.
able: eine Eigenschaft der Datei selbst. Keine Berechtigung, die Ihnen das Betriebssystem erteilt. Etwas, das sie ist.
Der Download ist der Fork
Damit bedeutet ein Download etwas anderes. Klassisch ist ein Download eine eingefrorene Kopie dessen, was der Entwickler gemacht hat.
Bei reWritable ist ein Download ein Ausgangspunkt, den der Benutzer weiterentwickeln kann. Die re-write-able Runtime steckt in der Datei. Der Benutzer installiert nichts, meldet sich nirgends an und braucht kein eigenes Werkzeug. Die Änderungsschicht ist fest eingebaut. Open Source war immer theoretisch zugänglich: Der Code liegt offen, jeder kann ihn ändern. Praktisch brauchte es aber jahrelange Übung, um die Lücke zwischen „kann lesen“ und „kann ändern“ zu überbrücken.
reWritable schließt diese Lücke für eine bestimmte Klasse von Software: leichte Local-First-Werkzeuge und -Artefakte, also das, was früher in einer Tabelle, einem Word-Dokument, einem geteilten Ordner oder auf einer Notion-Seite gelebt hat. Das ersetzt nicht alle Software, erweitert aber radikal, was als deploybare Software für Einzelpersonen und kleine Organisationen gelten kann. Die Implementierungskosten für Software in dieser Größenordnung brechen gerade zusammen. Das Denken wird dadurch nicht überflüssig. Es wird die Aufgabe.
Was sich geändert hat und was nicht
Das LLM hat die grundlegende Ökonomie nicht für alle Software verändert. Komplexe Systeme brauchen weiterhin Engineering, Urteilsvermögen und Wartung. Das hat sich nicht geändert. Geändert hat sich etwas am kleinen Ende: Die Übersetzungsschicht zwischen Absicht und Implementierung ist so billig geworden, dass man sie bei einer großen Klasse von internen Tools, lokalen Hilfsprogrammen und Einzweck-Artefakten ignorieren kann. In diesen Fällen ist das Beschreiben dessen, was Sie wollen, jetzt der größte Teil der Arbeit.
Ein paar echte Einschränkungen sollte man nennen:
- localStorage hat Grenzen (~5 bis 10 MB je nach Browser). Die Spezifikation begegnet dem mit einem Zwei-Stufen-Modell: localStorage für den App-Quellcode, IndexedDB für größere Daten. So bekommt jede Schicht das passende Werkzeug.
- Selbstumschreiben sammelt Drift an. Nach vielen Änderungen kann der Quellcode aufgebläht, widersprüchlich oder fragil werden. Die richtige Abhilfe ist eine regelmäßige Neugenerierung aus einer kompakten Spezifikation: von Grund auf neu schreiben, statt endlos zu flicken.
- Die API-Abhängigkeit ist real. Die Datei funktioniert offline, aber der Aufruf des Agenten braucht ein Netzwerk. Roman beantwortet Fragen ohne Internet, umschreiben kann er sich nur mit.
- Rollback ist wichtig. Die Runtime hält zehn Undo-Stufen vor. Für alles, was darüber hinaus zählt, versionieren Sie die Datei in git: Sie ist Text und lässt sich sauber diffen.
Die Verbindung zu clive
Die These von clive: Das Terminal ist ein Lebensraum für Agenten, weil es beobachtbar, zustandsbehaftet und persistent ist. Der Agent liest den Bildschirm, tippt Tastenanschläge, schaut, was passiert, und wiederholt das.
Re-write-able ist dieselbe These im Browser.
clive: read screen → type → watch → repeat
re-write-able: read outerHTML → generate → document.write → repeat
Der Browser-Tab ist der Lebensraum. localStorage ist der persistente Zustand. document.documentElement.outerHTML ist die Bildschirmaufnahme. Der Agent lebt im Tab.
Der Unterschied: Bei clive steuert der Agent Programme. Bei re-write-able ist das Programm das, was der Agent bisher gemacht hat. Zwischen dem Werkzeug und seiner Änderungsgeschichte gibt es keine Trennung. Jedes Umschreiben ist eine neue Version des Artefakts. Das Artefakt hat ein Gedächtnis.
Artefakt. Bewohner. Gedächtnis. Diese drei zusammen unterscheiden das hier von einem App-Builder im Browser.
Wie es weitergeht
Die zwei naheliegendsten Erweiterungen stecken schon in der Architektur. Der localStorage-Bus ermöglicht dokumentübergreifende Agenten: eine Reihe von re-writeable Dateien, die einander lesen und schreiben und so ohne Server eine lokale Anwendung bilden. Und weil die Datei Text ist, wird Versionierung trivial: Jedes Umschreiben ist ein Diff, jeder Export ein Snapshot, git funktioniert bereits. Beides sind Richtungen, keine Features. Interessanter ist die Frage, was Menschen bauen, wenn ein Local-First-Werkzeug nur noch einen Satz kostet. Das Web sollte read/write sein. Für die meisten Menschen war es das die längste Zeit nicht. Eine Datei. Ein Satz. Ein Umschreiben nach dem anderen.
Quellcode und Spezifikation: github.com/ikangai/rewritable
Der direkte Vorfahre: github.com/ikangai/clive
Aus dem Englischen übersetzt: zum Originalbeitrag