Copilot Code Review ya se limpia solo: auto-resolución y análisis más inteligente en tus PR

Si trabajas a diario con pull requests, como espero que estés haciendo, esta mejora de GitHub Copilot toca una fricción muy concreta y muy real: esos comentarios automáticos que al principio ayudan, pero que después se quedan flotando en la conversación aunque ya hayas corregido el problema. Según el anuncio de auto-resolution and analysis updates in Copilot code review, GitHub Copilot ahora puede resolver sus propios comentarios cuando detecta que ya los has abordado y además genera mensajes de commit más inteligentes cuando aplicas sus sugerencias. Esto no es un retoque cosmético, es un ajuste pequeño pero con un impacto muy sustancial y significativo en el día a día de esta era en la que trabajamos los humanos codo a codo con la IA.

Porque el problema nunca ha sido sólo que un bot comente. El problema aparece cuando comenta, tú actúas y el PR sigue pareciendo un tablón de notas viejas. Ahí es donde una automatización deja de ayudar y empieza a estorbar. Si la IA quiere quedarse en el flujo de revisión, tiene que saber cerrar el bucle, no sólo abrirlo. O en otras palabras, que si eres parte del problema, debes ser parte de la solución o la actuación que lo solventa.

Además, esto encaja bastante bien con el recorrido que GitHub ya había iniciado cuando llevó Copilot code review a Visual Studio y JetBrains. Es decir: no hablamos sólo del comentario en la pull request, sino de una experiencia que intenta aparecer antes, durante y después de cada una de estas. Yo aquí me voy a quedar en GitHub y con un ejemplo muy pequeño en .NET, porque es la forma más simple de ver el antes y el después sin montar una demo de escaparate.

Qué cambia de verdad en el flujo de revisión

Hasta ahora, una de las debilidades habituales de muchas automatizaciones de code review era bastante simple: detectaban mejor de lo que remataban. Te señalaban un riesgo, tú lo corregías, realizabas el commit con mejor o peor descripción, y aun así quedaba parada sin actuación esperando un trabajo manual adicional, pero innecesario o no esperado. Había que revisar si el comentario seguía aplicando, resolver la conversación a mano o dejar una respuesta explicando que ya estaba arreglado, a veces más de una vez para disparar nuevamente el code review. No era dramático, pero sí era otra pequeña tarea mecánica más que se sentía como una promesa incumplida.

El cambio anunciado por GitHub va justo contra esa molestia. Si GitHub Copilot a través del code review abre una conversación en una PR y más tarde detecta que el nuevo commit ya aborda esa observación, la conversación puede resolverse automáticamente. Y si aplicas una sugerencia suya, el mensaje de commit deja de quedarse en algo genérico del estilo «Apply suggestion» para ser más descriptivo.

Yo aquí haría una precisión importante: esto no sustituye el criterio de nadie. Recordemos que el juicio crítico y la capacidad de contrastar el trabajo de la Inteligencia Artificial es la habilidad o softskill más importante (y tristemente la mas rara y escaza) que necesita cualquier persona en la era de la IA. Por eso, no se convierte a GitHub Copilot en aprobador del PR, ni en arquitecto, ni en revisor de negocio. Lo que hace es otra cosa, bastante más humilde y bastante más útil: quitar residuos del proceso. Y sinceramente, en revisiones con mucha actividad o de larga duración, esa limpieza vale más de lo que parece.

Antes de empezar

Para reproducirlo de punta a punta, yo usaría un entorno mínimo como este:

• Una cuenta de GitHub con acceso a GitHub Copilot y a Copilot Code Review.
• Permisos para crear ramas y abrir pull requests en un repositorio propio o de pruebas.
• Git instalado.
• .NET 10 SDK para crear y validar el proyecto de ejemplo.
• GitHub CLI gh para abrir la PR desde terminal de forma reproducible.
• Un editor como Visual Studio o VS Code si quieres comparar el flujo local con el de GitHub, especialmente ahora que Copilot code review también está disponible en Visual Studio y JetBrains.

Preparar un repositorio mínimo en .NET 10 para provocar una observación útil

La idea no es engañar a GitHub Copilot con un caso absurdo, sino darle un cambio bastante normal: código que compila, parece correcto a primera vista, pero tiene una validación demasiado débil. Voy a crear una librería pequeña con un método que divide sin validar el divisor. Es un caso muy simple y trivial, pero precisamente por eso sirve bien para comprobar si la revisión automatizada detecta algo útil.

