Das vor 10 Jahren gescheiterte Startup-Wagnis wurde von KI gerettet, und künftig kann jeder seine eigene App selbst anpassen.

Meine gesammelten Langbeiträge werden alle auf meinen Leser übertragen.

Ich durchsuche arXiv jede Woche und behalte alle Arbeiten, die mit meinem Forschungsbereich zusammenhängen, und versehe sie mit Tags.

Die von mir häufig besuchten Websites zeigen ständig Zeichensalat, wenn ich sie herunterlade, also schreibe ich einen eigenen Parser für sie.

Das sind die „exklusiven Anforderungen“ von Jeremy Morrell, Chefingenieur von Cloudflare – die Lese-App, die er nutzt, kann keine davon erfüllen.

Er wünscht sich, dass nach dem Aussprechen dieser Sätze ein Roboter die entsprechenden fragmentierten Codes generiert, sie an die vordefinierten Erweiterungspunkte der Software hängt und sie dann selbstständig ausführt.

Nach der Fertigstellung kann man sie problemlos weitergeben, wer sie braucht, kann sie sich nehmen.

Das ist die ideale Form von Software, die er sich vorstellt: erweiterbare Software (Extensible Software).

Morrell ist der Ansicht, dass die allermeisten Web-Software, die wir heute nutzen, statisch ist.

Diese Statik bezieht sich nicht auf die Web-Technologie, sondern darauf, dass man ihre Logik nicht ändern kann.

Die Funktionen sind am Tag der Veröffentlichung endgültig festgelegt – man kann sie nur nutzen, aber nicht modifizieren.

KI hat all das verändert.

Jeder kann seine eigene App anpassen – das ist kein Traum mehr.

Der Nutzer sagt „Füge die Funktion hinzu, die ich brauche“, der Computer fügt sie sofort hinzu, und der Nutzer antwortet „nice“. Morrell sagt, das ist die Software, die er sich wünscht.

Warum werden die Funktionen, auf die du so sehr hoffst, nie umgesetzt

Weil es auf der ganzen Welt nur dich gibt, der sie will.

Die Zeit und Aufmerksamkeit der Entwickler sind begrenzt, also entwickeln sie nur Funktionen, die die größte Nutzergruppe bedienen.

Manchmal können sie, selbst wenn sie alles umsetzen wollen, es nicht schaffen.

Die Komplexität der Benutzeroberfläche hat eine Obergrenze – jede zusätzliche Funktion ist eine Belastung für alle, die sie nicht brauchen.

Wenn die Zielgruppe einer Funktion nur wenige Hundert Menschen umfasst, macht sie das Produkt für die verbleibenden Millionen Nutzer schwieriger zu bedienen.

Diese beiden Einschränkungen sind der unlösbare Knoten, mit dem Produktmanager in den letzten zwei Jahrzehnten ständig zu kämpfen hatten.

Verteilung der Nutzeranforderungen an Navigationssoftware. Links stehen die Navigationsfragen, die alle Nutzer stellen, rechts im langen Schwanz liegen die unterschiedlichen, seltenen Anforderungen jedes Einzelnen.

Die kleine Funktion, die du in einer bestimmten App haben willst, ist nicht unmöglich zu entwickeln – es lohnt sich einfach nicht, sie zu bauen.

Im letzten Jahr, seitdem Nutzer die Fähigkeit zum Vibe-Coding erlangt haben, hat sich alles verändert.

Die Kosten für die Erstellung eines Tools, das nur eine einzelne Person bedient, sind so niedrig geworden, dass sie kaum noch erwähnenswert sind.

Pete Koomen von Y Combinator nennt diese Art von Tools „Small Software“.

Y Combinator über Small Software: Diese Art von Tools bedient oft nur eine einzelne Person oder eine kleine Gruppe von Menschen.

Buchhalter, Ärzte, Anwälte und Tausende weitere Berufsgruppen können alle ihre eigene handhabbare „Small Software“ besitzen.

Es ist offensichtlich, dass man nicht erwarten kann, alle Menschen zu Ingenieuren zu machen, damit mehr Menschen intelligente Agenturen nutzen können.

Die Software selbst muss angepasst werden.

Die Kosten für das Schreiben von Erweiterungen sind auf Null gesunken – aber es gibt noch keinen Ort, um Erweiterungen zu sammeln

Da Code jetzt einfacher zu schreiben ist, taucht das Problem auf: Wohin soll man ihn nach dem Schreiben legen?

Viele Web-Produkte bieten heute den Nutzern Webhooks an, deren Hürde aber absurd hoch ist: Du musst einen kompletten unabhängigen Dienst selbst betreiben und alle möglichen Probleme bewältigen, die während der Übermittlung auftauchen.

