Cómo revisar código generado por IA: del diff al recorrido del usuario
Neaptide · 20 de septiembre de 2026 · 9 min de lectura · Actualizado: 3 de octubre de 2026
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
El agente corrige el envío del formulario y los tests pasan, pero un error del servidor sigue borrando los campos. Pasa cuando la revisión se queda en el diff y en los comandos que terminan en verde. Para aceptar código hace falta una cadena de pruebas: qué cambió, qué comprobación detecta el fallo y qué ocurre en el recorrido del usuario.
Revisa tres niveles: cambios en archivos, comprobaciones automáticas y recorrido del usuario. El método no garantiza que no haya errores. Te enseña qué evidencias faltan todavía.
Define los criterios primero
Para un formulario de contacto, «arregla el envío» se queda corto como encargo. Describe un comportamiento que se pueda observar:
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 un envío correcto se muestra una confirmación.
Separa los requisitos de las preferencias. Si no, una refactorización elegante puede acabar ocupando el lugar de la corrección que motivó la tarea.
En un trabajo complejo, pide primero al agente que localice las partes afectadas y las pruebas existentes. Darle al agente una forma explícita de verificar su trabajo también figura en las recomendaciones de Anthropic.
La explicación del agente describe su intención, no el comportamiento observado. El diff muestra el cambio. Un test valida una condición concreta. Ejecutar el recorrido conecta la interfaz con el resultado. Cada prueba tiene su límite, y una captura del mensaje de éxito no demuestra que el correo haya llegado.
Nivel 1: lee el diff
Repasa la lista de archivos cambiados y pregúntate por qué se ha tocado cada uno. Una pequeña corrección del formulario no tiene por qué modificar de paso la autenticación, las dependencias o el 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 ya ha creado un commit, compara los commits que correspondan, porque el diff de cambios sin confirmar puede estar vacío. Referencia de git diff.
Ejecuta git status --short antes de leer el diff, porque los archivos nuevos pueden no aparecer en él. git diff compara el directorio de trabajo con el índice, y git diff --cached compara lo preparado con HEAD. Para ver de una vez todos los cambios rastreados sin confirmar, usa git diff HEAD. Los commits ya creados se comparan con el punto de partida.
Nivel 2: ejecuta las comprobaciones adecuadas
Pide los comandos exactos y el resultado de cada prueba. «Iniciada», «terminada» y «correcta» no significan lo mismo. Un fallo del entorno puede detener un proceso sin demostrar nada sobre la corrección, ni a favor ni en contra.
| 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 de la tabla sustituye a las demás. Que la compilación salga bien, por ejemplo, no demuestra que un correo haya llegado.
Si el defecto es reproducible, asegúrate de que la prueba falla con el comportamiento anterior y pasa después del cambio. De lo contrario, puede que solo compruebe una propiedad cómoda de la nueva implementación y se le escape 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. Trabaja con datos y un destino de pruebas, así ves el resultado sin solicitudes reales de clientes.
En las pruebas automatizadas de navegador, comprueba el comportamiento visible y apóyate en referencias estables. Playwright recomienda pruebas aisladas y localizadores ligados a lo que ve el usuario. Buenas prácticas de Playwright.
Una captura confirma un estado visible, no toda la cadena. Comprueba también que el manejador ha recibido los campos correctos, que el registro aparece en el sistema de pruebas y que pulsar de nuevo no crea un duplicado.
Un escenario de regresión útil: rellenar el formulario, provocar un error controlado del servidor, comprobar que los valores siguen ahí y reintentar. Un segundo clic durante la petición no debe crear otro envío. Simular una respuesta solo comprueba la gestión del error. La entrega real se verifica aparte, con un destinatario de prueba.
Revisar con un segundo agente
Dale la tarea original, el diff y los resultados que tengas. Pídele que busque incumplimientos de los criterios y que explique cómo reproducir cada uno. Y no lo predispongas diciéndole 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 te aporta más preguntas, nada más. La decisión sigue apoyándose en el código y las comprobaciones. Si una observación es discutible, reproduce el caso. Una votación entre modelos no demuestra nada.
Redactar el informe final
Guarda un registro breve, que se pueda releer y comprobar más adelante:
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.Acepta el cambio cuando puedas relacionar el requisito, el diff y un resultado observado. Conserva las órdenes y los escenarios realmente ejecutados, junto con lo que quede por comprobar. Si el fallo se reproduce, dale al agente el paso exacto y el comportamiento esperado. Sirve más que pedirle que «revise otra vez».
Fuentes y verificación
Fuentes técnicas y cálculos verificados el 3 de octubre de 2026. Los escenarios y esquemas son ejemplos didácticos de Neaptide. No hicimos pruebas comparativas de rendimiento.