Simon Willison cita a Jeremy Morrell, pero las extensiones de IA seguras necesitan más que un sandbox

Simon Willison destacó un conflicto concreto el 19 de agosto de 2026: los LLM facilitan la creación de extensiones de software, mientras que el código que generan sigue siendo difícil de confiar.

La observación provino de Jeremy Morrell, quien sostiene que las aplicaciones web pueden combinar un núcleo responsable con extensiones creadas por los usuarios. Los grandes modelos de lenguaje generarían esas extensiones, mientras que los sandboxes del navegador limitarían a qué puede acceder el código resultante.

Ese modelo cuestiona dos enfoques conocidos. Las aplicaciones tradicionales ofrecen funciones fijas seleccionadas por sus desarrolladores. Los agentes de IA general reciben un acceso amplio e intentan operar interfaces existentes en nombre del usuario.

Morrell propone una tercera vía. La aplicación mantiene su centro fiable, pero los usuarios pueden describir las capacidades que les faltan a medida que las encuentran. Un LLM proporciona código acotado en lugar de controlar todo el producto.

La propuesta parece sencilla porque los navegadores ya incluyen mecanismos de aislamiento. Sin embargo, la generación de código y la ejecución segura resuelven solo una parte del problema. Los productos también deben controlar los permisos, el movimiento de datos, las actualizaciones, la responsabilidad y la recuperación cuando una extensión se comporta incorrectamente.

Por tanto, la verdadera competencia no es entre software fijo y personalización ilimitada. Es entre extensibilidad responsable y agencia de IA sin restricciones.

Simon Willison vuelve a poner el software extensible en la agenda

El acontecimiento importante no es el lanzamiento de un producto, sino una hipótesis arquitectónica más precisa para el software de IA.

En su publicación del 19 de agosto, Simon Willison citó el argumento de Morrell sobre una nueva oportunidad para el software web extensible. La publicación etiquetó la idea bajo sandboxing, LLMs, AI y generative AI.

La hipótesis de Morrell une dos cambios que a menudo se han debatido por separado. Los LLM reducen el esfuerzo necesario para producir pequeñas cantidades de código de aplicación. Las plataformas web modernas ofrecen primitivas capaces de restringir dónde se ejecuta ese código y qué puede hacer.

Ninguno de los dos cambios elimina la ingeniería de software. Sin embargo, juntos alteran la economía de una función que sirve únicamente a una persona o a un equipo.

Un equipo de producto convencional debe evaluar una solicitud, diseñar la interacción, implementarla, probarla, documentarla y mantenerla. Ese proceso tiene sentido para funciones ampliamente compartidas. Rara vez funciona para un flujo de trabajo específico utilizado por unas pocas personas.

Un LLM puede convertir una solicitud concreta en código sin esperar a que la función entre en una hoja de ruta pública. La extensión resultante podría transformar un documento, añadir una visualización personalizada, validar un formulario o conectar dos fuentes de datos autorizadas.

Eso no garantiza que el código generado sea correcto. Pero sí hace mucho más barato intentar la primera implementación.

La segunda mitad del argumento de Morrell se refiere al despliegue. Históricamente, instalar extensiones de terceros a menudo significaba confiar en un paquete, conceder permisos amplios o ejecutar código dentro de un proceso de aplicación privilegiado.

El navegador ofrece una base diferente. Un marco en sandbox crea un contexto de navegación separado y puede desactivar capacidades salvo que el host las restablezca explícitamente.

Los controles disponibles son específicos, no simbólicos. El host puede restringir scripts, formularios, ventanas emergentes, descargas, acceso al almacenamiento y navegación de nivel superior. También puede aplicar una Permissions Policy a funciones como cámaras y micrófonos.

Esos controles hacen posible una frontera de seguridad significativa. No producen automáticamente la frontera correcta para cada extensión.

