Introducción ‒ Malentendidos y realidad sobre la productividad de los desarrolladores con IA
- Mark Zuckerberg (CEO de Meta) declaró que "para finales de 2025 reemplazará a todos los ingenieros de nivel medio con IA", y eso ha puesto la misma presión sobre los CTO de distintas empresas.
- El ponente deja claro que "la IA no puede reemplazar por completo a los desarrolladores" y enfatiza que, aunque adoptar IA sí ayuda claramente a la productividad, no siempre ocurre así, y tampoco es raro que la productividad disminuya.
Diseño de la investigación y datos
- Medición realizada durante 3 años sobre más de 600 empresas, más de 100 mil ingenieros de software, más de mil millones de líneas de código y decenas de millones de commits.
- La mayoría de los datos provienen de repositorios privados (Private Repo), lo que permite medir cambios reales de productividad a nivel de equipo y empresa.
Limitaciones de los estudios previos
- Los reportes impulsados por proveedores suelen tener como objetivo promocionar sus propias herramientas de IA, por lo que carecen de objetividad.
- Contar simplemente commits/PR o cambios en el tiempo promedio de trabajo puede distorsionar la productividad real.
- Ejemplo: justo después de usar IA también aumentan los commits de bugs o de retrabajo (
rework), así que superficialmente puede parecer que la productividad subió.
- Ejemplo: justo después de usar IA también aumentan los commits de bugs o de retrabajo (
- En los "experimentos greenfield (proyectos nuevos)", el efecto de la IA parece muy grande, pero en código existente (brownfield) la diferencia se reduce.
- Las encuestas a desarrolladores (
self-report) tienen poca correlación con la productividad real (hay una brecha percibida vs. real de más de 30 puntos porcentuales).
Modelo de medición de productividad de Stanford
- Uso de un modelo automatizado basado en IA similar a una evaluación por panel de expertos:
- Medición por commit de cambios funcionales (
added/removed/refactored/rework) - El foco no está en la simple "cantidad de líneas", sino en "funcionalidad, mantenibilidad y calidad"
- Medición por commit de cambios funcionales (
- Evalúa con precisión el volumen de incorporación de funcionalidades, refactorización y la proporción de retrabajo (
rework) en commits recientes.
Principales hallazgos del estudio
- En general, al adoptar IA la productividad promedio aumenta entre 15% y 20%.
- Sin embargo, también viene acompañada de una cantidad considerable de "retrabajo" (
rework), por lo que los beneficios percibidos tienden a exagerarse.
- Sin embargo, también viene acompañada de una cantidad considerable de "retrabajo" (
- Hay grandes variaciones según el equipo, la empresa y el tipo de tarea.
Causas de la brecha de productividad: dificultad de la tarea, tipo de proyecto, lenguaje y tamaño del codebase
| Tipo de proyecto | Baja complejidad | Alta complejidad |
|---|---|---|
| Greenfield (nuevo) | 30~40% ↑ | 10~15% ↑ |
| Brownfield (existente) | 15~20% ↑ | 0~10% ↑ |
- En proyectos nuevos (greenfield) y de baja complejidad, el efecto de la IA es grande.
- En sistemas existentes (brownfield) y complejos, el efecto se reduce claramente, y en algunos casos incluso se encontraron casos de caída de productividad.
- Según lo mencionado en la charla, esto se basa en una muestra real de 136 equipos de 27 empresas.
Popularidad del lenguaje y efecto de la IA
- En Python/Java/JavaScript (lenguajes populares), la mejora de productividad con IA es mayor.
- En COBOL/Elixir/Haskell (lenguajes poco populares), la IA casi no ayuda y, en tareas complejas, incluso puede hacer perder tiempo y bajar la productividad.
- Ejemplo: en el caso de lenguajes poco populares y alta dificultad, "comete muchos errores y no produce código correcto" → es mejor no usarla.
Tamaño del codebase y efecto de la IA
- Mientras más grande es el codebase, más se reduce drásticamente el efecto de mejora de productividad de la IA.
- Causas:
- Límite de la ventana de contexto: un LLM no puede incorporar todo el contexto de múltiples archivos o de cientos de miles a millones de líneas.
- Disminución de la "relación señal/ruido": a medida que aumenta la información contextual, la IA no logra identificar correctamente la información relevante.
- A mayor complejidad por dominio o servicio, también sube la dificultad real de reimplementación.
- De hecho, en LLM grandes recientes (como Gemini 1.5 Pro), conforme aumenta el número de tokens, la precisión cae bruscamente de 90% a menos de 50%.
- Causas:
Resumen general: ¿cuándo es efectiva la IA?
- En la mayoría de los casos, la IA sí mejora claramente la productividad de los desarrolladores, especialmente al escribir código nuevo y simple.
- Pero en entornos con mantenimiento complejo, código antiguo (y grande), lenguajes no mainstream y muchas dependencias, sus limitaciones son importantes.
- La mejor estrategia de productividad con IA debe diseñarse cuidadosamente según las características de la empresa, el equipo y la tarea; no existe un enfoque one size fits all.
- Es difícil confiar en encuestas, métricas de marketing o simples aumentos en el número de commits; se necesita una medición basada en la realidad, considerando funcionalidad real del código, proporción de trabajo repetitivo y volumen de retrabajo.
Comentarios y casos adicionales
- "Ingeniero fantasma": en sus datos también encontraron que el 10% de los ingenieros casi no trabaja y solo recibe salario.
- Se enfatiza la necesidad de herramientas de toma de decisiones basadas en métricas para que líderes de equipo y CTO puedan diagnosticar rápidamente los problemas reales.
Conclusión
- La IA aumenta la productividad en "la mayoría de las situaciones", pero hay que cuidarse tanto de sobreestimarla como de subestimarla.
- Conviene identificar las condiciones concretas en las que sí da buenos resultados (simple/nuevo/lenguaje popular/codebase pequeño) y aplicarla ahí, ya que una adopción acrítica e indiscriminada puede incluso generar efectos contraproducentes.
2 comentarios
Aunque no se aplique al software principal, la IA ahorra muchísimo tiempo en programas de prueba o en la etapa inicial de un proyecto.
Incluso dejando de lado que escriba código, creo que las funciones de asistente cambiaron del cielo a la tierra desde que se incorporó la IA. Ahora creo que vivimos en una época en la que la IA ya no es una opción, sino algo indispensable.
En la práctica ayuda mucho en el MVP. En especial, creo que sí o sí hay que usarlo para comentarios, logging y redacción del historial.
Pero cuando la base de código crece, aparecen las alucinaciones, olvida el código existente y produce resultados raros. Hay que pensar en usar ingeniería de contexto o en cómo reducir la base de código.
Probablemente mejoraría si se pudieran usar prompts más grandes.
Por ahora parece funcionar bien con Java, Python, JavaScript y Go. Uso sobre todo Copilot, y también Claude y ChatGPT.