Simon Willison zitiert Jeremy Morrell, doch sichere KI-Erweiterungen brauchen mehr als eine Sandbox
Simon Willison hob am 19. August 2026 einen konkreten Zielkonflikt hervor: LLMs erleichtern das Schreiben von Software-Erweiterungen, während ihrem generierten Code weiterhin nur schwer zu vertrauen ist.
Die Beobachtung stammt von Jeremy Morrell, der argumentiert, dass Webanwendungen einen nachvollziehbaren Kern mit nutzererstellten Erweiterungen verbinden können. Große Sprachmodelle würden diese Erweiterungen generieren, während Browser-Sandboxes einschränken würden, worauf der daraus entstehende Code zugreifen kann.
Dieses Modell stellt zwei vertraute Ansätze infrage. Traditionelle Anwendungen bieten festgelegte Funktionen, die von ihren Entwicklern ausgewählt wurden. Allgemeine KI-Agenten erhalten weitreichenden Zugriff und versuchen, bestehende Schnittstellen im Namen eines Nutzers zu bedienen.
Morrell schlägt einen dritten Weg vor. Die Anwendung behält ihr verlässliches Zentrum, doch Nutzer können fehlende Fähigkeiten beschreiben, wenn sie darauf stoßen. Ein LLM liefert begrenzten Code, anstatt das gesamte Produkt zu steuern.
Der Vorschlag klingt einfach, weil Browser bereits Isolationsmechanismen enthalten. Doch Codegenerierung und sichere Ausführung lösen nur einen Teil des Problems. Produkte müssen außerdem Berechtigungen, Datenbewegungen, Updates, Verantwortlichkeit und die Wiederherstellung kontrollieren, wenn sich eine Erweiterung fehlerhaft verhält.
Der eigentliche Wettbewerb lautet daher nicht festgelegte Software gegen grenzenlose Anpassung. Es geht um nachvollziehbare Erweiterbarkeit gegen uneingeschränkte KI-Handlungsfähigkeit.
Simon Willison rückt erweiterbare Software wieder auf die Agenda
Das wichtige Ereignis ist kein Produktlaunch, sondern eine präzisere architektonische Hypothese für KI-Software.
In seinem Beitrag vom 19. August zitierte Simon Willison Morrells Argument zu einer neuen Chance für erweiterbare Websoftware. Der Beitrag ordnete die Idee den Themen Sandboxing, LLMs, KI und generative KI zu.
Morrells Hypothese verbindet zwei Veränderungen, die oft getrennt diskutiert wurden. LLMs verringern den Aufwand, kleine Mengen Anwendungscode zu erzeugen. Moderne Webplattformen bieten Grundbausteine, die einschränken können, wo dieser Code ausgeführt wird und was er tun darf.
Keine der beiden Veränderungen macht Softwareentwicklung überflüssig. Zusammen verändern sie jedoch die Wirtschaftlichkeit einer Funktion, die nur einer einzelnen Person oder einem einzelnen Team dient.
Ein konventionelles Produktteam muss eine Anfrage bewerten, die Interaktion gestalten, sie umsetzen, testen, dokumentieren und warten. Für breit geteilte Funktionen ergibt dieser Prozess Sinn. Für einen spezialisierten Ablauf, den nur einige wenige Personen nutzen, funktioniert er selten.
Ein LLM kann eine spezifische Anfrage in Code umsetzen, ohne darauf zu warten, dass die Funktion auf einer öffentlichen Roadmap erscheint. Die daraus resultierende Erweiterung könnte ein Dokument transformieren, eine individuelle Visualisierung hinzufügen, ein Formular validieren oder zwei erlaubte Datenquellen verbinden.
Das macht den generierten Code nicht korrekt. Es macht den ersten Umsetzungsversuch jedoch deutlich günstiger.
Die zweite Hälfte von Morrells Argument betrifft die Bereitstellung. Historisch bedeutete die Installation von Erweiterungen Dritter oft, einem Paket zu vertrauen, weitreichende Berechtigungen zu erteilen oder Code innerhalb eines privilegierten Anwendungsprozesses auszuführen.
Der Browser bietet eine andere Grundlage. Ein Sandbox-Frame schafft einen separaten Browsing-Kontext und kann Fähigkeiten deaktivieren, sofern der Host sie nicht ausdrücklich wiederherstellt.
Die verfügbaren Kontrollen sind konkret statt symbolisch. Der Host kann Skripte, Formulare, Pop-ups, Downloads, Speicherzugriff und Navigation auf oberster Ebene einschränken. Er kann zudem eine Permissions Policy auf Funktionen wie Kameras und Mikrofone anwenden.
Diese Kontrollen ermöglichen eine sinnvolle Sicherheitsgrenze. Sie erzeugen nicht automatisch für jede Erweiterung die richtige Grenze.
Morrells Formulierung eines „soliden, nachvollziehbaren Kerns“ ist der entscheidende Teil des Vorschlags. Die Host-Anwendung würde weiterhin Identität, dauerhafte Daten, Autorisierung, Prüfverlauf und kritische Vorgänge verwalten.
Generierte Erweiterungen würden lokale Lücken rund um diesen Kern schließen. Sie würden weder stillschweigend dessen Sicherheitsmodell ersetzen noch zum maßgeblichen Datensatz werden.
Diese Unterscheidung trennt erweiterbare Software von einem allgemeinen Coding-Chatbot. Ein Chatbot kann eine Datei erzeugen und dem Nutzer die Verantwortung überlassen, sie sicher auszuführen. Eine erweiterbare Anwendung kann festlegen, wo generierter Code lebt, welche Schnittstellen er erhält und wie seine Aktionen geprüft werden.
Sie trennt die Idee auch von gewöhnlichen Plugin-Stores. Traditionelle Plugins werden meist für viele Nutzer erstellt, als Produkte verpackt und über einen Prüfprozess verteilt. LLM-generierte Erweiterungen können auf einen einzelnen Ablauf zielen und dennoch innerhalb einer kontrollierten Laufzeitumgebung bleiben.
Das Ereignis ist relevant, weil Willisons Beitrag dieser Architektur einen prägnanten öffentlichen Rahmen gibt. Die Behauptung lautet nicht, dass KI jede Schnittstelle neu gestalten sollte. Sie lautet, dass KI sorgfältig begrenzte Anpassungen wirtschaftlich machen kann.
Das ist ein engeres Argument als „Agenten werden Apps ersetzen“. Es lässt sich auch leichter prüfen.
Der Druck trifft auf feste SaaS-Produkte und breit angelegte KI-Agenten
Produkte stehen nun unter Druck, Anpassbarkeit anzubieten, ohne die Kontrolle über Nutzerdaten oder zentrale Arbeitsabläufe aufzugeben.
Festgelegte Software funktioniert, indem sie häufige Bedürfnisse vorhersagt. Ihre Designer wählen die verfügbaren Objekte, Befehle, Ansichten, Integrationen und Automatisierungsregeln aus, bevor Kunden auf ihre individuellen Sonderfälle stoßen.
Dieses Modell schafft Konsistenz. Es erzeugt jedoch auch einen dauerhaften Rückstand an Anfragen, die zu spezifisch sind, um gemeinsame Entwicklung zu rechtfertigen.
Unternehmenskunden umgehen diese Lücken mit Tabellenkalkulationen, Skripten, Browser-Erweiterungen, Integrationsplattformen und manuellen Verfahren. Jeder Workaround schafft einen weiteren Ort, an dem Logik veralten oder unsichtbar werden kann.
Erweiterbare Software rückt diese Logik näher an die Anwendung, die die relevanten Daten verwaltet. Eine generierte Erweiterung kann eine schmale, vom Host definierte Schnittstelle nutzen, anstatt Bildschirme auszulesen oder Datensätze an anderer Stelle zu kopieren.
Stellen wir uns einen Projektmanager vor, der ein Prüfpanel auf Basis mehrerer ungewöhnlicher Metadatenfelder benötigt. Das Produkt wird dieses exakte Panel möglicherweise nie ausliefern, weil nur wenige Kunden es brauchen.
Eine Erweiterung könnte genehmigte Datensätze anfordern, die erforderliche Gruppierung berechnen und eine temporäre Ansicht darstellen. Die Kernanwendung würde weiterhin durchsetzen, welche Datensätze der Nutzer lesen darf.
Ein Forscher könnte einen einmaligen Extraktor für ein wiederkehrendes Dokumentformat benötigen. Ein Ingenieur könnte ein Dashboard für eine private Bereitstellungskonvention brauchen. Ein Vertriebsteam könnte eine Validierungsregel wünschen, die an seinen eigenen Account-Prozess gebunden ist.
Diese Anfragen sind für die meisten Roadmaps zu klein, aber für manuelle Arbeit zu wiederkehrend. Sie bilden die wirtschaftliche Chance hinter Morrells Hypothese.
Geoffrey Litt beschrieb in seiner früheren Arbeit über formbare Software eine verwandte Vision. Litt argumentierte, dass LLMs wie lokale Entwickler innerhalb von Rechenumgebungen agieren können, die Nutzer bereits verstehen.
Dieser historische Bezug ist wichtig, weil Endnutzerprogrammierung nicht neu ist. Tabellenkalkulationen, Makros, HyperCard, Browser-Skripte und visuelle Automatisierungstools ermöglichten es Menschen bereits, ihre Arbeitsumgebung zu verändern.
Der dauerhafte Engpass war nicht bloß Syntax. Nutzer mussten ein informelles Ziel in ausführbare Logik übersetzen, verfügbare Schnittstellen verstehen und das Ergebnis debuggen.
LLMs komprimieren Teile dieses Übersetzungsprozesses. Ein Nutzer kann ein Ergebnis in Fachsprache beschreiben, eine vorgeschlagene Erweiterung prüfen und sie anhand von Beispielen überarbeiten.
Die Erweiterung benötigt dennoch ein stabiles Fundament. Ohne definierte Objekte und Fähigkeiten muss das Modell raten, wie die Anwendung funktioniert. Das erzeugt fragilen Code und fördert Bildschirmautomatisierung.
Das setzt SaaS-Anbieter unter Druck, kleinere und sicherere Bausteine offenzulegen. Ein Produkt, das nur für menschliche Klicks entwickelt wurde, bietet einem LLM weniger verlässliche Möglichkeiten, es zu erweitern.
Derselbe Druck gilt für breit angelegte KI-Agenten. Ein Agent mit Zugriff auf E-Mails, Dateien, Browsing-Sitzungen und interne Tools kann vielfältige Arbeit leisten. Dieser Zugriff vergrößert jedoch auch die Folgen einer fehlerhaften Anweisung.
Eine begrenzte Erweiterung verfolgt den entgegengesetzten Ansatz. Sie erhält die minimalen Fähigkeiten, die für eine Aufgabe erforderlich sind. Die umgebende Anwendung vermittelt sensible Vorgänge.
Der Kompromiss besteht in geringerer Autonomie. Eine schmale Erweiterung kann nicht über jeden Dienst hinweg improvisieren oder beliebige Daten abrufen. Diese Einschränkung ist der Zweck, kein Mangel.
Für Käufer wird die Frage konkreter als die, ob ein Produkt „KI hat“. Sie können fragen, ob Nutzer lokale Fähigkeiten schaffen können, ohne einem Modell uneingeschränkten Zugriff zu gewähren.
Sie können auch prüfen, ob das generierte Verhalten sichtbar bleibt. Ein verborgener Agentenplan ist nach einem Fehler schwer zu prüfen. Eine installierte Erweiterung kann ihren Code, deklarierte Berechtigungen, Eingaben, Ausgaben und den Revisionsverlauf offenlegen.
Festgelegte Anwendungen werden unter diesem Modell nicht verschwinden. Gemeinsame Funktionen benötigen weiterhin professionelles Design, Barrierefreiheitsarbeit, Leistungstests, Support und langfristige Wartung.
Der wahrscheinliche Druck betrifft die Grenze um diese Funktionen herum. Anbieter, die jeden Arbeitsablauf geschlossen halten, müssen mit Produkten konkurrieren, die Nutzern erlauben, die letzte Meile selbst sicher zu bewältigen.
Teams werden außerdem bessere Wege benötigen, um den Kontext hinter individuellem Verhalten zu bewahren. Eine durchsuchbare Engineering-Wissensbasis kann dokumentieren, warum eine Erweiterung existiert, welche Annahmen sie trifft und wer für sie verantwortlich ist.
Dieser Nachweis wird essenziell, wenn sich generierte Erweiterungen von einem Nutzer auf eine Abteilung ausbreiten. Günstige Erstellung beseitigt nicht die Kosten institutionellen Wissens.
Sandboxes senken Bereitstellungskosten, nicht Verantwortlichkeitskosten
Eine Sandbox kann die Ausführung von Code einschränken, doch das Produkt muss weiterhin jeden bedeutsamen Pfad über die Grenze hinweg gestalten.
Eine Browser-Sandbox ist keine einzelne Schutzmauer. Sie ist eine Sammlung von Einschränkungen für Origin, Skripte, Navigation, Speicher, Gerätefähigkeiten und die Kommunikation mit dem Host.
Das sandbox-Attribut eines iframe beginnt mit einer restriktiven Haltung. Die Anwendung kann anschließend ausgewählte Fähigkeiten über explizite Tokens wiederherstellen.
Dies ist ein Fähigkeitenmodell, das heißt, Code erhält bestimmte Befugnisse, anstatt sämtliche Privilegien seines Hosts zu erben. Der Host könnte Rendering und Berechnungen erlauben, während Downloads, Navigation auf oberster Ebene oder Same-Origin-Speicher verweigert werden.
Die Browserdokumentation weist auch auf eine gefährliche Kombination hin. Ein Same-Origin-Frame, dem sowohl Skripte als auch Same-Origin-Berechtigungen erteilt wurden, kann unter bestimmten Bedingungen sein eigenes Sandbox-Attribut entfernen.
Diese Warnung veranschaulicht die übergeordnete Regel. Eine Sandbox bleibt nur dann nützlich, wenn ihre Konfiguration, das Origin-Design und die umgebenden Schnittstellen die beabsichtigte Trennung bewahren.
Das Bereitstellen von Erweiterungscode über eine separate Origin kann den Schaden begrenzen, falls dieser Code feindselig wird. Es verhindert außerdem den direkten Zugriff auf das Document Object Model der Host-Seite gemäß der Same-Origin-Policy des Browsers.
Die Kommunikation kann über postMessage erfolgen, wodurch Fenster strukturierte Nachrichten originübergreifend austauschen können. Der Host muss weiterhin Absender, Nachrichtentyp, Nutzlast und den angeforderten Vorgang validieren.
Eine unsichere Nachrichtenbrücke kann eine sorgfältige iframe-Konfiguration zunichtemachen. Wenn generierter Code „alle Datensätze löschen“ an einen unkritischen Host senden kann, bietet das Blockieren des direkten Datenbankzugriffs wenig Sicherheit.
Das bessere Design stellt schmale Verben bereit. Eine Erweiterung könnte readSelectedDocuments, renderChart oder proposeMetadataUpdate anfordern, vorbehaltlich Autorisierung und Validierung.
Sensible Änderungen sollten den verantwortlichen Kern durchlaufen. Dieser Kern kann den aktiven Nutzer, die aktuelle Datensatzversion, die zulässige Feldmenge und geltende organisatorische Richtlinien prüfen.
Er kann außerdem eine Bestätigung verlangen. Das Lesen freigegebener Werte für ein Diagramm unterscheidet sich davon, diese Werte an einen externen Server zu senden.
Content Security Policy fügt eine weitere Ebene hinzu. Eine Content Policy ermöglicht es Websites, einzuschränken, woher Skripte, Bilder, Frames, Styles und Netzwerkanfragen stammen dürfen.
Bei generierten Erweiterungen ist Netzwerkkontrolle ebenso wichtig wie die Ausführung von Code. Ein harmlos wirkendes Widget kann zu einem Kanal für Datenexfiltration werden, wenn es Anwendungsinhalte an beliebige Domains übertragen kann.
Eine strenge Richtlinie kann die meisten ausgehenden Verbindungen blockieren. Der Host könnte dann genehmigte Anfragen über einen Dienst weiterleiten, der Authentifizierung, Ratenbegrenzungen, Protokollierung und Zielregeln anwendet.
WebAssembly bietet eine weitere mögliche Laufzeitumgebung für begrenzte Berechnungen. Sein Sicherheitsmodell beschreibt die Ausführung innerhalb einer Sandbox-Umgebung und den Zugriff über explizite APIs, die vom Einbettenden bereitgestellt werden.
WebAssembly bestimmt keine Produktberechtigungen. Es stellt ein Ausführungsformat auf niedrigerer Ebene bereit, das in Verbindung mit einem sorgfältig konzipierten Host Isolation unterstützen kann.
Manche Erweiterungen benötigen überhaupt keinen beliebigen Code. Ein Produkt kann das LLM eine deklarative Spezifikation generieren lassen, die Felder, Filter, Layout, Berechnungen und erlaubte Aktionen beschreibt.
Die Anwendung interpretiert diese Spezifikation dann mithilfe vertrauenswürdiger Komponenten. Dieser Ansatz begrenzt die Ausdrucksmöglichkeiten, erleichtert jedoch die Prüfung und Validierung des Verhaltens.
Andere Aufgaben erfordern echten Code. Datentransformation, benutzerdefinierte Visualisierungen und spezialisierte Analyseverfahren überschreiten oft die Grenzen eines festen Schemas.
Eine ausgereifte Plattform könnte mehrere Ausführungsebenen unterstützen. Einfache Erweiterungen verwenden deklarative Regeln. Komplexere laufen unter strengerer Prüfung und engeren Berechtigungen mit JavaScript oder WebAssembly.
Der Host muss Modellausgaben auf jeder Ebene als nicht vertrauenswürdig behandeln. Natürlichsprachliche Absicht garantiert nicht, dass generierter Code dieselbe Absicht umsetzt.
Das Modell kann ein Feld missverstehen, eine Bedingung umkehren, einen Sonderfall auslassen oder sich auf ein nicht dokumentiertes Verhalten stützen. Es kann auch unsichere Muster aus öffentlich verfügbarem Code reproduzieren.
Prompt Injection fügt ein weiteres Risiko hinzu. Eine Erweiterung, die Dokumente oder Webseiten verarbeitet, kann auf Text stoßen, der darauf ausgelegt ist, das Verhalten des Modells zu verändern.
Die Leitlinien von OWASP zu Prompt Injection erklären, warum Modellanweisungen und externe Daten nicht immer sauber voneinander getrennt werden können. Filtern allein beseitigt das Problem nicht.
Die Laufzeitumgebung sollte daher davon ausgehen, dass generierte Logik fehlerhaft sein kann, selbst wenn kein Angreifer vorhanden ist. Berechtigungen begrenzen die Folgen, während Tests und Vorschauen helfen, Fehler zu erkennen.
Ein sinnvoller Erstellungsablauf würde das angeforderte Verhalten, die generierte Implementierung, deklarierte Eingaben, Berechtigungen und eine Beispielausgabe vor der Installation anzeigen.
Bei der ersten Ausführung sollte die Erweiterung Testdaten statt Produktionsdaten erhalten. Nutzer können erwartetes und tatsächliches Verhalten vergleichen, ohne eine irreversible Änderung zu riskieren.
Bei Schreiboperationen kann der Host einen Diff anzeigen. Die Erweiterung schlägt Änderungen vor, und der Kern wendet sie erst nach Validierung oder Bestätigung an.
Auch ein Rollback ist wichtig. Wenn eine Erweiterung viele Datensätze gemäß der falschen Regel korrekt aktualisiert, war die Sandbox technisch erfolgreich, während dem Nutzer dennoch Schaden entstanden ist.
Eine verantwortliche Plattform braucht eine unveränderliche Historie oder kompensierende Operationen. Sie sollte erkennen lassen, welche Erweiterungsversion jede Änderung verursacht hat und wer ihre Ausführung genehmigt hat.
Hier hat Morrells „verantwortlicher Kern“ mehr Gewicht als „moderne Sandbox-Primitiven“. Sandboxing senkt die Infrastrukturkosten der Isolation. Verantwortlichkeit erfordert Produktdesign, Governance und operative Disziplin.
Die generierte Erweiterung muss diesen Systemen untergeordnet bleiben. Andernfalls verlagert die Plattform lediglich weitreichende KI-Handlungsfähigkeit in ein kleineres Fenster.
Die fehlende Ebene ist Governance für kurzlebigen Code
Günstige Codegenerierung schafft ein Wartungsproblem, weil nützliche Erweiterungen selten dauerhaft kurzlebig bleiben.
Ein Nutzer kann ein einmaliges Tool für ein Meeting generieren und es danach nie wieder öffnen. Das ist der einfachste Fall, weil Wert und Risiko der Erweiterung gemeinsam enden.
Erfolgreiche Erweiterungen verhalten sich anders. Kollegen kopieren sie, Workflows beginnen von ihnen abzuhängen, und vorübergehende Annahmen werden zu inoffizieller Infrastruktur.
Ab diesem Punkt wird die Urheberschaft kompliziert. Der Nutzer lieferte die Absicht, das Modell einen Großteil der Implementierung, und der Host lieferte Schnittstellen und Laufzeitkontrollen.
Die Plattform braucht dennoch einen verantwortlichen Eigentümer. Jemand muss entscheiden, ob die Erweiterung weiterhin gültig ist, nachdem sich Anwendungsdaten, Richtlinien oder APIs ändern.
Generierter Code lässt sich möglicherweise günstig ersetzen, der Workflow darum jedoch nicht. Ein Team könnte bei operativen oder finanziellen Entscheidungen auf einen Bericht angewiesen sein.
Der verantwortliche Kern sollte Erweiterungen nach Reichweite und Konsequenz klassifizieren. Eine persönliche schreibgeschützte Ansicht verdient einen leichteren Prozess als eine organisationsweite Automatisierung mit Schreibzugriff.
Eine Hochstufung kann stärkere Kontrollen auslösen. Das Teilen einer Erweiterung könnte automatisierte Tests, eine benannte Verantwortlichkeit, eine Berechtigungsprüfung und ein Ablaufdatum erfordern.
Eine breitere Bereitstellung könnte die Genehmigung durch einen Administrator oder den Eigentümer der Anwendung erfordern. Die Prüfung sollte sich auf Fähigkeiten und Datenflüsse konzentrieren, nicht nur auf den Quellcode.
Code-Review allein reicht nicht aus, weil sich generierter Code häufig ändern kann. Prüfer brauchen stabile Beschreibungen dessen, was eine Erweiterung liest, sendet, ändert und speichert.
Diese Beschreibungen sollten durchgesetzt und nicht bloß dekorativ sein. Wenn eine Erweiterung erklärt, dass sie ausgewählte Datensätze liest, sollte die Laufzeit den Zugriff auf nicht zusammenhängende Datensätze verhindern.
Versionierung ist ebenso wichtig. Das erneute Generieren einer Erweiterung nach einer Nutzeranfrage erzeugt neues Verhalten, selbst wenn der sichtbare Name unverändert bleibt.
Die Plattform sollte jede Revision, ihre generierende Anfrage, Modellkonfiguration, Berechtigungen, Tests und ihren Genehmigungsstatus erhalten. Bestehende Nutzer sollten keine stillen Änderungen erhalten.
Modellaktualisierungen bringen eine weitere Unsicherheit mit sich. Dieselbe Anweisung kann anderen Code erzeugen, nachdem ein Anbieter ein Modell geändert hat.
Reproduzierbarkeit kann erfordern, das generierte Artefakt zu speichern, statt es bei jeder Ausführung neu zu generieren. Das Artefakt kann vor der Ausführung getestet und signiert werden.
Abhängigkeiten schaffen ein verwandtes Risiko. Generiertem Code zu erlauben, beliebige Pakete zu importieren, erweitert die Vertrauensfläche und verkompliziert den langfristigen Betrieb.
Eine eingeschränkte Standardbibliothek wäre weniger flexibel, aber zuverlässiger. Der Host könnte geprüfte Komponenten für Diagramme, Parsing, Datumsangaben, Speicherung und Nutzerinteraktion bereitstellen.
Erweiterungen könnten diese Komponenten kombinieren, ohne neuen Code herunterzuladen. Wenn eine Schwachstelle auftritt, könnte die Plattform die gemeinsam genutzte Komponente zentral aktualisieren.
Auch die Nutzererfahrung braucht Grenzen. Menschen zu bitten, eine lange Liste technischer Berechtigungen zu genehmigen, führt zu Gewöhnung statt zu informierter Zustimmung.
Berechtigungsanfragen sollten die Folgen in der Sprache der Aufgabe beschreiben. „Ausgewählte Dokumente an api.example.com senden“ ist nützlicher als eine allgemeine Aufforderung zum Netzwerkzugriff.
Standardeinstellungen sollten schreibgeschütztes Verhalten, begrenzte Bereiche und temporäre Berechtigungen bevorzugen. Dauerhafter Zugriff sollte einen Grund erfordern, der mit einem wiederkehrenden Workflow verbunden ist.
Der stärkste Einwand gegen Morrells Hypothese lautet daher nicht, dass Sandboxing versagt. Er lautet, dass die überzeugende Demo endet, bevor Governance beginnt.
Ein generiertes Widget kann nach einem Prompt erfolgreich wirken. Ein zuverlässiges Erweiterungssystem muss gemeinsame Nutzung, Richtlinienänderungen, bösartige Eingaben, Modelländerungen und Personalwechsel überstehen.
Diese Arbeit kann die anfänglichen Kosten der Codeerstellung überwiegen. Sie verschwindet nicht, weil die Anwendung in einem Browser läuft.
Es gibt auch ein Risiko für das Produktdesign. Endlose Anpassbarkeit kann eine Anwendung schwerer verständlich, unterstützbar und konsistent nutzbar machen.
Zwei Kollegen könnten innerhalb dessen, was wie dasselbe Produkt wirkt, unterschiedliche Befehle, Felder und Berechnungen sehen. Support-Teams könnten Schwierigkeiten haben, ein Problem zu reproduzieren.
Organisationen könnten darauf reagieren, indem sie erfolgreiche Erweiterungen standardisieren. Die Plattform kann wiederkehrende lokale Bedürfnisse beobachten und ausgereifte Lösungen zu unterstützten Funktionen weiterentwickeln.
Das schafft eine nützliche Rückkopplungsschleife. Nutzer erkunden den Long Tail, während der Anbieter Muster identifiziert, die dauerhaftes Design und Wartung verdienen.
Das Modell ersetzt das Produktteam in dieser Schleife nicht. Es hilft Nutzern, Belege für unerfüllte Bedürfnisse zu prototypisieren.
Erweiterungen, die eng begrenzt bleiben, können lokal bleiben. Erweiterungen, die wichtig werden, können eine strengere Prüfung durchlaufen und schließlich in den Kern übergehen.
Das ist verantwortlicher, als jedes generierte Artefakt entweder als kurzlebig oder als produktionsreif zu behandeln. Es erkennt an, dass Software ihren Status ändert, wenn Menschen beginnen, von ihr abhängig zu sein.
Die offene Frage ist, ob Anbieter diesen Lebenszyklus schaffen werden, bevor Nutzer ein unkontrolliertes Schattenökosystem aufbauen. LLMs machen die Codegenerierung bereits leicht genug, um der Governance davonzulaufen.
Worauf Leser von Simon Willison als Nächstes achten sollten
Die Hypothese wird glaubwürdiger, wenn Produkte eingeschränkte Erweiterungssysteme anbieten, die gewöhnliche Nutzer bedienen können, ohne weitreichenden Agentenzugriff zu gewähren.
Das erste Signal ist ein echtes Berechtigungsmodell für generierte Erweiterungen. Achten Sie auf Produkte, die eng begrenzte Fähigkeiten, getrennte Ausführungsursprünge, Kontrollen für ausgehendes Netzwerk und lesbare Berechtigungsmanifeste bereitstellen.
Eine überzeugende Implementierung macht Ablehnung zum Standard. Erweiterungen sollten nur die Daten und Operationen erhalten, die für ihren erklärten Zweck erforderlich sind.
Die stärksten Belege kämen von einem System, das Schreibzugriff sicher handhabt. Vorschauen, Diffs, Bestätigungen, Prüfprotokolle und Rollback sollten zusammenwirken, statt als getrennte Optionen zu erscheinen.
Wenn Anbieter diese Kontrollen ausliefern, wird Morrells Modell des verantwortlichen Kerns wesentlich stärker. Wenn Erweiterungen routinemäßig weitreichende Tokens oder vollständigen Seitenzugriff benötigen, wird das Modell schwächer.
Das zweite Signal ist, wie Plattformen eine Erweiterung nach ihrer ersten erfolgreichen Ausführung verwalten. Erstellungsdemos gibt es reichlich, doch Belege für den Lebenszyklus bleiben wertvoller.
Achten Sie auf Versions-Pinning, automatisierte Tests, Verantwortlichkeit, Ablaufdaten, Abhängigkeitskontrollen und einen Hochstufungspfad von der persönlichen zur Teamnutzung.
Eine Plattform sollte auch zeigen, was geschieht, nachdem sich ihre API ändert. Erweiterungen benötigen Kompatibilitätsverträge oder klare Fehler, nicht stillschweigend falsche Ergebnisse.
Erfolgreiches Lifecycle-Management würde zeigen, dass günstige Erstellung keine unbeherrschbaren Software-Schulden erzeugt. Häufige Ausfälle würden die skeptische Sichtweise bestärken.
Das dritte Signal ist das Nutzerverhalten. Die Theorie hängt davon ab, dass Menschen spezifische Tools erstellen, die sicherer und nützlicher bleiben als allgemeine Agenten oder externe Umgehungslösungen.
Nützliche Messgrößen umfassen die Wiederverwendung von Erweiterungen, verweigerte Berechtigungen, die Häufigkeit von Rollbacks, die Zeit bis zur Reparatur und den Anteil der Erstellungen, die zu wiederkehrenden Workflows werden.
Diese Zahlen sollten sorgfältig interpretiert werden. Eine hohe Zahl an Erstellungen kann auf Experimentierfreude, Verwirrung oder Neuheit statt auf nachhaltigen Wert hindeuten.
Das aussagekräftigere Ergebnis ist, ob Nutzer zuvor vernachlässigte Aufgaben lösen, ohne Sicherheitsvorfälle oder Supportaufwand zu erhöhen.
Forscher und Unternehmenskäufer sollten zudem beobachten, wo Erweiterungen laufen. Browserisolation ist attraktiv, doch manche Workloads benötigen lokale Dateien, private Dienste oder rechenintensive Verarbeitung.
Plattformen können Remote-Container, Edge-Isolates, WebAssembly-Laufzeitumgebungen oder Kombinationen dieser Systeme nutzen. Jede Entscheidung verändert Latenz, Kosten, Datenexposition und operative Verantwortung.
Der Browser bleibt wertvoll, weil er bereits Ursprünge, Berechtigungen und Nutzerinteraktionen vermittelt. Seine Kontrollen werden zudem von Sicherheitsteams weithin verstanden.
Dennoch kann keine Laufzeitumgebung aus generiertem Code die korrekten geschäftlichen Berechtigungen ableiten. Der Host muss diese Richtlinie aus seinem vertrauenswürdigen Kern bereitstellen.
Für Entwickler lautet die praktische Frage nicht, ob LLMs eine Erweiterung schreiben können. Sie erzeugen bereits häufig genug nützlichen Code, damit dieser Gestaltungsraum relevant ist.
Die Frage ist, ob eine Anwendung Fehler zu einem normalen und behebbaren Zustand machen kann. Schlechte Ergebnisse sollten eingegrenzt, sichtbar, rückgängig zu machen und kostengünstig zu ersetzen sein.
Unternehmenskäufer sollten Anbieter bitten, eine feindselige oder fehlerhafte Erweiterung vorzuführen – nicht nur eine erfolgreiche. Beobachten Sie, auf welche Daten sie zugreifen kann und welche Aktionen der Host verweigert.
Für Wissensarbeiter zählt eine Anpassbarkeit, die auch nach Ende des Chats verständlich bleibt. Sie sollten prüfen können, was das Tool tut, es überarbeiten, deaktivieren und seine Auswirkungen nachvollziehen können.
Das Zitat von Simon Willison ist wichtig, weil es KI-generierten Code als Komponente und nicht als das gesamte Produkt einordnet. Diese zurückhaltende Einordnung verleiht der Idee Glaubwürdigkeit.
Morrells Hypothese verlangt nicht, dass jeder Nutzer zum Softwareentwickler wird. Sie setzt voraus, dass Anwendungen sichere Bausteine bereitstellen, die ein LLM unter Anleitung des Nutzers zusammensetzen kann.
Die Chance ist real, doch das erfolgreiche Produkt wird nicht das sein, das den meisten Code generiert. Es wird das sein, das generiertes Verhalten rechenschaftspflichtig macht.
Wenn Sie das nächste erweiterbare KI-Produkt bewerten, fordern Sie eine eng umrissene Anpassung an und geben Sie ihm anschließend bewusst eine irreführende Eingabe. Können Sie seine Berechtigungen einsehen, die vorgeschlagenen Änderungen prüfen und das Ergebnis rückgängig machen?
Diese Fragen zeigen mehr als eine polierte Generierungsdemo. Sie prüfen, ob das Produkt den soliden Kern aufgebaut hat, den Morrell beschreibt.
Behalten Sie die Berichterstattung von Simon Willison über konkrete Implementierungen im Blick, legen Sie jedoch bei jeder davon denselben Maßstab an. Führt das System lediglich KI-geschriebenen Code aus, oder macht es diesen Code über seine gesamte Nutzungsdauer hinweg steuerbar?
