Revisión de código con IA: del comentario a la corrección verificada

Un comentario resuelto necesita una explicación comprobable

La revisión de código con IA puede ayudar a encontrar problemas y proponer arreglos antes de incorporar un cambio al sistema de una empresa. Para aprobar una entrega, conviene poder reconstruir qué fallaba, qué se modificó y cómo se comprobó el resultado. El estado de una conversación de revisión aporta información, pero por sí solo no demuestra el comportamiento del software.

Esta guía propone un recorrido para equipos internos y empresas chilenas que trabajan con proveedores: convertir cada hallazgo relevante en una decisión respaldada por evidencia. El objetivo es que negocio y tecnología puedan entender por qué se aceptó una corrección, incluso si después cambia la persona responsable del proyecto.

Qué cambió en las herramientas de revisión

El 11 de septiembre de 2026, GitHub anunció que Copilot code review resuelve sus propios comentarios durante una nueva revisión cuando un commit posterior atiende el problema señalado. También informó que amplió las herramientas disponibles para validar código, incluyendo ejecución de compilaciones, pruebas y scripts específicos. Es una actualización reciente del producto, no una verificación de los sistemas de cada cliente. GitHub, actualización de Copilot code review.

La documentación de uso responsable de GitHub reconoce que la revisión puede omitir problemas, señalar errores inexistentes o sugerir código que no corrige el hallazgo. Recomienda revisar y probar las sugerencias, y complementar la herramienta con revisión humana. Tener más capacidad de análisis no elimina esas limitaciones. GitHub, capacidades y limitaciones de sus agentes.

Un portal B2B y una corrección que parece suficiente

Imaginemos un portal de un distribuidor chileno donde cada comprador debe consultar exclusivamente sus cotizaciones. Es un ejemplo hipotético, sin relación con un cliente. La IA detecta que una consulta permite solicitar una cotización de otra empresa cambiando su identificador. Propone ocultar ese identificador en la pantalla y el equipo aplica la sugerencia.

La pantalla ahora parece correcta, pero queda una pregunta pendiente: ¿la solicitud directa al servidor sigue entregando la cotización ajena? En este caso, el criterio de aceptación tendría que exigir que el servidor deniegue el acceso entre empresas, conservando el acceso autorizado. Una corrección visual no bastaría para demostrar ese comportamiento. El ejemplo muestra por qué la evidencia debe seguir la regla de negocio que estaba en riesgo.

Del hallazgo a una prueba que pueda repetirse

Como práctica de trabajo, proponemos registrar primero la condición que dispara el problema, el comportamiento observado y el esperado. Para el portal, el equipo puede preparar dos empresas ficticias, usuarios con permisos conocidos y cotizaciones de prueba. Así puede investigar el hallazgo en un entorno controlado, sin consultar documentos reales de terceros.

Después conviene conservar una comprobación que detecte el fallo en la versión anterior y pase con la corrección. La guía de revisión de Google pide evaluar si las pruebas son útiles y si realmente fallarían ante código defectuoso. También plantea elegir pruebas unitarias, de integración o de extremo a extremo según el cambio. Es una referencia de ingeniería estable, no un anuncio de este mes. Google, qué revisar en un cambio de código.

En nuestro ejemplo, proponemos comprobar la respuesta del servidor y el contenido que devuelve, además de la interfaz. Si una prueba solo verifica que desapareció un botón, su resultado no responde a la pregunta sobre acceso a cotizaciones. La persona que revisa debería poder explicar esa relación entre regla, prueba y resultado.

Qué dejar registrado antes de cerrar el hallazgo

Sugerimos una nota breve vinculada al cambio: descripción del fallo, versión corregida, prueba ejecutada, resultado y responsable de la decisión. El registro debería indicar también qué quedó fuera de la comprobación. Esa precisión permite retomar el trabajo sin interpretar un mensaje genérico de aprobación como una revisión completa de todo el sistema.

Los falsos positivos necesitan otra salida: explicar por qué el hallazgo no corresponde, con contexto verificable del proyecto. Si el equipo decide posponer un problema real, conviene dejar una tarea, una persona responsable y un criterio para retomarlo. Corregido, descartado y pendiente representan decisiones diferentes; mantenerlas visibles ayuda a gestionar el trabajo con un proveedor.

Cómo evaluar si la revisión está aportando valor

Para un piloto, proponemos observar cuánto trabajo requiere confirmar un hallazgo, cuántas correcciones deben reabrirse y qué problemas llegan al usuario después de la entrega. Contar comentarios cerrados puede servir para administrar la cola, pero no demuestra por sí solo que mejoró la calidad. Conviene comparar cambios de dificultad semejante y conservar ejemplos que permitan interpretar los números.

El primer paso puede ser aplicar este recorrido a una entrega acotada del equipo. La guía de modernización incremental de software aporta contexto para organizar esos cambios. El método AI DevFlow conecta especificaciones, implementación y revisión contra criterios definidos. En ambos casos, una entrega explicable empieza por acordar qué resultado se espera y termina con evidencia que el equipo pueda revisar.