Los usuarios de Claude Code aprueban el 93% de las solicitudes: la supervisión se convierte en un trámite

El agente lleva más de una hora modificando el proyecto y pide permiso con frecuencia para ejecutar otro comando. Lees con atención las primeras solicitudes; después, reconoces formulaciones familiares y pulsas el botón casi automáticamente. En algún momento, entre las operaciones habituales aparece la eliminación de una rama remota o una migración de la base de datos de producción. Se ha concedido la autorización, pero puede que no haya habido una revisión de fondo.

Un artículo de Habr sobre la fatiga de supervisión cita una cifra de Anthropic: los usuarios de Claude Code aprueban el 93% de las solicitudes de confirmación. Por sí solo, ese porcentaje no demuestra falta de atención: la mayoría de las acciones podrían ser realmente seguras. Pero plantea una pregunta útil para el diseño del producto: ¿qué error puede detener tu interfaz si la forma habitual de utilizarla consiste en aceptar y continuar?

Por qué el botón deja de proteger

Quien realiza una tarea va construyendo poco a poco una comprensión de lo que ocurre. Quien supervisa al agente tiene que reconstruirla a partir de acciones ajenas: qué archivos se han leído, por qué se ha elegido una herramienta, qué se ha modificado ya y qué consecuencias tendrá el siguiente comando. Una ventana de confirmación aislada rara vez contiene todo ese contexto.

Imaginemos un agente al que se le ha encargado eliminar una funcionalidad obsoleta. Ha borrado el código, actualizado las pruebas y propone limpiar las ramas relacionadas. Para evaluar ese último paso no basta con ver un comando de Git correcto. Hay que saber qué ramas siguen en uso, si los compañeros tienen trabajo pendiente y si la limpieza del repositorio remoto formaba parte del encargo original. La sintaxis del comando apenas resuelve nada en este caso.

El problema de supervisar la automatización es muy anterior a los LLM. El artículo original recurre a la aviación y a los vehículos autónomos: la observación prolongada reduce la atención, mientras que intervenir de forma ocasional exige una habilidad difícil de mantener sin práctica. Estos ejemplos ayudan a comprender el mecanismo. No permiten trasladar las tasas de accidentes ni la eficacia de medidas concretas de un sector a otro.

Qué cambiar en el producto y en el proceso

El primer paso es definir los límites de actuación antes de poner en marcha al agente. Si tiene que preparar una corrección, el acceso a la publicación de versiones, los secretos y la base de datos de producción requiere una justificación independiente. Cuantas menos consecuencias pueda provocar por su cuenta, menos habrá que confiar en la atención de una persona al final de una sesión larga.

El segundo paso es organizar la revisión en torno a un resultado completo. Para un cambio de código, puede ser un conjunto de modificaciones acompañado de los resultados de las pruebas, una lista de los componentes afectados y una indicación explícita de las acciones realizadas fuera de la copia local. Así, quien revisa puede ver la relación entre los pasos. Eso sí, la aprobación por lotes no debe incluir inadvertidamente una operación peligrosa: conviene mostrar por separado las migraciones o la eliminación de datos, indicando el elemento concreto sobre el que se actuará y las consecuencias previstas.

El tercer paso es comprobar el resultado con los medios técnicos disponibles. ¿Existe el archivo prometido? ¿Se puede abrir? ¿Su contenido responde al encargo? ¿Se superan las comprobaciones? Estas preguntas son especialmente importantes cuando una herramienta ha terminado con un error y, aun así, el agente ha anunciado el éxito con seguridad. Un resumen bien redactado no demuestra que el trabajo se haya realizado.

Un clasificador automático de acciones también puede ayudar. Según recoge Habr, Anthropic informa de que su clasificador dejó pasar el 17% de 52 casos analizados en los que el agente tomó una iniciativa excesiva. Se trata de una muestra pequeña y específica, no de una estimación universal del riesgo. Para el equipo, la implicación es sencilla: un modelo adicional sigue dejando pasar errores, por lo que las restricciones de acceso y la comprobación de las consecuencias siguen siendo importantes.

Quién debe revisar al agente

Encargar la supervisión al empleado con menos experiencia parece un ahorro hasta que queda claro que evaluar exige entender el trabajo en sí. Para detectar una migración incorrecta, hay que comprender los datos. Para descubrir un resultado ficticio, hay que saber cómo sería uno real.

Por eso, las tareas realizadas sin asistente tienen un valor práctico: permiten que los empleados adquieran y conserven la capacidad de revisar. También conviene analizar fallos y correcciones reales: qué errores detuvo una persona, qué información le faltó y qué solicitudes podrían eliminarse del flujo de confirmaciones.

Para los responsables de producto, la conclusión es concreta: la tasa de aprobación, por sí sola, dice poco sobre la calidad del control. Para los desarrolladores, cada solicitud de permiso debe ir acompañada del contexto suficiente para decidir. Para los fundadores, el tiempo de revisión cualificada debe incluirse en el coste del trabajo del agente. De lo contrario, es fácil confundir una ejecución más rápida con la obtención más rápida de un resultado fiable.