Por qué la IA fracasa en la entrega de software ágil: ejemplos y soluciones para Engineering Managers

Muchos CTO esperan mucho del uso de IA en la entrega ágil de software: más velocidad, más automatización, más output. Eso suele ser cierto a corto plazo. Y aun así, muchos equipos y CTO no logran demostrar cómo esta aceleración local se traduce en beneficio para el cliente y en valor añadido para el negocio.

El problema es que, en el entusiasmo por la IA, las empresas optimizan las cosas equivocadas: más tokens en lugar de más valor para el cliente, más código en lugar de más confianza, más agentes en lugar de mejores sistemas de entrega.

Este artículo enlaza deliberadamente con nuestros otros dos textos:

• IA en el desarrollo de software ágil: base de estudios 2026 .
• Guía para CTOs y Engineering Managers sobre desarrollo de software asistido por IA .

Aquí se trata del puente entre ambos extremos: ¿por qué fracasa la IA en la entrega ágil de software en la práctica? Los ejemplos mostrarán de forma concreta lo que pueden hacer los managers y qué soluciones realmente sostienen el esfuerzo.

Por qué la IA optimiza tan a menudo el objetivo equivocado en la entrega de software ágil

En cuanto la IA se introduce como palanca de productividad, en muchas empresas ocurre algo muy previsible: lo medible se convierte en el objetivo. Eso se refleja en la nueva tendencia Tokenmaxxing. Pragmatic Engineer sobre la tendencia Tokenmaxxing

Lo que se quiere decir con esto es que las empresas o los equipos tratan implícita o explícitamente un alto consumo de tokens como señal de un buen uso de la IA. Esto es peligroso desde el punto de vista empresarial y organizativo. Porque los tokens, como mucho, son una medida de entrada, pero no una medida de valor.

El patrón es antiguo. Antes se sobrevaloraban las “Lines of Code” como métrica; hoy, el consumo de tokens o los paneles de uso de IA. En ambos casos se aplica una variante de la ley de Goodhart: en cuanto una métrica se convierte en objetivo, pierde su valor como métrica. Martin Fowler sobre Lines of Code como problema de métrica, Wikipedia sobre la ley de Goodhart

Para la IA en la entrega ágil de software, eso significa: quien maximiza la actividad a corto plazo, a menudo obtiene más actividad de IA. Pero no automáticamente una mejor entrega ágil de software.

La situación de los estudios al respecto es desalentadora: a nivel individual ya se observan claros efectos de productividad, pero a nivel de equipo y de organización hay significativamente menos mejoras sólidas y demostrables. Aquí hemos resumido los detalles: Sobre el estado de la investigación en 2026 sobre la IA en el desarrollo ágil de software

Cuatro ejemplos típicos de cómo fracasa la IA en la entrega ágil de software

El primer fallo es banal: los equipos producen muchas más modificaciones, pero comprenden realmente una parte cada vez menor de ellas.

Para los managers, al principio a menudo se ve bien:

• más pull requests
• primeras implementaciones más rápidas
• más historias “terminadas”

La contrapartida llega más tarde:

• las revisiones se vuelven más superficiales
• la responsabilidad se diluye
• el análisis de incidentes tarda más
• se evitan los refactors porque ya nadie está seguro de qué podría romperse y dónde

Kent Beck describe en su artículo “Trust Factory” que prácticas como las pruebas, las revisiones, el refactoring y la entrega incremental construyen sobre todo confianza. Precisamente esa confianza se pierde cuando la IA produce más rápido de lo que el equipo puede entender, comprobar y asumir como responsabilidad. Kent Beck en Trust Factory sobre la confianza en la ingeniería

Addy Osmani describe un riesgo similar como Comprehension Debt: cuando los equipos entregan cada vez más código que ya no comprenden activamente, con cada cambio crece la distancia entre el sistema y la comprensión. Addy Osmani sobre Comprehension Debt

Esto también encaja con hallazgos más amplios de la práctica: según una encuesta de Sonar resumida en 2026, la mayoría de los desarrolladores no confía plenamente en la corrección funcional del código generado por IA, y una parte considerable incluso considera que revisarlo requiere más esfuerzo que comprobar cambios escritos por personas. El problema, por tanto, no es solo la mala calidad, sino el esfuerzo adicional de verificación y comprensión. ITPro sobre la encuesta de Sonar acerca de la Verification Debt

