GitHub puso a disposición general, el 23 de septiembre, un conjunto de controles más granulares para la revisión automática de código hecha por Copilot. El cambio central es de acceso: la configuración personal de revisión, antes limitada a los planes Copilot Pro, Pro+ y Max, ahora llega también a las licencias Copilot Business y Copilot Enterprise, las que compran la mayoría de las empresas para equipos enteros.
En la práctica, cada usuario obtiene una página dedicada de configuración de revisión de código, donde puede activar revisiones automáticas de Copilot por separado para tres situaciones: al crear un pull request, al mover un pull request fuera del estado de borrador, y al enviar un nuevo push a un PR que Copilot ya está revisando. Antes, solo existía una llave general de encendido y apagado, sin este nivel de control.
El segundo cambio relevante es el esfuerzo de revisión. Copilot code review ya operaba en dos niveles, Lite, la revisión estándar más rápida, y Balanced, un análisis más profundo orientado a lógica compleja, código sensible a la seguridad y cambios que cruzan varios servicios. Ahora, administradores autorizados de una cuenta enterprise pueden fijar un nivel de esfuerzo predeterminado para toda la enterprise, que se propaga por herencia a los repositorios de las organizaciones vinculadas, aunque organizaciones y repositorios individuales todavía pueden anular esa elección con su propia configuración.
El modelo de gobernanza sigue el mismo patrón ya usado en otras políticas de nivel enterprise de GitHub: un ruleset de branch definido de forma centralizada, aplicado a organizaciones y repositorios objetivo, con la política "Automatically request Copilot code review" pudiendo quedar a criterio de cada organización, activada para organizaciones seleccionadas, o desactivada en toda la enterprise.
Para equipos de desarrollo en pequeñas y medianas empresas brasileñas que ya pagan por Copilot Business, la ganancia práctica es reducir ruido sin perder cobertura: los equipos que trabajan con borradores largos pueden optar por no activar la revisión hasta que el PR salga del estado de borrador, mientras que los equipos que iteran rápido con múltiples pushes pueden elegir revisar solo la versión final. Para quien lidera ingeniería en una empresa más grande, la novedad más importante es la posibilidad de estandarizar el nivel de esfuerzo de revisión automáticamente en todos los repositorios, en lugar de depender de que cada equipo lo configure manualmente, el tipo de control que normalmente aparece solo cuando una herramienta ya está en uso lo bastante extendido como para necesitar una política central.
Vale la pena registrar que esta expansión de controles llega junto con otro cambio en el mismo frente: el nivel de esfuerzo predeterminado de Copilot code review pasaría de Lite a Balanced en algunos contextos a partir del 28 de septiembre, según reportes de la comunidad de desarrolladores. Los equipos que dependen de la revisión automática como puerta de merge deberían revisar su configuración de esfuerzo antes de esa fecha, para no verse sorprendidos por un tiempo de revisión más largo en el flujo de CI.
Fuentes
GitHub Changelog, anuncio oficial: https://github.blog/changelog/2026-09-23-copilot-code-review-more-ways-to-request-and-configure-reviews/
GitHub Docs, documentación oficial de configuración: https://docs.github.com/en/copilot/how-tos/copilot-on-github/set-up-copilot/configure-automatic-review
Windows Forum, cobertura independiente sobre el cambio de nivel predeterminado: https://windowsforum.com/news/github-copilot-code-review-default-switches-to-balanced-september-28.445722/