La prueba que Anthropic hizo con 1.053 desarrolladores reales

Kai Zhou, ingeniero de software sénior en Nuro, puso en marcha un agente de Claude Code a las 22:00 y lo dejó trabajando. Cuando volvió a mirar a las 5:00 de la mañana, había generado tres pull requests, y en toda la noche no había tenido que aprobar ni una sola solicitud de permiso para conseguirlo. "Puse en marcha un agente a las 22:00 y siguió funcionando hasta las 5:00 de la mañana, y por la mañana me dio tres PR", explicó. Ese tipo de ejecución desatendida es exactamente lo que el modo automático de Anthropic fue diseñado para volver habitual en lugar de excepcional, y a partir del 14 de agosto de 2026 se convierte en el comportamiento predeterminado de toda cuenta de Claude Code en los planes Pro, Max y Team, no en un ajuste opcional que un equipo tenga que buscar y activar.

Antes de tomar esa decisión, Anthropic realizó una prueba controlada para comprobar si eliminar la solicitud de permiso es realmente más seguro o solo más rápido. Reclutaron a 1.053 probadores profesionales de pago y, a mitad de sesión, sustituyeron por un comando genuinamente peligroso la solicitud de permiso que cada uno de ellos veía. Los probadores que dependían de la revisión manual lo detectaron el 13,6 por ciento de las veces - 143 de 1.053. El modo automático, observando las mismas sesiones, bloqueó el 89 por ciento de esos mismos comandos insertados - 937 de 1.053. En la misma prueba exacta, sobre la misma población exacta, la comprobación automatizada detectó la acción peligrosa unas 6,5 veces más que la revisión humana.

Lo que cambia realmente el 14 de agosto

El modo automático no elimina las solicitudes de permiso por completo. Anthropic lo describe como un sistema que dirige las llamadas a herramientas a través de un clasificador que sigue deteniéndose y preguntando cuando una acción parece irreversible, destructiva o dirigida fuera del entorno - borrar datos, publicar en producción, contactar con un sistema que el agente no tiene motivo claro para tocar. Si el clasificador sigue bloqueando, la sesión vuelve a exigir aprobación manual tras 3 bloqueos consecutivos o 20 bloqueos en una misma sesión, de modo que una ejecución autónoma larga siempre incorpora un punto de control en lugar de completarse sin supervisión pase lo que pase. Anthropic también ha añadido una capa dedicada de detección de inyección de instrucciones y reglas de bloqueo fijas configurables que un administrador puede establecer para impedir acciones concretas, como rutas de exfiltración de datos, al margen de lo que decida el propio clasificador.

El equipo que lo construye ya trabaja así. "El equipo y yo usamos el modo automático de forma exclusiva desde hace muchos meses. No podría imaginarme volver a las solicitudes de permiso", dijo Boris Cherny, responsable de Claude Code en Anthropic. Tomislav Reil, Director de Ingeniería en Adobe, describió un patrón similar en su propio flujo de trabajo: "Claude construye la interfaz de usuario y después vuelve a verificar que coincide con el diseño previsto, corrigiendo automáticamente cualquier problema antes de que nosotros lleguemos siquiera a verlo". Según Anthropic, los equipos que adoptaron el modo automático entregan alrededor de un 25 por ciento más de pull requests, y desde el 14 de agosto también deja de cobrar a las cuentas Pro, Max y Team el coste adicional de tokens que generaba el propio clasificador, con el mismo cambio de precios previsto para Enterprise, que por ahora sigue siendo opcional, dentro de aproximadamente un mes.

La base real nunca fue una revisión cuidadosa

