Confía en eso: cómo verificar ejecuciones sin supervisión
Le diste a Claude una tarea y dejaste que se ejecutara sin observar cada paso. Ahora dice que terminó. Antes de enviar ese trabajo, necesitas una forma de comprobar algo que ni siquiera supervisaste. Esa comprobación es lo que hace que confiar en Claude Code sin supervisión sea seguro.
La idea aquí es simple: verifica en proporción a cuánta libertad le diste a la ejecución. Si observaste los mensajes desplazarse en una sesión corta, un vistazo rápido es suficiente. Pero una ejecución desatendida, o un trabajo que se disparó en integración continua sin nadie pendiente, necesita una comprobación real. Nadie vio lo que ocurrió, así que tienes que reconstruirlo después del hecho.
Aquí tienes una forma de visualizarlo. Cuanto menos observaste, más verificas.
Mantén las ejecuciones desatendidas en modo automático
Cuando una ejecución queda desatendida en el trabajo, mantenla en modo automático en lugar de omitir los permisos. En modo automático, el clasificador sigue revisando la mayoría de las acciones en busca de peligro. Esa es una red de seguridad que vale la pena conservar.
Pero sé claro sobre lo que esa red hace y no hace. El clasificador nunca juzga si el código es realmente correcto. Solo marca acciones peligrosas. Así que tu nivel de verificación se mantiene exactamente donde estaba. Establece ese nivel según cuán sin supervisión estuvo la ejecución.
Empieza por el diff, no por el resumen
No empieces con el resumen de Claude sobre lo que hizo. Empieza por el diff en sí.
- Ejecuta
/code-reviewpara recorrer los cambios y marcar problemas. - Luego pon tus propios ojos en
git diff.
La trampa es un resumen ordenado que se lee perfectamente bien, mientras que el diff real tocó un archivo que honestamente no esperabas que tocara. El resumen no te lo dirá. El diff sí.
Así que lee lo que cambió. Lee primero los archivos que formaban parte del plan, y luego busca cualquier cosa fuera de él. Una redacción limpia no es prueba de código limpio.
Convierte las pruebas en una puerta, no en una promesa
La verdadera puerta en una ejecución sin supervisión es si las pruebas pasaron, y si Claude realmente las ejecutó o solo afirmó haberlo hecho. No dejes eso a la confianza. Conéctalo como un hook para que Claude no pueda saltárselo.
Un par de hooks hacen el trabajo:
- Un stop hook que ejecuta tus pruebas y se niega a terminar el turno si hay un fallo.
- Un post-tool-use hook que hace lint y verifica tipos después de cada edición.
El detalle clave es el código de salida. Un hook que sale con exit 2 devuelve el fallo directamente a Claude. Claude lee ese fallo y lo corrige sin que se lo pidas. Lo mejor de todo es que la comprobación se dispara en cada ejecución, la recuerdes pedir o no.
Consigue una segunda opinión imparcial
La revisión de código con un sub-agente que ejecutarías antes de un pull request también funciona aquí. Apúntala a una ejecución sin supervisión.
Abre una sesión nueva o un sub-agente y haz que revise el código modificado sin memoria de cómo se construyó el código. Como no tiene nada en juego con el enfoque, detecta las cosas que la ejecución original se convenció de pasar por alto. Un segundo revisor con ojos frescos encuentra lo que el autor racionalizó.
Juntándolo todo
Haz que la comprobación sea tan seria como lo fue la falta de supervisión de la ejecución:
- Lee el diff tú mismo.
- Convierte las pruebas en un hook que controle el turno.
- Verifica las ejecuciones sin interfaz por su resultado JSON y código de salida.
- Consigue una segunda opinión imparcial sobre cualquier cosa que importe.
Haz eso, y "Claude lo hizo mientras yo no miraba" ya no requiere fe.