La medición independiente
Hay una medición de marzo de 2026 que apunta a propósito a fallos reales y no al estilo: 174 pull requests verificados, y entre sus métricas está también la relación señal-ruido.
| Configuración | Exhaustividad | Precisión | Relación señal-ruido |
|---|---|---|---|
| Una sola pasada, modelo potente | 27,01 % | 3,56 % | 5,11 |
| Una sola pasada, modelo pequeño | 18,39 % | 3,51 % | 2,89 |
| Con autorreflexión, modelo potente | 32,76 % | 5,10 % | 1,95 |
| Con autorreflexión, modelo pequeño | 27,59 % | 3,19 % | 0,91 |
Sácale dos conclusiones.
La primera: encuentra entre el 18 % y el 33 % de los fallos reales, y de lo que dice, es real entre el 3 % y el 5 %. Uno de cada veinte comentarios.
La segunda, que pesa más: el agent con autorreflexión mejoró la exhaustividad —encontró más fallos reales—, pero, en palabras de los autores, «al mismo tiempo paga un precio muy alto en integridad de la señal». En el peor caso, la relación señal-ruido es de 0,91: hay más ruido que señal.
Esto es lo más cercano que tenemos a una medición del review fatigue. Al revisor no lo agota que haya muchos fallos, sino que haya muchas falsas alarmas.
(Un límite importante: esta medición estudia paradigmas generales de modelos y agents, no los productos comerciales concretos.)
La medición del fabricante: revisada por pares, y dice otra cosa
Hay otra cifra que merece la misma seriedad: un gran fabricante de herramientas para desarrolladores publicó una evaluación de un año sobre su propia plataforma, y el estudio salió en actas de congreso con revisión por pares.
- El 38,7 % de los comentarios generados provocó un cambio de código en los commits siguientes.
- El tiempo de ciclo de los PR se acortó un 30,8 %.
- Hicieron falta un 35,6 % menos de comentarios escritos por personas.
Visto así parece justo lo contrario de lo anterior. Pues no lo es.
Por qué las dos cifras no se contradicen
Para esto también hay medición, y es la parte metodológica más importante del post.
Un estudio de 2026 revisó 2.604 comentarios generados por bots que ingenieros reales habían etiquetado como «corregido» o «no lo vamos a corregir». Después comprobó cuánto coincidía con esas etiquetas una evaluación automatizada hecha con un modelo: una coincidencia de entre 0,44 y 0,62.
La explicación, literal: las decisiones de los desarrolladores «no reflejan solo la calidad del comentario, sino también las restricciones contextuales». Según las entrevistas, la forma de etiquetar está «muy influida por la presión del flujo de trabajo y por las restricciones organizativas».
En cristiano: que alguien haya corregido un comentario no es lo mismo que que el comentario fuera correcto. Un desarrollador con prisa corrige el comentario fácil y deja pasar el difícil, al margen de cuál importaba más.
Por eso el 38,7 % y el 3,2 % no son la misma métrica. Una mide cuánto mueve el bot el comportamiento; la otra, cuánta razón tiene.
Cuánto cuesta
Por precios de tarifa, hoy el mercado está así:
- Hay nivel gratuito en casi todos los proveedores, normalmente con un número limitado de revisiones, y un plan gratuito aparte para proyectos de código abierto.
- Los planes de pago van más o menos de 20 a 72 dólares por persona y mes con pago anual; también hay modelos de consumo basados en créditos.
- Nivel empresarial: autoalojamiento, instancia dedicada o despliegue local, gestión de permisos, registro de auditoría; para esto rara vez publican precio.
- También hay alternativa de código abierto, ejecutada con tu propia clave de modelo.
Pero el precio no es donde se decide esto.
La pregunta que decide de verdad: qué ve el bot y si entrena con ello
Aquí está la utilidad práctica del post, porque los valores por defecto de cada fabricante no son iguales, y se diferencian en el contrato.
La documentación de un proveedor dice literalmente que «nunca usa el código del cliente para entrenar», sea cual sea la configuración de retención de datos. En esa misma página, en cambio, también deja escrito que comparte el código con los proveedores de modelos, exclusivamente para hacer la revisión.
Otro proveedor de precio parecido escribe esto: que «puede agregar y anonimizar los datos del cliente… para entrenar y mejorar algoritmos y modelos de inteligencia artificial», y añade que se puede desactivar en los ajustes de la cuenta.
El mismo nivel de precio, dos valores por defecto opuestos. Con código cerrado, esa diferencia es la que decide, no la lista de funciones.
Lo que conviene preguntar antes de adoptar uno:
1. ¿Entrena con mi código? ¿Por defecto SÍ o NO?
Y si es que sí, ¿dónde lo desactivo?
2. ¿A qué proveedor de modelos sale el código, y en qué
condiciones?
3. ¿Cuánto lo guardan? ¿Qué pasa si me doy de baja?
4. ¿Hay autoalojamiento / clave de modelo propia /
despliegue local? ¿Desde qué plan?
5. ¿Dónde está el dato geográficamente?
6. ¿Hay certificación de seguridad independiente, y se
puede pedir el informe?
Cómo probarlo tú mismo: con veinte PR
Este es el único método que responde para tu base de código. Dos horas de trabajo.
1. ELIGE 20 PR YA MERGEADOS del último medio año.
De esos en los que SABES cómo acabaron: cuál generó
un ticket de fallo, cuál necesitó un arreglo posterior.
2. PÁSALE EL BOT, a ciegas - el revisor no debe ver
sus comentarios de antemano.
3. CUENTA TRES COSAS:
- cuántos fallos REALES encontró de los que hoy
sabes que estaban ahí -> exhaustividad
- qué porcentaje de sus comentarios era real
-> precisión
- cuántos comentarios eran puro ruido -> eso lo van
a sufrir tus revisores
4. COMPÁRALO con lo que tu equipo encontró igualmente.
Si el bot solo encuentra lo que encuentra la persona,
no caza fallos: quita tiempo.
5. DECIDE CON UN NÚMERO, no con la demo.
La demo siempre sale bien - con PR escogidos.
Lo que hay que reconocer
Por honestidad, tres cosas que no sabemos:
- No hay medición independiente de precisión y exhaustividad de los bots comerciales concretos sobre pull requests reales. El estudio independiente examina paradigmas, no productos; las comparativas de los fabricantes son material de marketing.
- No hay medición independiente de si la revisión automática reduce la proporción de fallos que se escapan. El estudio del fabricante mide tiempo de ciclo y comentarios que provocaron un cambio de código, no tasa de fallos.
- El review fatigue no está cuantificado en la literatura. El indicador más cercano es la relación señal-ruido de arriba.
Malentendidos habituales
- «El bot acierta el 38 % de los comentarios.» Eso mide cuántos comentarios provocaron un cambio de código, no cuántos eran correctos. La medición de precisión da entre un 3 % y un 5 %.
- «Cuantos más fallos encuentre, mejor.» La configuración con autorreflexión encontró más fallos reales, pero por el camino la relación señal-ruido cayó a 0,91: más ruido que señal.
- «Es seguro porque lo pago.» De dos proveedores de precio parecido, uno nunca entrena con el código del cliente y el otro puede hacerlo por defecto. Se diferencian en el contrato.
- «La demo fue convincente.» La demo corre sobre PR escogidos. Veinte PR tuyos ya mergeados te dicen la verdad en dos horas.
- «Sustituye a la revisión humana.» El beneficio medido está en el tiempo de ciclo y en el número de comentarios humanos. La responsabilidad no se ha movido.
Lo que conviene llevarse
La IA en el code review no mejora la tasa de fallos, mejora el tiempo de ciclo: incluso el mejor resultado medido va de eso. Lo que ganas: primera respuesta más rápida y menos comentarios humanos pequeños. Lo que no ganas: garantía de que los fallos reales estén cubiertos, porque de los fallos reales solo caza entre un tercio y un quinto.
Que la adopción se decida por dos cosas: qué dice el contrato sobre tus datos y qué muestran veinte PR tuyos ya mergeados.
Qué merece la pena repasar a mano además de esto lo detalla el post revisar el código generado , paso a paso; y las cifras del lado de la seguridad las recorre el post la factura de seguridad del código generado por IA , con los números.