El segundo fracaso es aún más costoso para los líderes: la IA reduce el coste de producir, pero no automáticamente el coste de equivocarse.

Si los equipos han recortado mal los requisitos, los han validado de forma insuficiente o solo los han alineado internamente, la IA simplemente acelera el trabajo equivocado. Kelsey Hightower lo resume de forma muy directa en su publicación de LinkedIn: “Productivity doesn’t matter if you’re working on the wrong thing.” Publicación de LinkedIn de Kelsey Hightower sobre la productividad errónea

Precisamente en esa línea argumenta también Andrew Ng en una conversación muy citada de 2025: la IA ha acelerado mucho el coding, pero con ello se desplaza el verdadero cuello de botella. Ya no es la implementación el problema principal, sino la cuestión del producto:

¿Qué deberíamos construir en absoluto y con qué rapidez aprendemos del feedback real de los usuarios?

Fuente: Conversación de Business Insider con Andrew Ng sobre el cuello de botella en la gestión de producto

Por eso la IA en la entrega ágil de software solo puede tener éxito con una verdadera cercanía al cliente. Si el camino del prompt al código se vuelve más rápido, pero el camino del código al feedback del cliente sigue siendo lento, solo aumentan el output y el volumen de cambios.

La investigación sobre el trabajo ágil de producto también muestra exactamente este patrón en otro nivel: en un estudio de caso del sector sobre Agile Epics, los investigadores describen que unos requisitos mal definidos provocan churn, retrasos, problemas de calidad y costes innecesarios. La IA no puede resolver mágicamente estos cuellos de botella. Como mucho, puede materializarlos más rápido. Estudio de arXiv sobre Agile Epics y la calidad de los requisitos

Por eso, el contrapunto decisivo al uso ciego de la IA no es menos IA, sino una mejor entrega ágil. Quien busque las palancas transversales para ello, las encontrará aquí: Guía sobre el futuro del desarrollo de software ágil asistido por IA

Muchas visiones de futuro sobre la IA en la entrega ágil de software resultan atractivas porque hacen desaparecer elegantemente la responsabilidad: un agente analiza el feedback de los usuarios, el siguiente escribe los requisitos, el siguiente implementa, el siguiente prueba y el siguiente despliega.

Técnicamente, parte de eso es posible. Organizativamente, se vuelve difuso rápidamente.

Precisamente en la desarrollo de software agentico debe plantearse con más firmeza la vieja pregunta de gestión: ¿Quién decide? ¿Quién revisa? ¿Quién asume las consecuencias? IBM formula el problema de fondo en una обзор general sobre la toma de decisiones con IA: la responsabilidad sigue estando en las personas, especialmente cuando los sistemas preparan o aceleran decisiones. IBM sobre la responsabilidad en la toma de decisiones con IA

También el AI Agile Manifesto marca aquí el contrapunto correcto: más inteligencia de máquina sin juicio humano no es progreso, sino un camino equivocado. AI Agile Manifesto en su versión original

Por eso no basta con hablar solo de las capacidades de las herramientas. En cuanto los agentes interpretan requisitos, realizan cambios o incluso desencadenan acciones cercanas a producción, la responsabilidad debe quedar organizativamente más clara y ser más visible.

El cuarto fracaso a menudo solo se hace visible con retraso: desarrolladoras o equipos individuales parecen extremadamente productivos, mientras que la organización en su conjunto se vuelve más pesada.

Eso sucede cuando cada uno optimiza localmente con IA, pero casi nadie fortalece el sistema en su conjunto:

• Los principios de arquitectura se aplican de forma inconsistente
• los mismos problemas se resuelven varias veces en paralelo
• los sistemas de revisión y prueba son desbordados
• las pipelines de entrega se convierten en un cuello de botella
• aumenta la carga de incidencias y el retrabajo

Birgitta Böckeler describe en su conversación con InfoQ sobre Harness Engineering por qué una mayor autonomía siempre conlleva también mayores riesgos y debe limitarse mediante mecanismos de feedforward y feedback adecuados. Podcast de InfoQ con Birgitta Böckeler sobre Harness Engineering

