Copilot Code Review: qué exigir cuando la IA ejecuta código

Un comentario de revisión puede describir un fallo plausible y, aun así, equivocarse sobre el comportamiento real. El coste aparece cuando el equipo modifica código correcto, descarta un riesgo verdadero o confunde una conversación cerrada con una comprobación terminada. Copilot Code Review obliga a concretar una pregunta de ingeniería: ¿qué evidencia necesitamos para actuar sobre una observación de la IA?

GitHub anunció el 11 de septiembre de 2026 que su revisión incorpora más herramientas de shell, capaces de ejecutar builds, tests y scripts, detrás del firewall del agente. También anunció resolución automática de comentarios atendidos durante una nueva revisión y un conjunto de agentes para el nivel Lite. Esta actualización es el punto de partida; los criterios siguientes son nuestra propuesta de implementación, no resultados medidos por Wasyra.

El mecanismo útil es un ciclo corto: formular una hipótesis sobre el diff, elegir una comprobación que pueda refutarla, ejecutarla en un entorno delimitado y vincular el resultado al código revisado. Una salida de consola solo sirve si sabemos qué comando la produjo, sobre qué revisión y con qué datos. Pedir al agente que sea más cuidadoso deja demasiadas decisiones implícitas.

La documentación indica que las capacidades de revisión con agentes utilizan GitHub Actions. El entorno disponible, por tanto, importa: un checkout sin dependencias o sin fixtures puede impedir una prueba válida. Antes de ampliar el piloto, prepara una ruta de instalación reproducible y comprueba que el comando realmente descubre los tests esperados. Una ejecución que termina sin errores pero no ejecuta ningún caso no demuestra el comportamiento investigado.

Registra el SHA revisado, la base de comparación, los archivos afectados y el escenario que activa el posible fallo. Si llega otro commit, la evidencia anterior conserva valor histórico, pero no valida automáticamente el nuevo estado. Para decidir qué repetir, identifica si cambió la función, su dependencia, el fixture o la configuración que sostenían la prueba.

El registro puede ser pequeño: una observación, un comando, un resultado esperado y un resultado observado. Incluye el código de salida y el número de casos ejecutados. Si falta una dependencia, clasifica el hallazgo como pendiente de verificación. No conviertas la incapacidad de reproducirlo en una afirmación de que el fallo no existe.

Un script de test también es código ejecutable. Para el piloto, utiliza datos sintéticos, credenciales de alcance reducido y servicios desechables. Define qué necesita descargar el entorno y quién aprueba ampliar ese acceso. Revisa los scripts de instalación y preparación con el mismo cuidado que los comandos de pruebas; los nombres familiares no garantizan efectos inocuos.

GitHub documenta límites concretos del firewall: no cubre directamente procesos de servidores MCP ni los pasos de preparación configurados, y su alcance se limita al entorno appliance de GitHub Actions. La documentación también advierte de posibles evasiones. Conviene revisar esas rutas por separado y conservar las restricciones de red como una capa del diseño, sin asumir aislamiento completo.

Ejemplo hipotético: una API debe impedir que un usuario consulte documentos de otra organización. El agente observa que una consulta filtra por identificador de documento, pero parece omitir la organización. La prueba útil prepara dos organizaciones ficticias, intenta leer el documento ajeno y comprueba la denegación. Una compilación correcta no responde a esa pregunta de autorización.

Ejecuta el mismo caso sobre el estado previo y sobre la corrección propuesta. Si la prueba pasa en ambos, quizá ya existe otra barrera de autorización o el caso no alcanza la ruta vulnerable. Si falla en ambos, quizá el arreglo es incompleto. Añade el caso permitido de la propia organización para detectar una corrección que simplemente bloquee a todos. Guarda los resultados sin datos reales de clientes.

Propón tres estados en el proceso del equipo: comentario atendido, comportamiento comprobado y cambio aceptado por el responsable. Cada estado responde a una pregunta distinta. El primero organiza la conversación; el segundo exige evidencia; el tercero incluye compatibilidad, alcance y consecuencias operativas. Esta separación evita que una interfaz ordenada o una explicación convincente sustituyan la decisión técnica.

La guía vigente de GitHub distingue las revisiones de tipo Comment de las aprobaciones y permite configurar aprobaciones de Copilot. Por eso debes comprobar la política real del repositorio. Mantén las verificaciones obligatorias que correspondan al producto y define quién puede aceptar excepciones. Un test local del revisor y un check obligatorio de CI tienen procedencia y responsabilidades diferentes.

Selecciona cambios históricos con defectos confirmados, falsos positivos conocidos y casos sin problemas. Conserva una parte fuera de las instrucciones usadas para preparar al agente. Evalúa si descubre el defecto, si ofrece una reproducción válida y cuánto trabajo humano requiere decidir. Cuenta también los fallos que omite: medir solo comentarios aceptados favorece a un revisor que habla poco y deja pasar problemas.

Separa los resultados por tipo de cambio: autorización, lógica de negocio, interfaz o configuración. Registra tiempo total, consumo, comandos fallidos y revisiones que quedaron sin evidencia. Fija los criterios de aceptación antes de ver los resultados y repite una muestra para detectar variación. Las cifras promocionales de un proveedor no sustituyen esta evaluación en tus repositorios.

La adopción tiene sentido si el equipo puede reconstruir el entorno, delimitar accesos y auditar resultados. Si los tests dependen de producción o nadie mantiene los fixtures, empieza por corregir esa base. Automatizar sobre una comprobación frágil puede multiplicar incertidumbre y consumir tiempo sin mejorar la decisión de integración.

El contrato de cinco criterios sirve para adoptar esta actualización con expectativas verificables. No hemos ejecutado un benchmark de Copilot para este artículo ni afirmamos una reducción de defectos. Si estás incorporando revisión con IA, comienza por una ruta crítica y una prueba reproducible. Wasyra puede ayudarte a definir ese piloto dentro de un proyecto de agentes a medida, con alcance y condiciones de aceptación acordados.