La IA vuelve más lentos a los desarrolladores de código abierto. Peter Naur puede explicar por qué

• Según una investigación reciente, cuando desarrolladores de código abierto usan herramientas de IA en bases de código que conocen bien, su tiempo de trabajo aumenta 19%
• Los desarrolladores creen que la IA los hizo más rápidos, pero en realidad se vuelven más lentos: existe una brecha entre percepción y realidad
• La causa principal es el sofisticado modelo mental (estructura de comprensión) que tiene el desarrollador y las limitaciones para transferir ese conocimiento a la IA
• Según la teoría de Peter Naur, lo más importante en programación es el "modelo mental" que tiene el desarrollador en la cabeza
  • Pionero danés de la informática y ganador del Premio Turing en 2005. Contribuyó a la notación Backus-Naur Form (BNF) usada para describir la sintaxis de lenguajes de programación
• Desde una perspectiva de largo plazo, para comprender profundamente un proyecto es importante construir el modelo mental escribiendo código directamente

---

El fenómeno de que la IA vuelve más lentos a los desarrolladores de código abierto

• Según el estudio de Metr, usar herramientas de IA hizo que la resolución de problemas fuera 19% más lenta
• Antes de empezar, los desarrolladores esperaban que la IA los ayudara a ser 24% más rápidos y, aun después de terminar, seguían creyendo que habían sido 20% más rápidos de lo real
• El estudio se realizó con desarrolladores experimentados que gestionan directamente proyectos de código abierto que entienden en profundidad
• Aunque los resultados no se pueden generalizar a todos los desarrolladores, sí muestran que en este grupo las herramientas de IA tienen un efecto contraproducente sobre la productividad
• En entornos corporativos o para desarrolladores comunes que deben adaptarse a una nueva base de código, las herramientas de IA podrían tener un papel más positivo en la mejora de la productividad

Por qué la IA vuelve más lentos a los desarrolladores experimentados de código abierto

• Según el artículo de Peter Naur, “Programming as Theory Building”, el verdadero producto de la programación no es el código, sino el ‘modelo mental del desarrollador sobre el proyecto’
• Ese modelo mental es clave para entender el sistema, diagnosticar problemas y mejorarlo de forma efectiva
• La IA basada en LLM no puede acceder directamente al modelo mental del desarrollador y, incluso si se le proporciona parte de la información, se produce una pérdida esencial en la transferencia de conocimiento
  • Por ejemplo, cuando le encargas a alguien dormir a un bebé, aunque se lo expliques claramente, a menudo termina actuando distinto a lo que pretendías
• La transferencia del modelo mental es extremadamente compleja, y es casi imposible que la IA la absorba solo a partir de texto
• Por eso, delegar trabajo a la IA en un proyecto que uno ya entiende en profundidad puede reducir la productividad
• La abundante información contextual y la comprensión intuitiva del desarrollador no pueden ser reemplazadas fácilmente por la IA

¿Deberían prohibirse las herramientas de IA en el trabajo real?

• No necesariamente. Esto aplica solo a “personas que trabajan en proyectos que conocen y entienden bien por sí mismas”
• Muchos desarrolladores en empresas suelen mantener código escrito por seniors que ya se fueron, o trabajar sin comprender a fondo la arquitectura completa del sistema
• En esos entornos, la IA puede contribuir a mejoras de productividad a corto plazo al entender rápidamente la base de código y generar cambios automáticamente
• Si lo que se prioriza es la producción de valor de negocio a corto plazo y la eficiencia inmediata, las herramientas de IA pueden tener un papel positivo en la productividad

Construcción del modelo mental e IA

• Si no existe un modelo mental del proyecto, los LLM pueden ayudar a mejorar la productividad
• Pero si la esencia del desarrollo de software está en la ‘construcción del modelo mental’, depender en exceso de la IA puede deteriorar esa capacidad
• A largo plazo, si quieres entender profundamente un proyecto y transformarlo de forma activa, necesitas la experiencia de escribir código directamente
• En cambio, si el trabajo es más bien del tipo “solo hay que hacer que funcione”, usar IA puede ser eficiente