Que esto no es un riesgo teórico lo demuestran varios casos que se hicieron públicos. Según informes, Amazon endureció en 2026 sus guardrails internos tras graves series de incidentes, en las que también se mencionaron como factor coadyuvante sistemas agenticos o cercanos a la IA. La lección que se extrajo fue reveladora: más cambios documentados, más aprobaciones, más “controlled friction” en sistemas críticos. En otras palabras: no toda aceleración local mejora el sistema global. A veces solo hace más visibles sus puntos débiles. Informe de Business Insider sobre el endurecimiento de los guardrails de IA en Amazon

Una segunda forma, distinta, de la misma entropía se observa en el llamado Vibe Coding asistido por IA. Axios informó en 2026, citando a investigadores de seguridad, sobre cientos de miles de artefactos accesibles públicamente, entre ellos miles con datos empresariales sensibles. Aquí no falla principalmente un único prompt, sino el sistema global de estándares, accesos, valores predeterminados, comprensión de la seguridad y gobernanza. Informe de Axios sobre Vibe Coding y artefactos accesibles públicamente

En resumen: cuanto más autónoma es la IA, más importante es el marco organizativo y técnico en el que trabaja.

Por qué la productividad a corto plazo y el tokenmaxxing son la estrategia de IA equivocada

Algunos líderes reaccionan al nuevo poder de palanca de la IA con una conclusión simple: entonces solo tenemos que imponer el uso de la IA lo antes posible y en la mayor medida posible.

Esa es exactamente la reacción de gestión equivocada.

¿Por qué?

Porque en este contexto “short term productivity” suele significar solo lo siguiente:

• más código generado
• más sesiones de IA
• más consumo de tokens
• más tareas resueltas localmente

Pero todo eso todavía dice casi nada sobre las preguntas que para la IA en la entrega ágil de software son realmente decisivas:

• ¿Se resolvió el problema correcto?
• ¿El equipo entiende el cambio?
• ¿Se puede desplegar el cambio con seguridad?
• ¿El sistema queda mejor o más frágil después del cambio?
• ¿La organización aprende más rápido o solo con más frenesí?

Precisamente por eso, Tokenmaxxing es una señal de alerta tan buena. Muestra lo que ocurre cuando las empresas tratan el uso de la IA como un fin en sí mismo. Entonces los empleados maximizan exactamente aquello que recibe recompensa visible, incluso si con ello aumentan los costes, la entropía y el vuelo a ciegas. Pragmatic Engineer sobre la tendencia Tokenmaxxing

Jez Humble describió este problema de gestión con claridad mucho antes de la ola actual de IA: cuando los directivos se centran directamente en la productividad, las mejoras a largo plazo a menudo no se llevan a cabo. Para la IA en la entrega ágil de software, esto se agrava. Jez Humble sobre el enfoque en la productividad y la ausencia de mejoras a largo plazo

Lo que funciona en su lugar: cuatro soluciones robustas para la IA en la entrega ágil de software

1. Mantener explícitamente la responsabilidad en manos de las personas

La IA puede acelerar, proponer y aliviar carga. Pero no debe convertirse en una excusa para que la responsabilidad sobre las decisiones y la calidad se diluya.

En la práctica, eso significa:

• propietarios claros para arquitectura, seguridad y decisiones relevantes para el producto
• sin métricas de éxito que simplemente premien la actividad de IA
• reglas explícitas de revisión y aprobación para cambios generados por IA

2. Construir un engineering harness en lugar de limitarse a usar herramientas de IA

Muchos equipos invierten primero en modelos y, por último, en las condiciones bajo las cuales esos modelos pueden trabajar con seguridad. Justo eso hay que invertir.

Un harness sólido para la IA en la entrega ágil de software incluye, por ejemplo:

• buenas especificaciones
• paquetes de trabajo pequeños y verificables
• pruebas automáticas
• análisis estático
• sandboxes controlados
• contextos de arquitectura claros
• retroalimentación rápida desde CI, delivery y producción

Si te interesa esta idea, OpenSpec y el GitHub Spec Kit también son referencias útiles sobre el trabajo con IA basado en especificaciones: OpenSpec para el desarrollo de productos basado en especificaciones, GitHub Spec Kit para el desarrollo spec-driven

3. Hacer que el feedback de los clientes sea más rápido que la producción de código

La IA solo es una palanca de entrega sostenible si también acelera los ciclos de aprendizaje. De lo contrario, solo se produce más rápido de espaldas a la realidad.

Eso significa concretamente:

