Un artículo en arXiv recalcula el estudio de METR: la IA ralentizó a los desarrolladores un 19–24%

¿Cuánto tiempo ahorra realmente un asistente de IA? Solomon Shalom Lijo sostiene, en un trabajo de 18 páginas publicado en arXiv (cs.AI, 23 de octubre de 2026), que la lectura del cronómetro no sirve para responder a esa pregunta.

El autor recalculó los datos del estudio de METR, estimó el techo de aceleración de GPT-5 en el benchmark GDPval y montó su propio experimento con revisores de IA. En las mismas 246 tareas, los desarrolladores resultaron ser un 19% o un 24% más lentos, según qué se considere exactamente el efecto. Y cuando se le dijo al revisor que el borrador lo escribía un modelo casi sin errores, comprobó menos y dejó pasar una cifra incorrecta en el 22,5% de los briefs.

Cronómetro frente a libro contable

El autor distingue dos interpretaciones. En la del «cronómetro», el tiempo ahorrado es el que registró el reloj. En la del «libro contable», es una magnitud contrafactual: cuánto habría tardado el trabajo sin IA. Esa cifra debe leerse junto a los errores que el trabajo dejó pasar. Lijo defiende la segunda.

Para ello introduce un par de magnitudes que no dependen de un modelo concreto: el tiempo ahorrado y los defectos adicionales no detectados. Con ellas se obtiene un único número para la toma de decisiones: el umbral de equilibrio del coste de un defecto. Si un error en su proceso cuesta más que ese umbral, la aceleración no compensa.

El modelo base de revisión arroja tres conclusiones. Mientras el modelo no sea lo bastante bueno como para prescindir por completo de la revisión, la proporción de defectos no detectados de un trabajador calibrado no depende de la calidad del modelo. El tiempo de revisión crece con el logaritmo de la tasa de errores del modelo. Y el exceso de confianza compra minutos en el reloj a costa de aún más minutos en el cómputo global.

El recálculo de METR y el techo de GDPval

Lijo reprodujo el estudio de METR sobre desarrolladores a partir de datos públicos. El resultado depende de qué magnitud se elija estimar:

• ralentización del 19% o del 24% en las mismas 246 tareas, según el estimand;
• ralentización del 34% si no se corrige el desequilibrio aleatorio entre grupos;
• la IA ayudó en algún punto entre el 3–82% de las tareas. Un intervalo tan amplio muestra que el estudio aleatorizado responde a la pregunta sobre el efecto medio y dice casi nada sobre el efecto en una tarea concreta.

En el proceso de GDPval, donde se verifica cada resultado, el tiempo de revisión por sí solo limita la aceleración de GPT-5 a 3,6x. Los consultores que no pertenecían a la frontera trabajaron más rápido, pero se equivocaron con más frecuencia. Aquí el autor fija límites explícitos en lugar de importar supuestos puntuales.

Revisores que creyeron al autor

Lijo contrastó dos predicciones de su modelo en un pequeño experimento con registro previo. Revisores de IA comprobaron borradores, también generados por IA, de briefs de un mismo tipo, elaborados a partir de documentos de la SEC presentados después de la recopilación de los datos de entrenamiento de los modelos, de modo que la memoria del modelo no podía sugerir la respuesta.

Cuando se informaba al revisor de la tasa real de errores del autor, comprobaba más a medida que esta aumentaba. Pero lo hacía con una lógica de «todo o nada»: el cambio se producía cerca del punto en que se equilibraban los costes en su prompt. No hubo un ajuste gradual del esfuerzo.

Cuando se le decía que el autor se equivocaba diez veces menos de lo que ocurría en realidad, comprobaba 7 de cada 9 cifras menos. Una cifra incorrecta pasaba en el 22,5% de los briefs, mientras que sin ese engaño no pasaba en ninguno. El trabajo se hacía más rápido y peor, y todo ello por la reducción del esfuerzo.

Qué cambiar en las métricas de adopción

Si evalúa un asistente de IA en su equipo, una sola métrica de velocidad no basta. Hacen falta al menos tres cifras:

• el tiempo ahorrado respecto al proceso contrafactual sin IA;
• el número de defectos adicionales no detectados por unidad de trabajo;
• el coste de un defecto en su proceso y su comparación con el umbral de equilibrio.

Conviene vigilar aparte lo que se comunica a los revisores sobre la fiabilidad del modelo. Una estimación inflada de la calidad reduce el volumen de revisión más rápido de lo que el modelo mejora en realidad. En el precio de los tokens y de las horas de ingeniería, eso parece un ahorro, hasta que el defecto llega al cliente. El autor publicó el código y los datos en Zenodo, por lo que los cálculos se pueden repetir con sus propios registros.