GitHub abre la gestión de Copilot Code Review por API en tres niveles

Cuando una compañía tiene decenas de organizaciones y cientos de repositorios, configurar a mano la revisión con IA se convierte rápidamente en una lotería. En un proyecto Copilot revisa cada pull request, en otro está desactivado y en un tercero usa un servidor MCP del que el equipo de seguridad no sabe nada. GitHub ha cerrado esa brecha: los ajustes de Copilot Code Review ahora pueden gestionarse mediante las API REST y GraphQL en tres niveles: empresa, organización y repositorio individual.

El sentido práctico es sencillo: la política de revisión puede almacenarse como código, verificarse automáticamente y desplegarse de una vez en todo el entorno. La actualización está disponible en los planes Copilot Pro, Pro+, Max, Business y Enterprise.

Cómo funciona la jerarquía de ajustes

El administrador de la empresa decide si Copilot Code Review se permite en todas las organizaciones o si cada una elige por sí misma. Si un ajuste se fija desde arriba, no se puede sobrescribir en los niveles inferiores.

En el nivel de organización se puede activar la revisión, definir el nivel de rigurosidad predeterminado y gestionar la configuración del runner. El administrador del repositorio dispone de menos palancas: elige la rigurosidad de la revisión y permite o prohíbe el uso de instrucciones personalizadas y herramientas MCP.

Imaginemos una empresa con cincuenta repositorios. El equipo de seguridad prohíbe los servidores MCP externos, el equipo de plataforma activa por defecto un modo de revisión equilibrado y los responsables de servicios críticos eligen una revisión más profunda. Antes, un esquema así se mantenía mediante la interfaz y notas internas. Ahora puede describirse en un script, comparar el estado deseado con el real y corregir las discrepancias a través de la API.

Qué se puede obtener ahora de la API

GitHub ha añadido campos explícitos que permiten distinguir las revisiones y los comentarios de Copilot de los mensajes de personas y de otras aplicaciones. La API también puede devolver el nivel de rigurosidad utilizado e indicar qué habilidades, servidores MCP e instrucciones personalizadas citó Copilot como fuentes de una observación concreta.

Esto importa más de lo que parece. Un equipo puede recopilar automáticamente las observaciones de la revisión con IA, calcular la proporción de recomendaciones aceptadas e investigar un comentario polémico: si fue resultado del modelo estándar, de una instrucción interna o de una herramienta conectada. Las sesiones del agente ahora muestran además la cantidad de créditos de IA gastados, de modo que el coste de una revisión puede contrastarse con su utilidad.

El propio resumen de la revisión es más compacto. Los archivos omitidos y excluidos se agrupan en una sola sección con los motivos de exclusión, los bloques vacíos se ocultan y las listas largas se contraen. Al dar una valoración negativa, el usuario puede indicar el motivo: conclusión incorrecta, verbosidad excesiva o comentario quisquilloso.

Limitaciones y conclusión práctica

La API tiene un detalle molesto. Los endpoints de ajustes de empresa y organización, incluida la configuración del runner, no admiten GitHub Apps ni tokens de acceso personal de permisos granulares. Para gestionar un repositorio ambas opciones sirven: la lectura requiere el permiso Administration: read y la modificación, Administration: write. Un token de acceso personal clásico necesita acceso administrativo al repositorio.

GitHub también ha corregido problemas operativos: una revisión fallida o bloqueada se reintenta automáticamente una vez y, si el modelo elegido no está disponible, el sistema puede cambiar a otro adecuado. Los ajustes de facturación y de funciones en vista previa se conservan tras desactivar y volver a activar la revisión.

Para un equipo de plataforma, el siguiente paso es evidente: exportar los ajustes actuales mediante la API, definir una política de referencia y añadir una comprobación de discrepancias al flujo de gestión de GitHub existente. Pero no conviene dar de inmediato permisos de escritura a un script. Primero ejecute una auditoría de solo lectura, compruebe por separado la herencia de políticas y solo después automatice los cambios. La API hace que Copilot Code Review sea gestionable, pero la calidad de sus observaciones sigue debiendo medirse en sus propios repositorios.