Eine rewritable HTML-App verändert das Modell von Software-Updates. Wenn sich die Anwendung an Ort und Stelle selbst ändern kann, muss ein Update nicht mehr als neues Binary, neues Paket oder neue Zip-Datei kommen. Es kann als Anweisung kommen: „Füge dieses Feature hinzu“, „ändere diesen Workflow“, „migriere diese Datenstruktur“, „behebe dieses Verhalten“.
Der naheliegende nächste Schritt ist dann, die Anweisung zu signieren. Kommt der Prompt vom Urheber der App, kann der Benutzer ein offizielles Update von einem beliebigen Vorschlag unterscheiden. Aber dieser Schritt legt eine Lücke offen, die klassisches Code Signing nicht kennt: Wer den Prompt signiert, signiert nicht das Programm.
Dahinter steckt eine Entwicklung in Stufen. Zuerst erzeugten Prompts Antworten. Dann erzeugten sie Code. Dann begannen Prompts in Tools wie Claude Artifacts und rewritable HTML-Apps, Software-Artefakte direkt zu verändern. Der signierte Prompt ist die vierte Stufe: Prompts werden zu Update-Artefakten. Ab hier ist die Frage nach der Herkunft keine einfache Sache mehr.
Karpathys Denkmodell Software 3.0 behandelt Prompts als Programme für Modelle: Prompt → Modellverhalten. Rewritable Software schiebt einen weiteren Schritt dazwischen: Prompt → Modell bearbeitet Anwendung → Anwendungsverhalten. Das Problem des signierten Prompts sitzt in diesem mittleren Schritt. Die Signatur authentifiziert die Anweisung, bevor es das ausführbare Artefakt überhaupt gibt.
Code Signing ist seit Jahrzehnten eine Grundlage der Softwareverteilung, und seine Garantie ist bewusst eng gefasst. Die Signatur bestätigt, dass eine bestimmte Bytefolge von einem bestimmten Urheber stammt und dass sich diese Bytes seit ihrer Auslieferung nicht verändert haben. Was läuft, ist das, was signiert wurde. Die Signatur sagt nicht, dass die Bytes sicher, korrekt oder sauber gebaut sind. Sie sagt nur, dass das die Bytes sind, hinter denen der Urheber stand.
Ein signierter Prompt ist eine andere Art von Objekt. Die Bytes, die die Signatur abdeckt, sind nicht die Bytes, die laufen werden. Sie beschreiben eine Änderung: Anweisungen in natürlicher Sprache darüber, was aus der Anwendung werden soll. Was tatsächlich läuft, entsteht später, durch ein LLM, auf Basis der lokalen Kopie der App beim Benutzer, in dem Moment, in dem das Update angewendet wird. Die Signaturprüfung bestätigt, dass der Urheber die Anweisung geschrieben hat. Was die Anweisung hervorbringen wird, kann sie nicht bestätigen.
Das ist nicht die übliche Unterscheidung zwischen Quellcode und Binary. Im klassischen Release Engineering kontrolliert der Hersteller den Build-Prozess und signiert das fertige Artefakt. Bei Software, die per Prompt aktualisiert wird, signiert der Urheber die Anweisung und überlässt die Umsetzung dem lokalen Modell des Benutzers, dessen Kontext und dem Zustand seiner App. Der Build-Schritt hat die kontrollierte Umgebung des Herstellers verlassen.
In diesem Interpretationsschritt öffnet sich die Verifikationslücke. Der signierte Prompt landet auf einer Maschine und wird dort zu Code, er landet auf einer anderen und wird dort zu anderem Code. Beide Umsetzungen können die Absicht des Urhebers in irgendeinem vertretbaren Sinn erfüllen. Aber keine lässt sich gegen ein kanonisches Artefakt prüfen, weil es so ein Artefakt nicht gibt. Es gibt nur die signierte Beschreibung und die Art, wie das lokale Modell sie gelesen hat.
Die Lücke zeigt sich an mehreren strukturell verschiedenen Stellen. Am offensichtlichsten ist die Modellvarianz. Derselbe signierte Prompt, von einem Benutzer über Claude angewendet, von einem zweiten über ein lokales Llama, von einem dritten über GPT, ergibt drei verschiedene Programme. Gleiche Signatur, gleiches Rezept, andere Küche.
Daneben steht der lokale Zustand. Klassische Updates setzen auf einer bekannten Basis auf: der Version, die der Hersteller ausgeliefert hat, eventuell mit späteren Patches, die ebenfalls vom Hersteller kamen. Ein Prompt-Update setzt auf dem auf, was aus der Anwendung seit der Installation geworden ist. Zwei Benutzer, die „dieselbe“ rewritable App verwenden, führen nicht denselben Code aus. Sie führen das kumulierte Ergebnis aller früheren signierten Prompts aus, dazu das, was das LLM beim Interpretieren dieser Prompts erzeugt hat, dazu alle lokalen Änderungen, die sie selbst gemacht haben. Das neue signierte Update landet auf diesem Untergrund. Ignorieren kann es ihn nicht.
Und der Benutzer ist selbst Autor. Rewritable Anwendungen laden zur Veränderung ein: Der ganze Sinn dieses Modells ist, dass der Benutzer seine eigene App an Ort und Stelle per Prompt ändern kann, mit dem lokalen Modell seiner Wahl. Manche dieser Änderungen sind gewollt, manche sind Experimente, die er nie rückgängig gemacht hat, manche sind Nebenprodukte früherer signierter Updates, die er akzeptiert hat, ohne genau hinzusehen. Der Urheber sieht nichts davon. Wenn der nächste signierte Prompt kommt, ist die Anwendung, die er verändert, nicht die Anwendung, die sich der Urheber beim Schreiben der Anweisung vorgestellt hat.
Nichts davon erledigt die Idee. Prompt-basierte Updates bleiben ein plausibler Mechanismus für Software, bei der das Artefakt wirklich formbar ist und der Urheber den lokalen Zustand wirklich nicht aufzählen kann. Aber der Mechanismus leistet weniger, als es den Anschein hat. Die Signatur authentifiziert weiterhin den Urheber. Das Ergebnis authentifiziert sie nicht mehr.
Ein signiertes Binary sagt Ihnen, wer das produziert hat, was läuft. Ein signierter Prompt sagt Ihnen, wer das verlangt hat, was vielleicht produziert wird. Dieser Unterschied ist das neue Update-Problem.
Aus dem Englischen übersetzt: zum Originalbeitrag