La expresión de Morrell, “solid, accountable core”, es la parte decisiva de la propuesta. La aplicación host seguiría siendo responsable de la identidad, los datos persistentes, la autorización, el historial de auditoría y las operaciones críticas.

Las extensiones generadas cubrirían carencias locales en torno a ese núcleo. No sustituirían silenciosamente su modelo de seguridad ni se convertirían en el registro autoritativo.

Esa distinción separa el software extensible de un chatbot general de programación. Un chatbot puede producir un archivo y dejar al usuario la responsabilidad de ejecutarlo de forma segura. Una aplicación extensible puede definir dónde reside el código generado, qué interfaces recibe y cómo se revisan sus acciones.

También separa la idea de las tiendas de plugins convencionales. Los plugins tradicionales suelen crearse para muchos usuarios, empaquetarse como productos y distribuirse mediante un proceso de revisión. Las extensiones generadas por LLM pueden dirigirse a un solo flujo de trabajo y seguir dentro de un entorno de ejecución controlado.

El acontecimiento importa porque la publicación de Willison ofrece un marco público conciso para esa arquitectura. La afirmación no es que la IA deba rediseñar cada interfaz. Es que la IA puede hacer económicamente viable una personalización cuidadosamente acotada.

Es un argumento más limitado que “los agentes reemplazarán las aplicaciones”. También es más fácil de probar.

La presión recae sobre los productos SaaS fijos y los agentes de IA amplios

Los productos afrontan ahora presión para ofrecer personalización sin ceder el control de los datos de usuario ni de los flujos de trabajo centrales.

El software fijo funciona anticipando necesidades comunes. Sus diseñadores eligen los objetos, comandos, vistas, integraciones y reglas de automatización disponibles antes de que los clientes se encuentren con sus casos límite individuales.

Ese modelo aporta consistencia. También crea una lista permanente de solicitudes pendientes que son demasiado específicas para justificar un desarrollo compartido.

Los clientes empresariales sortean esas carencias con hojas de cálculo, scripts, extensiones de navegador, plataformas de integración y procedimientos manuales. Cada solución alternativa introduce otro lugar donde la lógica puede quedar obsoleta o invisible.

El software extensible acerca esa lógica a la aplicación que posee los datos relevantes. Una extensión generada puede usar una interfaz limitada definida por el host en lugar de extraer pantallas o copiar registros a otro lugar.

Pensemos en un gestor de proyectos que quiere un panel de revisión basado en varios campos de metadatos inusuales. Es posible que el producto nunca lance ese panel exacto porque pocos clientes lo necesitan.

Una extensión podría solicitar registros aprobados, calcular la agrupación requerida y mostrar una vista temporal. La aplicación central seguiría aplicando qué registros puede leer el usuario.

Un investigador podría querer un extractor puntual para un formato de documento recurrente. Un ingeniero podría necesitar un panel para una convención de despliegue privada. Un equipo de ventas podría querer una regla de validación vinculada a su propio proceso de cuentas.

Estas solicitudes son demasiado pequeñas para la mayoría de las hojas de ruta, pero demasiado repetitivas para el trabajo manual. Constituyen la oportunidad económica detrás de la hipótesis de Morrell.

Geoffrey Litt describió una visión relacionada en su trabajo anterior sobre software maleable. Litt sostuvo que los LLM pueden actuar como desarrolladores locales dentro de entornos computacionales que los usuarios ya comprenden.

Esa referencia histórica importa porque la programación de usuarios finales no es nueva. Las hojas de cálculo, las macros, HyperCard, los scripts de navegador y las herramientas de automatización visual ya permitían a las personas modificar su entorno de trabajo.

El cuello de botella persistente no era únicamente la sintaxis. Los usuarios necesitaban traducir un objetivo informal a lógica ejecutable, comprender las interfaces disponibles y depurar el resultado.

