El número de PRAssistant de Microsoft es real, pero mide caudal, no calidad

Microsoft ha publicado una cifra poco habitual en este terreno: un dato de rendimiento propio y atribuido a una herramienta interna de revisión de código con IA. PRAssistant corrió sobre 5.000 repositorios de la casa, cubrió más del 90% de los pull requests y llegó a procesar más de 600.000 al mes, con una mejora mediana del 10-20% en el tiempo de finalización. Después salió al exterior convertido en la revisión de código de GitHub Copilot.

Conviene detenerse en cómo está construida esa frase, porque "mejora mediana del tiempo de finalización del PR" es una métrica de caudal, no de calidad. La revisión de código funciona como una cola: alguien coge el PR, lo lee y lo fusiona. Una automatización que filtra los problemas obvios y desatasca los merges triviales mueve más rápido a una mayoría estricta de esa cola, y eso es justo lo que refleja una mejora en la mediana. Lo que no dice es si el código que entra es mejor.

Un revisor que se fía del bot y fusiona antes, sobre código que nadie ha razonado, consigue un merge más rápido y un producto peor. La métrica no distingue un caso del otro. No es una crítica a Microsoft: es un aviso para quien cite ese 10-20% como prueba de que la herramienta encuentra más bugs. Cambia cuándo empieza el trabajo, no necesariamente qué acaba entrando en la rama principal.

Una escala que también explica el resultado

El otro dato que merece atención es el volumen. Cubrir más del 90% de los PR y 600.000 al mes significa que el sistema se ejecutó solo donde podía seguir el ritmo. PRAssistant puede permitirse ser selectivo con lo que revisa porque el volumen de revisión de Microsoft es enorme y la automatización es aburrida: gana por estar disponible en casi todo.

Cuando eso se convirtió en la revisión de Copilot, el número pasó a leerse mejor como un suelo. Lo que la herramienta hizo con el volumen de Microsoft no marca el techo de lo que debería esperar un equipo más pequeño, y presentarlo como una expectativa replicable es un error de lectura bastante común.

Qué medir en tu equipo

Si estáis a punto de adoptar una de estas herramientas, la costumbre útil es separar caudal y calidad de señal. Mirad el tiempo mediano hasta el merge en vuestro lado, sí. Pero mirad también cuántos PR ya fusionados volvieron con una regresión o con un arreglo adicional seis semanas después. Una métrica habla de velocidad; la otra, de si esa velocidad es real. Las dos son fáciles de instrumentar, y ninguna debería venderse como argumento si solo se enseña una.