Claude Fable: cuando un agente de IA actúa sin descanso para depurar una interfaz

Resumen del incidente

Un desarrollador detectó una barra de desplazamiento horizontal inapropiada en un menú de búsqueda dentro de Datasette Agent y pidió a Claude Fable (versión 5) que investigara, comenzando por las dependencias del proyecto. En cuestión de minutos, el agente desplegó una serie de técnicas automáticas —algunas a nivel de sistema— para reproducir, medir y verificar el fallo en un navegador real.

El experimento quedó registrado por el autor y sirve como ejemplo claro de lo que un agente de código con permisos locales puede hacer cuando se le deja actuar con autonomía. A continuación describimos qué hizo Claude, cómo lo logró y las implicaciones para equipos de desarrollo y responsables de seguridad.

Qué hizo Claude Fable: pasos y herramientas utilizadas

1. Inspección de dependencias

Claude inició su investigación buscando en las dependencias del proyecto, con la hipótesis de que el comportamiento provenía de Datasette o algún paquete relacionado. Esa estrategia es consistente con agentes que pueden examinar el ambiente de ejecución y archivos instalados.

2. Automatización de navegación y capturas de pantalla

El agente abrió ventanas de navegador (Firefox y luego Safari) y tomó capturas de pantalla de las páginas relevantes. Para eso utilizó utilidades de macOS: en el terminal apareció una invocación ligada a pyobjc-framework-Quartz y a la herramienta screencapture, lo que sugiere que el agente recorrió ventanas del sistema y pidió capturas por su número de ventana.

3. Creación de páginas de prueba locales

Para reproducir el problema, Claude escribió archivos HTML temporales en /tmp (por ejemplo /tmp/textarea-scrollbar-test.html) y los abrió en el navegador. Esto le permitió controlar el entorno de prueba y realizar observaciones específicas sobre el elemento bajo sospecha: un <textarea> dentro de un Web Component llamado navigation-search.

4. Inserción de JavaScript para disparar atajos de teclado

El agente modificó plantillas locales del proyecto para inyectar código JavaScript que, al cargar la página, simulaba la pulsación de la tecla ”/” después de 1.2 segundos. Ese atajo era el mecanismo necesario para abrir el modal en examen. El fragmento añadido tenía la forma general de:

<script> window.addEventListener(“load”, function () { setTimeout(function () { document.dispatchEvent(new KeyboardEvent(“keydown”, {key: ”/”, bubbles: true})); }, 1200); }); </script>

Con esto, Claude pudo provocar el estado exacto de la interfaz que quería medir.

5. Levantar un servidor local para recoger diagnósticos vía CORS

Para obtener mediciones del DOM desde el navegador, Claude creó un pequeño servidor HTTP local usando la librería estándar de Python, capaz de aceptar POSTs y escribir el contenido en /tmp/diag.json. El servidor respondía a OPTIONS y añadía Access-Control-Allow-Origin: * para permitir que una página abierta en otro origen pudiera enviar datos.

Un ejemplo del manejador usado (simplificado) era:

from http.server import HTTPServer, BaseHTTPRequestHandler class H(BaseHTTPRequestHandler): def do_POST(self): n = int(self.headers.get(“Content-Length”, 0)) open(“/tmp/diag.json”, “w”).write(self.rfile.read(n).decode()) self.send_response(200) self.send_header(“Access-Control-Allow-Origin”, "") self.end_headers() def do_OPTIONS(self): self.send_response(200) self.send_header(“Access-Control-Allow-Origin”, "") self.send_header(“Access-Control-Allow-Headers”, ”*”) self.end_headers() def log_message(self, *a): pass HTTPServer((“127.0.0.1”, 9999), H).serve_forever()

Desde la página abierta en el navegador, Claude inyectó JavaScript que tomaba medidas del textarea y enviaba esos datos al servidor local:

const host = document.querySelector(“navigation-search”); const ta = host.shadowRoot.querySelector(“textarea”); const cs = getComputedStyle(ta); fetch(“http://127.0.0.1:9999/diag”, { method: “POST”, body: JSON.stringify({ dpr: window.devicePixelRatio, scrollWidth: ta.scrollWidth, clientWidth: ta.clientWidth, whiteSpace: cs.whiteSpace, width: cs.width, }), });

Con esto Claude pudo leer las mediciones desde disco (/tmp/diag.json) y avanzar en la depuración.

6. Cambio de modelo y reporte final

En algún punto Fable alcanzó un límite operativo y “se degradó” a Opus; aun así, Opus tenía acceso al historial de la sesión y pudo continuar con las mismas técnicas para probar, verificar y documentar la solución. El agente generó un informe de automatización con ejemplos ejecutables que el autor usó para reconstruir lo ocurrido.

Por qué este comportamiento es relevante (y preocupante)

El ejemplo muestra la capacidad de agentes avanzados para combinar operaciones a nivel de código, sistema y navegador: inspección de dependencias, modificación de archivos fuente, ejecución de scripts locales, automatización de GUIs y levantamiento de servidores locales con CORS relajado. Todo eso, si se realiza sin restricciones, puede impactar la seguridad y la integridad de entornos de desarrollo.

Para organizaciones y equipos —incluyendo los de América Latina, donde muchas empresas están acelerando iniciativas de IA— esto implica dos señales claras:

• Capacidad de diagnóstico vs. control: la misma autonomía que permite que un agente identifique y arregle fallos puede llevar a cambios no deseados en el código o a exfiltración de datos si el agente tiene permisos amplios.
• Supervisión y trazabilidad: sin registros y límites claros, es difícil auditar qué archivos se tocaron, qué comandos se ejecutaron y qué datos se enviaron fuera del entorno.

Recomendaciones prácticas para equipos y tomadores de decisión

1. Minimizar privilegios: ejecutar agentes de IA en entornos con permisos reducidos, contenedores o sandboxes que limiten acceso a archivos del sistema, a utilidades de captura de pantalla y a la red.

2. Controlar la modificación de código: impuesto de revisiones obligatorias (pull requests, revisiones humanas) antes de que cualquier agente escriba cambios en repositorios o plantillas de producción.

3. Supervisión y logging: mantener registros detallados de las acciones del agente, con snapshots de comandos, archivos modificados y comunicaciones de red para auditoría posterior.

4. Políticas de CORS y servidores locales: restringir puertos y orígenes que pueden aceptar datos desde navegadores de desarrollo, y revisar cualquier servidor levantado por procesos no humanos.

5. Formación y gobernanza: definir roles y responsabilidades para el uso de agentes automáticos, y capacitar a equipos sobre riesgos específicos.

Conclusión

El experimento documentado por Simon Willison ilustra el poder y la complejidad de los agentes de código modernos: cuando se les permite interactuar con el sistema operativo y con el código fuente, pueden ejecutar cadenas de acciones sofisticadas para reproducir y diagnosticar fallos. Para empresas y equipos —en América Latina y en todo el mundo— esto abre oportunidades de productividad, pero también obliga a implementar controles técnicos y procesos de gobernanza claros. La clave será equilibrar la autonomía útil de estos agentes con límites que eviten modificaciones indeseadas y riesgos de seguridad.

Lecturas y recursos

El autor compartió la transcripción completa de la sesión con Claude Code; revisar ese material es útil para entender exactamente qué comandos y archivos se tocaron durante la investigación. Para equipos que experimenten con agentes similares, practicar en entornos aislados y auditar cada experimento es una buena práctica inicial.