Los LLM comprimen partes de ese proceso de traducción. Un usuario puede describir un resultado en lenguaje propio de su dominio, inspeccionar una extensión propuesta y revisarla mediante ejemplos.

La extensión sigue necesitando un sustrato estable. Sin objetos y capacidades definidos, el modelo debe adivinar cómo funciona la aplicación. Eso produce código frágil y fomenta la automatización de pantallas.

Esto presiona a los proveedores de SaaS para que expongan bloques de construcción más pequeños y seguros. Un producto diseñado únicamente para clics humanos ofrece a un LLM menos formas fiables de ampliarlo.

La misma presión se aplica a los agentes de IA amplios. Un agente con acceso al correo electrónico, archivos, sesiones de navegación y herramientas internas puede realizar trabajos variados. Ese acceso también amplía las consecuencias de una instrucción equivocada.

Una extensión acotada adopta el enfoque opuesto. Recibe las capacidades mínimas necesarias para un trabajo. La aplicación circundante media las operaciones sensibles.

La contrapartida es una menor autonomía. Una extensión limitada no puede improvisar en todos los servicios ni recuperar datos arbitrarios. Esa limitación es precisamente el objetivo, no un defecto.

Para los compradores, la pregunta se vuelve más concreta que si un producto “tiene IA”. Pueden preguntar si los usuarios pueden crear capacidades locales sin conceder a un modelo acceso sin restricciones.

También pueden examinar si el comportamiento generado sigue siendo visible. Un plan de agente oculto es difícil de auditar después de un error. Una extensión instalada puede mostrar su código, permisos declarados, entradas, salidas e historial de revisiones.

Las aplicaciones fijas no desaparecerán con este modelo. Las funciones compartidas siguen necesitando diseño profesional, trabajo de accesibilidad, pruebas de rendimiento, soporte y mantenimiento a largo plazo.

La presión probable afecta al límite alrededor de esas funciones. Los proveedores que mantienen cerrado cada flujo de trabajo deben competir con productos que permiten a los usuarios completar de forma segura el último tramo por sí mismos.

Los equipos también necesitarán mejores formas de preservar el contexto detrás del comportamiento personalizado. Una base de conocimiento de ingeniería con capacidad de búsqueda puede documentar por qué existe una extensión, qué supuestos adopta y quién es responsable de ella.

Ese registro se vuelve esencial cuando las extensiones generadas se extienden de un usuario a un departamento. La creación barata no elimina el coste de la memoria institucional.

Los sandboxes reducen el coste de despliegue, no el de responsabilidad

Un sandbox puede restringir la ejecución de código, pero el producto aún debe diseñar cada ruta significativa a través de la frontera.

Un sandbox de navegador no es un único muro protector. Es una colección de restricciones que abarcan origen, scripts, navegación, almacenamiento, capacidades de dispositivos y comunicación con el host.

El atributo sandbox de un iframe comienza con una postura restrictiva. La aplicación puede restaurar después capacidades seleccionadas mediante tokens explícitos.

Este es un modelo de capacidades, lo que significa que el código recibe poderes concretos en lugar de heredar todos los privilegios de su host. El host podría permitir el renderizado y los cálculos mientras deniega las descargas, la navegación de nivel superior o el almacenamiento del mismo origen.

La documentación de los navegadores también identifica una combinación peligrosa. Un marco del mismo origen al que se conceden tanto scripts como privilegios de mismo origen puede eliminar su propio atributo sandbox en determinadas condiciones.

Esa advertencia ilustra la regla más amplia. Un sandbox sigue siendo útil solo cuando su configuración, el diseño de origen y las interfaces circundantes preservan la separación prevista.

Servir el código de extensión desde un origen separado puede reducir el daño si ese código se vuelve hostil. También impide el acceso directo al Document Object Model de la página host conforme a la política de mismo origen del navegador.

La comunicación puede pasar mediante postMessage, que permite a las ventanas intercambiar mensajes estructurados entre orígenes. El host aún debe validar el remitente, el tipo de mensaje, la carga útil y la operación solicitada.

