BookinglyTech News
Software

Atlassian no publico la metrica que respalda su anuncio de Rovo Dev

La herramienta promete reducir un 45% el tiempo de revision de pull requests, pero el estudio interno carece de metodologia, baseline definida o datos de sesgo de cola.

2 min de lecturaDev.to0 vistas

Atlassian ha anunciado que Rovo Dev, su asistente de IA para revisar codigo, redujo el ciclo de tiempo de los pull requests (PR) un 45% en su uso interno y un 32% en clientes. La cifra suena atractiva para cualquier equipo de desarrollo, pero el comunicado de prensa no incluye el metodo, la definicion de la linea base ni el tamaño de la muestra utilizada para obtenerla. Es un dato sin contexto, y ese es precisamente el problema cuando los equipos intentan validar la herramienta.

La trampa del tiempo de cola

El primer punto a revisar es contra que se mide ese 45%. Si la referencia es el tiempo que un pull request se quedaba esperando en una cola por falta de revisores humanos, entonces cualquier herramienta que procese en minutos dara una mejora estadistica enorme, independientemente de la calidad técnica de la revision. Al eliminar la espera administrativa, la métrica sube artificialmente. Una vez que la cola se vacia, ese porcentaje de mejora deja de tener sentido operativo.

Ademas, un promedio general oculta la realidad del trabajo dificil. Un modelo de IA suele acortar rapidamente los casos faciles: diffs pequenos, cambios de riesgo bajo y bien documentados que un humano ya iba a aprobar. Las revisiones caras, aquellas con riesgo de arquitectura o cambios profundos, siguen requiriendo tiempo humano y son las que dominan la cola de larga duracion. Un equipo que solo mira la media podria creer que todo es rapido, mientras que un informe separado de la mediana (p50) y el percentil 95 (p95) mostraria donde esta realmente la ganancia y donde se estan acumulando los cuellos de botella.

Factores de sesgo

Tampoco se descarta que el resultado se deba a factores externos no controlados. Si durante el periodo de prueba cambio el equipo de revisores, o si la cultura de revision del equipo se volvio mas laxa simultaneamente al despliegue de la herramienta, entonces la mejora se atribuye erroneamente al software. Sin un grupo de control o un periodo previo estable, es imposible aislar el impacto real de Rovo Dev.

Para validar este tipo de anuncios, la prueba es sencilla y reproducible en un dia. Se debe seleccionar una ventana temporal fija, preferiblemente de dos semanas, manteniendo el pool de revisores inalterable. Los resultados se deben desglosar por tamaño del PR y nivel de riesgo, reportando mediana y p95, nunca solo la media. Y, fundamental, definir claramente que es el "tiempo de revision" antes de aplicar la herramienta para poder comparar con la misma definicion despues.

Cuando un proveedor entrega un porcentaje unico sin mostrar el mecanismo de medida, se trata de una declaracion de intenciones, no de un resultado tecnico comprobable. Los equipos de infraestructura y desarrollo pueden replicar estas métricas en sus propios repositorios rapidamente. Es mas eficiente verificarlo con datos propios que esperar a que el fabricante detalle su metodologia.