El 11 de septiembre de 2026, GitHub cambió dos partes visibles de Copilot Code Review: los comentarios del propio Copilot que ya fueron atendidos pueden resolverse automáticamente durante una nueva revisión, y las sugerencias de código aplicadas desde la interfaz pasan a recibir un mensaje de commit generado según el cambio realizado. Al mismo tiempo, el motor de análisis incorporó más herramientas y un enfoque de varios agentes en el nivel de esfuerzo Lite.
El resultado práctico es menos trabajo de limpieza de hilos y menos mensajes genéricos al aceptar sugerencias. Pero la actualización no convierte cada push en una nueva revisión, no cierra el feedback humano y no reemplaza la decisión de aceptar, probar y fusionar el código.
Qué cambió en el flujo de pull request
| Etapa | Comportamiento relevante ahora | Qué significa en la práctica |
|---|---|---|
| Comentario de Copilot ya atendido | Durante una nueva revisión, Copilot puede resolver su propio comentario cuando un commit posterior atiende el feedback subyacente. | Los hilos antiguos pueden salir de la lista de pendientes sin resolución manual. |
| Comentario todavía no atendido | Permanece abierto. | La lista de hilos abiertos tiende a concentrar el trabajo que aún requiere atención. |
| Nuevo push | No dispara una nueva revisión por sí solo, salvo que el repositorio esté configurado para revisar nuevos pushes. | Sin esa configuración, alguien debe solicitar la nueva revisión manualmente. |
| Aplicación de una sugerencia de Copilot | GitHub genera un mensaje de commit contextual basado en el cambio sugerido. | El mensaje se convierte en un borrador más descriptivo en lugar de un texto genérico. |
| Análisis de la revisión | Copilot ahora usa un conjunto más amplio de herramientas de shell y, en el nivel Lite, un conjunto de agentes. | La revisión puede validar más aspectos del código sin cambiar la forma básica de solicitarla. |
La resolución automática depende de una nueva revisión, no solo del push
El detalle más importante de la actualización es el orden de los eventos. GitHub indica que el comentario se resuelve durante la nueva revisión cuando un commit posterior atiende el problema señalado. Por tanto, la secuencia típica queda así:
- Copilot revisa el pull request y deja comentarios.
- Modificas el código para atender algunos de ellos.
- Haces push del nuevo commit.
- Copilot ejecuta una nueva revisión, solicitada manualmente o activada por una regla que revisa nuevos pushes.
- En ese nuevo análisis, los comentarios que Copilot considera atendidos pueden marcarse como resueltos; lo que siga pendiente permanece abierto.
Por defecto, enviar un nuevo commit a un pull request que Copilot ya revisó no obliga a ejecutar otra revisión. Para tener nuevas revisiones automáticas en cada push, el repositorio debe habilitar la revisión automática y la opción Review new pushes en sus rulesets. De lo contrario, la nueva revisión se solicita desde el menú de revisores del pull request.
También hay que delimitar el alcance: el anuncio se refiere a los comentarios creados por el propio Copilot Code Review. No afirma que los hilos de revisores humanos se cierren automáticamente. Además, la documentación de GitHub señala que las respuestas añadidas a los comentarios de Copilot son visibles para las personas, pero no para Copilot. En la práctica, la automatización se apoya en el cambio de código evaluado durante la nueva revisión, no en una conversación escrita con el bot.
Antes y después en un pull request: un ejemplo sencillo
Imagina un pull request con tres comentarios de Copilot: uno sobre manejo de errores, otro sobre una prueba ausente y un tercero sobre lógica duplicada. La persona desarrolladora corrige el manejo de errores y la duplicación, pero deja la prueba para un commit posterior.
Antes de la actualización: incluso después de aplicar las correcciones, podía quedar trabajo manual para cerrar hilos que ya habían perdido relevancia.
Con la actualización: después del push y de la nueva revisión, Copilot puede resolver automáticamente los dos comentarios que considera atendidos y mantener abierto el comentario sobre la prueba. La mejora no es “Copilot decidió que el pull request está listo”; es una lista potencialmente más limpia de trabajo pendiente.
Hay una salvedad útil: la documentación actual de GitHub todavía advierte que, durante nuevas revisiones, Copilot puede repetir comentarios anteriores aunque ya se hayan resuelto o recibido una valoración negativa. Por eso, la resolución automática reduce el trabajo de seguimiento, pero no debe interpretarse como garantía de que un mismo punto o uno parecido nunca volverá a aparecer.
Smart commit messages: el recurso es más específico de lo que parece
El segundo cambio visible aparece cuando aplicas una sugerencia de código incluida en un comentario de Copilot Code Review. En lugar de rellenar un mensaje estándar, Copilot genera un mensaje basado en lo que modifica la sugerencia.
Esto no significa que Copilot reescriba los mensajes de todos los commits del pull request ni que los commits creados localmente reciban automáticamente una descripción inteligente. El disparador descrito por GitHub es el flujo de suggested changes asociado al propio comentario de revisión de Copilot.
El flujo normal de sugerencias sigue siendo importante: puedes aplicar una sugerencia de forma individual o agrupar varias en un único commit. GitHub sigue mostrando un campo de mensaje antes de confirmar el commit. Por eso, conviene tratar el mensaje generado como un borrador y comprobar que describe con precisión el alcance real, sobre todo cuando se agrupan varias sugerencias.
Qué cambió detrás del análisis
El anuncio del 11 de septiembre también incluyó cambios que no alteran los botones del flujo de trabajo, pero pueden influir en la calidad del feedback.
- Más herramientas de shell: además de las herramientas de lectura de archivos que ya se usaban en la revisión, Copilot Code Review ahora utiliza el conjunto completo de herramientas de shell del Copilot SDK, ejecutado detrás del firewall del agente. GitHub menciona como ejemplos ejecutar builds, pruebas, scripts específicos y obtener información de herramientas y APIs disponibles.
- Varios agentes en el nivel Lite: las revisiones Lite ahora usan un conjunto de agentes cuyos hallazgos se combinan en una única revisión.
En los experimentos divulgados por GitHub, el enfoque de varios agentes aumentó el promedio de comentarios atendidos por revisión en un 47% para hallazgos de alta severidad, un 31% para los de severidad media y un 11% para los de baja, al tiempo que redujo el costo de la revisión cerca de un 8%. Esos datos son resultados experimentales de GitHub, no una promesa de que todos los repositorios obtendrán el mismo rendimiento.
El changelog separa de forma explícita estas mejoras del flujo de uso: profundizan el análisis, pero no cambian la manera básica de solicitar o recibir una revisión.
Qué sigue requiriendo criterio humano
- Un comentario resuelto no prueba que el código sea correcto. Significa que, durante la nueva revisión, Copilot evaluó que un commit posterior atendió su feedback anterior.
- La nueva revisión todavía tiene que ocurrir. Puede solicitarse manualmente o configurarse para ejecutarse después de nuevos pushes.
- El feedback pendiente sigue pendiente. La función está diseñada para mantener abiertos los puntos que todavía requieren atención.
- Los comentarios de revisores humanos siguen siendo responsabilidad del equipo. La resolución automática anunciada se aplica a los comentarios de Copilot.
- Aplicar una sugerencia todavía exige revisar el diff. Un mejor mensaje de commit no valida el cambio por sí solo.
- La decisión de merge sigue formando parte del proceso del repositorio. Por defecto, Copilot Code Review envía una revisión de tipo comentario; las aprobaciones de Copilot son una capacidad independiente y configurable.
Un flujo práctico para aprovechar la novedad sin delegar el pull request
- Solicita la revisión inicial de Copilot, manualmente o mediante la configuración de revisión automática.
- Lee los comentarios y prioriza primero los hallazgos de mayor impacto, en vez de aplicar sugerencias en bloque sin evaluación.
- Cuando exista una sugerencia de código, inspecciona el diff antes de aplicarla.
- Si aplicas la sugerencia, revisa también la smart commit message y edítala si no refleja el alcance real del commit.
- Haz push de las correcciones.
- Asegúrate de que habrá una nueva revisión: solicítala manualmente o confirma que Review new pushes está habilitado.
- Después de la nueva revisión, mira tanto lo que se resolvió como lo que sigue abierto. Que un hilo desaparezca es una señal de seguimiento, no un sustituto de pruebas o revisión técnica.
- Antes del merge, conserva las validaciones normales del proyecto: CI, pruebas, revisión humana cuando corresponda y comprobación del impacto del cambio.
La mejora real de la actualización
El beneficio principal es operativo. Copilot Code Review ahora mantiene mejor el estado de sus propios comentarios después de que cambia el código y produce borradores de mensajes de commit más útiles cuando se aceptan sugerencias. Eso elimina dos tareas mecánicas — limpiar hilos ya atendidos y reescribir mensajes genéricos — sin cambiar la responsabilidad final de la persona autora y de quienes revisan el pull request.
Los equipos que ya usan nuevas revisiones automáticas probablemente noten el cambio de inmediato: después de cada push revisado, los comentarios abiertos pueden reflejar mejor lo que todavía falta. Los equipos que ejecutan Copilot una sola vez por pull request verán la resolución automática solo cuando se ejecute realmente una nueva revisión.
