IA: 30% más código, pero no más software nuevo

El debate que abrió Nate Meyvis: más código, pero no más software

Un estudio sobre 300 millones de eventos de trabajo en más de 700 empresas de software encontró que los agentes de código de IA elevan la producción de código un 30%, pero no mueven la aguja en funcionalidades terminadas. Esa es la paradoja que Nate Meyvis pone sobre la mesa en un ensayo publicado en su blog: si la IA para programar es tan buena, ¿por qué no vemos ya una ola de software nuevo y bueno?

Para un founder, la pregunta no es filosófica. Es de asignación de capital. Si tu equipo escribe el triple de código y el negocio no lo nota, el problema no está en la herramienta sino en el sistema que la rodea.

Las hipótesis del ensayo: el software existe, pero no lo ves

Meyvis no da una respuesta única, sino una lista de hipótesis que él mismo califica de especulativas. Se ordenan en tres familias.

La primera: sí hay mejor software, pero no lo percibimos como software nuevo. Menos bugs, mejor rendimiento, más funciones en productos que ya usas. La mejora se disuelve dentro de lo existente en lugar de aparecer como una aplicación nueva.

La segunda: el software se volvió privado y efímero. Expertos de dominio construyen sus propias herramientas, ejecutivos arman sus propios dashboards y las empresas desarrollan proyectos internos a medida. Ese software existe, pero no es visible desde afuera. En paralelo, mucha gente resuelve tareas directamente con un modelo de lenguaje en lugar de comprar o construir una aplicación dedicada: el beneficio es real, la "app maravillosa" nunca aparece.

La tercera: estamos haciendo más software en vez de mejor software, y los equipos capturan parte de la velocidad en forma de tiempo libre. Meyvis lo resume con una imagen potente: el equipo ofrece a la empresa el doble de velocidad, usa herramientas que le permitirían trabajar diez veces más rápido, y se toma cafés largos.

¿Qué dicen los datos sobre la productividad de la IA?

La hipótesis tiene respaldo empírico. Un estudio de las investigadoras de Harvard Fiona Chen y James Stratton, basado en datos de Jellyfish sobre 300 millones de eventos de trabajo y más de 700.000 empleados en más de 700 firmas de desarrollo entre 2021 y marzo de 2026, encontró que la introducción de agentes de código produce un aumento del 30% en líneas de código, un 20% más de commits y un 23% más de pull requests, según reportó Ars Technica.

Pero la tasa de resolución de Issues y Epics —es decir, funcionalidades completas— no cambió de forma estadísticamente significativa. El código extra se queda atascado en el proceso.

El estudio de Leon Musolff (Wharton) junto a Mert Demirer y Liyuan Yang (MIT), que siguió a más de 100.000 desarrolladores en GitHub entre 2022 y 2026, llega al mismo lugar desde otro ángulo. El autocompletado elevó la actividad de código un 40%; los agentes síncronos llevaron el acumulado al 140%; los agentes asíncronos, al 180%. Todo eso se tradujo en apenas un 50% más de proyectos y un 30% más de releases, según Knowledge at Wharton.

El cuello de botella se mudó a la revisión y el despliegue

Si el código ya no es el límite, ¿dónde está? En la revisión, la integración y la distribución. El informe ROI of AI-Assisted Software Development (2026.01) del equipo DORA de Google Cloud describe dos costos que casi nadie presupuesta: el impuesto de verificación (el tiempo de revisar código generado) y el impuesto de inestabilidad (más cambios rápidos desbordan los pipelines y las puertas de revisión manual), según InfoQ.

El propio modelo del informe ilustra el punto: en una organización de 500 ingenieros, la tasa de fallo de cambios sube del 5% al 6% tras adoptar IA, lo que se traduce en un impacto negativo de 344.000 dólares por caídas. Aun así, el escenario base proyecta un retorno de aproximadamente 11,6 millones de dólares contra una inversión de 8,4 millones en el primer año, con un ROI del 39% y un período de repago de unos ocho meses.