Un puente de mensajes inseguro puede deshacer una configuración de iframe cuidadosa. Si el código generado puede enviar “delete all records” a un host que no cuestiona nada, bloquear el acceso directo a la base de datos ofrece poco consuelo.

El mejor diseño expone verbos limitados. Una extensión podría solicitar readSelectedDocuments, renderChart o proposeMetadataUpdate, sujetos a autorización y validación.

Los cambios sensibles deben pasar por el núcleo responsable. Ese núcleo puede comprobar el usuario activo, la versión actual del registro, el conjunto de campos permitidos y la política organizativa aplicable.

También puede exigir confirmación. Leer valores aprobados para un gráfico es distinto de enviar esos valores a un servidor externo.

Content Security Policy añade otra capa. Una política de contenido permite a los sitios restringir desde dónde pueden originarse scripts, imágenes, marcos, estilos y solicitudes de red.

Para las extensiones generadas, el control de red importa tanto como la ejecución de código. Un widget aparentemente inocuo puede convertirse en un canal de exfiltración de datos si puede transmitir contenido de la aplicación a dominios arbitrarios.

Una política estricta puede bloquear la mayoría de las conexiones salientes. El host podría entonces canalizar las solicitudes aprobadas mediante un servicio que aplique autenticación, límites de tasa, registros y reglas de destino.

WebAssembly ofrece otro posible entorno de ejecución para cómputo acotado. Su modelo de seguridad describe la ejecución dentro de un entorno aislado y el acceso mediante API explícitas proporcionadas por el integrador.

WebAssembly no determina los permisos del producto. Proporciona un formato de ejecución de bajo nivel que puede respaldar el aislamiento cuando se combina con un host cuidadosamente diseñado.

Algunas extensiones no necesitarán código arbitrario en absoluto. Un producto puede hacer que el LLM genere una especificación declarativa que describa campos, filtros, diseño, cálculos y acciones permitidas.

La aplicación interpreta entonces esa especificación mediante componentes de confianza. Este enfoque limita la expresividad, pero hace que el comportamiento sea más fácil de inspeccionar y validar.

Otras tareas requieren código real. La transformación de datos, las visualizaciones personalizadas y el análisis especializado suelen superar los límites de un esquema fijo.

Una plataforma madura podría admitir varios niveles de ejecución. Las extensiones simples usan reglas declarativas. Las más complejas ejecutan JavaScript o WebAssembly bajo una revisión más estricta y permisos más acotados.

El host debe tratar la salida del modelo como no confiable en todos los niveles. La intención expresada en lenguaje natural no garantiza que el código generado implemente esa misma intención.

El modelo puede malinterpretar un campo, invertir una condición, omitir un caso límite o depender de un comportamiento no documentado. También puede reproducir patrones inseguros aprendidos del código público.

La inyección de prompts añade otro riesgo. Una extensión que procesa documentos o páginas web puede encontrarse con texto diseñado para alterar el comportamiento del modelo.

La guía de OWASP sobre inyección de prompts explica por qué las instrucciones del modelo y los datos externos no siempre pueden separarse limpiamente. El filtrado por sí solo no elimina el problema.

Por tanto, el entorno de ejecución debe asumir que la lógica generada puede ser errónea, incluso cuando no haya ningún atacante presente. Los permisos limitan las consecuencias, mientras que las pruebas y las vistas previas ayudan a detectar errores.

Un flujo de creación útil mostraría el comportamiento solicitado, la implementación generada, las entradas declaradas, los permisos y un resultado de ejemplo antes de la instalación.

La extensión debería recibir datos de prueba en lugar de datos de producción durante su primera ejecución. Los usuarios pueden comparar el comportamiento esperado y el real sin arriesgar un cambio irreversible.

