Este es el último capítulo con chicha del curso Claude Code in Action de Anthropic y va de comprobar lo de que Claude nos entrega finalmente, porque le das una tarea, se va a hacerla sin ti y vuelve diciendo que ya está. ¿Ahora qué? ¿Habrá sorpresas en el diff?
La regla
Compruebas en proporción a la magnitud de las instrucciones que le diste.
Si estabas delante viendo pasar los mensajes en una sesión corta, con echarle un ojo vale. Si corrió sola mientras tú fregabas los platos, o peor, si saltó en integración continua sin nadie delante, ahí toca revisión de la seria. Nadie vio lo que pasó, así que hay que reconstruirlo después.
Cuanto menos miraste, más verificas y da igual lo bien que se ha portado hasta ahora.
Cuando dejas una sesión corriendo sola en el trabajo, lo suyo es dejarla en modo auto y no en bypass permissions, porque en auto el clasificador sigue mirando cada acción por si es peligrosa. Esa red está muy bien y hay que tenerla puesta.
Pero el clasificador no juzga en ningún momento si el código está bien. Solo mira si la acción es peligrosa. Un rm -rf raro lo para. Una función que devuelve el signo cambiado se la come con patatas.
Vamos que tener el modo auto puesto no quiere decir que todo salga fenomenal, hay que echarle un ojo igual.
El diff antes que el resumen
Cuando termina, Claude te escribe un resumen de lo que ha hecho. Está bien escrito, ordenado, con sus puntos y es agradable de leer y eso es lo peligroso.
La trampa es un resumen super convincente mientras el diff de verdad ha tocado un fichero que tú no esperabas ni de coña. El resumen no te lo va a contar pero el diff sí.
Lo que funciona es lanzar /code-review para que recorra los cambios y marque lo que ve, y después poner tus ojos en un git diff de tota la vida. Primero los ficheros que estaban en el plan, después lo que aparezca fuera de él, que es donde están los sustos.
Y hay tres sitios donde yo miraría siempre aunque el plan no los tocara. El package.json y el lockfile, por si ha entrado una dependencia nueva de camino. Cualquier cosa dentro de .github/, que es código que se va a ejecutar solo. Y los ficheros de configuración de la raíz, que se tocan de refilón para que algo pase y ahí se quedan.
Un informe limpio no demuestra nada sobre el código, por eso hay que echarle un ojito por si aca.
Los tests hay que atarlos
De todo esto, lo único que de verdad cierra el paso es si los tests pasaron. Y ahí hay que decirle la pregunta de verdad, que es si Claude los llegó a ejecutar los tests o solo dijo que sí y ya.
Eso no lo dejes a la buena fe, que para eso están los hooks. Con dos basta:
- Un hook de
Stopque lance tus tests y se niegue a terminar el turno si fallan. - Un
PostToolUseque pase el linter y el chequeo de tipos después de cada edición.
El detalle que hace que esto funcione es el código de salida. Un hook que sale con exit 2 le mete el fallo de vuelta a Claude por la entrada estándar, y Claude lo lee y lo arregla sin que tú digas nada. Con exit 1 el mensaje se va a tu terminal y el modelo ni se entera, que es el error clásico y al que ya le dediqué medio post en su día.
Y lo mejor de montarlo así es que salta siempre, te acuerdes tú de pedirlo o no. Que es justo cuando no estás delante cuando no te acuerdas.
Que lo mire alguien que no estaba
Abres una sesión nueva, o lanzas un subagente, y le pides que revise el código cambiado sin haber visto cómo se construyó.
Funciona precisamente por lo que no sabe. Como no tiene ni idea del camino que se siguió, no tiene nada que defender, y pilla justo aquello de lo que la sesión original se autoconvenció a mitad de faena.
Con el modo headless esto es todavía más tonto, porque te vas al JSON del resultado y al código de salida del proceso. Ahí no hay resumen bonito. Hay un número.
Nada, que me voy a poner el hook de Stop con los tests, que llevo la serie entera escribiendo sobre ellos y en este blog no tengo ninguno.
EA! Nos vemos en los bares! 🍻