Reconteo del experimento METR: en tareas complejas y revisiones, los desarrolladores con IA pierden un 24% de horas

En 2025, el centro de investigación independiente METR midió el trabajo de 16 desarrolladores experimentados de software de código abierto en 246 tareas reales de sus propios repositorios: con asistentes de IA, el ticket típico se cerraba un 19% más lento que trabajando a mano. El investigador independiente Solomon Shalom Lijo, en su artículo "Counting the Bandages: On measuring the time that AI saves" (publicado en arXiv el 23 de octubre de 2026), recalculó a partir de los registros abiertos de METR el gasto total de horas del equipo. Teniendo en cuenta los prolongados atascos en las tareas complejas, los desarrolladores con IA perdieron ya un 24% del tiempo laboral (y, sin ajustar por el tamaño inicial de las tareas, un 34%), y corregir las observaciones tras la revisión de código tomaba en promedio 14,9 minutos por ticket frente a 9,7 minutos sin la red neuronal.

A continuación, el autor analizó el benchmark GDPval de OpenAI y, en 540 sesiones de Claude Code, mostró por qué detener el cronómetro en el momento de entregar el borrador no tiene sentido: los minutos ganados en la generación se traducen en errores pasados por alto y horas de reelaboración.

De dónde salen el 19%, el 24% y el 34% en los mismos registros

Lijo reprodujo los cálculos a partir del repositorio público de METR y demostró que las mismas 246 tareas cerradas arrojan tres cifras distintas según cómo se calcule el tiempo del equipo:

• Un 19% más de tiempo resulta de la media geométrica de los logaritmos, cifra que los autores de METR destacaron en su titular. Refleja el desplazamiento típico en una tarea individual.
• Un 24% más de tiempo surge si se dividen todas las horas realmente gastadas con IA entre las horas sin IA. Con la red neuronal, la dispersión del tiempo es notablemente mayor: cuando el programador se atasca en iteraciones fallidas de prompting en un ticket grande, esas colas de varias horas consumen el fondo total de tiempo con más fuerza de lo que sugiere la media logarítmica.
• Un 34% más de tiempo muestran las horas brutas sin ajustar por el sesgo inicial de la muestra. En el sorteo, al grupo con IA le tocaron por azar tickets más grandes: antes de empezar a trabajar, los propios programadores los estimaban en promedio en 116 minutos frente a 106 minutos en el grupo de control.
• Las correcciones tras la revisión de código se midieron en 230 de las 246 tareas: retrabajar el código devuelto por el revisor con IA requería 14,9 minutos frente a 9,7 minutos a mano. Al mismo tiempo, los límites estadísticos de Makarov sobre esos mismos datos dejan un rango amplio: la IA realmente aceleró el trabajo en algún punto entre el 2,6% y el 82,1% de las tareas individuales. Un único promedio oculta en qué tickets la herramienta ahorra horas y en cuáles las hunde.

Por qué la aceleración de 100 veces de GPT-5 se contrae a 1,1–3,6 veces

Hace cien años, el ingeniero Frank Gilbreth intentó afeitarse con dos navajas a la vez: ahorró 44 segundos frente al espejo, pero gastó dos minutos pegándose tiritas en los cortes. Los benchmarks modernos de IA repiten el mismo error cuando excluyen de la medición la verificación del resultado.

Un ejemplo claro es el test aplicado GDPval de OpenAI. En el anuncio, la compañía afirmaba que los modelos insignia resuelven las tareas de especialistas de la industria unas 100 veces más rápido y más barato: GPT-5 genera una respuesta en 4,5 minutos frente a 404 minutos de trabajo manual experto. Pero dentro del propio artículo científico de GDPval hay un circuito de trabajo con aceptación obligatoria de cada respuesta:

• leer y revisar un borrador por parte de un especialista humano toma 109 minutos (27% del tiempo total de trabajo manual);
• por la ley de Amdahl, incluso con un modelo sin errores, la aceleración de todo el proceso se topa con un tope de `404 / (4,5 + 109) = 3,56x`, es decir, un máximo de 3,6 veces;
• las respuestas de GPT-5 superaron a las respuestas expertas solo en el 39% de las tareas, por lo que, teniendo en cuenta la reelaboración de los borradores débiles, los propios autores del artículo GDPval estiman la aceleración real en apenas 1,12–1,39 veces.

La misma disyuntiva se observa en el experimento de campo con consultores de negocios (Dell'Acqua et al., 2026) en tareas fuera de la zona confiable del modelo. Con GPT-4, los participantes entregaban la solución en 26,2 minutos en lugar de 37,7 minutos del grupo de control, pero la proporción de respuestas correctas caía del 84,5% al 60,0%. Según la fórmula del umbral de rentabilidad del defecto que introduce Lijo, los 11,5 minutos ganados solo se amortizan si detectar y corregir un error que llega al cliente cuesta menos de 47 minutos de trabajo del consultor.

Experimento con 540 sesiones de

Claude Code: cómo la confianza excesiva desactiva la revisión

Para medir en la práctica cómo la reputación del autor del borrador afecta la profundidad de la revisión, Lijo ejecutó una serie de pruebas controladas con agentes de IA. La base fueron informes financieros trimestrales de empresas estadounidenses según el formulario 10-Q de la base de datos de la Comisión de Bolsa y Valores de EE. UU. (SEC), correspondientes al período hasta el 30 de junio de 2026. Los informes se publicaron después del 1 de julio de 2026, posterior al corte de entrenamiento de los modelos, por lo que la red neuronal no podía recordar las cifras de memoria.

El agente autor (`claude-haiku-5-5`) armaba un resumen con 9 indicadores (ingresos, beneficio neto y margen operativo de tres empresas), en el que en el 30% de los casos se introducía deliberadamente un error: una línea ajena, un trimestre antiguo o cifras intercambiadas. Después, el documento era revisado por un agente revisor (`claude-sonnet-5-5` en una sesión aislada de Claude Code), que contaba con una herramienta de cotejo línea por línea con la fuente original de la SEC. Según las condiciones del prompt, verificar un número costaba 3 minutos (las 9 líneas completas, 27 minutos), y un error que llegara al cliente sin detectar se penalizaba con 10 horas (600 minutos).

El cotejo exhaustivo se amortizaba cuando la tasa de error superaba el 4,5%.

El experimento reveló tres efectos concretos:

• Modo "todo o nada". Cuando al revisor se le informaba honestamente de una proporción alta de errores (entre el 10% y el 30%), en las 40 pruebas pareadas cotejó las 9 líneas y corrigió el 100% de los errores. Pero no hubo una verificación selectiva gradual: en torno al umbral del 4,5%, el modelo cambiaba abruptamente entre el cotejo completo y cero consultas a la fuente.
• Ceguera por subestimación del error. En los mismos borradores con un 30% real de errores, al revisor se le dijo en el prompt que el autor se equivocaba diez veces menos (en el 3% de los casos). En 29 de 40 sesiones, `Sonnet 5.5` no abrió en absoluto el informe original, verificando en promedio solo 2 de los 9 números. Se ahorraron 21 minutos en la revisión, pero la cifra falsa llegó al informe del cliente en el 22,5% de los resúmenes en lugar de en ninguno; la pérdida neta ascendió a 135 minutos por documento.
• La inutilidad de las advertencias en el prompt. En una rama aparte, a la cifra "3% de error" se añadió una exigencia explícita de considerar esa estimación como no verificada. En 26 de 40 ejecuciones, el modelo admitía en su razonamiento que no se podía confiar en esa cifra y, de todos modos, entregaba el resumen sin una sola verificación. El anclaje numérico pesó más que la advertencia textual.

Cómo medir la utilidad de la IA en un equipo sin autoengañarse

En lugar de un único cronómetro "hasta el primer commit", el autor propone medir tres indicadores al implementar herramientas de IA (el código y los registros brutos están disponibles en GitHub, en el repositorio `tsb-bench`, y en Zenodo):

1. Cuántas horas en total gasta el equipo en la tarea completa, incluida la revisión de código y la reelaboración de los PR devueltos. 2. Cuántos errores adicionales se dejan pasar al resultado final, según una aceptación a ciegas en grupos con y sin IA. 3. A qué costo del error la aceleración deja de ser rentable, y cuándo se puede desactivar el control manual: para eliminar con un 95% de confianza la revisión obligatoria con una tasa de error admisible del 0,85%, la herramienta debe superar primero 352 tareas verificadas consecutivas sin un solo fallo.