Revisión de código de IA: lista de comprobación

Cuando el asistente genera el código y también sus pruebas, las dos cosas nacen de la misma interpretación de la tarea. Si esa interpretación olvidó un caso —otro usuario, un valor fuera de rango—, las pruebas lo olvidan igual. El resultado es una integración continua en verde y una cobertura alta que confirman que el código hace lo que hace, no que hace lo que debía.

Una revisión útil de código generado empieza por escribir, o al menos exigir, las pruebas del caso que el generador no pensó: el que debería fallar.

En una operación sobre dinero, la pregunta de autorización es siempre la misma: ¿quién dice a qué cuenta se aplica? Si lo dice el usuario en la petición, cualquiera con sesión puede escribir el identificador de otro. Lo correcto es tomar ese dato de la sesión autenticada y comprobar además que el recurso —aquí, el pago— pertenece a quien lo pide.

Lee el extracto del diff y localiza el campo del que sale el comercio al que se carga el reembolso.

Una lista marcada en cuatro minutos tiende a marcarse entera. Por eso la revisión posterior no se fía de las cruces: toma cada punto y busca en el cambio la prueba de que se cumple. Aquí hay varios puntos marcados que el diff no respalda; uno de ellos habla justo de lo que encontraste en la tarea anterior.

El tamaño del cambio y el tiempo de aprobación dicen mucho de la revisión. Un asistente produce cientos de líneas en minutos, y eso empuja a aprobar a la misma velocidad. Comparar las líneas cambiadas con el tiempo entre la apertura y la aprobación es una forma simple de comprobar si el punto «quien aprueba leyó el diff completo» pudo cumplirse.

El PR ya está fusionado, así que la recomendación tiene dos partes: corregir el fallo y que el próximo cambio así no pase igual. La lista no está mal; lo que falló es cómo se usó.