La idea clave
Copilot puede cerrar sus comentarios cuando una nueva revisión considera corregido el problema. Ese cierre no demuestra por sí solo que el cambio esté listo para integrarse.
Una revisión de código puede dejarte dos trabajos: corregir el problema y limpiar la conversación cuando ya está resuelto. GitHub anunció el 11 de septiembre que Copilot code review puede ocuparse de parte de ese segundo paso. Al revisar un nuevo commit, cierra sus comentarios cuando considera atendido el problema.
La novedad resulta especialmente útil si un cambio acumula varias rondas de correcciones. El objetivo de lectura debería ser claro: identificar qué queda pendiente sin confundir un hilo cerrado con una garantía sobre todo el código.
Las novedades confirmadas
El anuncio oficial también incorpora mensajes de commit adaptados a las sugerencias que aplicas. En el análisis, el agente dispone de más herramientas de terminal para comprobar código, y el nivel Lite combina aportaciones de varios agentes en una revisión.
GitHub comunica mejoras de calidad y coste en sus experimentos internos. Son resultados del proveedor; no hemos repetido esas evaluaciones ni sabemos si el ahorro se reproducirá en tu repositorio. Tener más herramientas disponibles tampoco significa que cada revisión ejecute todas tus pruebas.
Cómo pedir una revisión
La guía de uso de GitHub indica abrir una pull request y solicitar a Copilot como revisor desde la sección de revisores. Después debes leer sus observaciones y valorar los cambios propuestos. El servicio está asociado a los planes de pago, con condiciones específicas para miembros de organizaciones sin licencia individual, según la documentación de disponibilidad.
Una pull request es una propuesta de cambios antes de incorporarlos a la rama principal. Un commit guarda una versión de esos cambios. No necesitas interpretar la revisión como una conversación informal: cada observación debería ayudarte a localizar un problema, entender su efecto y comprobar una solución.
Un ejemplo: corregir la causa
Caso propuesto por Texploto
Imagina que una función divide un total por el número de elementos. Copilot señala que la lista puede estar vacía. Añades una comprobación, subes el cambio y pides otra revisión.
Si el hilo se cierra, revisa todavía qué devuelve la función con una lista vacía, quién consume ese valor y si hay una prueba que refleje el comportamiento deseado. Devolver cero puede evitar una excepción y aun así introducir una interpretación equivocada para el resto de la aplicación.
Este ejemplo no procede de una prueba nuestra del producto. Sirve para distinguir tres cosas: que el aviso deje de aparecer, que el código ejecute sin error y que la solución cumpla el requisito.
Una rutina breve antes de integrar
- Lee el cambio completo, incluidas las líneas que no recibieron comentarios.
- Pide evidencia concreta para cada fallo importante: entrada, comportamiento observado y consecuencia.
- Comprueba que la corrección tiene una prueba pertinente y revisa su resultado.
- Lee los hilos cerrados que afectaban a permisos, datos o comportamiento central.
GitHub permite configurar aprobaciones de Copilot, actualmente en vista previa. Por defecto sus revisiones no cuentan como aprobaciones obligatorias. Cerrar un comentario y aprobar una pull request son decisiones distintas; comprueba qué reglas tiene tu repositorio.
Para entender antes la estructura de un proyecto, puedes apoyarte en nuestra guía de Archify. Un mapa orienta la lectura; la evidencia de la revisión debe seguir estando en el código y en sus comprobaciones.
Documentación consultada el 14/09/2026. No hemos ejecutado una revisión funcional con estas novedades.