La letra chica importa: DORA advierte que la mayoría de las organizaciones atraviesa primero una caída temporal de productividad —la "curva J"— antes de capturar las ganancias. El informe la llama "el costo de matrícula de la transformación" y sostiene que los líderes que la leen como fracaso cortan el financiamiento justo antes del retorno.

Hay una advertencia adicional sobre la percepción. Según Forbes, un ensayo controlado aleatorio de METR en 2025 con 16 desarrolladores open source experimentados encontró que esperaban ser un 25% más rápidos con IA, creían haberlo sido, y en medición objetiva terminaron un 19% más lentos.

¿Por qué hay más apps pero los mismos usuarios?

El otro tramo del embudo tampoco ayuda. El estudio de Wharton revisó los cuatro mayores mercados de software —Apple App Store, Google Play, Chrome Web Store y SourceForge— y encontró un salto fuerte en lanzamientos desde mediados de 2025, sin aumento en el uso total.

En la App Store, los lanzamientos mensuales pasaron de unos 30.000 antes de la llegada de los agentes de código a comienzos de 2025 a cerca de 100.000 por mes hacia abril de 2026. El uso agregado se mantuvo plano o cayó. Como resume Musolff, puede ser simplemente que descubrir una aplicación nueva sea mucho más difícil cuando hay una inundación de ellas.

Ahí conecta con la tercera hipótesis de Meyvis: la IA no solo cambia cómo se produce software, también puede empujarnos a usar menos software. Si resolver algo con un modelo es suficiente, la categoría entera de producto que iba a existir deja de existir.

¿Qué significa esto para tu startup?

Mide el sistema, no el código. Líneas generadas, aceptación de sugerencias y velocidad individual son métricas locales. Si tu tablero se ve bien y la cadencia de releases no cambia, el cuello de botella está en aprobaciones, pruebas de regresión o entornos. Empieza a medir tiempo desde el pedido hasta el release validado, y retrabajo posterior a marcar una feature como terminada.

Invierte aguas abajo antes de escalar agentes. DORA es explícito: el retorno escala con la madurez del sistema que rodea a la IA. Testing automatizado, integración continua y lotes pequeños son lo que convierte el throughput extra en valor, en lugar de en inestabilidad. Si vas a sumar agentes asíncronos, hazlo después de tener esa base.

Presupuesta el bache. La caída temporal de productividad del primer año es un costo esperado, no una señal de que la apuesta falló. Definir de antemano el escenario conservador y el optimista evita la conversación incómoda con finanzas a mitad de camino.

Revisa si tu mejor software es interno. Si parte del valor se está yendo a herramientas privadas —dashboards de dirección, automatizaciones de un equipo, scripts de un experto de dominio—, ahí hay producto. Vale la pena preguntarse cuáles de esas herramientas internas resuelven un problema que otros también tienen.

Conclusión

El ensayo de Meyvis acierta en el diagnóstico: la ausencia de software nuevo y bueno no prueba que la IA no funcione, prueba que el código nunca fue el único cuello de botella. Los datos de Harvard, Wharton y DORA coinciden en que la restricción se movió a la revisión, la integración y la distribución, y que el software generado se está volviendo más privado, más efímero y más difícil de descubrir.

Para un founder, la lectura práctica es incómoda pero clara: comprar herramientas de IA es la parte fácil. Rediseñar el proceso que las absorbe es donde está el retorno. Y si tu equipo ya está capturando esa velocidad en forma de cafés largos, quizá el problema no sea la herramienta, sino que nadie definió qué hacer con el tiempo que libera.

Fuentes

• Where is all the new, good software? (fuente original)
• AI coding agents generate more code, but not more software
• AI Is Producing More Software. Why Isn't It Being Used?
• New DORA Report Claims Strong Engineering Foundations Drive AI Return on Investment
• Software Engineering Productivity: You're Measuring The Wrong Thing