Cómo revisar cambios de código generados por IA antes de aceptarlos
Comprueba alcance, diferencias, cambios preparados, pruebas y riesgos pendientes en Mono Code con una plantilla práctica y comandos Git de solo lectura.
Revisa el código que está en el repositorio, además del resumen del agente. Una explicación convincente puede acompañar una solución incompleta, una prueba que nunca se ejecutó o cambios ajenos a la tarea. Separa el comportamiento solicitado, los cambios reales y las pruebas antes de aceptar el resultado.
Mono Code te permite abrir los archivos del proyecto, trabajar con agentes de programación y ver los cambios de Git directamente en el editor. Esta guía trata de revisar un cambio pequeño ya terminado; la guía de programación remota explica cómo conectarte. El repositorio y los comandos siempre se quedan en tu propio ordenador, el anfitrión. Mono aún no está disponible; puedes apuntarte a la lista de espera.
1. Define de nuevo el criterio de aceptación
Usa un ejemplo concreto: un formulario ficticio de tareas acepta un título compuesto solo por espacios. Se pide rechazar esa entrada y conservar los títulos normales. Antes de mirar el parche, escribe qué debe cumplirse:
- No se pueden enviar títulos vacíos ni compuestos solo por espacios.
- Un título normal se envía correctamente.
- La persona ve un mensaje de validación útil.
- El resto del formulario permanece dentro del alcance acordado.
Mantén esta lista junto a las diferencias. Así evalúas el cambio con un criterio propio, en vez de aceptar la explicación que presente el agente. Si la solicitud inicial era ambigua, aclara el comportamiento antes de aceptar una implementación más amplia.
2. Determina el estado del repositorio
Confirma el equipo anfitrión, la carpeta del proyecto y la rama. Compara la lista de archivos modificados con el estado inicial registrado antes de trabajar con el agente. Los cambios previos del usuario no pasan a ser del agente porque aparezcan en el mismo archivo.
En una terminal del equipo adecuado pueden ayudarte estos comandos de solo lectura:
git status --short
git diff --stat
git diff -- path/to/file
git diff --cached -- path/to/fileSustituye la ruta de ejemplo. git diff muestra cambios sin preparar; --cached compara los cambios preparados con el commit. Revisa aparte los archivos sin seguimiento. La documentación de Git diff explica estas comparaciones. Un árbol de trabajo limpio no revela si el agente ya creó un commit; revisa el historial correspondiente si ocurrió.
3. Lee el parche y el código que lo rodea
En el editor de Mono, el margen marca las líneas añadidas y modificadas, y al tocar una marca se abren las diferencias de esa parte. Es una forma práctica de ver un cambio, no una prueba de que los has revisado todos. Que falte una marca o esté desactualizada no significa que el archivo no haya cambiado.
En el ejemplo del título, localiza la condición de validación y sigue lo que ocurre después. ¿Comprueba el valor normalizado? ¿Se ve el error? ¿Se detiene el envío? Inspecciona el código circundante, no solo una condición añadida sin quien la invoca.
Comprueba archivos nuevos, código eliminado, dependencias y formato ajeno al objetivo. Una explicación corta no justifica una diferencia grande sin explicar. Pasa al equipo anfitrión o a una pantalla mayor si hay líneas truncadas o el cambio resulta demasiado ancho para leerlo bien.
4. Relaciona las pruebas con el comportamiento
Pide el comando que realmente se ejecutó, su resultado y las comprobaciones omitidas. «Las pruebas deberían pasar» es una predicción, no un resultado registrado. Una batería correcta también necesita un caso pertinente para el fallo.
| Caso | Observación esperada |
|---|---|
| Título vacío | Se detiene el envío con el mensaje previsto |
| Solo espacios | Mismo rechazo, sin crear un elemento |
| Título normal | El envío sigue funcionando |
| Comportamiento previo ajeno al cambio | Siguen pasando las comprobaciones pertinentes |
Una comprobación manual puede servir para mensajes visibles; una prueba automatizada de regresión puede proteger la regla de validación. Elige evidencias que demuestren el cambio, no pruebas que repitan su implementación. Si el entorno impide probar, documenta esa limitación y decide dónde completar la verificación pendiente.
5. Resuelve hallazgos sin perder trabajo ajeno
Da comentarios precisos: «Se rechaza el título con espacios, pero no aparece el mensaje de error» o «Explica por qué cambió el archivo de dependencias para esta corrección». Señala el comportamiento y el archivo, no solo «inténtalo otra vez».
Evita reinicios o restauraciones globales para quitar un cambio pequeño si existe otro trabajo. Pide una corrección localizada e inspecciona las nuevas diferencias. Repite después las comprobaciones afectadas: un resultado anterior no verifica modificaciones posteriores.
Autorizar un comando y aceptar código son decisiones distintas. Aprobar un comando de prueba no aprueba crear commits, fusionar ni desplegar. Consulta la guía de permisos para evaluar la operación en sí.
6. Deja un traspaso que se pueda revisar
Registra la conclusión en una nota breve:
Comportamiento solicitado: Rechazar títulos de tareas en blanco.
Archivos revisados: Indicar las rutas reales.
Evidencias: Comandos, resultados y comprobaciones manuales relevantes.
Dudas pendientes: Lo que aún no se ha verificado.
Siguiente decisión: Aceptar, pedir una corrección o posponer.Mantén explícitas las acciones de commit y publicación. Si necesitas conservar la conversación, expórtala a Markdown, pero guarda también los archivos reales del proyecto. La transcripción registra la conversación; el repositorio y las comprobaciones verificadas establecen qué cambió.
