Es fin de trimestre y el equipo de desarrollo hace su retrospectiva. Usa agentes de código desde el trimestre pasado. Todos dicen lo mismo: vamos más rápido. ¿Hace falta medirlo?
Sí, porque lo que el equipo siente no mide la velocidad. METR, un laboratorio que evalúa modelos de IA, le preguntó a 349 trabajadores técnicos en 2026 (la prueba 102). La mediana dijo trabajar 3 veces más rápido con IA. METR puso una advertencia junto al resultado: “Importantly, survey results are not necessarily grounded in reality.” La apoya en un dato propio. En su estudio aleatorizado de 2025, la gente sobreestimó su ganancia por unos 40 puntos.
3 veces
Mediana del cambio de velocidad que dicen tener (valor: de 1,4 a 2 veces), en 349 personas. Prueba 102
Casi todos los planes de agentes se apoyan en la productividad. Por eso importa qué se midió, en qué tarea y con qué herramienta. Y si el número cuenta trabajo terminado o solo producido.
La prueba más limpia es un estudio aleatorizado: un sorteo decide quién usa la herramienta. Un experimento de 2026 sorteó a 1.174 adultos (la prueba 49). Cada uno resolvió un problema de negocio con un asistente de IA o sin él. Todos mejoraron con el asistente. Pero es un asistente de chat, no un agente, y la tarea fue en línea, fuera de una empresa.
Para agentes de código, el dato más grande viene de Microsoft (la prueba 116). Decenas de miles de sus ingenieros empezaron a usar dos agentes de terminal, Claude Code y GitHub Copilot CLI. En cuatro meses, quienes los adoptaron fusionaron 24,0 % más pull requests por día. Un pull request es una propuesta de cambio al código. La comparación es contra un grupo de control sintético, armado con datos de quienes no los adoptaron.
+24,0 % (de +14,5 % a +33,7 %)
Pull requests fusionados por ingeniero por día frente al control, en una ventana de 4 meses (intervalo de 95 %). Prueba 116
El estudio tiene tres límites. Es observacional: mira lo que pasó, sin sorteo. Lo firman autores de Microsoft. Y no mide calidad. Cursor publicó un 39 % parecido sobre su propia herramienta (la prueba 18). El estudio de Cursor no se pudo abrir.
El agente de código de Copilot trabajó diez meses en dotnet/runtime, el repositorio del runtime de .NET (la prueba 68). Abrió 878 pull requests, con 67,9 % de éxito. De los cambios aceptados, se revirtió el 0,6 %, contra el 0,8 % del resto. Rindió mejor en tareas mecánicas, como escribir tests, que en tareas que piden juicio.
Una medida simple casi duplicó el éxito. Con un archivo de instrucciones y el build configurado, pasó de 38,1 % a 69 %. El build es el proceso que compila y prueba el código. Lo escribe un ingeniero de Microsoft sobre una herramienta de Microsoft.
En los foros hay casos fuera del código. Un responsable de TI armó un flujo de triage con acceso de solo lectura (la prueba 117). Triage es ordenar los tickets por tipo y urgencia. Contó en Reddit que le ahorra 30 minutos por ticket complejo. En otro equipo, un agente bajó la mediana de los incidentes de unos 40 a 12 minutos (la prueba 142). Son relatos sin medición independiente.
En un hilo de Hacker News, quienes contaron éxitos nombran las mismas condiciones (la prueba 43): código ordenado, tests amplios, tareas acotadas y revisar el plan antes.
El límite aparece cuando la tarea se alarga. Un benchmark es un conjunto fijo de tareas para comparar modelos. En SlopCodeBench, un benchmark de 2026, el agente extiende su propio código mientras cambian los requisitos (la prueba 100). El mejor de 15 agentes pasó solo el 14,8 % de los puntos de control. Una nota de la Agentic AI Foundation cuenta el caso de una “fábrica de software” poco supervisada (la prueba 131). Corrió tres o cuatro meses, y la empresa terminó archivando el código.
Los agentes de código ya hacen trabajo real en repositorios serios.
Veredicto: Sí, en tareas acotadas y con revisión experta. En dotnet/runtime, el agente abrió 878 pull requests con 67,9 % de éxito. Casi ninguno se revirtió. En Microsoft, quienes adoptaron agentes de terminal fusionaron 24,0 % más pull requests que un grupo de control. Ese estudio no midió la calidad. Pero cuando tiene que extender su propio código, el mejor de 15 agentes pasa solo 14,8 % de los controles.
Criterio
Dale al agente tareas acotadas que tengan tests, escribí un archivo de instrucciones y dejá el build listo para que lo corra. Que cada cambio lo revise alguien que conoce el código.
Por qué confianza media. Los datos a favor los publican empresas sobre herramientas propias o de su grupo. Microsoft publica sobre Copilot y sobre su despliegue interno. Cursor publica sobre un estudio que no se pudo abrir. Ninguno es aleatorizado y casi ninguno mide calidad. En contra hay un benchmark (una prueba estándar) de 2026 y una anécdota: una fábrica de software que terminó archivada. Los relatos de practicantes coinciden en las condiciones: código ordenado, tests amplios, tareas acotadas y alguien que revisa todo.
Ver el detalle de las 7 pruebasOcultar el detalle3 a favor, 2 en contra, 2 matizan
Diez meses de datos del agente de código de Copilot en el repositorio dotnet/runtime. Más de la mitad de sus pull requests se aceptaron y casi no se revirtieron, porque cada uno pasó por revisión experta. Rindió mejor en tareas mecánicas y acotadas (limpieza, tests) y peor en las que piden juicio (rendimiento). Un archivo de instrucciones y la configuración del build casi duplicaron el éxito. El cuello de botella pasó de escribir código a revisarlo.
Números
878 PR, 67,9 % de éxitoPull requests del agente y tasa de éxito (87,1 % en los PR de personas de Microsoft; poblaciones no comparables).
0,6 % contra 0,8 %PR aceptados que después se revirtieron: del agente contra el resto.
de 38,1 % a 69 %Éxito antes y después de agregar instrucciones y configurar el build.
86,2 % contra 55,1 %Éxito con commits de una persona en el PR y sin ellos.
de 5 a 9 horasRevisión que generaron nueve PR abiertos por el autor en un rato.
Limitación Lo escribe un ingeniero de Microsoft sobre una herramienta de Microsoft. Es un repositorio con revisores muy expertos. El propio autor aclara que el agente y las personas no hacen el mismo tipo de tareas.
“we cannot compromise on review quality, on expert and experienced eyes validating the changes”
Murphy-Hill, E., Butler, J., Savelieva, A. arXiv (Microsoft)
Estudia el despliegue de dos agentes de código de terminal entre decenas de miles de ingenieros de Microsoft. Quienes los adoptaron fusionaron más pull requests que un grupo de control sintético. En los ingenieros más junior (IC2), los pull requests creados subieron más: +34 %, contra +21 % del nivel de referencia (IC4). Por antigüedad, la mejora tiene forma de C: ganan más los de poca y los de mucha antigüedad. El estudio de adopción mira solo Copilot CLI: ahí los perfiles junior lo probaron menos al principio. El uso se contagió sobre todo por redes de colegas. No mide calidad.
Números
+24,0 % (de +14,5 % a +33,7 %)Pull requests fusionados por ingeniero por día frente al control, en una ventana de 4 meses (intervalo de 95 %).
+34 % contra +21 %Aumento de pull requests creados con 3 días de uso por semana, frente a las semanas sin uso de la misma persona. Compara el nivel IC2 contra IC4, el de referencia (IC3: +21 %, IC5: +25 %, IC6: +22 %). Leído de la figura 9, con Claude Code y Copilot CLI.
-13 % y -14 %Chances de probar Copilot CLI al principio en los niveles IC2 e IC3 frente a IC4 (IC5: +22 %). Solo Copilot CLI: el estudio de adopción no incluye Claude Code.
Limitación Observacional, no aleatorizado. Los autores son de Microsoft, dueña de GitHub, y lo declaran. Un pull request no es valor entregado. El aumento por nivel compara semanas con y sin uso de cada persona: es una asociación, no una causa. El estudio de adopción incluye solo Copilot CLI.
“first use spread primarily through social networks”
Resume un estudio de la Universidad de Chicago sobre organizaciones que usan Cursor. Cuando el agente pasó a ser el modo por defecto, fusionaron más pull requests (pedidos de cambio de código) que un grupo de base. Los perfiles junior aceptan más el autocompletado, y los senior aceptan más lo que edita el agente. Los más experimentados también planifican más antes de generar código.
Números
+39 %Pull requests fusionados frente a la tendencia del grupo de base.
+6 %Tasa de aceptación de lo que edita el agente por cada desvío estándar más de años de experiencia (relativo a la media).
Limitación Post del proveedor sobre un estudio (Sarkar, SSRN 5713646) que no se pudo abrir (403). No es aleatorizado. Sin cambio significativo en la tasa de reversión.
“more experienced developers are more likely to plan an action before generating code”
Orlanski, G., Roy, D., et al. arXiv (UW-Madison y otros)
El agente tiene que extender su propio código a medida que cambian los requisitos. Ningún agente resuelve un problema completo de punta a punta. El código del agente se vuelve más largo y más enredado en cada iteración, mientras el código humano se mantiene estable. Pedirle calidad en el prompt mejora el arranque, pero no frena la degradación.
Números
14,8 %Checkpoints que pasa el mejor de 15 agentes, en 36 problemas y 196 checkpoints.
77 % y 75,5 %Trayectorias en las que sube la erosión estructural y en las que sube la verbosidad del código.
2,3 y 2,0 vecesCuánto más verboso y más erosionado es el código del agente que el de 473 repositorios de Python de código abierto.
Limitación Se usan los números de la versión 2 (7 de mayo de 2026), que amplía el benchmark de 20 a 36 problemas y cambia los resultados. La versión 1 es del 25 de marzo de 2026. Se leyó el resumen. Mide calidad de código, no errores por paso.
Nota sobre Dex Horthy, autor de la guía 12-factor agents. Un año después sostiene la misma idea: un bucle grande de agente no aguanta trabajo serio sin estructura y verificación. Su empresa dejó correr tres o cuatro meses una "fábrica de software" con poca supervisión y después archivó todo el código. Según él, faltan mejores verificadores de la calidad del código.
Números
30.000 a 40.000 líneasTamaño que llegó a tener el código de la fábrica antes de archivarlo.
10 de 30 (33,3 %)Checkpoints que pasaron los mejores modelos en el subconjunto de SlopCodeBench que cita; las diferencias entre proveedores están dentro del margen de error.
Limitación Es una nota sobre una persona, con una anécdota propia; no es un estudio.
Un ingeniero con 11 años de experiencia cuenta que automatizó cerca del 80 % de su trabajo con un agente de código. El agente toma los issues y abre pull requests. Dice que la calidad se mantiene porque revisa todos los cambios. Le dedica 2 a 3 horas por día a revisar y probar. Un comentarista cuenta que, al sacar la revisión, la calidad se degradó en una semana. Otros discuten la ética de hacerlo a escondidas del empleador.
Números
cerca del 80 %Parte del trabajo que el autor dice haber automatizado.
2 a 3 horas por díaTiempo que dedica a revisar y probar.
1.200 puntos y 276 comentariosTamaño del hilo según el archivo.
Limitación Relato de una persona, con una semana de uso al momento del post. Los comentarios señalan que funciona porque el trabajo es simple. Se leyó en el archivo público Arctic Shift porque reddit.com bloquea la lectura automática. La cita se comparó letra por letra con el original.
El autor ve un empuje a revisar poco o nada el código ("si pasan los tests, publicá"). En su código existente, la mitad del tiempo se le iba en arreglar errores sutiles. Quienes cuentan éxitos coinciden en las condiciones: código ya ordenado por personas, tipos estáticos, tests amplios, tareas acotadas y revisar el plan antes. Uno cuenta que el agente escribió tests que no probaban nada.
Números
461 puntos y 455 comentariosTamaño del hilo.
Limitación Opiniones de practicantes. Se leyó con la API de Algolia (post y respuestas de primer nivel con más respuestas).
La primera objeción: la velocidad del arranque no dura. Un estudio de Carnegie Mellon comparó 806 proyectos de GitHub que adoptaron Cursor contra 1.380 que no (la prueba 17). El primer mes, las líneas agregadas subieron 281,3 %. A los dos meses, la mejora desapareció. Quedó deuda técnica, es decir, código que después cuesta mantener. La complejidad del código subió 41,64 %, y esa complejidad frena el trabajo después. Son proyectos abiertos, no empresas.
Después está el propio METR. En 2025 midió que sus desarrolladores tardaban 19 % más con IA. En 2026 repitió el estudio con herramientas de fines de 2025 (la prueba 60). Fueron 57 desarrolladores, 143 repositorios y más de 800 tareas. Esta vez, el tiempo con IA bajó 18 % en quienes repetían.
Pero los intervalos de confianza cruzan el cero. Un intervalo de confianza es el rango donde probablemente está el efecto real. Si incluye el cero, el efecto puede ser nulo. Además, entre 30 % y 50 % de los desarrolladores no presentaron algunas tareas para no hacerlas sin IA. Eso es sesgo de selección: la comparación pierde justo esas tareas. METR concluye que hoy la IA probablemente acelera más que en 2025. Pero su dato es una evidencia muy débil de cuánto.
Veredicto: Probablemente acelera la producción, pero el tamaño es incierto. En un experimento aleatorizado con un asistente, todos mejoraron en una tarea de negocio. En proyectos abiertos que adoptaron Cursor, las líneas agregadas subieron 281,3 % el primer mes. Pero la mejora se apagó a los dos meses. METR repitió su estudio en 2026. METR cree que la IA probablemente acelera más que en 2025, aunque no confía en sus propios números.
Criterio
No des por hecha la ganancia: medila en tu propio trabajo, comparando contra hacerlo sin la herramienta. Volvé a medir la calidad unos meses después, porque la velocidad del arranque puede dejar deuda.
Por qué confianza media. El experimento aleatorizado es con un asistente de chat, no con agentes. Los datos de agentes de código son observacionales. Uno es de Microsoft sobre su propio despliegue y otro es sobre proyectos de código abierto. La repetición de METR tiene intervalos que cruzan el cero. METR desconfía de su dato por sesgo de selección. Un proveedor que estima la productividad con sus datos la achica al ajustar por éxito.
Ver el detalle de las 5 pruebasOcultar el detalle2 a favor, 1 en contra, 2 matizan
Cruces, G., Fernández Meijide, D., Galiani, S., Gálvez, R. H., Lombardi, M. NBER (Working Paper 34851)
Es un experimento aleatorizado (con grupos armados al azar) con un asistente de IA generativa, en una tarea de resolver un problema de negocio. Todos mejoran, y los que tienen menos educación mejoran más. La brecha se achica mucho, pero no desaparece, y al sacar la IA vuelve en buena parte. Los que tienen más educación usan mejor la herramienta.
Números
de 0,548 a 0,139 desvíos estándarBrecha de desempeño por educación sin IA y con IA (se cierra cerca de tres cuartos), en 1.174 adultos de 25 a 45 años.
Limitación Se leyó la página de NBER con el resumen. Mide educación, no experiencia; es un asistente de chat, no un agente, y la tarea es en línea, fuera de una empresa. Tiene revisiones de mayo y octubre de 2026.
Murphy-Hill, E., Butler, J., Savelieva, A. arXiv (Microsoft)
Estudia el despliegue de dos agentes de código de terminal entre decenas de miles de ingenieros de Microsoft. Quienes los adoptaron fusionaron más pull requests que un grupo de control sintético. En los ingenieros más junior (IC2), los pull requests creados subieron más: +34 %, contra +21 % del nivel de referencia (IC4). Por antigüedad, la mejora tiene forma de C: ganan más los de poca y los de mucha antigüedad. El estudio de adopción mira solo Copilot CLI: ahí los perfiles junior lo probaron menos al principio. El uso se contagió sobre todo por redes de colegas. No mide calidad.
Números
+24,0 % (de +14,5 % a +33,7 %)Pull requests fusionados por ingeniero por día frente al control, en una ventana de 4 meses (intervalo de 95 %).
+34 % contra +21 %Aumento de pull requests creados con 3 días de uso por semana, frente a las semanas sin uso de la misma persona. Compara el nivel IC2 contra IC4, el de referencia (IC3: +21 %, IC5: +25 %, IC6: +22 %). Leído de la figura 9, con Claude Code y Copilot CLI.
-13 % y -14 %Chances de probar Copilot CLI al principio en los niveles IC2 e IC3 frente a IC4 (IC5: +22 %). Solo Copilot CLI: el estudio de adopción no incluye Claude Code.
Limitación Observacional, no aleatorizado. Los autores son de Microsoft, dueña de GitHub, y lo declaran. Un pull request no es valor entregado. El aumento por nivel compara semanas con y sin uso de cada persona: es una asociación, no una causa. El estudio de adopción incluye solo Copilot CLI.
“first use spread primarily through social networks”
Los proyectos de GitHub que adoptaron Cursor aceleran mucho al principio, pero la mejora se apaga a los dos meses. Quedan más complejidad y más alertas de análisis estático (revisión automática del código), y eso frena la velocidad después. Cursor acelera un rato y deja deuda técnica (problemas para arreglar más adelante).
Números
+281,3 % y +48,4 %Líneas agregadas en el mes 1 y en el mes 2 después de adoptar, en 806 repositorios contra 1.380 de control.
+30,26 % y +41,64 %Alertas de análisis estático y complejidad del código después de adoptar.
Limitación Diferencias en diferencias sobre proyectos de código abierto, no empresas. Los números salen de la versión 3 (26 de enero de 2026); el título cambió entre versiones y no se verificó si cambiaron los resultados. La discusión menciona 25,1 % de complejidad, que no coincide con la tabla.
“a statistically significant, large, but transient increase in project-level development velocity”
Becker, J., Rush, N., Cunningham, T., Rein, D., Mahamud, K. METR
METR repitió su estudio con más desarrolladores y con herramientas de fines de 2025. Los números indican que la IA ahora acelera el trabajo, pero METR no confía en ellos. Muchos desarrolladores no quisieron trabajar sin IA y dejaron afuera tareas para no hacerlas sin ella. Concluye que hoy la IA probablemente acelera más que en 2025, pero el dato es una evidencia muy débil del tamaño de la mejora. También cambió el diseño del experimento.
Números
57 desarrolladores, 143 repositorios, más de 800 tareasTamaño del nuevo estudio (10 repiten y 47 son nuevos).
-18 % y -4 %Cambio en el tiempo con IA: los que repiten (intervalo de -38 % a +9 %) y los nuevos (de -15 % a +9 %).
+19 %Cambio en el tiempo con IA en el estudio original de 2025 (intervalo de +2 % a +39 %).
entre 30 % y 50 %Desarrolladores que no presentaron algunas tareas para no hacerlas sin IA.
Limitación Sesgo de selección que METR reconoce. Además bajó el pago, y quienes usan varios agentes en paralelo miden mal su tiempo. Los intervalos cruzan el cero: no muestran una mejora segura.
Con datos de noviembre de 2025, en el chat de Claude la colaboración volvió a superar a la automatización. Bajaron las conversaciones en las que la persona solo da órdenes. En la API, que usan sobre todo empresas, la automatización sigue en cerca de tres cuartos. El éxito de la tarea es menor en la API, y al ajustar por éxito se achica la mejora de productividad estimada. El informe dice que el primer efecto neto puede ser descalificar trabajos, es decir, sacarles las tareas que piden más habilidad.
Números
52 % y 45 %Conversaciones de colaboración y de automatización en el chat. Las directivas bajaron a 32 % (39 % en agosto de 2025).
67 % y 49 %Éxito de la tarea en el chat y en la API.
de 1,8 a 1,0 a 1,2 puntosAporte anual estimado al crecimiento de la productividad laboral de EE. UU., antes y después de ajustar por éxito.
Limitación Lo publica el proveedor con sus propios datos. Son 1 millón de conversaciones y 1 millón de transcripciones de la API (13 al 20 de noviembre de 2025).
“the productivity benefits will be smaller than raw speedups suggest”
Cita verificada contra el original
Leída en la fuente. Revisada el 2 nov 2026.
La segunda objeción es de método. Si la gente sobreestima su ganancia por unos 40 puntos, una encuesta al equipo no mide la productividad. Una nota de METR calculó el ahorro con 5.305 transcripciones de uso real (la prueba 58). Son de 7 personas de su personal. Dio factores de ahorro de 1,5 a 13 veces. Pero un modelo de lenguaje estimó el tiempo sin IA. Por eso la autora presenta el resultado como una cota superior, es decir, un máximo, no un efecto medido. Los 30 minutos por ticket del foro de TI también son un ahorro autoinformado.
Si el equipo siente que trabaja más rápido con agentes, es porque trabaja más rápido.
Veredicto: No alcanza con sentirlo. En una encuesta de METR, trabajadores técnicos dicen ir 3 veces más rápido con la IA. El mismo METR recuerda su estudio aleatorizado. Ahí, la gente sobreestimó su ganancia por unos 40 puntos. Las estimaciones hechas con transcripciones dan ahorros de 1,5 a 13 veces. Pero su autora las presenta como una cota superior, es decir, un máximo.
Criterio
Medí con un grupo de control o con un antes y después sobre el mismo tipo de tarea. No uses encuestas de percepción ni ahorros autoinformados como prueba de productividad.
Por qué confianza media. La sobreestimación de unos 40 puntos la recuerda METR sobre su estudio de 2025. Su repetición de 2026 no la confirma ni la descarta. La encuesta es por conveniencia, con cerca de 2 % de respuesta. Lo que está a favor son estimaciones de 7 personas y un ahorro autoinformado en Reddit.
Ver el detalle de las 4 pruebasOcultar el detalle2 a favor, 1 en contra, 1 matiza
Nota exploratoria que estima el tiempo ahorrado con agentes de código. Usa transcripciones de uso real del personal de METR. Da factores de ahorro altos, pero la autora los presenta como una cota superior blanda (un techo aproximado), no como un efecto medido.
Números
5.305 transcripciones de 7 personasBase del análisis, de enero de 2026.
de 1,5 a 13 vecesFactor de ahorro de tiempo estimado (por persona, de 2,11 a 11,62 veces).
Limitación El tiempo que habría llevado sin IA lo estima un modelo de lenguaje, validado con solo 34 muestras. Son 7 personas y una sola herramienta. Es una cota superior, no un efecto medido con grupo de control.
Un hilo pregunta qué tareas de TI se automatizaron de verdad con IA, y el comentario más votado responde “ninguna”. A favor, un responsable armó un flujo de triage (clasificación de pedidos) con acceso de solo lectura. El flujo lee la gestión de equipos, el directorio, el doble factor, la red y el historial de tickets. El paso siguiente es automatizar con una persona que aprueba desde un chat. Él dice que el objetivo es crecer, no sacar gente.
Números
30 minutos por ticketAhorro en tickets complejos, según quien construyó el triage.
67 puntos y 146 comentariosTamaño del hilo según el archivo. El comentario citado tiene 47 puntos y el de “ninguna”, 134.
Limitación Ahorro autoinformado, sin medición. Se leyó en el archivo público Arctic Shift porque reddit.com bloquea la lectura automática. La cita se comparó letra por letra con el original.
“On more complicated stuff this is saving EASILY 30 minutes per ticket.”
Encuesta a trabajadores técnicos sobre cuánto valor y velocidad les suma la IA. Dicen que mucho. METR advierte que las encuestas suelen dar resultados más altos que los experimentos. Recuerda que en su estudio aleatorizado (con grupos sorteados) la gente sobreestimó su ganancia por unos 40 puntos.
Números
3 vecesMediana del cambio de velocidad que dicen tener (valor: de 1,4 a 2 veces), en 349 personas.
Limitación Muestra por conveniencia, con cerca de 2 % de respuesta y cerca de 70 % de participantes pagos. Es autorreporte, no medición.
“Importantly, survey results are not necessarily grounded in reality.”
Becker, J., Rush, N., Cunningham, T., Rein, D., Mahamud, K. METR
METR repitió su estudio con más desarrolladores y con herramientas de fines de 2025. Los números indican que la IA ahora acelera el trabajo, pero METR no confía en ellos. Muchos desarrolladores no quisieron trabajar sin IA y dejaron afuera tareas para no hacerlas sin ella. Concluye que hoy la IA probablemente acelera más que en 2025, pero el dato es una evidencia muy débil del tamaño de la mejora. También cambió el diseño del experimento.
Números
57 desarrolladores, 143 repositorios, más de 800 tareasTamaño del nuevo estudio (10 repiten y 47 son nuevos).
-18 % y -4 %Cambio en el tiempo con IA: los que repiten (intervalo de -38 % a +9 %) y los nuevos (de -15 % a +9 %).
+19 %Cambio en el tiempo con IA en el estudio original de 2025 (intervalo de +2 % a +39 %).
entre 30 % y 50 %Desarrolladores que no presentaron algunas tareas para no hacerlas sin IA.
Limitación Sesgo de selección que METR reconoce. Además bajó el pago, y quienes usan varios agentes en paralelo miden mal su tiempo. Los intervalos cruzan el cero: no muestran una mejora segura.
Leída en la fuente. Revisada el 1 nov 2026.
La tercera objeción: un cambio entregado no es un cambio aceptado. METR le pidió a cuatro mantenedores que revisaran 296 pull requests de agentes (la prueba 67). Un mantenedor es quien decide qué entra en un proyecto. Eran de scikit-learn, Sphinx y pytest. Todos los cambios ya pasaban el corrector automático de SWE-bench Verified, un benchmark de tareas de código reales. Cerca de la mitad no se habría integrado. En los modelos nuevos, las fallas fueron más de calidad del código que de funciones rotas. Los autores aclaran un límite: el agente tuvo un solo intento, sin poder iterar con el revisor.
Simon Willison lo resumió en un ensayo muy discutido en Hacker News (la prueba 35). Quien manda código tiene que mostrar que funciona. Para eso sirven tests que fallen si alguien revierte el cambio. Al agente se le pide lo mismo. En el hilo de Hacker News de antes, alguien contó que el agente escribió tests que no probaban nada.
Si el pull request del agente pasa los tests, está listo para integrar.
Veredicto: No. Mantenedores de tres proyectos revisaron pull requests de agentes que ya pasaban el corrector de SWE-bench Verified. Cerca de la mitad no se habría integrado. En los modelos nuevos, las fallas fueron más de calidad del código que de funciones rotas. En proyectos abiertos que adoptaron Cursor, la complejidad del código subió 41,64 %. Las alertas de análisis estático subieron 30,26 %.
Criterio
Antes de integrar, que lea el cambio alguien que conoce el código. Mirá la complejidad y las alertas de análisis estático, además de los tests. Pedile al agente tests que fallen si se revierte el cambio.
Por qué confianza media. La nota de METR es de investigación, con cuatro mantenedores y tres repositorios. El agente tuvo un solo intento, sin poder iterar con el revisor. El estudio de calidad mira código abierto, no empresas. El dato a favor lo publica un proveedor sobre un estudio que no se pudo abrir. Muestra más pull requests fusionados, sin cambio significativo en la tasa de reversión. Los relatos de Hacker News coinciden con la nota. Uno cuenta que el agente escribió tests que no probaban nada.
Ver el detalle de las 5 pruebasOcultar el detalle1 a favor, 2 en contra, 2 matizan
Resume un estudio de la Universidad de Chicago sobre organizaciones que usan Cursor. Cuando el agente pasó a ser el modo por defecto, fusionaron más pull requests (pedidos de cambio de código) que un grupo de base. Los perfiles junior aceptan más el autocompletado, y los senior aceptan más lo que edita el agente. Los más experimentados también planifican más antes de generar código.
Números
+39 %Pull requests fusionados frente a la tendencia del grupo de base.
+6 %Tasa de aceptación de lo que edita el agente por cada desvío estándar más de años de experiencia (relativo a la media).
Limitación Post del proveedor sobre un estudio (Sarkar, SSRN 5713646) que no se pudo abrir (403). No es aleatorizado. Sin cambio significativo en la tasa de reversión.
“more experienced developers are more likely to plan an action before generating code”
Cuatro mantenedores de scikit-learn, Sphinx y pytest revisaron pull requests de agentes que ya pasaban el corrector automático de SWE-bench Verified. Cerca de la mitad no se integraría. En los modelos nuevos, las fallas se corrieron hacia la calidad del código más que hacia funciones rotas. Los autores aclaran que no prueba un límite de capacidad: el agente tuvo un solo intento, sin poder iterar con el revisor.
Números
24,2 puntosCuánto más da el corrector automático que los mantenedores, normalizado contra pull requests humanos (error estándar 2,7). Sin normalizar, 34,9 puntos.
296 pull requests de agentesRevisados, junto con 47 humanos de referencia, en 95 de los 500 problemas. Los mantenedores integraron cerca de 68 % de los humanos.
unos 50 contra unos 8 minutosHorizonte de Claude Sonnet 4.5 con el corrector automático y con revisión de mantenedores; los autores dicen que esta cifra es muy ruidosa.
Limitación Nota de investigación, no paper revisado. Cuatro mantenedores y tres repositorios. Modelos desde Claude 3.5 Sonnet hasta Claude Sonnet 4.5 y GPT-5.
“roughly half of test-passing SWE-bench Verified PRs”
Los proyectos de GitHub que adoptaron Cursor aceleran mucho al principio, pero la mejora se apaga a los dos meses. Quedan más complejidad y más alertas de análisis estático (revisión automática del código), y eso frena la velocidad después. Cursor acelera un rato y deja deuda técnica (problemas para arreglar más adelante).
Números
+281,3 % y +48,4 %Líneas agregadas en el mes 1 y en el mes 2 después de adoptar, en 806 repositorios contra 1.380 de control.
+30,26 % y +41,64 %Alertas de análisis estático y complejidad del código después de adoptar.
Limitación Diferencias en diferencias sobre proyectos de código abierto, no empresas. Los números salen de la versión 3 (26 de enero de 2026); el título cambió entre versiones y no se verificó si cambiaron los resultados. La discusión menciona 25,1 % de complejidad, que no coincide con la tabla.
“a statistically significant, large, but transient increase in project-level development velocity”
Quien manda código tiene que mostrar que funciona: probarlo a mano y dejar tests automáticos que fallen si se revierte el cambio. A los agentes de código se les pide lo mismo, y la persona sigue siendo la responsable de lo que entrega.
Números
859 puntos y 658 comentariosTamaño de la discusión en Hacker News (item 46313297).
Limitación Ensayo de opinión de un especialista, sin datos propios.
“Your job is to deliver code you have proven to work.”
El autor ve un empuje a revisar poco o nada el código ("si pasan los tests, publicá"). En su código existente, la mitad del tiempo se le iba en arreglar errores sutiles. Quienes cuentan éxitos coinciden en las condiciones: código ya ordenado por personas, tipos estáticos, tests amplios, tareas acotadas y revisar el plan antes. Uno cuenta que el agente escribió tests que no probaban nada.
Números
461 puntos y 455 comentariosTamaño del hilo.
Limitación Opiniones de practicantes. Se leyó con la API de Algolia (post y respuestas de primer nivel con más respuestas).
Leída en la fuente. Revisada el 2 nov 2026.
La cuarta objeción sigue de la tercera. Si cada cambio pide una revisión seria, la revisión pone el límite. En dotnet/runtime, el cuello de botella pasó de escribir código a revisarlo (la prueba 68). El autor abrió nueve pull requests con el agente en un rato. Eso le generó de 5 a 9 horas de revisión. Con commits de alguien del equipo, los cambios salieron bien el 86,2 % de las veces. Sin esos commits, el 55,1 %. El autor lo resume así: “we cannot compromise on review quality, on expert and experienced eyes validating the changes”.
Éxito con commits de una persona en el PR y sin ellos.Prueba 68
Pull requests del agente con éxito, en %
Con commits de una persona86,2 %
Sin commits de una persona55,1 %
0100 %
Un ingeniero con 11 años de experiencia automatizó cerca del 80 % de su trabajo (la prueba 79). Contó en Reddit que dedica de 2 a 3 horas por día a revisar y probar. Un comentarista contó la otra cara: sacó la revisión y la calidad bajó en una semana. BCG encuestó a cerca de 12.000 personas de la primera línea (la prueba 109). Una buena parte dice pasar más tiempo revisando y corrigiendo a la IA.
Veredicto: Se produce antes, pero terminarlo depende de la revisión. En dotnet/runtime, el autor abrió con el agente nueve pull requests en un rato. Esos cambios generaron de 5 a 9 horas de revisión. Una persona dice haber automatizado cerca del 80 % de su trabajo. Igual dedica de 2 a 3 horas por día a revisar y probar.
Criterio
Medí el tiempo hasta que el cambio queda aceptado, no hasta que el agente entrega. Antes de sumar agentes, asegurá la capacidad de revisión.
Por qué confianza media. El dato de revisión es de un solo repositorio y lo da un ingeniero de Microsoft. La encuesta de BCG también ve a buena parte de la primera línea con más tiempo de revisión y corrección de la IA. Pero es autorreporte. A favor, un equipo cuenta que un agente bajó la mediana de sus incidentes de unos 40 a 12 minutos. Los relatos de Reddit son de una persona o de un equipo, sin medición independiente.
Ver el detalle de las 4 pruebasOcultar el detalle1 a favor, 2 en contra, 1 matiza
Un agente que atiende alertas bajó la mediana de los incidentes de unos 40 a 12 minutos. Pero después falló un servicio viejo al que las herramientas no tienen acceso. Las 3 personas de guardia pasaron la primera hora entendiendo cómo funcionaba, porque hacía meses que nadie lo tocaba a mano. El autor propone resolver a mano algunos incidentes por mes, a propósito. Lo compara con los taxistas de Londres, que siguen aprendiendo las calles aunque tengan GPS.
Números
de unos 40 a 12 minutosMediana de los incidentes con el agente.
105 puntos y 35 comentariosTamaño del hilo según el archivo. El comentario citado tiene 81 puntos.
Limitación Relato de un equipo, sin medición independiente. Un comentarista dice que parece publicidad, porque el post menciona una herramienta comercial. Se leyó en el archivo público Arctic Shift porque reddit.com bloquea la lectura automática. La cita se comparó letra por letra con el original.
“All the Star Trek engineers still actually knew how things worked.”
Diez meses de datos del agente de código de Copilot en el repositorio dotnet/runtime. Más de la mitad de sus pull requests se aceptaron y casi no se revirtieron, porque cada uno pasó por revisión experta. Rindió mejor en tareas mecánicas y acotadas (limpieza, tests) y peor en las que piden juicio (rendimiento). Un archivo de instrucciones y la configuración del build casi duplicaron el éxito. El cuello de botella pasó de escribir código a revisarlo.
Números
878 PR, 67,9 % de éxitoPull requests del agente y tasa de éxito (87,1 % en los PR de personas de Microsoft; poblaciones no comparables).
0,6 % contra 0,8 %PR aceptados que después se revirtieron: del agente contra el resto.
de 38,1 % a 69 %Éxito antes y después de agregar instrucciones y configurar el build.
86,2 % contra 55,1 %Éxito con commits de una persona en el PR y sin ellos.
de 5 a 9 horasRevisión que generaron nueve PR abiertos por el autor en un rato.
Limitación Lo escribe un ingeniero de Microsoft sobre una herramienta de Microsoft. Es un repositorio con revisores muy expertos. El propio autor aclara que el agente y las personas no hacen el mismo tipo de tareas.
“we cannot compromise on review quality, on expert and experienced eyes validating the changes”
Beauchene, Duranton, Martin, Lyon, Walters. Boston Consulting Group
El uso de IA en la primera línea creció mucho y la gente dice ahorrar tiempo. Pero a la mayoría nadie le dice qué hacer con ese tiempo. Una buena parte pasa más tiempo revisando, corrigiendo o dirigiendo a la IA. Las organizaciones con agentes integrados en sus flujos de trabajo se duplicaron en un año.
Números
74 % (+23 puntos)Personas de primera línea que usan IA a diario o varias veces por semana, sobre cerca de 12.000 encuestados.
66 %Reciben poca o ninguna guía sobre qué hacer con el tiempo ahorrado.
30 % (13 % en 2025)Organizaciones que integraron agentes en sus flujos de trabajo.
Limitación Autorreporte; BCG vende consultoría. Hoy la descarga automática da 403, así que no lleva cita textual.
Un ingeniero con 11 años de experiencia cuenta que automatizó cerca del 80 % de su trabajo con un agente de código. El agente toma los issues y abre pull requests. Dice que la calidad se mantiene porque revisa todos los cambios. Le dedica 2 a 3 horas por día a revisar y probar. Un comentarista cuenta que, al sacar la revisión, la calidad se degradó en una semana. Otros discuten la ética de hacerlo a escondidas del empleador.
Números
cerca del 80 %Parte del trabajo que el autor dice haber automatizado.
2 a 3 horas por díaTiempo que dedica a revisar y probar.
1.200 puntos y 276 comentariosTamaño del hilo según el archivo.
Limitación Relato de una persona, con una semana de uso al momento del post. Los comentarios señalan que funciona porque el trabajo es simple. Se leyó en el archivo público Arctic Shift porque reddit.com bloquea la lectura automática. La cita se comparó letra por letra con el original.
“output quality degraded within a week”
Cita verificada contra el original
Leída en la fuente. Revisada el 2 nov 2026.
La quinta objeción: si la IA acelerara tanto el trabajo, se vería en la economía. En la encuesta de BCG, el 66 % recibe poca o ninguna guía sobre el tiempo que ahorra. Un estudio de Dinamarca cruzó el uso de chatbots con los ingresos y las horas trabajadas (la prueba 62). Usó datos administrativos, no encuestas. Dos años después de la llegada de ChatGPT, descarta efectos mayores al 2 %.
Anthropic ajustó su estimación con datos de su propio producto (la prueba 42). El ajuste cuenta solo las tareas que salen bien. Con ese ajuste, el aporte anual de la IA a la productividad de Estados Unidos bajó. Pasó de 1,8 a entre 1,0 y 1,2 puntos de crecimiento.
La IA ya cambió cuánto gana y cuánto trabaja la gente.
Veredicto: Todavía no se ve. En Dinamarca, con datos administrativos, los efectos sobre ingresos y horas no pasan del 2 %. Eso se midió dos años después de la llegada de ChatGPT. A 66 % de quienes trabajan en la primera línea les dan poca o ninguna guía. No saben qué hacer con el tiempo que ahorran. Un proveedor ajusta por éxito su estimación para la productividad estadounidense. Así, el aporte anual al crecimiento baja de 1,8 a entre 1,0 y 1,2 puntos.
Criterio
No metas en el plan de negocio un ahorro de toda la empresa sacado de estudios sobre tareas sueltas. Medí el resultado de tu proceso de punta a punta.
Por qué confianza media. El estudio danés usa datos administrativos sólidos, pero de chatbots en 2023 y 2024, no de agentes. La encuesta de BCG es autorreporte de una consultora. La estimación de productividad la hace un proveedor con sus propios datos. Ninguna fuente de la base muestra un cambio medido en ingresos u horas.
Ver el detalle de las 3 pruebasOcultar el detalle0 a favor, 1 en contra, 2 matizan
Humlum, A., Vestergaard, E. NBER (working paper 33777)
Datos administrativos de Dinamarca que cruzan el uso de chatbots en el trabajo con ingresos y horas. Encuentra efectos nulos y medidos con precisión. Descarta efectos mayores al 2 % sobre ingresos y horas registradas dos años después de la llegada de ChatGPT.
Números
menos de 2 %Tamaño máximo del efecto sobre ingresos y horas que los datos permiten.
Limitación Datos de 2023 y 2024, de chatbots y no de agentes. La primera versión, de mayo de 2025, se llamaba “Large Language Models, Small Labor Market Effects” y descartaba efectos mayores al 1 %. La revisión de marzo de 2026 cambia los resultados. La cota pasa a 2 % dos años después de ChatGPT, y suma la reorganización de tareas y el paso a ocupaciones mejor pagas. Por eso la ficha usa la fecha de la revisión. Un ahorro de tiempo promedio de cerca de 3 % viene de la primera versión, no se verificó en la revisión y no se usa.
Beauchene, Duranton, Martin, Lyon, Walters. Boston Consulting Group
El uso de IA en la primera línea creció mucho y la gente dice ahorrar tiempo. Pero a la mayoría nadie le dice qué hacer con ese tiempo. Una buena parte pasa más tiempo revisando, corrigiendo o dirigiendo a la IA. Las organizaciones con agentes integrados en sus flujos de trabajo se duplicaron en un año.
Números
74 % (+23 puntos)Personas de primera línea que usan IA a diario o varias veces por semana, sobre cerca de 12.000 encuestados.
66 %Reciben poca o ninguna guía sobre qué hacer con el tiempo ahorrado.
30 % (13 % en 2025)Organizaciones que integraron agentes en sus flujos de trabajo.
Limitación Autorreporte; BCG vende consultoría. Hoy la descarga automática da 403, así que no lleva cita textual.
Con datos de noviembre de 2025, en el chat de Claude la colaboración volvió a superar a la automatización. Bajaron las conversaciones en las que la persona solo da órdenes. En la API, que usan sobre todo empresas, la automatización sigue en cerca de tres cuartos. El éxito de la tarea es menor en la API, y al ajustar por éxito se achica la mejora de productividad estimada. El informe dice que el primer efecto neto puede ser descalificar trabajos, es decir, sacarles las tareas que piden más habilidad.
Números
52 % y 45 %Conversaciones de colaboración y de automatización en el chat. Las directivas bajaron a 32 % (39 % en agosto de 2025).
67 % y 49 %Éxito de la tarea en el chat y en la API.
de 1,8 a 1,0 a 1,2 puntosAporte anual estimado al crecimiento de la productividad laboral de EE. UU., antes y después de ajustar por éxito.
Limitación Lo publica el proveedor con sus propios datos. Son 1 millón de conversaciones y 1 millón de transcripciones de la API (13 al 20 de noviembre de 2025).
“the productivity benefits will be smaller than raw speedups suggest”
La IA probablemente acelera la producción en tareas acotadas, con tests y con alguien que revisa.El tamaño de la mejora es incierto. Las seis fichas tienen confianza media, y dicen lo mismo.
Los números grandes cuentan pull requests fusionados, y casi ninguno mide calidad. El único estudio que mide calidad tras adoptar la herramienta encontró deuda técnica.
La regla de método queda firme. Lo que se siente no mide nada. El tiempo que importa termina cuando el cambio queda aceptado, no cuando el agente entrega o pasan los tests. Ese tiempo tiene un techo: las horas de quien revisa.
La economía todavía no muestra el salto. Eso no prueba que no vaya a llegar. Pero un plan de negocio no puede tomar el 24,0 % de un despliegue y aplicarlo a toda la empresa.
Medí la ganancia en tu propio trabajo, de punta a punta, contra hacerlo sin la herramienta. Contá hasta que el cambio queda aceptado. Volvé a medir la calidad unos meses después.
Ahora:
Elegí un tipo de tarea acotada que tenga una verificación automática, como tests o un build.
Escribí el archivo de instrucciones del agente. Dejá el build listo para que el agente lo corra.
Medí con un grupo de control o con un antes y después sobre el mismo tipo de tarea. Si podés, elegí el grupo de control, porque da una prueba más fuerte. No uses encuestas de percepción como prueba.
Antes de integrar, que lea el cambio alguien que conoce el código. Mirá la complejidad y las alertas del análisis estático (la revisión automática del código sin ejecutarlo). Pedile al agente tests que fallen si se revierte el cambio.
Registrá las horas de revisión junto con el tiempo del agente. Si la revisión no da abasto, no sumes más agentes.
El plan de evaluación sirve para armar las tareas y fijar el criterio de salida. La calculadora de costo por tarea exitosa suma las horas de revisión al costo del modelo. El próximo capítulo sigue con los perfiles junior cuando el agente hace sus tareas.