Discusión adicional y conclusión

• Con las herramientas de IA en su estado actual, es difícil mejorar la productividad de desarrolladores que ya cuentan con un modelo mental suficiente
• Aún hace falta más investigación y avances para que la IA pueda apoyar correctamente los modelos mentales o elevar de forma revolucionaria la productividad de desarrolladores experimentados
• Puede que en el futuro, con modelos más avanzados, llegue el día en que los desarrolladores ya no necesiten tener un modelo mental propio; pero con el nivel actual, la comprensión y el aprendizaje directos siguen siendo indispensables
• En última instancia, la IA puede ser un estorbo en entornos donde uno entiende profundamente lo que está haciendo, y una herramienta de productividad en entornos donde lo importante es obtener resultados rápidos

[paruaa]

> Los desarrolladores creen que la IA los ha hecho más rápidos,
como la investigación con IA se ha acelerado, se puede lograr una mayor calidad, así que incluso en el mismo trabajo, ¿no terminará saliendo con una calidad un poco mejor? Tal vez los desarrolladores piensan que, para desarrollar de acuerdo con la calidad del resultado final, es más rápido llegar con la ayuda de la IA que llegar por su cuenta.
Si para empezar no la hubieran usado, quizás habrían implementado las cosas solo con el conocimiento que ya tenían; eso me hace pensar si no será por eso.

[tested]

> Por el contrario, si se trata de trabajo de "solo hacer que funcione", usar IA puede ser eficiente.

No solo entre los desarrolladores, pero como hay personas con perfiles muy distintos, siento que entre quienes terminaron siendo desarrolladores por casualidad y no les gusta o incluso les da miedo escribir o revisar código, y tienen una mentalidad de que mientras funcione basta en vez de interpretar las cosas desde una perspectiva de estructura sistemática o mantenimiento, tiende a ser más fuerte la dependencia o la fe ciega en la IA. O quizá no sea así.

[xguru]

Medir el "impacto de la IA" en la productividad de desarrolladores experimentados de código abierto

[GN⁺]

Opiniones de Hacker News

• Gente de HN, soy el autor del paper.
  Creo que la entrada del blog abordó de forma interesante un factor concreto que puede contribuir a que la IA ralentice el desarrollo.
  También pueden ver citas de desarrolladores en el paper (sección C.1.5).
  A mucha gente le resulta fácil leer el paper, encontrar un factor con el que se identifica y concluir: “esta única cosa es la razón por la que se vuelve más lento”.
  Pero en realidad hay varios elementos (al menos 5 parecen probables, y no se puede descartar hasta 9; vean la tabla de factores en la p.11).
  Es más razonable un análisis multicausal que asumir que una sola cosa es la causa.
  Si alguien planea probarlo por su cuenta, me gustaría mucho que compartiera los resultados al correo del paper.
  Y sobre que el título del artículo se haya escrito como “AI slows down open source developers. Peter Naur can teach us why”, creo que sería más preciso algo como “A inicios de 2025, la IA ralentiza a desarrolladores experimentados de código abierto. Peter Naur aporta más contexto sobre un factor específico”.
  Puede ser una formulación menos provocadora, pero creo que la precisión importa.
  Gracias de nuevo por el gran artículo; sigo leyendo los comentarios
  Discusión relacionada anterior
  Paper completo
  • Tengo una curiosidad personal: en el estudio, ¿cómo midieron de forma confiable cuánto cambió realmente el tiempo requerido antes y después de usar IA? Me pregunto si, por ejemplo, hicieron que el desarrollador estimara cuánto tiempo se ahorraría usando IA y luego midieron el tiempo real de uso para ver la diferencia. Y cuando era difícil estimar la dificultad de un issue o el tiempo necesario para resolverlo, también me interesa saber cómo controló eso el equipo de investigación. Entiendo perfectamente que este tipo de medición es realmente compleja
  • Coincido con los resultados y agradezco la respuesta. No planeo cambiar el título porque me gusta el estilo más radical, pero sí voy a corregir claramente en el artículo lo que esté mal expresado. En el texto que escribí, señalé que factores que contribuyen de forma importante a los resultados del estudio —“alta familiaridad del desarrollador con el repositorio”, “repositorios grandes y complejos”, “contexto implícito del repositorio”— van en la misma línea de la investigación. También me gustaría hacer el experimento yo mismo, pero me parece muy difícil crear un entorno controlado mientras atiendo exigencias de trabajo. Además, faltan listas de tareas claras que puedan completarse en poco tiempo
  • Si cambias un flujo de trabajo ya optimizado en un proyecto que conoces bien, esperaría que al principio te vuelva más lento. Lo importante es ver cómo estarán esos desarrolladores en 6 meses o 1 año. Este estudio no muestra la tendencia de largo plazo, así que ojalá investigaciones futuras puedan decirnos cómo cambia el desempeño del mismo desarrollador después de habituarse. Yo también he experimentado que, con IA, puedo convertir en scripts muchas tareas que antes eran difíciles de automatizar. Siempre hay que hacerse la pregunta: “¿esto vale el tiempo que cuesta?”
    Cómic de xkcd sobre gestión del tiempo
  • También mencionaría que incluso “a inicios de 2025 la IA ralentiza a desarrolladores experimentados de código abierto” sigue siendo una generalización excesiva. Hay tareas concretas en las que la IA sí puede ahorrar tiempo, así que el efecto depende del tipo de trabajo
  • Que te vuelva más lento no necesariamente es malo; creo que la programación lenta (programación literaria / estilo Knuth) incluso ayuda más a la teorización. También se puede defender que es importante un desarrollo lento, con suficiente reflexión y abstracción, en lugar de programación tipo comida rápida