Para las operaciones de escritura, el host puede presentar un diff. La extensión propone mutaciones y el núcleo las aplica solo después de validación o confirmación.

La reversión también importa. Si una extensión actualiza correctamente muchos registros conforme a una regla equivocada, el sandbox habrá tenido éxito técnicamente, aunque el usuario haya sufrido daños.

Una plataforma responsable necesita un historial inmutable u operaciones compensatorias. Debe identificar qué revisión de la extensión provocó cada cambio y quién aprobó su ejecución.

Aquí es donde el “núcleo responsable” de Morrell tiene más peso que las “primitivas modernas de sandbox”. El sandboxing reduce el coste de infraestructura del aislamiento. La responsabilidad exige diseño de producto, gobernanza y disciplina operativa.

La extensión generada debe seguir subordinada a esos sistemas. De lo contrario, la plataforma simplemente traslada una amplia capacidad de acción de la IA a una ventana más pequeña.

La capa que falta es la gobernanza para el código desechable

La generación barata de código crea un problema de mantenimiento porque las extensiones útiles rara vez siguen siendo desechables.

Un usuario puede generar una herramienta puntual para una reunión y no volver a abrirla. Ese es el caso más sencillo, porque el valor y el riesgo de la extensión terminan a la vez.

Las extensiones exitosas se comportan de otra manera. Los colegas las copian, los flujos de trabajo empiezan a depender de ellas y las suposiciones temporales se convierten en infraestructura no oficial.

En ese momento, la autoría se vuelve compleja. El usuario aportó la intención, el modelo proporcionó gran parte de la implementación y el host suministró las interfaces y los controles de ejecución.

La plataforma sigue necesitando un propietario responsable. Alguien debe decidir si la extensión sigue siendo válida después de que cambien los datos, las políticas o las API de la aplicación.

El código generado puede ser barato de reemplazar, pero el flujo de trabajo que lo rodea quizá no lo sea. Un equipo podría depender de un informe para tomar decisiones operativas o financieras.

El núcleo responsable debería clasificar las extensiones según su alcance y sus consecuencias. Una vista personal de solo lectura merece un proceso más ligero que una automatización para toda la organización con acceso de escritura.

La promoción puede activar controles más estrictos. Compartir una extensión podría requerir pruebas automatizadas, una propiedad nominal, revisión de permisos y una fecha de caducidad.

Un despliegue más amplio podría requerir la aprobación de un administrador o del propietario de la aplicación. La revisión debería centrarse en las capacidades y los flujos de datos, no solo en el código fuente.

La revisión de código por sí sola es insuficiente porque el código generado puede cambiar con frecuencia. Los revisores necesitan descripciones estables de lo que una extensión lee, envía, modifica y conserva.

Esas descripciones deberían aplicarse, no ser meramente decorativas. Si una extensión declara que lee registros seleccionados, el entorno de ejecución debería impedirle acceder a registros no relacionados.

El control de versiones es igual de importante. Regenerar una extensión tras una solicitud del usuario crea un comportamiento nuevo, incluso cuando el nombre visible permanece sin cambios.

La plataforma debería conservar cada revisión, su solicitud de generación, la configuración del modelo, los permisos, las pruebas y el estado de aprobación. Los usuarios existentes no deberían recibir cambios silenciosos.

Las actualizaciones del modelo introducen otra incertidumbre. La misma instrucción puede producir código diferente después de que un proveedor modifique un modelo.

La reproducibilidad puede requerir almacenar el artefacto generado en lugar de regenerarlo en cada ejecución. El artefacto puede probarse y firmarse antes de ejecutarse.

Las dependencias crean un riesgo relacionado. Permitir que el código generado importe paquetes arbitrarios amplía la superficie de confianza y complica la operación a largo plazo.

Una biblioteca estándar restringida sería menos flexible, pero más fiable. El host podría proporcionar componentes revisados para gráficos, análisis, fechas, almacenamiento e interacción de usuario.