Morrell ist der Ansicht, dass man fünf Hürden überwinden muss, damit fremder Code wirklich in deinem System ausgeführt werden kann.

Erste Hürde: Kosten.

Angenommen, es gibt eine Million Nutzer, von denen jeder seine eigenen wenigen Codezeilen betreibt. Wenn man für jeden einen eigenen Container bereitstellt, ist diese Rechnung sofort nicht mehr nachvollziehbar.

Morrells Standard lautet: Wenn der Code nicht aufgerufen wird, sind die Kosten nahezu Null; bei jedem Aufruf liegt der Preis bei einem Bruchteil eines Cents.

Zusammen mit Kompilierung, Dateispeicherung und Protokollerfassung hängt die Anzahl der Nutzer, die ein einzelner Rechner aufnehmen kann, letztendlich nur von einem einzigen Indikator ab: dem Speicheraufwand.

Zweite Hürde: Kaltstart.

Nutzer-Code befindet sich im kritischen Pfad der Anfrageverarbeitung – man kann keine Minute warten, bis der Container gestartet ist, der Idealwert liegt bei einzelnen Millisekunden. Für Code, der nur geplante Aufgaben ausführt oder Ereignis-Callbacks verarbeitet, kann diese Anforderung gelockert werden.

Dritte Hürde: Kontingente.

Man kann niemals erraten, was die Nutzer an Code schreiben werden. Morrell erzählt eine wahre Geschichte, die er bei Heroku gehört hat.

Damals gab es ein sehr beliebtes Einsteiger-Tutorial, das Anfängern Schritt für Schritt beibrachte, ihr erstes Programm online zu deployen. Das Programm im Tutorial bestand aus nur zwei Zeilen: einer Endlosschleife, die ständig „hello world“ ausgibt.

Plötzlich tauchte eine Anwendung auf, die in der ersten Sekunde nach ihrem Start Millionen von Protokollzeilen pro Sekunde ausgibt – und das für immer.

Die Anfänger, die dem Tutorial folgten, wussten davon nichts und riefen die Echtzeit-Protokolle auf, in der Erwartung, dass auf dem Bildschirm normale Inhalte erscheinen.

Deshalb muss für jeden Punkt eine Obergrenze festgelegt werden: wie viel CPU genutzt wird, wie viel Speicher belegt ist, wie viele Netzwerkanfragen nach außen geschickt werden können, wie groß jede Anfrage ist, wie viele Inhalte zurückgegeben werden und wie viele Protokollzeilen pro Sekunde geschrieben werden können.

Vierte Hürde: Isolation, die zwei Ebenen hat.

Abstürze, Endlosschleifen und exzessive Speicheranforderungen dürfen keine anderen Nutzer beeinträchtigen. Bösartiger Code darf nicht ausbrechen, keine anderen Mieter ausspionieren und Angriffe durch spekulative Ausführung wie Spectre müssen abgewehrt werden.

Fünfte Hürde: Der Code muss wirklich funktionieren. Code, der auf nichts zugreifen kann, ist nutzlos.

Von der Schlüsselübergabe zu einer Tür, die man öffnen kann

Wie man nicht vertrauenswürdigen Code arbeiten lässt, ohne ihm alle eigenen Ressourcen preiszugeben.

Morrell hat drei Generationen von Lösungen in der Branche aufgeschlüsselt.

Erste Generation: Direkte Übergabe von API-Schlüsseln.

Morrell hält diese Flexibilität für sehr gefährlich. Code, der den Schlüssel erhalten hat, kann ihn sofort an Dritte per POST übermitteln; selbst wenn er keine Daten stiehlt, kann deine Infrastruktur jederzeit missbraucht werden, um DDoS-Angriffe auf andere auszuführen.

Zweite Generation: Hinzufügen einer Vermittlungsschicht (Proxy).

Der Nutzer erhält ein undurchsichtiges Token, das nur für den Proxy eine Bedeutung hat. Der Proxy prüft es, ersetzt es durch echte Anmeldeinformationen und leitet die Anfrage weiter, wobei er gleichzeitig Whitelist-Prüfungen und Ratenbegrenzungen durchführt.

Das ist zwar sicherer als die direkte Übergabe von Schlüsseln, aber der Nachteil liegt im Wartungsaufwand. Wenn du die Berechtigungen so einschränken willst, dass nur bestimmte Operationen erlaubt sind, musst du Filterlogik im Proxy schreiben, die mit der Weiterentwicklung der vorgelagerten APIs ständig angepasst werden muss.

Morrell hat in seinem Text ein Beispiel angefügt – selbst für die einzige Operation „eine genehmigte E-Mail lesen“ ist der Code bereits lang und schwer zu testen.