• Me identifico con ese fenómeno de que “el desarrollador no se da cuenta si la herramienta realmente lo hizo más rápido o más lento”. Lo compararía con un bote que se desvía del objetivo por el viento y la corriente: uno solo percibe el progreso según el movimiento a su alrededor, pero intuitivamente le cuesta saber si realmente se está acercando a la meta. Por eso tendemos a elegir estrategias que nos hagan sentir “que avanzamos”, y eso puede llevarnos a rutas ineficientes o incluso más lentas en la práctica (por ejemplo, al manejar y estar doblando constantemente a la derecha)
  • Cuando empecé a usar herramientas de IA, me gustaba esa sensación de que el trabajo fluía sin trabas. Pero en realidad me pasaba que, aun cuando arreglar una sola línea por mi cuenta era más rápido, terminaba llamando a la IA por costumbre. Similar a la analogía de manejar: si cierta ruta se bloquea, es fácil volver una y otra vez al GPS que te recomienda retomar el camino anterior
  • Es parecido a cómo apps de navegación como Waze a veces te mandan por rutas más largas, pero por tantos desvíos enredados te hacen sentir que “sigues avanzando” y entonces crees que vas más rápido. Con las herramientas de IA también se siente que programar es más fácil, pero la productividad real puede bajar. Los humanos tendemos a recordar la experiencia de avanzar sin dolor a corto plazo, y como no fue difícil sentimos que progresamos
  • Al final, los humanos preferimos por instinto los algoritmos voraces (greedy algorithm)
  • Los usuarios de Linux/Unix creen que el control por teclado y las herramientas CLI son lo más eficiente, pero hay estudios que muestran que para la mayoría de las tareas el mouse es más rápido. La razón por la que se siente más rápido escribir con teclado es que hay más acciones por segundo
  • El código generado por IA casi no se revisa, y a muchos desarrolladores la revisión de código en sí les cuesta tanto que se niegan a leerlo. Por eso aparecen fenómenos como la popularidad de frameworks nuevos o reescrituras de código
    Joel on Software: Things you should never do, part I
    Mucho código generado por IA simplemente se produce, pasa pruebas simples y ahí queda. Incluso aumenta la cantidad de código cuyo contexto general o razón de ser ni el propio autor entiende lo suficiente