Las extensiones podrían combinar esos componentes sin descargar código nuevo. Cuando aparezca una vulnerabilidad, la plataforma podría actualizar el componente compartido de forma centralizada.

La experiencia de usuario también necesita límites. Pedir a las personas que aprueben una larga lista de permisos técnicos lleva a la habituación, no al consentimiento informado.

Las solicitudes de permisos deberían describir las consecuencias en el lenguaje de la tarea. “Enviar documentos seleccionados a api.example.com” es más útil que un aviso genérico de acceso a red.

Los valores predeterminados deberían favorecer el comportamiento de solo lectura, los ámbitos limitados y las concesiones temporales. El acceso persistente debería requerir una razón vinculada a un flujo de trabajo recurrente.

Por tanto, la objeción más sólida a la hipótesis de Morrell no es que el sandboxing falle. Es que la demostración atractiva termina antes de que empiece la gobernanza.

Un widget generado puede parecer exitoso después de un prompt. Un sistema de extensiones fiable debe sobrevivir al uso compartido, los cambios de política, las entradas maliciosas, los cambios de modelo y la rotación de personal.

Ese trabajo puede superar el coste inicial de crear código. No desaparecerá porque la aplicación se ejecute en un navegador.

También existe un riesgo de diseño de producto. La personalización ilimitada puede hacer que una aplicación sea más difícil de entender, mantener y usar de forma coherente.

Dos colegas podrían ver comandos, campos y cálculos distintos dentro de lo que parece ser el mismo producto. Los equipos de soporte podrían tener dificultades para reproducir un problema.

Las organizaciones pueden responder estandarizando las extensiones exitosas. La plataforma puede observar necesidades locales repetidas y promover soluciones maduras a funcionalidades compatibles oficialmente.

Eso crea un ciclo de retroalimentación útil. Los usuarios exploran la cola larga, mientras el proveedor identifica patrones que merecen diseño y mantenimiento permanentes.

El modelo no sustituye al equipo de producto en este ciclo. Ayuda a los usuarios a crear prototipos que aportan evidencia sobre necesidades no cubiertas.

Las extensiones que sigan siendo acotadas pueden permanecer locales. Las que se vuelvan importantes pueden pasar por una revisión más estricta y acabar entrando en el núcleo.

Esto es más responsable que tratar cada artefacto generado como desechable o listo para producción. Reconoce que el software cambia de estatus cuando las personas empiezan a depender de él.

La cuestión sin resolver es si los proveedores construirán este ciclo de vida antes de que los usuarios creen un ecosistema paralelo descontrolado. Los LLM ya facilitan la generación de código lo suficiente como para superar a la gobernanza.

Qué deberían observar a continuación los lectores de Simon Willison

La hipótesis ganará credibilidad cuando los productos expongan sistemas de extensiones restringidos que los usuarios comunes puedan operar sin conceder un acceso amplio a los agentes.

La primera señal es un modelo de permisos real diseñado para extensiones generadas. Busque productos que expongan capacidades acotadas, orígenes de ejecución separados, controles de red saliente y manifiestos de permisos legibles.

Una implementación convincente hará que la denegación sea el valor predeterminado. Las extensiones deberían recibir únicamente los datos y las operaciones necesarios para su propósito declarado.

La evidencia más sólida provendría de un sistema que gestione con seguridad el acceso de escritura. Las vistas previas, los diffs, las confirmaciones, los registros de auditoría y la reversión deberían funcionar juntos, en lugar de aparecer como opciones separadas.

Si los proveedores lanzan estos controles, el modelo de núcleo responsable de Morrell se refuerza de forma sustancial. Si las extensiones requieren habitualmente tokens amplios o acceso completo a la página, el modelo se debilita.

La segunda señal es cómo gestionan las plataformas una extensión después de su primera ejecución exitosa. Las demostraciones de creación abundan, pero la evidencia sobre el ciclo de vida sigue siendo más valiosa.

