Revisión: no le creas a la primera
Lección 22 de 26 del curso «Vibe coding». Gratis, con animaciones y un test.
«Listo» no significa «funciona»
Le pediste al agente que agregara estadísticas del mes a tu registro de entrenamientos. Un par de minutos después: «¡Listo, todo funciona!». Suena seguro, pero quizá no corrió el código, probó un solo caso de muchos o no notó que rompió la página de al lado. ¿Recuerdas el ciclo del esquema: describes, la IA escribe, tú revisas? El último paso es tuyo y no se salta.
Recorre la vista previa
El agente trabajó en una rama y abrió un PR, así que hay un enlace de vista previa: una copia del sitio con la función nueva, sin tocar el sitio en vivo. Ábrelo en el celular y en la compu. Primero el camino normal: registras un entrenamiento, abres las estadísticas. Luego lo raro: un mes sin entrenamientos, un nombre larguísimo, doble toque en el botón. Lo que se rompe suele romperse en lo raro.
Tests automáticos: revisores robot
Un test automático es un programa pequeño que revisa tu código. Ejemplo: «si hay tres entrenamientos seguidos, la racha muestra 3». Pídele al agente que escriba tests para la función nueva y que los corra, muchas veces con el comando npm test. La ventaja: la próxima vez que la IA cambie algo, los tests muestran al instante qué se rompió. La trampa: un test que siempre pasa. Lee los nombres de los tests: deben describir el comportamiento real.
CI: revisión en cada PR
CI (continuous integration, integración continua): GitHub corre solo los tests y el build en cada PR, por ejemplo con GitHub Actions. El build es el paso que convierte tu proyecto en los archivos listos del sitio. El resultado se ve en el propio PR: palomita verde o cruz roja, como en la tarjeta del esquema. ¿Rojo? No hagas merge: abre el log y pásale el error al agente. Puedes pedirle al propio agente que configure el CI.
Lee el diff antes del merge
Los checks están en verde, pero mira el diff igual. Qué buscar: código borrado que no pediste, como la línea roja «¿verificación eliminada?» del esquema. Claves y contraseñas en el código. Paquetes nuevos con nombres desconocidos: usa los conocidos, porque hay estafadores que publican copias con nombres parecidos. Cambios en archivos que no tienen que ver con la tarea. ¿Encontraste algo? Pregúntale al agente «¿por qué?» antes del merge.
Checklist antes del merge
En resumen, cinco puntos antes del merge. Vista previa revisada en celular y compu. Tests en verde. CI en verde. Diff leído: sin claves, sin verificaciones borradas, sin paquetes raros. Commits con mensajes claros. ¿Todo bien? Merge, y el hosting actualiza el sitio en vivo. ¿Algo falla? Corrígelo en la misma rama. La regla de la tarjeta del esquema: primero revisa, luego merge. Practica en el simulador de GitHub.
Ponte a prueba
- El agente escribe «Listo, todo funciona». ¿Y ahora?
Respuesta correcta: Revisar tú mismo la vista previa y los tests. El «listo» del agente no es prueba. Quizá no corrió el código o probó un solo caso. La vista previa y los tests muestran la verdad. - ¿Qué es CI?
Respuesta correcta: GitHub corre solo los tests en cada PR. CI (integración continua) corre automáticamente tests y build en cada PR y muestra palomita verde o cruz roja. - En el diff se borró una verificación que no pediste. ¿Qué haces?
Respuesta correcta: Pregunto al agente «¿por qué?» antes del merge. Los tests en verde no detectan todo: pueden pasar por alto una verificación borrada. Resuélvelo antes del merge, antes de que llegue al sitio en vivo.
← Bugs: leer el error Ayudantes del agente: skills y revisión con IA →