El 1 de septiembre de 2026, GitHub anunció en vista previa pública que Copilot Code Review no solo podía indicar que una pull request parecía lista, sino también enviar una aprobación que cuenta para las reglas de fusión cuando un administrador activa esta capacidad. La función está desactivada por defecto y se configura en los niveles de empresa, organización y repositorio, con la posibilidad de restringirla por rutas de archivos. Esta evolución puede acelerar los cambios rutinarios; sobre todo, modifica el límite de confianza de la cadena de entrega.
Idea clave: la opinión de un agente puede complementar una revisión, pero nunca debe convertirse en el único control de un cambio sensible ni aprobar un cambio producido por la misma cadena sin validación independiente. Las ramas protegidas, las pruebas, CODEOWNERS, la separación de responsabilidades y la trazabilidad siguen siendo las salvaguardas principales.
1. Distinguir evaluación y aprobación
GitHub introduce dos comportamientos diferentes. Todas las revisiones de Copilot pueden incluir una evaluación que indica si la pull request parece lista para ser aprobada. Esta indicación aparece en el comentario de resumen, pero no satisface los requisitos de fusión.
Cuando se activa la opción, Copilot puede enviar una aprobación real. Puede contar dentro del número de aprobaciones exigido por la regla de protección. Si se incorporan nuevos commits después de la aprobación, GitHub indica que esta se revoca, como la de un revisor humano, y debe solicitarse una nueva revisión.
Esta distinción debe permanecer visible en la interfaz y en los procedimientos. Un desarrollador no debe confundir «el modelo no encontró ningún problema bloqueante» con «el cambio está autorizado para entrar en producción». La primera frase describe una señal. La segunda implica responsabilidad y participa en una decisión de control.
Al principio, la evaluación que no cuenta puede activarse ampliamente para medir la pertinencia de la señal. La aprobación efectiva debe limitarse a los repositorios y rutas cuyo riesgo se haya evaluado.
2. Por qué la aprobación es una facultad y no un comentario
Una revisión de código produce observaciones. Una aprobación modifica el estado de la pull request y puede desbloquear una fusión automática. Por tanto, constituye una llamada a herramienta con consecuencias, comparable a añadir una etiqueta de despliegue o validar un cambio de infraestructura.
La pregunta central no es «¿Copilot sabe detectar defectos?». Es: ¿en qué condiciones puede su juicio sustituir una parte del control obligatorio? Un revisor humano a veces conoce el objetivo de negocio, el historial del componente, una restricción de cliente o una dependencia operativa que no aparece en el diff.
El modelo también puede verse influido por el contenido del repositorio: comentarios, documentación, nombres de archivos o instrucciones integradas. Incluso cuando la plataforma aplica protecciones, los datos analizados siguen siendo una entrada no fiable. Una regla importante no debe depender únicamente de un sistema probabilístico que lee el cambio que debe autorizar.
También hay que considerar los fallos correlacionados. Si el mismo proveedor, modelo o instrucción genera el código y luego lo aprueba, ambas etapas pueden compartir los mismos puntos ciegos. Multiplicar agentes no crea automáticamente independencia.
3. Preservar la separación de responsabilidades
El principio mínimo es el siguiente: un cambio no debe ser creado y aprobado por la misma identidad lógica sin otro control independiente. Si Copilot o un agente abre la pull request, su aprobación no debe bastar para fusionarla.
Esta regla puede aplicarse mediante procedencia. Añada a las pull requests un atributo que indique si el cambio es humano, asistido o generado por un agente. Entonces las reglas de fusión exigen validación humana para las contribuciones de agentes, incluso si hay una revisión de Copilot.
Para cambios humanos sencillos, Copilot puede proporcionar una aprobación complementaria. La organización puede decidir que cuente como una de dos aprobaciones, pero no como la aprobación final de un componente crítico. Un CODEOWNER sigue siendo responsable del perímetro.
Separe también las configuraciones. La cuenta que administra las reglas de aprobación no debe poder modificarse mediante el flujo de trabajo evaluado. Los cambios de parámetros de empresa, protección de ramas y archivos de política pasan por un grupo restringido y una revisión humana.
Por último, la identidad de Copilot debe ser explícita en el historial. Una aprobación automatizada no debe parecer la de un miembro del equipo. La auditoría debe permitir encontrar el modelo, la versión de la función, la fecha, los commits examinados y los controles disponibles en el momento de la decisión.
4. Definir las rutas que la IA no puede aprobar por sí sola
GitHub permite a los administradores elegir las rutas que Copilot está autorizado a aprobar. Esta capacidad debe utilizarse como una lista positiva: la aprobación solo es válida en zonas consideradas explícitamente de bajo riesgo.
Un primer perímetro puede incluir cambios documentales, ejemplos, traducciones, pruebas sin cambios de producción, dependencias de desarrollo o correcciones repetitivas en un componente bien cubierto. Incluso en estas zonas, siguen siendo necesarias las pruebas y los límites de volumen.
Excluya como mínimo:
- archivos de secretos, identidades y permisos;
- flujos CI/CD, scripts de despliegue e infraestructura;
- migraciones y esquemas de bases de datos;
- código de autenticación, pagos, cifrado o control de acceso;
- políticas de seguridad, CODEOWNERS y protecciones;
- dependencias de producción y archivos de bloqueo cuando no se haya analizado su impacto;
- código regulado o sujeto a validación contractual;
- modificaciones masivas, generadas o difíciles de revisar.
La sensibilidad no depende únicamente de la ruta. Una documentación puede contener un comando operativo peligroso; una prueba puede desactivar una aserción. Añada reglas sobre tamaño del diff, tipo de archivo, permisos modificados y presencia de marcadores de riesgo.
Las rutas deben revisarse con cada evolución de la arquitectura. Un directorio antes estático puede convertirse en una fuente de configuración activa.
5. Reforzar las protecciones de rama y la CI
La aprobación de Copilot no debe eludir los controles existentes. Exija una rama actualizada, estados de CI obligatorios, ausencia de conversaciones sin resolver, firma de commits cuando la política lo prevea y revocación de aprobaciones después de una modificación.
Las pruebas deben cubrir más que la sintaxis. Añada análisis estático, dependencias, secretos, migraciones, contratos de API, permisos y pruebas de seguridad adaptadas al componente. Una revisión de IA puede comentar una intención; la CI aporta pruebas reproducibles.
Utilice una merge queue para impedir que una aprobación valide un estado distinto del que realmente se integra. La cola repite los controles sobre la combinación final de cambios y limita los conflictos entre pull requests aprobadas por separado.
Para repositorios de alto impacto, exija un entorno de preproducción o una validación de despliegue distinta. El código puede ser correcto localmente y producir un efecto inesperado sobre datos, configuración u observabilidad.
No dé al agente la capacidad de modificar las pruebas obligatorias en el mismo recorrido que aprueba. Cuando un cambio afecta a la CI, a la política o a los conjuntos de evaluación, se impone una revisión humana específica.
6. Evaluar la calidad de la revisión antes de activarla
Empiece observando las evaluaciones que no cuentan. Durante varias semanas, compare el juicio de Copilot con el resultado de los revisores humanos, los incidentes posteriores a la fusión y los retornos de producción.
Construya un conjunto de pull requests históricas que incluya defectos conocidos: error lógico, control de acceso ausente, migración arriesgada, concurrencia, ruptura de compatibilidad, filtración de datos, prueba debilitada y cambio documental legítimo. Mida qué detecta Copilot, qué deja pasar y qué bloquea erróneamente.
Las métricas útiles son la cobertura de defectos críticos, la tasa de falsa sensación de seguridad, el número de comentarios accionables, el tiempo de revisión y la tasa de desacuerdo humano. Una tasa global de acuerdo puede ser elevada y aun así ocultar los errores raros más graves.
Pruebe también la solidez: instrucción contradictoria en el repositorio, diff muy voluminoso, código generado, renombrado masivo, submódulo y archivo binario. Verifique que el sistema se abstenga cuando el contexto sea incompleto o la pull request quede fuera de su perímetro.
Repita la evaluación tras cada cambio importante de modelo o funcionalidad. Una vista previa pública evoluciona; un resultado obtenido en septiembre de 2026 no garantiza el mismo comportamiento meses después.
7. Desplegar por etapas y prever la reversión
La primera etapa es informativa: Copilot comenta y publica su evaluación sin contar en las reglas. La segunda autoriza la aprobación en un repositorio de bajo riesgo, pero sigue exigiendo una aprobación humana. La tercera permite que la aprobación satisfaga una regla únicamente para una lista muy limitada de rutas y cambios.
No active globalmente en el nivel de empresa antes de observar el comportamiento por tipo de repositorio. Utilice la jerarquía de parámetros para que las organizaciones o repositorios se unan explícitamente al piloto.
Defina umbrales de parada: defecto crítico no detectado, tasa de falsos positivos demasiado alta, divergencia con los revisores, cambio de comportamiento no documentado o incidente posterior a la fusión. La desactivación debe ser inmediata y no requerir modificar cada repositorio individualmente.
Conserve el historial de decisiones. Cuando un equipo amplía las rutas autorizadas, proporciona los resultados de evaluación y el propietario del riesgo. La autorización expira automáticamente si no se revisa.
Tras el despliegue, muestree pull requests aprobadas por Copilot y realice una revisión posterior. La ausencia de incidente visible no prueba la ausencia de defecto; el control continuo evita que la función se convierta en un automatismo olvidado.
8. Una política de referencia para las organizaciones
Una política sencilla puede formularse así:
- la evaluación de Copilot es por defecto una señal consultiva;
- la aprobación efectiva está desactivada a nivel de empresa, salvo delegación explícita;
- solo los repositorios inscritos en el piloto pueden activarla;
- las rutas autorizadas se definen positivamente;
- las contribuciones de agentes siempre exigen aprobación humana;
- se excluyen los archivos sensibles y cambios de política;
- los estados de CI y CODEOWNERS siguen siendo obligatorios;
- todo nuevo commit revoca la decisión y desencadena una nueva revisión;
- el comportamiento se evalúa y audita periódicamente;
- un mecanismo central permite la desactivación inmediata.
Esta política debe acompañarse de ejemplos, pues los equipos deben entender qué constituye un cambio sencillo o sensible. También debe precisar que la aprobación técnica no sustituye la validación de producto, jurídica o de seguridad exigida por determinados proyectos.
La experiencia de Asana y el uso de Codex para una migración de deuda técnica recuerda la importancia de una fuerte cobertura de pruebas y de una revisión humana de cada modificación, incluso cuando los agentes aceleran considerablemente el trabajo.
Conclusión
La posibilidad de que Copilot apruebe una pull request puede reducir la latencia de los cambios rutinarios, pero concede a un sistema probabilístico un papel en la decisión de fusión. Ese papel debe tratarse como una delegación de facultad y no como un simple comentario enriquecido.
El marco sólido se basa en rutas autorizadas, separación entre autor y aprobador, protecciones de rama, CI independiente, CODEOWNERS, evaluaciones locales y un despliegue gradual. Partitech acompaña a los equipos en el diseño de estas políticas, la automatización de GitHub y la integración de agentes de desarrollo sin debilitar el control de la entrega.
Referencias verificadas el 3 de septiembre de 2026
- GitHub — «Copilot code review can now approve pull requests», 1 de septiembre de 2026: https://github.blog/changelog/2026-09-01-copilot-code-review-can-now-approve-pull-requests/
- Documentación de GitHub — protección de ramas y reglas de pull request: https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository
- Documentación de GitHub — CODEOWNERS: https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners