Un asistente de programación con IA puede ayudarle a terminar más trabajo, pero un titular de productividad no puede decirle cuántas horas ahorrará. Los experimentos de campo publicados han encontrado tanto más trabajo terminado como tareas que llevan más tiempo. Estudiaron a personas, herramientas y resultados distintos.
La pregunta útil es adónde se va su jornada: a escribir código, a entender un repositorio, a esperar a un agente o a revisar sus cambios. Dos proyectos de investigación, seguidos por las actualizaciones de METR en 2026, muestran por qué importan esas distinciones. Ninguno ofrece un porcentaje medido para los agentes de programación disponibles en octubre de 2026.
Dos experimentos, dos medidas distintas
Cui y sus colegas estudiaron los primeros despliegues de GitHub Copilot en tres empresas. Becker y sus colegas, en METR, estudiaron a desarrolladores experimentados de código abierto que trabajaban en repositorios que ya conocían. Son proyectos de investigación distintos; las cifras de abajo son los hallazgos que reportaron.
Experimentos de campo históricos. Un aumento del trabajo terminado no es la misma métrica que un cambio en el tiempo de la tarea.
| Estudio y contexto | Qué se midió | Resultado reportado | Límite principal |
|---|---|---|---|
| Cui et al.: ensayos de Copilot en empresas iniciados en 2022–2023 | Pull requests terminadas por semana | 26.08% más; error estándar de 10.3 puntos porcentuales | Una estimación ajustada por la adopción, no una medición de minutos ahorrados |
| METR: repositorios de código abierto conocidos, febrero–junio de 2025 | Tiempo de implementación por tarea | 19% más largo; intervalo de confianza reportado de 2%–39% más largo | Una muestra pequeña y experimentada que usaba las herramientas de ese período |
Más pull requests no significa el mismo porcentaje menos de tiempo
El artículo de febrero de 2025 de Cui y sus colegas combina tres ensayos realizados por las propias empresas en Microsoft, Accenture y una firma anónima del Fortune 100, con una muestra combinada de 4,867 desarrolladores. Los ensayos comenzaron en septiembre de 2022, julio de 2023 y el otoño de 2023, respectivamente. La herramienta ofrecía completados de código dentro del editor; no fue una prueba de los agentes autónomos de programación de hoy. No se revelan las versiones exactas del modelo en el backend ni los presupuestos de tokens.
Las empresas aleatorizaron el acceso o el momento de la invitación. Algunos desarrolladores que recibieron acceso no adoptaron Copilot. Por eso los autores usaron la asignación aleatoria para estimar el efecto de la adopción, dando más peso a los períodos en que la adopción difería más entre grupos y combinando después las estimaciones de cada empresa según su precisión. El resultado de la tabla es esta estimación ajustada, no la diferencia en bruto entre todas las personas a las que se ofreció una licencia y todas las del grupo de control. La estimación de cada empresa es incierta.
Un pull request terminado es una unidad de trabajo útil dentro de las convenciones de un equipo. No dice cuánto duró la tarea, qué tamaño tuvo el cambio ni cuánto valor entregó. Dividir una función en más solicitudes elevaría el recuento sin mejorar necesariamente la entrega. Esa es una razón para acompañar los recuentos de producción con tiempo y calidad al revisar el propio flujo de trabajo, en lugar de traducir el porcentaje del estudio a horas ahorradas.
El código conocido puede hacer que el costo de la revisión importe más
METR aleatorizó si se permitía la IA en cada una de 246 tareas reales completadas por 16 desarrolladores experimentados. Trabajaron en repositorios grandes que ya conocían y, durante febrero–junio de 2025, usaron sobre todo Cursor Pro con Claude 3.5 o 3.7 Sonnet. Los desarrolladores reportaron su tiempo de implementación y grabaron sus pantallas. La estimación de tiempo que encabeza el resultado se ajusta en función de las previsiones de dificultad de la tarea hechas antes de la aleatorización.
Antes de trabajar, los desarrolladores esperaban que la IA redujera su tiempo en un 24%. Después, seguían pensando que los había hecho cerca de un 20% más rápidos. Esas creencias diferían de la ralentización medida. El análisis de METR señala factores como la familiaridad con el repositorio, el contexto ausente, las sugerencias poco fiables y el tiempo dedicado a formular indicaciones, esperar y revisar.
En una corrección conocida, un cambio que parece plausible puede necesitar aun así una comprobación considerable frente a las convenciones locales, las pruebas y la documentación. La pregunta práctica es si la sugerencia elimina más trabajo del que esa comprobación añade. El estudio no establece que la mayoría de los desarrolladores se ralenticen, ni que las herramientas posteriores se comporten del mismo modo. Su escenario estrecho es útil precisamente porque identifica una situación que conviene examinar, en lugar de ofrecer un veredicto universal.
El seguimiento de 2026 no demuestra que el resultado se haya invertido
METR inició una continuación en agosto de 2025 y la reportó el 24 de febrero de 2026. Incluyó a 10 desarrolladores que volvían y a 47 participantes nuevos. La estimación puntual de quienes volvían fue un 18% menos de tiempo, con un intervalo que va de un 38% menos a un 9% más. La estimación de los participantes nuevos fue un 4% menos de tiempo, de un 15% menos a un 9% más. Ambos intervalos incluyen la ausencia de cambio y cierta ralentización.
Los autores también advirtieron que los datos eran una señal poco fiable del efecto actual. Cada vez más personas rechazaban participar porque no querían trabajar sin IA, y los participantes retuvieron algunas tareas por la misma razón. La paga por participar bajó de $150 a $50 por hora, lo que pudo cambiar quién se unía. Ejecutar varios agentes mientras se hacía otro trabajo también dificultó interpretar los registros de tiempo de las tareas.
Esas limitaciones importan más que elegir la estimación puntual que apoye la propia opinión. El seguimiento sugiere que las condiciones estaban cambiando, pero no establece de forma fiable la magnitud de una aceleración actual. Proviene del mismo grupo de investigación y, en parte, de los mismos participantes, así que no es una replicación independiente. Tampoco asigna un porcentaje de productividad a una versión actual concreta de Claude Code o Codex.
La encuesta más reciente mide lo que las personas creen
El informe de METR de mayo de 2026 encuestó a 349 trabajadores técnicos durante febrero–abril, incluidos 87 ingenieros de software. Los encuestados reportaron un cambio mediano de 1.4–2x en el valor de su trabajo según la formulación de las preguntas, y un cambio mediano de 3x en la velocidad. Son estimaciones autorreportadas de una muestra de conveniencia, no resultados experimentales cronometrados. Los autores cuestionan de forma explícita hasta qué punto las ganancias reportadas coinciden con la realidad.
El valor y la velocidad también pueden divergir. Producir rápido un panel adicional no hace necesariamente más valioso el proyecto de fondo. A la inversa, un asistente podría hacer posible un trabajo que merezca la pena y que de otro modo no se intentaría. La encuesta pone estas posibilidades a la vista; no confirma de forma causal ninguno de los dos experimentos anteriores.
Lleve un registro pequeño del trabajo que de verdad acepta
Empiece por una clase recurrente de tareas, como correcciones pequeñas en un repositorio. Decida qué cuenta como terminado antes de registrar resultados. Un parche generado por sí solo es un resultado distinto de un cambio probado, revisado y aceptado por el equipo.
Lo que sigue es un registro propuesto para su propio trabajo, no un resultado experimental nuevo. Ayuda a ver adónde va el tiempo y qué cambios siguen siendo útiles.
- Registre la tarea y sus criterios de finalización, incluidas las pruebas y la revisión.
- Separe los minutos humanos activos del tiempo transcurrido y del tiempo de espera de un agente; anote el trabajo que se solapa.
- Incluya la revisión y el retrabajo, y después registre el resultado aceptado y los defectos posteriores.
- Anote la herramienta, el modelo o la versión cuando estén disponibles, y cualquier cambio en el flujo de trabajo.
Use ese registro para preguntarse si unos cambios aceptados y comparables exigen menos minutos humanos sin que empeore el registro de defectos. Un registro personal pequeño no puede establecer causalidad, y el aprendizaje o la selección de tareas pueden cambiar el resultado. Aun así, ofrece una base mejor para ajustar su forma de trabajar que tomar prestado un porcentaje medido en el trabajo de otra persona.
Fuentes
Claude Radar sintetizó los hallazgos publicados por los autores y no repitió los experimentos ni reanalizó los datos de los participantes. Fuentes comprobadas el 3 de octubre de 2026: el artículo de febrero de 2025 de Cui, Demirer, Jaffe, Musolff, Peng y Salz, y el resumen de Microsoft Research; el artículo de METR de julio de 2025 de Becker, Rush, Barnes y Rein; y las actualizaciones de METR de febrero y mayo de 2026. Los ensayos en empresas incluyen coautores empleados por Microsoft. Un ensayo anterior de Accenture, abandonado y sin datos de uso, queda fuera de la muestra del resultado que encabeza el estudio. Los artículos y sus páginas de resumen no son replicaciones distintas. Estos experimentos históricos y los autorreportes posteriores no miden las herramientas de octubre de 2026.
- Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity - METR
- We are Changing our Developer Productivity Experiment Design - METR
- Measuring the Self-Reported Impact of Early-2026 AI on Technical Worker Productivity - METR
- The Effects of Generative AI on High-Skilled Work: Evidence from Three Field Experiments with Software Developers - Microsoft Research
- Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity
- economics.mit.edu: Draft Copilot Experiments.Pdf