• La idea central de este estudio puede resumirse como: “la IA hace que parezca que la mejora de productividad es mayor de lo real”. Solo algunos participantes tuvieron una ligera mejora de productividad; la mayoría, de hecho, empeoró bastante. Mucha gente dice que gracias a la IA su productividad explotó, pero se está ignorando la conclusión del estudio de que ese efecto mismo podría ser una ilusión. La IA es un producto optimizado para hacer que el usuario sienta que debería usarlo y que es útil. El valor personal es una realidad percibida y eso no se puede negar, pero quien depende mucho de la IA de verdad debería cuidarse de la distorsión de la autopercepción, de la falsa sensación de logro y de la dependencia de la herramienta. La IA a veces responde con un flujo de tokens optimizado, pero vale la pena preguntarse cuál es el verdadero objetivo de esa optimización
  • Los LLM sí ayudan al aprender algo, pero siento que esa comprensión termina siendo muy abstracta y “al estilo LLM”. Al aprender, me parece mejor mezclar varios métodos
  • Las herramientas de IA no hacen que el desarrollador se sienta tanto “rápido” como “ágil en el momento”. Hay algo parecido a la ilusión de menor carga mental; es un fenómeno interesante que surge porque cambia la sensación misma en otros bucles de retroalimentación y también el mecanismo de formación de recuerdos
• Mientras se discutía el estudio de que “si desarrolladores experimentados de código abierto usan IA al trabajar en sus propios proyectos, se vuelven más lentos”, me tocó trabajar en una base de código de otra persona, de 3 meses de antigüedad, y con un framework que no conocía. Pero usando Claude Code, en apenas unas horas pude completar rápidamente cosas (como sincronización de datos) que en otros proyectos antes me habrían tomado uno o dos días, o hasta dos semanas. Fue un jumpstart enorme. Supongo que, a medida que aumente la complejidad, se volverá más lento, pero me sorprendió lo rápido que fue arrancar con ayuda de la herramienta
  • Yo tuve una experiencia parecida, pero lo que dice este estudio no trata de ese ramp-up que vivimos nosotros, sino de desarrolladores de código abierto ya muy familiarizados que hacen tareas con IA. Los LLM sí aceleran claramente la adaptación a una base de código nueva, pero una vez que ya la conoces, he sentido que más bien estorban
  • Siempre acompaña la conversación de productividad eso de “un PR de 2 semanas en unas horas”, pero pocas veces se comprueba qué tan precisos somos realmente al estimar tiempos de desarrollo. También hay que revisar si la calidad de un PR sacado tan rápido es la que originalmente se esperaba, o si por correr se omitió contexto importante del sistema y eso aumenta la probabilidad de bugs. Incluso sin IA, si sacrificas calidad, avanzas más rápido
  • También me pregunto si gracias a la IA realmente ha aumentado de forma natural el dominio promedio de la base de código y del sistema. El efecto de aprendizaje al usar LLM se siente como poder leer un idioma nuevo, pero no hablarlo desde cero. En C++, por ejemplo, puedes leer y modificar lo existente, pero arrancar algo nuevo desde dónde empezar ya cuesta más
  • Solo quería decir que obtuve un jumpstart enorme gracias a las herramientas de IA, no criticar el estudio, el artículo ni el paper. Quería señalar que en ciertos contextos la IA sí ayuda de verdad. Y no se trata solo de escribir código: por ejemplo, Claude Code incluso intentó conectarse directamente a un clúster de AWS desde un contenedor interno del proyecto, y eso me ayudó mucho a entender toda la infraestructura y la arquitectura. En mi experiencia, en 80~90% de los casos se prioriza el “valor de negocio” por encima de la calidad del código. No sé qué tan útil será en trabajos donde la calidad del código sí sea crítica, o en áreas que requieran algoritmos o estructuras de datos especiales. Pero también he visto que, si le das buenos ejemplos y contexto claro, produce código bastante usable. Estas herramientas mejoran cada semana o cada mes a gran velocidad. Al final, la IA no es magia sino una herramienta, y la responsabilidad por el producto o el resultado sigue siendo de uno mismo
  • Hay que tener presente que el paper (TFA) trata casos en proyectos muy familiares. Lo que yo viví fue justo lo contrario: la IA brilló sobre todo en un entorno desconocido