mkdir copilot-review-lab
cd copilot-review-lab
dotnet new sln --name CopilotReviewLab
dotnet new classlib --framework net10.0 --name Pricing.Core
dotnet sln add Pricing.Core/Pricing.Core.csproj
git init
git checkout -b main

Ahora crea Pricing.Core/PriceCalculator.cs con este contenido:

namespace Pricing.Core;

public static class PriceCalculator
{
    public static decimal CalculateUnitPrice(decimal totalPrice, int quantity)
    {
        return totalPrice / quantity; // Dejo el caso frágil a propósito para que la review tenga algo concreto que señalar
    }
}

Y elimina el archivo que crea la plantilla para que el proyecto quede limpio:

rm Pricing.Core/Class1.cs
dotnet build

Si todo va bien, deberías obtener un Build succeeded sin advertencias ni errores. Después haz el primer commit y publícalo en tu repositorio remoto:

git add .
git commit -m "Create initial pricing library"
git remote add origin git@github.com:arquitectura-practica/copilot-review-lab.git
git push -u origin main

No hace falta complicarlo más. Lo importante aquí es tener una base mínima, compilable y lo bastante creíble como para que el comentario posterior de GitHubCopilot no parezca forzado.

Abrir una PR con un cambio mejorable para que Copilot revise

Ahora creo una rama de trabajo con una mejora aparentemente razonable: añadir redondeo al cálculo del precio unitario. El detalle interesante es que sigo sin validar quantity, así que el método mejora por un lado pero continúa siendo frágil por otro. Ese tipo de cambio da bastante contexto al análisis del diff.

git checkout -b feature/unit-price-rounding
cat > Pricing.Core/PriceCalculator.cs <<'EOF'
namespace Pricing.Core;

public static class PriceCalculator
{
    public static decimal CalculateUnitPrice(decimal totalPrice, int quantity)
    {
        return decimal.Round(totalPrice / quantity, 2, MidpointRounding.AwayFromZero);
    }
}
EOF

dotnet build
git add Pricing.Core/PriceCalculator.cs
git commit -m "Add rounded unit price calculation"
git push -u origin feature/unit-price-rounding

Con eso ya puedes abrir la PR desde terminal:

gh pr create \
  --base main \
  --head feature/unit-price-rounding \
  --title "Add rounded unit price calculation" \
  --body "Esta PR añade redondeo al cálculo de precio unitario para probar Copilot Code Review en un caso real y pequeño."

A partir de aquí, toca esperar a que GitHub Copilot analice la PR con Code Review. Según la actualización oficial de GitHub, también hay mejoras internas en el análisis, así que yo no me fijaría sólo en si aparece un comentario, sino en si ese comentario es accionable y suficientemente específico sobre el diff.

Lo esperable es que GitHub Copilot señale que quantity no se valida y que eso puede provocar una división por cero o aceptar valores no válidos. El texto exacto puede variar, claro, pero el sentido debería ser ese. Y aquí está una de las claves: no necesito que redacte un ensayo brillante; necesito que encuentre algo útil, concreto y corregible.

Corregir el problema y comprobar la auto-resolución

Aquí está la parte interesante de verdad. Voy a aplicar una corrección pequeña, explícita y fácil de verificar. Cuanto más clara sea la intención del cambio, más sencillo será comprobar si la conversación se resuelve sola después del push.

using System;

namespace Pricing.Core;

public static class PriceCalculator
{
    public static decimal CalculateUnitPrice(decimal totalPrice, int quantity)
    {
        ArgumentOutOfRangeException.ThrowIfNegativeOrZero(quantity); // Expresa exactamente la precondición y evita una validación manual más verbosa

        return decimal.Round(totalPrice / quantity, 2, MidpointRounding.AwayFromZero);
    }
}

Valida y publica el cambio:

dotnet build
git add Pricing.Core/PriceCalculator.cs
git commit -m "Validate quantity before division"
git push

En la PR deberías ver una de estas dos cosas: o bien la conversación de GitHub Copilot pasa automáticamente a resuelta, o bien queda marcada como abordada por el propio sistema. Ese es justamente el comportamiento que describe la mejora de auto-resolución en Copilot code review.

Para mí, aquí está el valor real. En un repositorio con bastante movimiento, esta pequeña automatización evita que el PR termine convertido en una excavación arqueológica de comentarios que ya no aplican. La limpieza del contexto también es productividad. No suena épico, pero funciona.