La comparación a la que Anthropic quiere dirigir la atención es la tasa de detección del 89 por ciento del modo automático frente al 13,6 por ciento de la revisión manual. Pero una cifra distinta, comunicada junto con el anuncio, explica mejor de dónde viene esa diferencia: los usuarios de Claude Code ya aprueban el 97 por ciento de las solicitudes de permiso que se les presentan. Ese es el punto de partida honesto para esta decisión, y no se trata de "un revisor humano cuidadoso frente a un piloto automático sin probar". Es un revisor que ya aprobaba por costumbre unas 19 de cada 20 solicitudes, sustituido por un sistema que es mediblemente mejor detectando esa una de cada 20 que realmente importaba. Los datos de producción de Anthropic respaldan esto también fuera del laboratorio: las sesiones que dependían de aprobación manual registraron daños no intencionados de nivel de gravedad 7 o superior en el 6,3 por ciento de los casos, frente al 2,4 por ciento en sesiones con modo automático haciendo el mismo tipo de trabajo.

Nada de esto convierte el 89 por ciento en una cifra definitiva. La propia prueba de Anthropic deja un 11 por ciento de los comandos peligrosos insertados que el clasificador no habría bloqueado, y la lectura honesta del estudio es "notablemente más seguro que lo que la mayoría de los equipos hacía en realidad", no "resuelto". Anthropic también informa de una tasa de éxito del 0 por ciento en ataques de inyección de instrucciones contra modelos Claude que funcionan en modo automático dentro de su propia evaluación, y vincula esa afirmación a la nueva capa de detección y a las reglas de bloqueo fijas descritas antes.

Un comentario independiente publicado un día antes del anuncio de Anthropic, del desarrollador e investigador de modelos de lenguaje Simon Willison, trazó una distinción más afilada que conviene tener presente en cualquier decisión de adopción: detectar un daño accidental y descuidado es un problema distinto a detectar una instrucción deliberadamente maliciosa introducida en el contexto de un agente. Su ejemplo fue un paquete de terceros comprometido cuyas instrucciones se leen como un paso normal dentro del entorno - "ejecutar la batería de pruebas" - pero que en realidad dispara una petición maliciosa, precisamente el tipo de acción que un clasificador entrenado para señalar trabajo "dirigido fuera del entorno" podría dejar pasar por no parecer externo a simple vista. Eso no es un argumento a favor de mantener la revisión manual, que en la propia prueba de Anthropic detectó menos de todo. Es una razón para no tratar el clasificador como una respuesta completa a las instrucciones inyectadas, solo a las accidentales y destructivas.

Qué decidir antes del 14 de agosto, no después

Audita qué puede tocar el modo automático antes de que el cambio de valor predeterminado te alcance. El clasificador de Anthropic traza su propia línea alrededor de "irreversible, destructivo o dirigido fuera del entorno" - enumera las acciones de tu pipeline concreto que esa línea podría no captar pero que tú sí considerarías irreversibles: escrituras en la base de datos de producción, rotación de claves, comandos de despliegue, cualquier cosa que alcance un entorno de cliente. Las nuevas reglas de bloqueo fijas de Anthropic permiten a un administrador bloquear esas acciones de forma explícita; configúralas antes del 14 de agosto, no después de que una sesión ya haya ejecutado alguna.

Fija tu propio umbral de respaldo, no el predeterminado de Anthropic. El disparador de 3 bloqueos consecutivos o 20 por sesión para exigir aprobación manual es un ajuste predeterminado, no una ley fija, y un límite desatendido de 20 acciones es un margen amplio para una sola ejecución nocturna como la de Kai Zhou. Bájalo para cualquier pipeline que toque credenciales, datos de clientes o infraestructura de producción, y déjalo en el valor predeterminado solo donde un error sea realmente reversible.

Resuelve la cuestión del registro de auditoría antes de que lo pregunte un regulador. Si tu organización está dentro del ámbito de NIS2 o DORA, confirma - esta misma semana, no durante una auditoría futura - que las decisiones de bloqueo y permiso del modo automático quedan registradas con el mismo nivel de detalle probatorio que tenía tu rastro de aprobación humana. El anuncio de Anthropic no aborda esto directamente; verificarlo es tarea del equipo que adopta la herramienta, no del proveedor, antes de que "eliminamos las solicitudes de permiso" se convierta en la respuesta a una pregunta sobre supervisión de riesgos de TIC.