Busque fijación de versiones, pruebas automatizadas, propiedad, caducidad, controles de dependencias y una ruta de promoción del uso personal al uso en equipo.

Una plataforma también debería mostrar qué ocurre después de que cambie su API. Las extensiones necesitan contratos de compatibilidad o fallos claros, no resultados incorrectos silenciosos.

Una gestión exitosa del ciclo de vida demostraría que la creación barata no genera una deuda de software inmanejable. Las averías frecuentes reforzarían la visión escéptica.

La tercera señal es el comportamiento de los usuarios. La teoría depende de que las personas creen herramientas específicas que sigan siendo más seguras y útiles que los agentes generales o las soluciones externas.

Las métricas útiles incluyen la reutilización de extensiones, las denegaciones de permisos, la frecuencia de reversión, el tiempo de reparación y la proporción de creaciones que se convierten en flujos de trabajo recurrentes.

Esas cifras deben interpretarse con cautela. Un elevado número de creaciones puede indicar experimentación, confusión o novedad, en lugar de valor duradero.

El resultado más revelador es si los usuarios resuelven tareas previamente desatendidas sin aumentar los incidentes de seguridad ni la carga de soporte.

Los investigadores y compradores empresariales también deberían observar dónde se ejecutan las extensiones. El aislamiento del navegador es atractivo, pero algunas cargas de trabajo necesitan archivos locales, servicios privados o cómputo intensivo.

Las plataformas pueden usar contenedores remotos, aislados de edge, entornos de ejecución WebAssembly o combinaciones de estos sistemas. Cada elección modifica la latencia, el coste, la exposición de datos y la responsabilidad operativa.

El navegador sigue siendo valioso porque ya media entre orígenes, permisos e interacción del usuario. Sus controles también son ampliamente comprendidos por los equipos de seguridad.

Sin embargo, ningún entorno de ejecución puede inferir la autorización empresarial correcta a partir de código generado. El host debe proporcionar esa política desde su núcleo de confianza.

Para los desarrolladores, la pregunta práctica no es si los LLM pueden escribir una extensión. Ya producen código útil con la suficiente frecuencia como para que este espacio de diseño sea relevante.

La cuestión es si una aplicación puede hacer que los fallos sean algo normal y recuperable. Las salidas deficientes deben estar contenidas, ser visibles, reversibles y económicas de sustituir.

Para los compradores empresariales, pidan a los proveedores que demuestren una extensión hostil o incorrecta, no solo una que funcione correctamente. Observen a qué datos puede acceder y qué acciones rechaza el host.

Para los trabajadores del conocimiento, busquen una personalización que siga siendo comprensible cuando termine el chat. Deberían poder inspeccionar qué hace la herramienta, modificarla, desactivarla e identificar sus efectos.

La cita de Simon Willison es importante porque plantea el código generado por IA como un componente, no como el producto completo. Ese enfoque modesto da credibilidad a la idea.

La hipótesis de Morrell no exige que todos los usuarios se conviertan en ingenieros de software. Exige que las aplicaciones expongan materiales seguros que un LLM pueda ensamblar bajo la dirección del usuario.

La oportunidad es real, pero el producto ganador no será el que genere más código. Será el que haga que el comportamiento generado rinda cuentas.

Al evaluar el próximo producto de IA extensible, solicite una personalización acotada y luego proporciónele deliberadamente una entrada engañosa. ¿Puede ver sus permisos, inspeccionar los cambios propuestos y revertir el resultado?

Estas preguntas revelan más que una demostración pulida de generación. Ponen a prueba si el producto ha construido el núcleo sólido que describe Morrell.

Siga la cobertura de Simon Willison para conocer implementaciones concretas, pero aplique el mismo criterio a cada una. ¿El sistema se limita a ejecutar código escrito por IA o hace que ese código sea gobernable durante toda su vida útil?