Simon Willison cita Jeremy Morrell, ma le estensioni AI sicure richiedono più di una sandbox
Simon Willison ha evidenziato un conflitto concreto il 19 agosto 2026: gli LLM rendono più facile scrivere estensioni software, mentre il codice che generano resta difficile da considerare affidabile.
L'osservazione proviene da Jeremy Morrell, secondo cui le applicazioni web possono combinare un nucleo responsabile con estensioni create dagli utenti. I modelli linguistici di grandi dimensioni genererebbero tali estensioni, mentre le sandbox del browser limiterebbero ciò a cui il codice risultante può accedere.
Questo modello mette in discussione due approcci familiari. Le applicazioni tradizionali offrono funzionalità fisse selezionate dai loro sviluppatori. Gli agenti AI generici ricevono un accesso ampio e tentano di operare sulle interfacce esistenti per conto dell'utente.
Morrell propone una terza via. L'applicazione mantiene il suo centro affidabile, ma gli utenti possono descrivere le capacità mancanti nel momento in cui le incontrano. Un LLM fornisce codice delimitato invece di controllare l'intero prodotto.
La proposta sembra semplice perché i browser contengono già meccanismi di isolamento. Tuttavia, la generazione del codice e l'esecuzione sicura risolvono solo una parte del problema. I prodotti devono anche controllare autorizzazioni, movimento dei dati, aggiornamenti, responsabilità e ripristino quando un'estensione si comporta in modo errato.
La vera competizione non è quindi tra software fisso e personalizzazione illimitata. È tra estensibilità responsabile e autonomia AI senza restrizioni.
Simon Willison riporta il software estensibile al centro dell'attenzione
L'evento importante non è il lancio di un prodotto, ma un'ipotesi architetturale più nitida per il software AI.
Nel suo post del 19 agosto, Simon Willison ha citato l'argomentazione di Morrell su una nuova opportunità per il software web estensibile. Il post ha associato l'idea a sandboxing, LLM, AI e AI generativa.
L'ipotesi di Morrell unisce due cambiamenti che sono stati spesso discussi separatamente. Gli LLM riducono lo sforzo necessario per produrre piccole quantità di codice applicativo. Le piattaforme web moderne offrono primitive in grado di limitare dove quel codice viene eseguito e cosa può fare.
Nessuno dei due cambiamenti elimina l'ingegneria del software. Insieme, tuttavia, modificano l'economia di una funzionalità che serve una sola persona o un solo team.
Un team di prodotto convenzionale deve valutare una richiesta, progettare l'interazione, implementarla, testarla, documentarla e mantenerla. Questo processo ha senso per funzionalità ampiamente condivise. Raramente funziona per un flusso di lavoro ristretto usato da poche persone.
Un LLM può trasformare una richiesta specifica in codice senza attendere che la funzionalità entri in una roadmap pubblica. L'estensione risultante potrebbe trasformare un documento, aggiungere una visualizzazione personalizzata, convalidare un modulo o collegare due fonti di dati autorizzate.
Questo non rende corretto il codice generato. Rende però molto meno costoso tentare la prima implementazione.
La seconda metà dell'argomentazione di Morrell riguarda il deployment. Storicamente, installare estensioni di terze parti significava spesso fidarsi di un pacchetto, concedere autorizzazioni ampie o eseguire codice all'interno di un processo applicativo privilegiato.
Il browser offre una base diversa. Un frame in sandbox crea un contesto di navigazione separato e può disabilitare capacità a meno che l'host non le ripristini esplicitamente.
I controlli disponibili sono specifici anziché simbolici. L'host può limitare script, moduli, popup, download, accesso allo storage e navigazione di primo livello. Può anche applicare una Permissions Policy a funzionalità come fotocamere e microfoni.
Questi controlli rendono possibile un confine di sicurezza significativo. Non producono automaticamente il confine corretto per ogni estensione.
L'espressione di Morrell, “solid, accountable core”, è la parte decisiva della proposta. L'applicazione host continuerebbe a possedere identità, dati persistenti, autorizzazioni, cronologia di audit e operazioni critiche.
Le estensioni generate colmerebbero lacune locali attorno a quel nucleo. Non sostituirebbero silenziosamente il suo modello di sicurezza né diventerebbero la fonte autorevole dei dati.
Questa distinzione separa il software estensibile da un chatbot generico di programmazione. Un chatbot può produrre un file e lasciare all'utente la responsabilità di eseguirlo in sicurezza. Un'applicazione estensibile può definire dove risiede il codice generato, quali interfacce riceve e come vengono esaminate le sue azioni.
Distingue inoltre l'idea dai normali marketplace di plugin. I plugin tradizionali sono solitamente creati per molti utenti, confezionati come prodotti e distribuiti attraverso un processo di revisione. Le estensioni generate da LLM possono rivolgersi a un singolo flusso di lavoro e rimanere comunque all'interno di un runtime controllato.
L'evento conta perché il post di Willison offre a questa architettura una cornice pubblica concisa. L'affermazione non è che l'AI debba riprogettare ogni interfaccia. È che l'AI può rendere economicamente sostenibile una personalizzazione attentamente delimitata.
È un argomento più ristretto rispetto a “gli agenti sostituiranno le app”. È anche più facile da testare.
La pressione ricade sui prodotti SaaS fissi e sugli agenti AI ad ampio raggio
I prodotti affrontano ora la pressione di offrire personalizzazione senza cedere il controllo sui dati degli utenti o sui flussi di lavoro principali.
Il software fisso funziona prevedendo esigenze comuni. I suoi progettisti scelgono gli oggetti, i comandi, le viste, le integrazioni e le regole di automazione disponibili prima che i clienti incontrino i propri casi limite individuali.
Questo modello produce coerenza. Crea anche un arretrato permanente di richieste troppo specifiche per giustificare uno sviluppo condiviso.
I clienti enterprise aggirano queste lacune con fogli di calcolo, script, estensioni del browser, piattaforme di integrazione e procedure manuali. Ogni soluzione alternativa introduce un altro punto in cui la logica può diventare obsoleta o invisibile.
Il software estensibile avvicina questa logica all'applicazione che possiede i dati rilevanti. Un'estensione generata può usare un'interfaccia ristretta definita dall'host invece di estrarre schermate o copiare record altrove.
Si consideri un project manager che desidera un pannello di revisione basato su diversi campi di metadati insoliti. Il prodotto potrebbe non distribuire mai quel pannello esatto perché pochi clienti ne hanno bisogno.
Un'estensione potrebbe richiedere record approvati, calcolare il raggruppamento necessario e visualizzare una vista temporanea. L'applicazione core continuerebbe a imporre quali record l'utente può leggere.
Un ricercatore potrebbe desiderare un estrattore una tantum per un formato di documento ricorrente. Un ingegnere potrebbe aver bisogno di una dashboard per una convenzione di deployment privata. Un team vendite potrebbe voler applicare una regola di convalida legata al proprio processo di gestione degli account.
Queste richieste sono troppo piccole per la maggior parte delle roadmap, ma troppo ripetitive per il lavoro manuale. Costituiscono l'opportunità economica alla base dell'ipotesi di Morrell.
Geoffrey Litt ha descritto una visione correlata nel suo lavoro precedente sul software malleabile. Litt sosteneva che gli LLM possano agire come sviluppatori locali all'interno di ambienti computazionali che gli utenti già comprendono.
Questo riferimento storico conta perché la programmazione da parte degli utenti finali non è una novità. Fogli di calcolo, macro, HyperCard, script per browser e strumenti di automazione visuale hanno tutti consentito alle persone di modificare il proprio ambiente di lavoro.
Il collo di bottiglia persistente non era soltanto la sintassi. Gli utenti dovevano tradurre un obiettivo informale in logica eseguibile, comprendere le interfacce disponibili e correggere il risultato.
Gli LLM comprimono parti di questo processo di traduzione. Un utente può descrivere un risultato in linguaggio di dominio, esaminare un'estensione proposta e rivederla attraverso esempi.
L'estensione necessita comunque di un substrato stabile. Senza oggetti e capacità definite, il modello deve indovinare come funziona l'applicazione. Questo produce codice fragile e incoraggia l'automazione delle schermate.
Ciò esercita pressione sui fornitori SaaS affinché espongano elementi costitutivi più piccoli e sicuri. Un prodotto progettato solo per i clic umani offre a un LLM meno modi affidabili per estenderlo.
La stessa pressione si applica agli agenti AI ad ampio raggio. Un agente con accesso a email, file, sessioni di navigazione e strumenti interni può svolgere lavori diversi. Questo accesso amplia anche le conseguenze di un'istruzione errata.
Un'estensione delimitata adotta l'approccio opposto. Riceve le capacità minime necessarie per un singolo compito. L'applicazione circostante media le operazioni sensibili.
Il compromesso è una minore autonomia. Un'estensione ristretta non può improvvisare su ogni servizio né recuperare dati arbitrari. Questa limitazione è il punto, non un difetto.
Per gli acquirenti, la domanda diventa più concreta che chiedersi se un prodotto “ha l'AI”. Possono chiedere se gli utenti possono creare capacità locali senza concedere a un modello un accesso senza restrizioni.
Possono anche verificare se il comportamento generato rimane visibile. Un piano nascosto di un agente è difficile da controllare dopo un errore. Un'estensione installata può esporre il proprio codice, le autorizzazioni dichiarate, input, output e cronologia delle revisioni.
Le applicazioni fisse non scompariranno con questo modello. Le funzionalità condivise richiedono ancora progettazione professionale, lavoro sull'accessibilità, test delle prestazioni, supporto e manutenzione a lungo termine.
La probabile pressione riguarda il confine attorno a tali funzionalità. I fornitori che mantengono chiuso ogni flusso di lavoro devono competere con prodotti che consentono agli utenti di completare in sicurezza l'ultimo miglio da soli.
I team avranno anche bisogno di modi migliori per preservare il contesto dietro i comportamenti personalizzati. Una base di conoscenza ingegneristica ricercabile può documentare perché esiste un'estensione, quali ipotesi adotta e chi ne è responsabile.
Questa documentazione diventa essenziale quando le estensioni generate si diffondono da un utente a un reparto. La creazione economica non elimina il costo della memoria istituzionale.
Le sandbox riducono il costo del deployment, non il costo della responsabilità
Una sandbox può limitare l'esecuzione del codice, ma il prodotto deve comunque progettare ogni percorso significativo attraverso il confine.
Una sandbox del browser non è un singolo muro protettivo. È un insieme di restrizioni che coprono origine, script, navigazione, storage, capacità dei dispositivi e comunicazione con l'host.
L'attributo sandbox su un iframe parte da una configurazione restrittiva. L'applicazione può quindi ripristinare capacità selezionate tramite token espliciti.
Questo è un modello basato sulle capacità, ossia il codice riceve poteri specifici invece di ereditare ogni privilegio detenuto dal suo host. L'host potrebbe consentire rendering e calcoli negando download, navigazione di primo livello o storage same-origin.
La documentazione dei browser identifica anche una combinazione pericolosa. Un frame same-origin a cui siano concessi sia gli script sia i privilegi same-origin può rimuovere il proprio attributo sandbox in determinate condizioni.
Questo avvertimento illustra la regola più ampia. Una sandbox resta utile solo quando la sua configurazione, il design dell'origine e le interfacce circostanti preservano la separazione prevista.
Servire il codice dell'estensione da un'origine separata può ridurre i danni se quel codice diventa ostile. Impedisce inoltre l'accesso diretto al Document Object Model della pagina host secondo la policy same-origin del browser.
La comunicazione può avvenire tramite postMessage, che consente alle finestre di scambiarsi messaggi strutturati tra origini diverse. L'host deve comunque convalidare il mittente, il tipo di messaggio, il payload e l'operazione richiesta.
Un ponte di messaggistica non sicuro può vanificare un'accurata configurazione dell'iframe. Se il codice generato può inviare “elimina tutti i record” a un host che non verifica nulla, bloccare l'accesso diretto al database offre ben poco conforto.
Il design migliore espone verbi ristretti. Un'estensione potrebbe richiedere readSelectedDocuments, renderChart o proposeMetadataUpdate, soggetti ad autorizzazione e convalida.
Le modifiche sensibili dovrebbero passare attraverso il core responsabile. Questo core può verificare l’utente attivo, la versione corrente del record, l’insieme di campi consentiti e la politica organizzativa applicabile.
Può anche richiedere una conferma. Leggere valori approvati per un grafico è diverso dall’inviarli a un server esterno.
La Content Security Policy aggiunge un ulteriore livello. Una content policy consente ai siti di limitare le origini di script, immagini, frame, stili e richieste di rete.
Per le estensioni generate, il controllo della rete conta quanto l’esecuzione del codice. Un widget apparentemente innocuo può diventare un canale di esfiltrazione dei dati se può trasmettere i contenuti dell’applicazione a domini arbitrari.
Una policy rigorosa può bloccare la maggior parte delle connessioni in uscita. L’host potrebbe quindi inoltrare richieste approvate tramite un servizio che applica autenticazione, limiti di frequenza, logging e regole sulle destinazioni.
WebAssembly offre un altro possibile runtime per il calcolo delimitato. Il suo security model descrive l’esecuzione in un ambiente sandbox e l’accesso tramite API esplicite fornite dall’embedder.
WebAssembly non determina le autorizzazioni del prodotto. Fornisce un formato di esecuzione di livello inferiore che può favorire l’isolamento se abbinato a un host progettato con cura.
Alcune estensioni non avranno affatto bisogno di codice arbitrario. Un prodotto può far generare all’LLM una specifica dichiarativa che descriva campi, filtri, layout, calcoli e azioni consentite.
L’applicazione interpreta quindi quella specifica mediante componenti affidabili. Questo approccio limita l’espressività, ma rende il comportamento più facile da ispezionare e validare.
Altre attività richiedono codice reale. La trasformazione dei dati, le visualizzazioni personalizzate e il parsing specializzato spesso superano i limiti di uno schema fisso.
Una piattaforma matura potrebbe supportare diversi livelli di esecuzione. Le estensioni semplici usano regole dichiarative. Quelle più complesse eseguono JavaScript o WebAssembly con revisioni più rigorose e autorizzazioni più ristrette.
L’host deve trattare l’output del modello come non affidabile a ogni livello. L’intento espresso in linguaggio naturale non garantisce che il codice generato implementi lo stesso intento.
Il modello può fraintendere un campo, invertire una condizione, omettere un caso limite o dipendere da un comportamento non documentato. Può anche riprodurre pattern non sicuri appresi dal codice pubblico.
Il prompt injection aggiunge un altro rischio. Un’estensione che elabora documenti o pagine web può incontrare testo progettato per alterare il comportamento del modello.
Le linee guida sul prompt injection di OWASP spiegano perché le istruzioni del modello e i dati esterni non possono sempre essere separati in modo netto. Il solo filtraggio non elimina il problema.
Il runtime dovrebbe quindi presumere che la logica generata possa essere errata, anche in assenza di un attaccante. Le autorizzazioni limitano le conseguenze, mentre test e anteprime aiutano a rilevare gli errori.
Un utile flusso di creazione mostrerebbe il comportamento richiesto, l’implementazione generata, gli input dichiarati, le autorizzazioni e un output di esempio prima dell’installazione.
Durante la prima esecuzione, l’estensione dovrebbe ricevere fixture di test anziché dati di produzione. Gli utenti possono confrontare il comportamento previsto con quello effettivo senza rischiare una modifica irreversibile.
Per le operazioni di scrittura, l’host può presentare un diff. L’estensione propone le modifiche e il core le applica solo dopo validazione o conferma.
Anche il rollback è importante. Se un’estensione aggiorna correttamente molti record secondo una regola sbagliata, la sandbox ha tecnicamente avuto successo mentre l’utente ha comunque subito un danno.
Una piattaforma responsabile necessita di una cronologia immutabile o di operazioni compensative. Dovrebbe identificare quale revisione dell’estensione ha causato ogni modifica e chi ne ha approvato l’esecuzione.
È qui che il “accountable core” di Morrell ha più peso rispetto alle “modern sandbox primitives”. Il sandboxing riduce il costo infrastrutturale dell’isolamento. La responsabilità richiede progettazione del prodotto, governance e disciplina operativa.
L’estensione generata deve rimanere subordinata a tali sistemi. Altrimenti, la piattaforma si limita a trasferire un’ampia agentività dell’IA in una finestra più piccola.
Il livello mancante è la governance per il codice usa e getta
La generazione economica di codice crea un problema di manutenzione perché le estensioni utili raramente restano usa e getta.
Un utente può generare uno strumento una tantum per una riunione e non riaprirlo mai più. È il caso più semplice, perché valore e rischio dell’estensione terminano insieme.
Le estensioni di successo si comportano diversamente. I colleghi le copiano, i flussi di lavoro iniziano a dipendere da esse e le ipotesi temporanee diventano infrastruttura non ufficiale.
A quel punto, l’attribuzione della paternità diventa complicata. L’utente ha fornito l’intento, il modello ha fornito gran parte dell’implementazione e l’host ha fornito interfacce e controlli del runtime.
La piattaforma ha comunque bisogno di un proprietario responsabile. Qualcuno deve decidere se l’estensione resta valida dopo modifiche ai dati dell’applicazione, alle policy o alle API.
Il codice generato può essere economico da sostituire, ma il flusso di lavoro che lo circonda potrebbe non esserlo. Un team potrebbe fare affidamento su un report per prendere decisioni operative o finanziarie.
Il core responsabile dovrebbe classificare le estensioni in base alla portata e alle conseguenze. Una vista personale in sola lettura merita un processo più leggero rispetto a un’automazione a livello organizzativo con accesso in scrittura.
La promozione può attivare controlli più rigorosi. La condivisione di un’estensione potrebbe richiedere test automatizzati, una proprietà nominativa, la revisione delle autorizzazioni e una data di scadenza.
Una distribuzione più ampia potrebbe richiedere l’approvazione di un amministratore o del proprietario dell’applicazione. La revisione dovrebbe concentrarsi sulle capacità e sui flussi di dati, non solo sul codice sorgente.
La sola revisione del codice è insufficiente perché il codice generato può cambiare frequentemente. I revisori hanno bisogno di descrizioni stabili di ciò che un’estensione legge, invia, modifica e conserva.
Tali descrizioni dovrebbero essere applicate, non decorative. Se un’estensione dichiara di leggere record selezionati, il runtime dovrebbe impedirle di accedere a record non correlati.
Il versioning è altrettanto importante. Rigenerare un’estensione dopo una richiesta dell’utente crea un nuovo comportamento, anche quando il nome visibile rimane invariato.
La piattaforma dovrebbe conservare ogni revisione, la relativa richiesta di generazione, la configurazione del modello, le autorizzazioni, i test e lo stato di approvazione. Gli utenti esistenti non dovrebbero ricevere modifiche silenziose.
Gli aggiornamenti dei modelli introducono un’ulteriore incertezza. La stessa istruzione può produrre codice diverso dopo che un fornitore modifica un modello.
La riproducibilità può richiedere l’archiviazione dell’artefatto generato anziché la sua rigenerazione a ogni esecuzione. L’artefatto può essere testato e firmato prima dell’esecuzione.
Le dipendenze creano un rischio correlato. Consentire al codice generato di importare pacchetti arbitrari amplia la superficie fidata e complica l’operatività a lungo termine.
Una libreria standard vincolata sarebbe meno flessibile ma più affidabile. L’host potrebbe fornire componenti revisionati per grafici, parsing, date, archiviazione e interazione con l’utente.
Le estensioni potrebbero combinare tali componenti senza scaricare nuovo codice. Quando emerge una vulnerabilità, la piattaforma potrebbe aggiornare centralmente il componente condiviso.
Anche l’esperienza utente necessita di confini. Chiedere alle persone di approvare un lungo elenco di autorizzazioni tecniche porta all’assuefazione, non al consenso informato.
Le richieste di autorizzazione dovrebbero descrivere le conseguenze nel linguaggio dell’attività. “Invia i documenti selezionati a api.example.com” è più utile di una richiesta generica di accesso alla rete.
Le impostazioni predefinite dovrebbero favorire il comportamento in sola lettura, ambiti limitati e concessioni temporanee. L’accesso persistente dovrebbe richiedere una motivazione collegata a un flusso di lavoro ricorrente.
L’obiezione più forte all’ipotesi di Morrell non è quindi che il sandboxing fallisca. È che la demo attraente termina prima che inizi la governance.
Un widget generato può sembrare riuscito dopo un solo prompt. Un sistema di estensioni affidabile deve sopravvivere all’uso condiviso, alle modifiche delle policy, agli input dannosi, alle modifiche dei modelli e al turnover del personale.
Questo lavoro può superare il costo iniziale della scrittura del codice. Non scomparirà perché l’applicazione viene eseguita in un browser.
Esiste anche un rischio di progettazione del prodotto. La personalizzazione senza fine può rendere un’applicazione più difficile da comprendere, supportare e usare in modo coerente.
Due colleghi potrebbero vedere comandi, campi e calcoli diversi all’interno di quello che sembra essere lo stesso prodotto. I team di supporto potrebbero avere difficoltà a riprodurre un problema.
Le organizzazioni potrebbero rispondere standardizzando le estensioni di successo. La piattaforma può osservare esigenze locali ricorrenti e promuovere soluzioni mature a funzionalità supportate.
Questo crea un utile ciclo di feedback. Gli utenti esplorano la lunga coda, mentre il fornitore identifica pattern che meritano progettazione e manutenzione permanenti.
Il modello non sostituisce il team di prodotto in questo ciclo. Aiuta gli utenti a prototipare evidenze di esigenze non soddisfatte.
Le estensioni che restano ristrette possono rimanere locali. Quelle che diventano importanti possono passare attraverso una revisione più rigorosa e infine entrare nel core.
Questo è più responsabile che trattare ogni artefatto generato come usa e getta o pronto per la produzione. Riconosce che il software cambia stato quando le persone iniziano a dipenderne.
La questione irrisolta è se i fornitori costruiranno questo ciclo di vita prima che gli utenti creino un ecosistema ombra incontrollato. Gli LLM rendono già la generazione di codice abbastanza facile da superare la governance.
Cosa dovrebbero osservare i lettori di Simon Willison
L’ipotesi acquisirà credibilità quando i prodotti esporranno sistemi di estensioni vincolati che gli utenti comuni possono usare senza concedere un ampio accesso agli agenti.
Il primo segnale è un vero modello di autorizzazioni progettato per le estensioni generate. Occorre osservare prodotti che espongono capacità ristrette, origini di esecuzione separate, controlli della rete in uscita e manifest di autorizzazioni leggibili.
Un’implementazione convincente renderà il rifiuto l’impostazione predefinita. Le estensioni dovrebbero ricevere solo i dati e le operazioni richiesti per lo scopo dichiarato.
L’evidenza più forte proverrebbe da un sistema che gestisce in sicurezza l’accesso in scrittura. Anteprime, diff, conferme, registri di audit e rollback dovrebbero operare insieme anziché apparire come opzioni separate.
Se i fornitori distribuiscono questi controlli, il modello di accountable core di Morrell diventa materialmente più forte. Se le estensioni richiedono abitualmente token ampi o accesso completo alla pagina, il modello si indebolisce.
Il secondo segnale è il modo in cui le piattaforme gestiscono un’estensione dopo la sua prima esecuzione riuscita. Le demo di creazione sono numerose, ma le evidenze sul ciclo di vita restano più preziose.
Occorre osservare il blocco delle versioni, i test automatizzati, la proprietà, la scadenza, i controlli sulle dipendenze e un percorso di promozione dall’uso personale a quello di team.
Una piattaforma dovrebbe anche mostrare cosa accade dopo la modifica della sua API. Le estensioni necessitano di contratti di compatibilità o errori chiari, non di risultati silenziosamente errati.
Una gestione del ciclo di vita riuscita dimostrerebbe che un’autorialità economica non produce debito software ingestibile. Interruzioni frequenti rafforzerebbero la visione scettica.
Il terzo segnale è il comportamento degli utenti. La teoria dipende dalla creazione di strumenti specifici che restino più sicuri e utili degli agenti generali o delle soluzioni esterne.
Le misurazioni utili includono il riuso delle estensioni, i rifiuti di autorizzazione, la frequenza dei rollback, il tempo di riparazione e la quota di creazioni che diventano flussi di lavoro ricorrenti.
Questi dati dovrebbero essere interpretati con cautela. Un numero elevato di creazioni può indicare sperimentazione, confusione o novità anziché valore duraturo.
Il risultato più significativo è se gli utenti risolvono attività precedentemente trascurate senza aumentare gli incidenti di sicurezza o il carico di supporto.
Ricercatori e acquirenti aziendali dovrebbero anche osservare dove vengono eseguite le estensioni. L’isolamento del browser è interessante, ma alcuni carichi di lavoro richiedono file locali, servizi privati o calcolo intensivo.
Le piattaforme possono usare container remoti, isolate edge, runtime WebAssembly o combinazioni di questi sistemi. Ogni scelta modifica latenza, costo, esposizione dei dati e responsabilità operativa.
Il browser resta prezioso perché già media origini, autorizzazioni e interazione dell’utente. I suoi controlli sono inoltre ampiamente compresi dai team di sicurezza.
Eppure nessun runtime può dedurre la corretta autorizzazione aziendale dal codice generato. L’host deve fornire tale policy dal proprio nucleo fidato.
Per gli sviluppatori, la domanda pratica non è se gli LLM possano scrivere un’estensione. Producono già codice utile abbastanza spesso da rendere rilevante lo spazio progettuale.
La domanda è se un’applicazione possa rendere gli errori ordinari e recuperabili. Un output errato dovrebbe essere contenuto, visibile, reversibile ed economico da sostituire.
Per gli acquirenti enterprise, chiedete ai fornitori di dimostrare un’estensione ostile o errata, non soltanto una riuscita. Osservate a quali dati può accedere e quali azioni l’host rifiuta.
Per i knowledge worker, cercate una personalizzazione che resti comprensibile anche dopo la fine della chat. Dovreste poter ispezionare ciò che fa lo strumento, modificarlo, disabilitarlo e identificarne gli effetti.
La citazione di Simon Willison è importante perché inquadra il codice generato dall’AI come un componente, anziché come l’intero prodotto. Questa formulazione sobria conferisce credibilità all’idea.
L’ipotesi di Morrell non richiede che ogni utente diventi un ingegnere software. Richiede che le applicazioni espongano materiali sicuri che un LLM possa assemblare sotto la direzione dell’utente.
L’opportunità è reale, ma il prodotto vincente non sarà quello che genera più codice. Sarà quello che rende responsabile il comportamento generato.
Quando valutate il prossimo prodotto AI estensibile, richiedete una personalizzazione circoscritta e poi fornitegli deliberatamente un input fuorviante. Riuscite a vederne le autorizzazioni, ispezionare le modifiche proposte e annullare il risultato?
Queste domande rivelano più di una demo di generazione rifinita. Verificano se il prodotto ha costruito il nucleo solido descritto da Morrell.
Continuate a seguire la copertura di Simon Willison per implementazioni concrete, ma applicate lo stesso standard a ciascuna di esse. Il sistema si limita a eseguire codice scritto dall’AI, oppure rende quel codice governabile per tutta la sua vita utile?