Außerdem ist es fast unmöglich, alle diese Logiken vollständig zu berücksichtigen. Man kann nie erraten, was die Nutzer tun werden.

Die dritte Generation ist der entscheidende Schritt: Capability (Fähigkeitsberechtigung).

Statt Schlüsseln oder Adressen zu übergeben, übergibst du direkt eine fertige Funktion. Zum Beispiel nur die Aktion „die genehmigte E-Mail abrufen“ – mehr kann der Code nicht tun.

Der Code des Nutzers verfügt nur über diese wenigen Funktionen. Die Anmeldeinformationen sind nie in seinen Bereich gelangt, und selbst wenn er Daten erhält, gibt es keinen Kanal, um sie nach außen zu übermitteln.

Die ersten zwei Zeilen sind der Code der Plattform selbst, hier werden die Schlüssel aufbewahrt. Die Funktion darunter ist der Code des Nutzers – er hat nie gesehen, wie der Schlüssel aussieht.

Es gibt einen zusätzlichen Vorteil: Wenn man eine in TypeScript geschriebene Capability-Definition an ein großes Sprachmodell übergibt, spart das mehr Tokens und ist genauer als eine Menge JSON im OpenAPI-Format.

Deshalb ist die eigentliche Hürde nicht, die KI Code schreiben zu lassen, sondern zu bestimmen, auf was dieser Code zugreifen darf.

Vier Wege – keiner davon ist kostenlos

Ob man Erweiterungen schreiben kann, darauf gab es schon vor zwanzig Jahren Antworten. Große Sprachmodelle haben nur geändert, wer sie schreiben kann.

Morrell listet vier Wege auf:

Die leichteste Variante sind eingebettete Interpreter wie Lua, QuickJS oder sogar eine selbst entwickelte Lösung.

Darüber liegen V8-Isolates.

Google hat Unmengen an Geld und Personal in die Sicherheitshärtung von V8 gesteckt – die direkte Nutzung erspart dir die eigene Neuerfindung des Rades.

Auf diesem Weg gibt es Cloudflares Dynamic Workers, Node.js isoliert-vm und Rivets secure-exec.

Die dritte Stufe sind MicroVMs.

Sie entfernen alle Simulationen von USB, Grafikkarte und Festplatte aus vollständigen virtuellen Maschinen, behalten nur das Grundgerüst bei. Sie bieten die stärkste Isolation, können Binärcode ausführen und verfügen über ein vollständiges POSIX-System – der Nachteil ist der deutlich höhere Overhead.

Firecracker und libkrun gehören zu dieser Kategorie.

Die vierte Stufe ist WASM kombiniert mit WASI.

WebAssembly begann als leeres Blatt – es gibt nicht einmal Module zum Senden von HTTP-Anfragen oder Lesen von Umgebungsvariablen, alle Berechtigungen werden explizit vom Host erteilt.

Aus sicherheitstechnischer Sicht ist das der beste Ausgangspunkt, der Nachteil ist eine deutlich komplexere Toolchain.

Diese vier Wege schließen sich nicht gegenseitig aus.

WASM kann in V8-Isolaten und auch in MicroVMs ausgeführt werden. Selbst wenn du V8-Isolate oder WASM als Isolationsgrenze nutzt, sind MicroVMs bei Aufgaben wie Kompilieren, Verpacken und Testen von Erweiterungen nach wie vor nützlich.

Morrell hat selbst ausprobiert, ob dieses System funktioniert. Er hat seinen statischen Blog zu einem Demo umgebaut und sich selbst als „kleinste Vibe-Coding-Plattform der Welt“ bezeichnet.

Im Wesentlichen handelt es sich um einen anpassbaren Crawler: Gib eine URL ein, er holt den Inhalt zurück und übergibt ihn zusammen mit mehreren vorab gewährten Tools an den Nutzer-Code – du kannst den Quellcode direkt ändern und ausführen.

Eine Idee, die vor 10 Jahren verloren hat, wurde von der KI wiederbelebt

Vor zehn Jahren gründete Kenton Varda, der heutige technische Leiter von Cloudflare Workers, ein Startup namens Sandstorm.io.

Seine Idee klang damals etwas seltsam: Jedes Dokument, das du öffnest, läuft in einer eigenen Sandbox-Instanz; das Programm erhält nichts, was du nicht persönlich an es weitergegeben hast. Keine Schlüssel werden ausgegeben, nur Capabilities.

Dieses Projekt war nicht erfolgreich.

Später analysierte Varda die Gründe für das Scheitern: Niemand hatte die Geduld, die Software einzeln manuell in diese Form zu verpacken.

Zehn Jahre später, am 5. August 2026, hat Cloudflare dieses System unter der Apache-2.0-Lizenz neu als Open-Source veröffentlicht und es Cloudflare