- Se realizó un ensayo controlado aleatorizado sobre el impacto de las herramientas de IA de inicios de 2025 en la productividad real de desarrolladores de código abierto
- Los resultados mostraron que, al usar herramientas de IA, el tiempo para completar tareas fue en promedio 19% mayor
- Los desarrolladores esperaban que la IA los hiciera 24% más rápidos, pero en la práctica ocurrió una desaceleración pese a su percepción
- La brecha entre las capacidades de la IA observadas en benchmarks y experiencia cotidiana y su efecto real resulta muy marcada
- El estudio subraya la importancia de comprender con precisión el impacto de la IA en la productividad y de usar métodos de evaluación diversos
Resumen general
- Este estudio realizó un ensayo controlado aleatorizado (RCT) para verificar el impacto de las herramientas de IA de inicios de 2025 (Early-2025) en la productividad de desarrolladores experimentados de código abierto
- Contra lo esperado, se confirmó que los desarrolladores tardaban 19% más al usar herramientas de IA
- Este resultado puede interpretarse como un caso de medición del impacto real que tiene la automatización de la investigación con IA sobre el desarrollo de software
- Con base en esta metodología, los autores señalan que planean seguir estimando de forma continua los efectos reales de la aceleración del I+D en IA
Motivación del estudio
- Los benchmarks de coding/agentes existentes tienen la limitación de no reflejar suficientemente las condiciones reales de trabajo
- Debido a pruebas autocontenidas, tareas aisladas sin contexto y estructuras de calificación automática, pueden sobreestimar la capacidad de la IA
- Por el contrario, cuando no existe intervención adaptativa humana, también es posible que se subestime el rendimiento real de los modelos de IA
- Para complementar esas limitaciones, se midió el impacto real de la IA experimentando sobre la productividad real de desarrolladores de código abierto
Método experimental
- Se reclutó a 16 desarrolladores veteranos de código abierto y se seleccionaron 246 issues reales dentro de grandes repositorios en los que habían trabajado durante años (promedio de más de 22 mil estrellas y más de 1 millón de líneas de código)
- Para cada issue, se asignó aleatoriamente a un grupo con uso de IA permitido o prohibido
- Cuando la IA estaba permitida, los desarrolladores podían usar libremente Cursor Pro y modelos recientes como Claude 3.5/3.7 Sonnet; cuando estaba prohibida, debían trabajar sin ayuda de IA generativa
- Los participantes grabaron el proceso de resolución de cada issue (con una duración promedio de 2 horas) y reportaron por sí mismos el tiempo invertido
- A los participantes del experimento se les pagó una compensación de 150 dólares por hora
Resultados principales
- Al usar herramientas de IA, el tiempo para resolver issues aumentó en promedio 19%
- Los desarrolladores esperaban que la IA realmente aumentara su productividad en 24%, y aun después del experimento respondieron que seguían sintiendo una mejora de velocidad de 20%
- Así, apareció una gran brecha entre la percepción y el rendimiento real
- Para evitar malentendidos, este estudio no aporta evidencia sobre lo siguiente:
- que pueda generalizarse que la IA vuelve más lento a todo desarrollador o al desarrollo de software en general
- que el efecto de la IA quede definido para otros campos o configuraciones
- que el mismo resultado vaya a mantenerse también en el futuro cercano
- que no sea posible optimizar los LLM o las técnicas de prompting existentes
Análisis de factores de impacto
- Se analizaron 20 factores que podrían explicar la demora en las tareas, y se consideró que 5 de ellos sí tuvieron un efecto real
- Se confirmó que variables importantes como las condiciones experimentales, el modelo, la dificultad del issue o la calidad del PR no tuvieron un impacto significativo en el resultado
- El fenómeno de retraso se observó de forma consistente también en distintos subconjuntos de datos y métodos de estimación
- El análisis detallado puede consultarse en el artículo original
Interpretación y discusión de los resultados
Conflicto entre evidencias y sus causas
- La diferencia entre los resultados de puntajes en benchmarks de IA / reportes de casos / experimentos reales es clara
- Los benchmarks miden la capacidad de la IA principalmente sobre problemas acotados que permiten evaluación automática
- SWE-Bench: PRs de código abierto basados en tests, RE-Bench: problemas evaluables algorítmicamente
- En el RCT real, en cambio, los humanos se volvieron más lentos en tareas complejas y realistas que toman entre 20 minutos y 4 horas
- Por otro lado, en la industria y en comunidades existen muchos reportes cualitativos de que la IA resulta bastante útil para trabajos de larga duración
Marco de interpretación
- Cada uno de estos enfoques tiene la característica de medir de manera distinta la “capacidad real”
- Enfoques por caso:
- Problema de subestimación del RCT: puede existir una especificidad limitada a nuestro entorno experimental
- Posible sobreestimación en benchmarks/casos: brecha con la resolución real y confiabilidad insuficiente de la evidencia basada en autorreporte
- Los tres enfoques podrían ajustarse bien solo a algunos subproblemas reales
- La brecha entre distintas fuentes y la capacidad real puede interpretarse como error/sesgo de medición (rojo) y diferencia en el alcance de medición (azul)
Implicaciones adicionales del experimento
- Los resultados del RCT pueden no aplicar a entornos donde se muestrean resultados de IA cientos o miles de veces
- Existe la posibilidad de que las mejoras de eficiencia aparezcan solo después de usar durante decenas o cientos de horas herramientas de IA como Cursor
- En entornos con código de alta calidad y muchos requisitos implícitos (documentación, testing, formateo, etc.), la capacidad de la IA podría ser limitada
- Los benchmarks tienen un alcance de problemas estrecho, por lo que no reflejan adecuadamente la dificultad del trabajo real
- Los reportes cualitativos de percepción podrían ser menos confiables debido a sobreestimación y autoengaño
- Se enfatiza la necesidad de usar de forma complementaria múltiples métodos de evaluación, ya que ninguno es perfecto por sí solo
Perspectivas futuras
- Se prevé seguir mejorando esta metodología para rastrear cuantitativamente cuánto cambian en realidad las herramientas de IA la productividad de los desarrolladores
- Si las herramientas de IA aumentaran de forma importante la eficiencia de los desarrolladores en campo, también podrían surgir riesgos como una aceleración abrupta del I+D en IA, fallas de supervisión o concentración de poder
- El desarrollo de marcos de evaluación adecuados para entornos reales será muy importante para la evolución futura de la IA y de la industria en general
2 comentarios
¿¿Desde 150 dólares por hora? Hasta el control de variables jajajaja
Opiniones de Hacker News
Comentario de Simon Willison:
El artículo completo tiene muchos detalles que no aparecen en el resumen enlace al artículo
Mi impresión personal es que, para obtener una mejora real de productividad con herramientas de IA basadas en LLM, hay una curva de aprendizaje mucho más empinada de lo que la gente imagina
En este estudio participaron 16 personas con distintos niveles de experiencia usando herramientas de IA, y 56% estaba usando Cursor por primera vez; en esencia, era un estudio principalmente sobre Cursor
Cada participante trabajó en unas 15 incidencias en total, y para cada una se asignó aleatoriamente si podía usar IA o no
Es decir, cada desarrollador hizo una mezcla de tareas con IA permitida y tareas sin IA
Solo 1/4 de los participantes mejoró su rendimiento y 3/4 empeoró
Entre quienes más usaron IA estaban quienes habían usado Cursor por más de 50 horas
Los investigadores también reconocen que los desarrolladores con suficiente experiencia en Cursor sí mostraron mejoras de rendimiento
Mi intuición es que este artículo mostró que, debido a la alta curva de aprendizaje en el desarrollo colaborativo con IA, si la mezclas de inmediato con flujos de trabajo existentes en el trabajo real, el rendimiento más bien empeora
Con los LLM suele aparecer la reacción de “es porque no sabes usarlos bien”, pero eso me parece una excusa que le carga demasiada responsabilidad al usuario
En la mayoría de los productos tecnológicos, si el usuario no percibe valor, pensamos que el diseño del producto está mal. Me pregunto por qué esa lógica no se aplica a la IA
Gracias a Simon, y gracias por leer el artículo con tanto cuidado; soy fan de los proyectos OS y quiero señalar algunos puntos importantes
1) En estudios previos, algunos mostraron mejoras de rendimiento incluso con poca experiencia en la herramienta, así que la teoría de la “curva de aprendizaje empinada” por sí sola no explica completamente este resultado
2) Antes del estudio, más del 90% de los participantes ya tenía experiencia escribiendo prompts para LLM, y se consideraba que esa era la habilidad principal. La idea establecida era que, si ya dominas VSCode, Cursor es fácil de usar
3) Si todos ya estaban acostumbrados a la IA, podrían rendir peor en un contexto sin IA (al menos a mí me hace sentido); y si eso ocurriera, en realidad produciría un efecto que haría parecer mejor a la IA, no peor
4) La información sobre experiencia se compartió de antemano con expertos en predicción, y aun así los pronosticadores sobreestimaron mucho las expectativas de mejora de productividad
5) Es posible que existan habilidades de cola larga que solo aparecen tras cientos de horas de uso; este estudio no permite decir mucho sobre eso
Como el artículo presenta un resultado sorprendente, es fácil que quien lo lea escoja un solo factor y concluya “¡es por esto!”
En realidad puede haber causas múltiples (no se pueden descartar al menos 5, o incluso 9; ver la tabla de la página 11)
Una implicación realmente importante: la satisfacción autorreportada por los desarrolladores tuvo una brecha enorme respecto de la realidad, y eso fue independiente del tipo de herramienta usada
Para medir productividad, hacen falta datos reales en el campo (ver artículo C.2.7: sección “Uso de herramientas de IA por debajo del promedio”, donde se trata con más detalle)
Esto puede interpretarse como que, aunque el 75% de los participantes tenía experiencia con LLM, al usar IA en realidad trabajaban más lento. Una interpretación es que la curva de aprendizaje de los LLM es muy empinada; la otra es que la eficiencia real de los LLM como apoyo para programar está sobreestimada. La gente se equivoca de forma consistente al predecir su rendimiento
Incluso si llegas a manejar bien los LLM, tu comprensión del código que tú mismo produces puede empeorar
El desarrollador se vuelve más experto en su código con el tiempo, pero el LLM puede ir empeorando relativamente
Puedes generar código rápido con un LLM, pero si no prestas suficiente atención, no acumulas verdadera maestría sobre ese código
Al principio el desarrollo se siente ágil y rápido, pero por detrás hay poca comprensión, y el LLM también deja de mejorar tras cierto punto; llega un momento en que el código se vuelve un caos que ni el LLM ni el usuario pueden manejar
Creo que hay que resistir esa tentación, insistir para que el LLM produzca código más limpio y, además, estudiar de verdad el código uno mismo. Hace falta el esfuerzo de entenderlo por cuenta propia
Se nota que hay personas cuya productividad sí aumenta con herramientas de IA y otras a las que no
Mi sospecha es que quien puede leer rápidamente textos largos o código tiene una ventaja considerable
Es muy importante detectar rápido las sugerencias inútiles e iterar hasta obtener una buena respuesta
La capacidad de escaneo rápido se correlaciona con la experiencia, pero curiosamente también hay gente junior que la tiene muy desarrollada
Quien es bueno buscando también puede tener ventaja usando LLM; parece una habilidad parecida a saber googlear bien
Esto me hace pensar otra vez en la regla 80/20: resuelve el 80% del trabajo en el 20% del tiempo, y luego consume el 80% del tiempo para el 20% restante
Siempre da la sensación de que “ya casi está”, así que es fácil caer en la falacia del costo hundido
Un enfoque que he probado recientemente es usar la IA no como “solucionadora”, sino como “removedora de fricción”
Yo sigo programando directamente, y solo le pregunto a la IA cosas pequeñas como sintaxis que olvidé, para acelerar el trabajo
Casi nunca veo sugerencias completas de código; siempre escribo pensando por mi cuenta, para evitar perder comprensión y habilidad
Antes era una especie de Pareto invertido: 80% del trabajo con 80% del esfuerzo, y el 20% restante también se llevaba otro 80% del esfuerzo
Coincido con usar la IA solo para resolver “pequeños obstáculos”
Ayer mismo estaba procesando una
Listcon la Java stream API y me atoré con unaConcurrentOperationsExceptionIntenté escribir el método yo mismo y no salía, así que le pedí a la IA un “método de transformación de lista seguro para hilos” y me dijo que ya existía un método integrado en esa API
Para ese tipo de problemas misceláneos, la IA es excelente: cuando es complejo, pero está claramente definido
Es especialmente útil como una versión más poderosa de Stack Overflow, cuando más o menos sé lo que tengo que hacer pero no sé exactamente cómo adaptarlo a mi entorno, y también ayuda para depurar o para hacer rubber ducking
“Consumir el 80% del tiempo en el último 20%” ya era mi experiencia antes de la IA. Si al menos reduce el tiempo inicial, ya ayuda. La mejor descripción de la IA que escuché de alguien con experiencia fue: “el 90% de mis habilidades perdió valor, y el otro 10% se volvió mil veces más importante”. Es una exageración, pero me gusta la idea central
La ilusión de que “siempre falta poco” en realidad puede hacerte perder tiempo
La IA está especializada en hacer que algo parezca útil, así que para distinguir si de verdad mejora la productividad hace falta pensamiento crítico de alto nivel
Es especialmente útil al agregar funcionalidad a una base de código existente, en tareas como “hay que añadir
fooademás de los parámetros de búsqueda existentes” o “quita el código relacionado conx”Para la gente de HN: soy autor del artículo. Llevo mucho tiempo en HN y hoy estoy tratando de responder tantas preguntas/comentarios como pueda. Si no tienen tiempo para leer el artículo completo, recomiendo mejor el post del blog de presentación o el hilo de presentación en x.com
La metodología del artículo y la forma en que el autor se está comunicando son muy profesionales e impresionantes; es una muy buena investigación
Creo que esta es una de las mejores investigaciones porque presenta los resultados con honestidad, sin clickbait, y está muy bien organizada para ser fácil de leer
¿Consideraron si los tickets que se resolvían con IA realmente eran del tipo adecuado para IA? Decir simplemente “resuelve este ticket con IA” es realista, pero puede ser ineficiente. Si usas IA donde realmente encaja, puede aportar mucho, pero en muchos casos produce el efecto contrario. Si los participantes tenían suficiente experiencia con IA, quizá sí supieron hacer esa distinción, pero al leer el artículo no me queda claro si fue así
Me pregunto si podrían publicar un dataset anonimizado de datos brutos, o al menos añadir al artículo los tiempos absolutos por desarrollador. Quisiera saber si la persona con más experiencia en Cursor de verdad era más rápida que el resto, o si en realidad ya era lenta y por eso obtuvo una mejora mayor con IA. Da gusto ver una evaluación experimental realmente buena que incluso toma en cuenta el efecto Hawthorne
(No leí el artículo, solo vi el post). Me pregunto si midieron la fatiga subjetiva como un indicador que explique por qué la gente cree que la IA es más rápida. Desde que pasé de desarrollador a gerente, cuando el cerebro ya está cansado, la IA se siente más cómoda y por eso gusta más
Los resultados de este estudio, especialmente la parte de “los desarrolladores esperaban que la IA aumentara su velocidad en 24%, pero en realidad se volvieron más lentos y aun después de la experiencia siguieron creyendo que habían sido 20% más rápidos”, son muy interesantes. ¿Por qué será tan dramática esta brecha entre realidad y percepción? También me pregunto si el cerebro podría estar confundiendo el “esfuerzo mental” con la experiencia subjetiva del tiempo
No tengo evidencia, pero se me ocurre una idea inquietante: ¿y si la interacción con la IA al programar estimula el cerebro de forma parecida a los bucles de dopamina de las redes sociales, aunque en menor grado? Como la IA va ofreciendo respuestas una y otra vez, quizá el cerebro siente que está recibiendo retroalimentación positiva, y por eso el desarrollador la evalúa mejor de lo que corresponde. Si eso incluso generara algún tipo de adicción, ¿no podría llevar a sobreestimar su efecto real en la productividad?
Este fenómeno también podría ser el resultado de una gran campaña que ha llevado a muchísima gente a creer que las herramientas de IA son mejores de lo que realmente son. Economistas, expertos en ML y otros grupos se superponen con los intereses de las empresas de IA, y la dirección ejecutiva toma eso al pie de la letra y promete grandes resultados. Eso termina elevando la expectativa base en todo el ecosistema, e influye incluso en desarrolladores con mucha experiencia. Es difícil demostrarlo empíricamente, pero podría explicar por qué la ilusión colectiva sobre la productividad de la IA se ha difundido tanto
Me pregunto si muchos entusiastas de la IA en los comentarios de HN también están atrapados en este fenómeno. A menos que uno mida realmente su propio rendimiento, queda la duda de si la IA de verdad está aumentando la productividad personal
A veces me pasa exactamente lo contrario. Hoy intenté usar Claude code para crear una app demo de ejemplo; mientras lo veía, era impresionante, casi de ciencia ficción, y divertido, pero después de 15 minutos me sentía mentalmente apagado y aburrido
Al leer “los desarrolladores esperaban que la IA fuera 24% más rápida, y aunque en realidad fueron más lentos creyeron que habían sido 20% más rápidos”, siento que aquí hay dos problemas
Uno es que es muy difícil para una misma persona comparar con precisión cuánto tarda haciendo algo con IA y sin IA en el mismo contexto
El otro es que es fácil medir la eficiencia de la IA con métricas superficiales como el tiempo hasta abrir o hacer merge de un PR, pero en la práctica, al introducir IA, más tiempo se va a refactorización, pruebas, resolución de issues y otros trabajos posteriores
Es fácil engañarse viendo solo “el PR se abrió rápido” y pensar que la IA acelera, mientras se pasa por alto que aumenta el trabajo futuro
Medir el impacto de una tecnología o práctica específica sobre la productividad es realmente difícil. Me parece peligroso concluir algo basándose solo en reportes subjetivos o anécdotas, porque cualquiera puede caer fácilmente en la autoilusión. El propio estudio reconoce sus límites, así que en cualquier discusión sobre productividad conviene tener presente un margen de error grande. La IA es la tecnología más extraña que he visto en mi vida; intentar extraer causalidad de casos aislados o benchmarks dudosos se parece casi a leer el horóscopo
En el artículo no se observó una caída en la calidad del PR entre las condiciones con IA y sin IA. La mayoría de los participantes ya estaba acostumbrada a los estándares del repositorio y no tenía un estilo de “entregar cualquier cosa para abrir un PR”. El tiempo mediano de revisión intermedia de los PR dentro del estudio fue de alrededor de 1 minuto. Como dice el autor, la distribución del tiempo cambia por completo. En la página 10 del artículo aparece el desglose del tiempo con y sin IA: con IA baja el tiempo de codificación, pero ese ahorro se compensa con el tiempo de interacción con la IA
Sobre la objeción de que es imposible saber con exactitud “la diferencia de tiempo cuando la misma persona trabaja con IA o sin IA en el mismo contexto”, el diseño experimental separa el efecto del grupo con IA y del grupo sin IA mediante asignación aleatoria. Las diferencias entre personas, situaciones y entorno se compensan por azar. Si la muestra y el tamaño del efecto son suficientemente grandes, se puede extraer una diferencia estadísticamente significativa
Si miras la Figure 21, el tiempo de implementación inicial (hasta el PR) también aumentó, y aunque después del review del PR se añadió algo más de tiempo, no parece haber tenido un gran impacto en el total. Como se ve en la Figure 18, el tiempo de codificación real sí bajó, pero el ahorro se anuló por el tiempo invertido en escribir prompts, esperar resultados y revisar la salida. En tareas simples de menos de 5 minutos, quizá incluso era mejor no usar LLM
Me gustaría comparar el contenido de los PR entre cada flujo de trabajo. Copilot suele proponer más código del que escribiría yo mismo, y muchas veces eso termina inflando el volumen de código con chequeos innecesarios, repeticiones o abstracciones que no hacen falta. Mi hipótesis personal es que, al ver a un LLM escribir tanto código, se distorsiona la percepción de cuánto tiempo va a tomar realmente resolver el problema
La verdadera dificultad al usar LLM para trabajar en bases de código grandes es describir con precisión lo que hay que hacer. Muchas veces solo explicar un issue en medio de tantas interacciones de código toma más tiempo que resolverlo a mano, mientras que para generar boilerplate en proyectos nuevos parece ser donde mejor encajan los LLM
Solo en reclutar desarrolladores participantes se gastaron 300 x 246 = unos 73K, y el artículo ni siquiera está publicado en una revista ni pasó revisión por pares. A simple vista se ve ordenado y no parece generado por IA, pero me pregunto cómo fue posible financiar algo así
El mayor apoyo financiero vino de The Audacious Project, y se puede comprobar en el anuncio oficial. Además, en una nota al pie del sitio web se indica que hasta abril de 2025 no habían recibido pagos por evaluaciones de empresas de IA
Las empresas suelen publicar este tipo de “whitepapers”. Son una mezcla de informe técnico, propuesta de política pública y material promocional
No creo que tenga mucho sentido fijarse solo en si está en una revista o si tuvo peer review. En ciencia lo importante no es quién publica, sino la reproducibilidad y la repetición de resultados. Como muestra la crisis de replicación en psicología, estar indexado en una revista no garantiza confiabilidad
En la mayoría de los países existen fondos públicos para investigación; en Estados Unidos antes había mucho más apoyo, pero últimamente se ha recortado de forma drástica
Si ves la página sobre la fundación, parece que reciben fondos de muchos lugares, incluidas empresas de IA y gobiernos
En proyectos OSS de hobby, la IA más bien estorba. Generar código o scaffolding no es realmente la preocupación principal; pesan mucho más el code review y la gestión de la comunidad. Hay límites muy claros a lo que las herramientas de IA pueden hacer. Y aun así, alguien mete una herramienta de code review con IA en mi PR abierto y, para un PR de 30 líneas, me escupe un resumen de dos páginas con emojis y viñetas ordenadas. Es puro ruido innecesario, y ahora pierdo más tiempo de mantenimiento borrando u ocultando esos comentarios
Puede que una vez superada la curva de aprendizaje sí te vuelvas más rápido (o, como dijo alguien, “hasta que se te olvide cómo trabajar sin IA”), pero lo que realmente habría que medir es… cuando suena la alerta de PagerDuty a las 3 a. m., cuánto tiempo toma de verdad depurar ese código. Y también me interesa cuál es la calidad de ese código a largo plazo. Yo he pasado mucho tiempo mejorando la estructura del código: subir la lógica de negocio a carpetas compartidas, agrupar hacia arriba las cadenas de llamadas y dejar las APIs más limpias abajo, separar lógica/API/presentación, encapsular mejor, reducir acoplamiento con inyección de dependencias, etc. ¿El código generado por IA tendrá a largo plazo mejor calidad, portabilidad y extensibilidad? ¿O al final se irá acumulando código de baja calidad hasta convertirse en un basurero enredado, donde termines gastando la mitad del tiempo solo corrigiendo bugs?