Formación › Programar con Claude Code en 12 horas › Hora 5
Programar con Claude Code en 12 horas · hora 5 de 12
Verificar y revisar
Si solo te quedas con una lección de este curso, que sea esta. La documentación de Claude Code la pone la primera de sus buenas prácticas: dale a Claude una forma de comprobar su trabajo. Verás una sesión real en la que lo hace bien, de principio a fin.
Al terminar sabrásDar a Claude una comprobación ejecutable para un cambio, exigir evidencias en lugar de afirmaciones y añadir una revisión en un contexto limpio, quedándote solo con los hallazgos que importan.
60 minutos· 2 esquemas· 6 preguntas· 1 ejercicio· laboratorio· entregable
Repaso
Comprueba De la hora 4: ¿cuándo recomienda la guía oficial saltarse el modo plan?
No. La prisa no cambia el riesgo de un cambio grande.
No. Es justo cuando más compensa planificar.
Correcto. Un cambio así se revisa fácil; planificarlo solo añade tiempo y contexto.
Comprueba De la hora 4: el plan real avisó de dos fallos de los datos y preguntó qué hacer. ¿Qué evitó?
No. La longitud no es el criterio.
No. Las pruebas siguen haciendo falta.
Correcto. Corregirlos por su cuenta habría ampliado el alcance.
Comprueba De la hora 1: ¿qué fase del bucle convierte «parece terminado» en «está terminado»?
No. Editar no demuestra nada por sí solo.
Correcto. Ejecutar las pruebas o el build es lo que lo demuestra.
No. Entender el código no demuestra el resultado.
Vocabulario
- Comprobación ejecutable
- Algo que devuelve «pasa» o «no pasa» y que Claude puede leer: pruebas, build, linter o una comparación.
- Evidencia
- La salida de las pruebas, el comando y su resultado, o una captura; lo contrario de una afirmación.
- Revisión adversarial
- Una revisión hecha por otro contexto que intenta encontrar fallos en el cambio.
- Sobreingeniería
- Código, capas o pruebas que no hacen falta para cumplir los requisitos.
El ejemplo: un arreglo que se demuestra
Pedimos a Claude Code que arreglara la parada que cruza la medianoche con la prueba primero, y que enseñara la salida.
Antes y después Una petición que se verifica sola
La petición
Las paradas que empiezan antes de medianoche y terminan después salen con horas negativas en el parte (mira la fila P-104 de datos/paradas.csv). Mira src/fechas.js.
Primero escribe una prueba que reproduzca el fallo con una parada de 23:30 a 01:15 y ejecuta npm test para ver que falla.
Después arregla la causa, no el síntoma, y ejecuta npm test hasta que pase. No cambies ni borres pruebas existentes.
Al terminar, enséñame la salida de npm test.La sesión real
Salida real Claude Sonnet 5.5 · 24 de octubre de 2026 · sin editar · Claude Code en modo acceptEdits sobre el repositorio de práctica
Para repetirla, en el repositorio: claude --permission-mode acceptEdits --allowedTools "Bash(npm test*)" y pega la petición. Se grabó con claude -p, sin conversación: lo que aquí se deniega, a ti te lo preguntaría.
Lo que hizo: 8 acciones
Read: src/fechas.jsBash: ls -R . | grep -v node_modules | head -50 && cat package.json && grep -n "P-104" datos/paradas.csv && head -3 datos/paradas.csvRead: pruebas/fechas.test.jsGrep: horasEntreEdit: pruebas/fechas.test.jsBash: npm test 2>&1 | tail -40Edit: src/fechas.jsBash: npm test 2>&1
Arreglado: P-104 (23:30 a 01:15) ya cuenta 1,75 h en vez de salir negativa, y los 5 tests pasan.
Causa: horasEntre en src/fechas.js restaba las dos horas dando por hecho que el fin era posterior al inicio. Con 23:30 y 01:15 salía -22,25 h. Ahora, si la diferencia es negativa, le suma 24 h, porque la parada cruza la medianoche. Lo cambié en esa función y no en paradas.js, así que cualquier otro código que la use queda corregido también.
Prueba: añadí "horas de una parada que cruza la medianoche" en pruebas/fechas.test.js. Antes del arreglo falló con -22.25 !== 1.75. No toqué ninguna prueba existente.
Salida de npm test tras el arreglo:
```
informes-mantenimiento@1.0.0 test
node --test "pruebas/*.test.js"
✔ horas entre dos horas del mismo día (0.9412ms)
✔ horas de una parada que cruza la medianoche (0.1442ms)
✔ semana ISO (0.1797ms)
✔ suma las horas por línea (1.8587ms)
✔ el parte usa coma decimal (19.2137ms)
ℹ tests 5
ℹ suites 0
ℹ pass 5
ℹ fail 0
ℹ cancelled 0
ℹ skipped 0
ℹ todo 0
ℹ duration_ms 125.6786
```
No he regenerado el parte con npm run parte, así que no he comprobado la fila P-104 en la salida real.
Una parada con inicio y fin iguales (por ejemplo 08:00 a 08:00) sigue dando 0 h y no 24 h. Me parece lo razonable, pero dímelo si en vuestros partes eso significaría un día entero.
Los cambios que dejó (diff)
diff --git a/pruebas/fechas.test.js b/pruebas/fechas.test.js
index 91c2872..da84aa0 100644
--- a/pruebas/fechas.test.js
+++ b/pruebas/fechas.test.js
@@ -7,6 +7,10 @@ test("horas entre dos horas del mismo día", () => {
assert.equal(horasEntre("14:15", "15:00"), 0.75);
});
+test("horas de una parada que cruza la medianoche", () => {
+ assert.equal(horasEntre("23:30", "01:15"), 1.75);
+});
+
test("semana ISO", () => {
assert.equal(semanaIso("2025-03-03"), 10);
assert.equal(semanaIso("2025-01-01"), 1);
diff --git a/src/fechas.js b/src/fechas.js
index 732450c..0ff70fd 100644
--- a/src/fechas.js
+++ b/src/fechas.js
@@ -1,10 +1,12 @@
// Utilidades de fechas y horas del parte.
-/** Horas entre dos horas del mismo día, en formato «HH:MM». */
+/** Horas entre dos horas en formato «HH:MM». Si el fin es anterior al inicio, cruza la medianoche. */
export function horasEntre(inicio, fin) {
const [hi, mi] = inicio.split(":").map(Number);
const [hf, mf] = fin.split(":").map(Number);
- return (hf * 60 + mf - (hi * 60 + mi)) / 60;
+ let minutos = hf * 60 + mf - (hi * 60 + mi);
+ if (minutos < 0) minutos += 24 * 60;
+ return minutos / 60;
}
/** Número de semana ISO de una fecha «AAAA-MM-DD». */Qué ha pasado
En el registro de acciones se ve el orden: edita la prueba, ejecuta npm test (falla), edita el código, vuelve a ejecutar (pasa). Ver fallar la prueba demuestra que detecta el fallo de verdad: una prueba que pasa desde el principio no prueba nada. Además:
- Arregla la causa en la función, no en el informe, y explica por qué.
- Termina con evidencias: la salida completa de las pruebas.
- Dice lo que no ha comprobado: no regeneró el parte.
- Deja una decisión para ti: si una parada de 08:00 a 08:00 son cero horas o un día entero.
Por qué «parece terminado» no basta
Claude para cuando el trabajo parece terminado. Sin una comprobación que pueda ejecutar, esa es su única señal y tú te conviertes en el bucle de verificación: cada error espera a que lo veas. Si le das algo que devuelva «pasa o no pasa», el bucle se cierra solo.
Según cuánto quieras que la comprobación obligue, la documentación propone varios niveles:
- En el prompt: «ejecuta las pruebas y repite hasta que pasen», como en el ejemplo.
- En toda la sesión:
/goalfija una condición que un evaluador independiente revisa tras cada turno. - Como puerta determinista: un hook
Stopejecuta tu comprobación y no deja terminar el turno hasta que pasa (hora 10). - Con una segunda opinión: un subagente revisor intenta refutar el resultado.
Si Claude «arregla» una prueba borrándola o debilitándola, no ha arreglado nada. Pon en CLAUDE.md «no cambies una prueba para que pase sin decírmelo» y revisa el diff de las pruebas.
Revisión con contexto limpio
Un revisor que no ha visto el razonamiento que produjo el cambio lo juzga por lo que es. Por eso la revisión funciona mejor en un contexto nuevo, con un subagente o con otra sesión.
Claude Code incluye la skill /code-review, que revisa el diff actual con un subagente nuevo. Para revisar contra tu plan, escribe tú la petición: «Usa un subagente para revisar el diff contra PLAN.md: que cada requisito esté implementado, que los casos límite tengan prueba y que no haya cambios fuera del alcance. Informa de huecos, no de preferencias de estilo».
Ojo con la sobreingeniería. Un revisor al que pides huecos casi siempre encuentra alguno, aunque el trabajo esté bien. Quédate con lo que afecta a la corrección o a los requisitos.
Practica
Clasifica ¿Es una comprobación que Claude puede ejecutar?
npm testcon una prueba nueva que reproduce el falloDevuelve pasa o no pasa y Claude lee el resultado.- «Que quede bonito»No hay señal objetiva: dale una captura de referencia para comparar.
- Un script que compara el parte generado con un fichero esperadoEs una comprobación exacta.
- «Que funcione como antes»Conviértelo en pruebas de los casos que funcionaban antes.
- El código de salida de
npm run buildUn build que falla devuelve un código distinto de cero.
Laboratorio Escribe una petición que se verifique sola
Escribe la petición para un cambio real del repositorio de práctica o de tu proyecto.
- Pendiente: Da casos de prueba concretos
- Pendiente: Pide ver fallar la prueba antes de arreglar
- Pendiente: Pide repetir hasta que pase
- Pendiente: Pide evidencias
- Pendiente: Protege las pruebas existentes
- Da el caso concreto: la parada P-106 aparece dos veces y debe contar una.
- Pide la prueba primero y que la vea fallar; después, el arreglo y npm test hasta que pase.
- Cierra con «no cambies ni borres pruebas existentes» y «enséñame la salida de npm test».
Si una parada aparece dos veces con el mismo id (como P-106 en datos/paradas.csv), debe contar una sola vez en el parte.
Primero escribe una prueba con dos filas iguales de P-106 y ejecuta npm test para ver que falla.
Después arregla la causa en src/paradas.js y ejecuta npm test hasta que pase.
No cambies ni borres pruebas existentes.
Al terminar, enséñame la salida de npm test.Comprueba lo que has aprendido
Comprueba Claude dice «he arreglado el fallo y todo funciona», sin más. ¿Qué haces?
Correcto. Revisar la evidencia es rápido.
No. Su afirmación no es una evidencia.
No. En algo crítico puede hacer falta, pero primero pide la evidencia: es más barato.
Comprueba El revisor devuelve 14 hallazgos sobre un cambio pequeño que funciona. ¿Qué haces?
No. Es la receta de la sobreingeniería.
No. Entre los 14 puede haber uno importante.
Correcto. El resto es opcional.
Comprueba En la sesión real, ¿qué demuestra que la prueba nueva detecta el fallo de verdad?
No. El nombre no demuestra nada sobre lo que comprueba.
No. Pasar al final es necesario, pero no basta: también debe haber fallado antes.
Correcto. Una prueba que pasa desde el principio no prueba nada.
Entregable Un cambio verificado y revisado
Haz un cambio pequeño en el repositorio de práctica o en tu proyecto con una petición que incluya casos, la prueba primero y la evidencia final. Después pide una revisión con /code-review o con un subagente. Pega aquí tu petición, la evidencia y qué hallazgos aplicaste y cuáles descartaste, con el motivo.
Está bien si: la prueba nueva falló antes del arreglo y pasa después; pegas la salida real de npm test; y cada hallazgo descartado lleva su motivo. Tiempo: unos 30 minutos.
Lo esencial
- Dale una comprobación que pueda ejecutar: pruebas, build, comparación o captura.
- Prueba primero y vela fallar: así sabes que detecta el fallo.
- Pide evidencias (salida, comando, captura), no afirmaciones.
- Revisión en contexto limpio, quedándote con lo que afecta a la corrección.
Fuentes y para seguir
- Buenas prácticas: dale a Claude una forma de verificar su trabajo (se abre en otra pestaña) (documentación oficial, consultada el 24/10/2026).
- Subagentes (se abre en otra pestaña) y hooks: el evento Stop (se abre en otra pestaña).
- En MaestrIA: le dimos a Claude 200 órdenes de trabajo y se inventó un máximo, otro caso de por qué una afirmación no es una evidencia.
Lección revisada el 24/10/2026 con la documentación oficial enlazada en sus fuentes. Revisamos los cursos cada trimestre.