• lanzamientos más pequeños
• más experimentos con ciclos de retroalimentación reales con los clientes
• un análisis más sistemático de los datos de uso de las funcionalidades
• evaluación más rápida de señales de soporte y de usuarios

Quien solo aumenta la velocidad de codificación, pero no la velocidad ni la calidad del feedback, no está construyendo una organización AI-native, sino solo una “Feature Factory” más rápida, como la describe John Cutler. Véase: 12 señales de que estás trabajando en una Feature Factory

4. Tomar en serio las retrospectivas y los bucles de aprendizaje

Si la IA falla en la entrega ágil de software, las causas suelen ser sistémicas. Entonces ayuda poco optimizar solo prompts o herramientas individuales.

Los equipos necesitan rutinas en las que hagan visibles los patrones recurrentes y los resuelvan de forma sistemática:

• ¿Dónde perdemos comprensión?
• ¿Dónde crece el atasco de revisión?
• ¿Dónde genera la IA más retrabajo que beneficio?
• ¿Dónde optimizamos la velocidad local a costa del sistema global?

Precisamente por eso las retrospectivas siguen siendo relevantes. No como un ritual del pasado de Scrum, sino como un mecanismo para el aprendizaje organizacional en un entorno con mayor frecuencia de cambios.

Conclusión: la IA en la entrega ágil de software rara vez fracasa por tener demasiada poca IA

La verdadera ironía es esta: muchas organizaciones no fracasan con la IA porque sean demasiado cautas, sino porque gestionan con demasiada visión a corto plazo.

Confunden la productividad a corto plazo con la creación de valor sostenible y la mejora del sistema de entrega. Confunden el consumo de tokens con la creación de valor. Confunden la generación autónoma de código con la madurez organizativa.

Por eso, la mejor pregunta guía no es: “¿Cómo conseguimos que nuestros equipos usen aún más IA?”

Sino más bien:

• ¿Bajo qué condiciones mejora realmente la IA nuestra entrega?
• ¿Dónde está generando la IA nuevos cuellos de botella en la cadena de valor?
• ¿Dónde está poniendo al descubierto la IA deficiencias sistémicas que debemos corregir?
• ¿Qué capacidades organizativas debemos reforzar para que la aceleración no derive en entropía?

Si primero quieres la evidencia fría, sigue leyendo aquí: base de estudios sobre IA en el desarrollo ágil de software .

Si buscas directamente palancas de gestión, sigue aquí: Guía para CTOs y Engineering Managers sobre IA en el desarrollo ágil de software .

FAQ sobre IA en la entrega ágil de software

¿Por qué la IA aporta más output a mi equipo, pero no una mejor delivery?

Porque más output no significa automáticamente una mejor delivery. Si las revisiones, las pruebas y el feedback no van al mismo ritmo, lo que aumenta sobre todo es la complejidad.

¿Qué significa Tokenmaxxing en el desarrollo de software asistido por IA?

Tokenmaxxing significa convertir el uso de la IA o el consumo de tokens en el objetivo. Eso mide actividad, pero no valor.

¿Qué deberían hacer los Engineering Managers en lugar de limitarse a impulsar la productividad con IA?

Deberían fortalecer la responsabilidad, las pruebas, las revisiones y los ciclos de retroalimentación. Solo eso hace que la IA sea útil a largo plazo.

¿Los equipos con mucho apoyo de IA siguen necesitando rituales ágiles?

Sí, pero con otro enfoque. Menos mantenimiento de estado, más feedback, aprendizaje y mejora continua.

¿Cómo mido, como Engineering Manager, si la IA realmente aporta algo en el desarrollo de software?

Mide el Lead Time, el esfuerzo de revisión, la tasa de errores y el valor para el cliente. El mero output no basta.

¿Por qué mi equipo va más rápido con IA, pero los resultados no mejoran?

Porque más código no ofrece automáticamente mejores resultados. Sin revisiones, pruebas y feedback limpios, solo aumenta la entropía.

¿Qué KPIs debería seguir de verdad para la IA en el desarrollo de software?

Haz seguimiento del tiempo de ciclo, la tasa de defectos, el retrabajo, la seguridad del despliegue y el tiempo hasta el feedback del cliente. Los tokens por sí solos dicen demasiado poco.

¿Cómo evito que el código generado por IA frene a mi equipo más adelante?

Mantén los cambios pequeños, pruébalos bien y exige una revisión clara. La IA puede aportar velocidad, pero no sustituir la comprensión.