Cómo revisar código generado por IA: del diff al recorrido del usuario
Neaptide · 20 de septiembre de 2026 · 8 min de lectura
Revisa código generado por IA mediante diffs, pruebas útiles y recorridos de usuario, con plantillas de revisión e informe.
En este artículo
«Las pruebas pasaron» solo responde a parte de las preguntas. Debes saber qué pruebas se ejecutaron, si cubrían el problema original y si hubo cambios fuera del alcance. La aceptación empieza con criterios que puedas contrastar con el código y el comportamiento.
Revisa tres niveles: cambios en archivos, comprobaciones automáticas y recorrido del usuario. Es un método propuesto, no una garantía de ausencia de errores. Ayuda a localizar las evidencias que faltan.
Define los criterios primero
«Arregla el envío» no basta para un formulario. Describe un comportamiento observable:
Si el servidor devuelve un error, se conservan los valores y aparece un mensaje claro. Durante el envío no se crea una petición duplicada. Tras el éxito se muestra una confirmación.
Separa requisitos y preferencias. Una refactorización elegante no sustituye la corrección que motivó la tarea.
Para trabajos complejos, pide primero localizar las partes afectadas y las pruebas existentes. La verificación explícita también aparece en las recomendaciones de Anthropic.
Nivel 1: lee el diff
Revisa los archivos cambiados y entiende la función de cada uno. Una pequeña corrección del formulario no debería modificar silenciosamente autenticación, dependencias y despliegue.
Comprueba que:
- Se mantienen las reglas de acceso y el tratamiento de errores.
- Una validación real no se ha sustituido por un éxito incondicional.
- No han desaparecido pruebas que detectaban el problema.
- No hay secretos, registros innecesarios ni soluciones temporales que eviten controles.
Usa `git diff` y `git diff --stat`. Si el agente creó un commit, compara los commits adecuados: el diff de cambios sin confirmar puede estar vacío. Referencia de git diff.
Nivel 2: ejecuta las comprobaciones adecuadas
Pide los comandos y el resultado de cada prueba. Distingue «iniciada», «terminada» y «correcta». Un fallo del entorno puede detener un proceso sin demostrar si la corrección funciona.
| Comprobación | Qué responde |
|---|---|
| Tipos | Cumplimiento de las restricciones comprobadas |
| Prueba de función | Resultado esperado para entradas elegidas |
| Integración | Compatibilidad entre partes |
| Compilación | Si la aplicación compila con esa configuración |
| Escenario de navegador | Si funciona el recorrido observable |
Ninguna fila sustituye a todas las demás. Compilar correctamente no demuestra que un correo haya llegado.
Para un defecto reproducible, verifica que la prueba detecta el comportamiento anterior y pasa después. De lo contrario, podría comprobar una propiedad cómoda de la nueva implementación y omitir el error original.
Nivel 3: recorre la aplicación
En el formulario prueba campos vacíos, valores inválidos, fallo del servidor y envío correcto. Usa datos y un destino de pruebas para observar resultados sin solicitudes reales de clientes.
En automatización de navegador comprueba comportamiento visible y referencias estables. Playwright recomienda pruebas aisladas y localizadores relacionados con lo que percibe el usuario. Buenas prácticas de Playwright.
Una captura confirma un estado visible, no toda la cadena. Comprueba también los campos recibidos por el manejador, el registro en el sistema de pruebas y la ausencia de duplicados al pulsar de nuevo.
Revisar con un segundo agente
Dale la tarea original, el diff y los resultados disponibles. Pídele incumplimientos y formas de reproducirlos. No lo predispongas diciendo que el primero lo arregló todo.
Ejemplo:
Revisa los cambios frente a los criterios de la tarea. Para cada observación indica archivo, condiciones que provocan el error y forma de comprobarlo. Evita recomendaciones generales ajenas al diff. Señala por separado lo que no puede confirmarse con los datos disponibles.El segundo agente aporta preguntas adicionales. La decisión debe seguir basándose en código y comprobaciones. Reproduce un caso discutido en lugar de votar entre modelos.
Redactar el informe final
Guarda un registro breve y verificable:
Cambio: qué se corrigió y en qué archivos.
Comprobado: comandos, condiciones y resultados.
Escenario: acciones realizadas en la aplicación.
Sin comprobar: limitaciones del entorno y dudas.
Decisión: aceptar, corregir o pedir más evidencias.No ocultes incertidumbre con «en general funciona». Si el servicio de pruebas no está disponible, indica que la entrega final no se ha confirmado.