Aplicar una sugerencia de Copilot y observar el mensaje de commit

La otra mejora que menciona GitHub es que ahora escribe mensajes de commit más inteligentes cuando aplicas sus sugerencias de código. Y esto, otra vez, parece menor hasta que llevas unos cuantos meses revisando historiales llenos de mensajes genéricos que no cuentan nada.

No siempre vas a obtener exactamente el mismo resultado, porque depende del cliente, del diff y de cómo se aplique la sugerencia. Pero la idea que describe el anuncio oficial es clara: si aceptas una sugerencia de GitHub Copilot, el mensaje generado debería reflejar mejor qué cambio acabas de incorporar.

Un historial razonable podría terminar viéndose así:

git log --oneline -3
9f31e3a Validate quantity before division
53bb2c1 Round unit price to two decimals
f84a1d7 Create initial pricing library

Lo importante no es la cadena exacta, sino la intención. Si el historial explica mejor qué ha pasado en cada paso, revisar y entender la PR después también cuesta menos. Y sí, esto parece una tontería… hasta que te toca revisar un cambio antiguo con prisas.

Comparar el antes y el después del análisis en un repo de trabajo

Aquí conviene separar un poco el entusiasmo del marketing. GitHub habla de análisis actualizado behind the scenes, pero eso no implica que GitHub Copilot vaya a descubrir de repente una nueva categoría de errores en todos tus repositorios. Yo sería bastante más prudente con esa expectativa.

Lo que sí esperaría, y lo que me parece más valioso en la práctica, es una combinación de tres cosas: comentarios más centrados en el diff real, menos conversaciones obsoletas una vez corriges el problema y una trazabilidad mejor cuando aceptas sugerencias y se generan commits.

Si quieres medirlo con un poco de disciplina, yo haría una prueba muy simple en un repositorio real:

1. Abre una PR pequeña pero no trivial;
2. Anota cuántos comentarios de Copilot aparecen;
3. Corrige dos o tres observaciones legítimas;
4. Comprueba cuántas quedan auto-resueltas tras el siguiente push;
5. Revisa si el historial de commits cuenta mejor lo que ha cambiado.

No es una métrica o KPI (ni pretende serlo), pero sí una comprobación útil de trabajo cotidiano. Yo no evaluaría esta mejora por cuánta «magia» de IA promete, sino por cuántos clicks irrelevantes y cuánta limpieza manual te ahorra en una semana normal.

Dónde encaja esto en un flujo sano de PR

Mi recomendación aquí es muy pragmática: usa Copilot Code Review como primera capa de fricción barata. Que te señale aquellos detalles que se pudieron haber escapado durante la implementación, que te ayude a autocorregirte y que mantenga el PR algo más limpio. Después deja a las personas lo que de verdad importa: intención de diseño, contratos, impacto arquitectónico, nomenclatura, deuda técnica tolerable y riesgos de negocio.

Si además trabajas desde IDE, tiene bastante sentido aprovechar que Copilot code review ya está integrado en Visual Studio y JetBrains. Cuanto antes aparezca un comentario útil, menos retrabajo arrastras hasta la PR. Y eso, en mi experiencia, reduce tanto tiempo como fricción mental.

También me parece sensato no perder de vista el contexto operativo. GitHub sigue tocando políticas y facturación de Copilot, así que si estás valorando una adopción más amplia en equipo o empresa, yo no separaría la mejora técnica del modelo de uso, permisos y coste. Una experiencia mejor sigue formando parte de una plataforma que hay que gobernar.

Mi conclusión

Esta novedad me gusta porque ataca una molestia pequeña, frecuente y bastante poco glamurosa. No intenta venderte que la IA revisa por ti. Intenta algo más sensato: que la revisión automática se comporte de una forma más madura dentro del flujo real de desarrollo.

Si GitHub Copilot comenta y luego sabe reconocer que ya lo has arreglado, el PR se parece más a una conversación útil y menos a un buzón de avisos acumulados. En resumen: menos ruido, mejor cierre del feedback y commits más comprensibles cuando aceptas sugerencias.

Si ya usas GitHub Copilot en revisión, yo probaría esta mejora hoy mismo en un repositorio de laboratorio como el de este artículo. Y si todavía no lo usas, este tipo de detalle es precisamente lo que a mí me hace tomármelo en serio para flujos reales, no sólo para demos bonitas.