• Citando la analogía de que “las herramientas agentic de IA (Claude Code, Amp, Gemini CLI, etc.) son para la programación lo que la sierra de mesa fue para la carpintería”, se argumenta que, si aprendes a usarlas, puedes hacer ciertos trabajos más rápido y mejor, pero si no estás familiarizado también puedes terminar lastimándote los dedos. En lo personal, gracias a la IA agentic me animo a intentar proyectos más ambiciosos, y como le delego tareas repetitivas o que no me gustan, me queda más espacio mental. Pero también hay que cuidarse de no dejar que haga todo por ti y limitarse a hacer commits sin entender nada. Como cualquier herramienta, hace falta esforzarse por aprender a usarla mejor
  • No me parece que la analogía con la sierra de mesa encaje. Una sierra de mesa es una herramienta precisa comparada con herramientas manuales, y la IA agentic está lejos de ser precisa
  • La lógica de “estás usando mal la IA” resulta ofensiva para desarrolladores que ya habían construido stacks completos de código abierto antes de que existiera la IA. Además, todavía no hay evidencia de que la IA haya producido software valioso por sí sola
• En este estudio, solo hubo un desarrollador con más de 50 horas de experiencia en Cursor (incluyendo el tiempo de participación en la investigación), y ese desarrollador experimentó una mejora de velocidad del 25%. Todos los demás eran principiantes, y si un principiante usa una herramienta nueva, es obvio que se volverá más lento. No creo que se pueda sacar una conclusión sobre productividad de la IA solo con este estudio
  • Si revisas los detalles del paper, estudios anteriores con participantes de experiencia similar con la herramienta (o incluso menor) reportaron aumentos de velocidad. La mayoría ya tenía suficiente experiencia usando prompts con LLM, y además Cursor se parece a VSCode, así que tampoco hay una curva de aprendizaje enorme. Si todos los desarrolladores llegaran a volverse extremadamente dependientes de las herramientas de IA, su capacidad al trabajar sin IA podría deteriorarse; entonces, al usar IA, podría parecer que son más rápidos simplemente porque el punto de referencia ya empeoró. Lo importante no es qué herramienta usaron, sino la idea central de que los autoreportes de productividad eran excesivamente optimistas frente a la realidad. Para evaluar el efecto real hacen falta métricas concretas
    (Se trata con más detalle en la sección C.2.7 del paper, “Uso de herramientas de IA por debajo del promedio”)
  • Si un desarrollador lleva muchos años usando su IDE (Vim/Neovim, etc.), al cambiarse a una herramienta nueva (como Cursor) su productividad podría caer notablemente durante meses
  • Pienso lo mismo. Un desarrollador que usa herramientas que no domina inevitablemente se vuelve más lento. La IA no es la excepción
• Aclaro que actualmente soy revisor regular de código en Burn (framework de deep learning basado en Rust). Hace poco cerré un PR de bugfix que parecía haber sido escrito enteramente por un agente de IA. Ese PR no resolvía la causa del problema; simplemente ignoraba el error, añadía código innecesariamente verboso a modo de justificación e incluso incluía pruebas para ignorar el error. Parecía hecho solo para dejar un commit registrado. Me preocupa que este tipo de abuso de la IA se esté extendiendo como tendencia
  • Es curioso cómo, cuando un LLM no sabe la respuesta correcta, suelta cualquier cosa, pero si le señalas que está mal responde algo como “sí, tienes razón, lo corrijo”. De verdad me preocupa que la gente sin experiencia no pueda distinguir estos problemas, o que poco a poco deje de prestar atención al código. También temo que empecemos a ver una avalancha de vulnerabilidades y casos de abuso
  • Revisando el MR de un colega, encontré casos de prueba que claramente se notaban generados por IA (solo cambiaban nombres como thing1, thing2, etc., mientras el contenido era siempre igual). Le sugerí usar nombres más distinguibles, y esta vez la IA terminó poniendo nombres demasiado verbosos, como enumerando todas las características de cada caso, de modo que el código dejó de leerse de un vistazo. Quizá el autor sintió que había acelerado muchísimo la escritura, pero en la práctica el tiempo invertido en feedback, revisión y correcciones borró cualquier ganancia de productividad
  • También hubo un comentario en tono de broma sobre “framework de deep learning en Rust → círculo vicioso con la IA”
  • En realidad, ese ambiente de usar IA para dejar commits registrados ya existe desde hace tiempo. La IA solo facilita aún más producir spam simple
    Referencia: viejo problema de spam con IA
  • Se señala que los LLM tienden a usar bloques try:catch demasiado amplios, lo que dificulta rastrear la fuente del problema. Yo prefiero que el problema falle rápido y de forma contundente (fail fast) para corregirlo de inmediato
• Comparto mi impresión: programar con IA me corta mucho el flujo de concentración y me fatiga más fácilmente. Eso de programar todo el día es un mito; lo normal es concentrarse 1~3 horas, descansar en medio, y así. Incluso leer código o cambios de colegas cuenta como tiempo de trabajo, pero no necesariamente como progreso real. La IA agentic (pequeños refactors, etc.) puede ser útil, pero no tanto como para dar una mejora enorme de productividad. El autocompletado de código (por ejemplo, Copilot al principio) más bien agrega demasiado ruido innecesario
  • Si uno grabara lo que realmente hizo en un día entero, el resultado probablemente sería bastante deprimente. Sobre todo en bases de código maduras, hasta una hora de concentración podría ser una exageración
• Al depurar un bug complicado (por ejemplo, una race condition) en una base de código desconocida, es indispensable agregar logging, reemplazar funciones de librería, mejorar la estructura, etc. Si la IA solo te da una solución rápida del tipo “la carrera está aquí y se arregla así”, eso puede terminar perjudicando la comprensión de la estructura y de la lógica del código. A largo plazo, si sigue dominando la edición de código guiada por IA, el código mismo podría degradarse hasta el punto de que ni la propia IA pueda reaccionar ya de manera adecuada
  • Cada vez que escucho la historia de alguien que “contribuyó a un código en un lenguaje y base de código que no conocía gracias a la IA”, pienso que a corto plazo puede estar bien, pero me pregunto qué aprendió realmente. Tal vez este tipo de contribuciones sirva para tareas pequeñas, pero no siento escuchar muchas historias de mantenimiento a largo plazo
• En la retrospectiva de mi primer proyecto donde usé herramientas de IA de forma activa, mi conclusión fue: 1) no me hizo más rápido, 2) quizá incluso me hizo más lento, 3) la calidad del resultado sí mejoró. La ralentización y la mejora de calidad están conectadas, porque la usé sobre todo como apoyo para validar ideas o explorar alternativas. Gracias a la IA también tuve una buena experiencia de aprendizaje en áreas que no conocía, y en mi área principal el resultado mejoró porque fui puliendo mis ideas o las de la IA. La velocidad no es lo único importante; aunque la calidad sea difícil de cuantificar, lo siento suficientemente valioso
  • Justamente porque la IA puede contribuir a mejorar la calidad, últimamente prefiero una IA que discuta, que no esté de acuerdo a ciegas. Si le pido ideas y le digo que ataque los problemas o que busque junto conmigo los puntos débiles de mis ideas, resulta productivo. Puede que no termine implementando nada, pero me ayuda a pensar en ángulos que antes no se me habrían ocurrido. En la práctica, se parece a conversar con un colega capaz de opinar razonablemente sobre el dominio

[eususu]

Yo también tenía una idea parecida, pero me costaba expresarla con claridad.
Modelo mental es un nombre muy acertado. Voy a tratar de usarlo de vez en cuando.