Estadísticas sobre la velocidad del desarrollo de software empresarial (2026)

Yury Pukhov CEO & Mobile Engineering Lead, YuSMP Group

Las estadísticas sobre la velocidad del desarrollo de software empresarial son fáciles de encontrar y difíciles de verificar. La mayoría de las recopilaciones mezclan tamaños de mercado con afirmaciones de proveedores y rara vez dicen a qué velocidad llevan los equipos reales el código de la idea a producción. Esta página reúne solo datos relacionados con la velocidad — benchmarks de entrega, cycle times, experimentos controlados con IA, desviaciones de proyectos y estudios sobre el uso del tiempo — e indica la fuente y el año de cada cifra.

Está dirigida a responsables de tecnología que necesitan una referencia defendible: un CTO que prepara una actualización para el consejo, un VP de ingeniería que fija los objetivos del próximo año o un equipo de compras que compara proveedores que prometen «una entrega 2x más rápida». Si planifica un gran desarrollo y quiere ver cómo se traducen estos benchmarks en un plan de entrega, nuestra página de servicios de desarrollo de software empresarial muestra cómo organizamos equipos, pipelines e hitos en torno a ellos.

Lea las cifras con una advertencia en mente: las métricas de velocidad solo tienen sentido junto con la estabilidad. Un equipo que despliega diez veces al día y rompe producción cada semana no es rápido, es ruidoso. Por eso cada sección siguiente combina cifras de rendimiento con cifras de calidad, del mismo modo que deberían combinarse los KPI del desarrollo de software en su propio panel.

¿Cuáles son las principales estadísticas sobre la velocidad del desarrollo de software empresarial en 2026?

Las principales estadísticas sobre la velocidad del desarrollo de software empresarial en 2026 abarcan cuatro áreas: con qué frecuencia despliegan los equipos, cuánto tarda un cambio en llegar a producción, cuánto lo modifica la IA y con qué frecuencia se desvían los grandes programas. Estas doce cifras son las que más se citan en las conversaciones de planificación, y cada una se explica en detalle más abajo.

1. El 19 % de los equipos eran de élite en la investigación State of DevOps 2024 de DORA, con despliegues bajo demanda y plazos de entrega inferiores a un día; el 25 % tenía un rendimiento bajo y entregaba entre una vez al mes y una vez cada seis meses.
2. Menos de 25 horas es el cycle time de élite (del primer commit a producción) en los benchmarks de LinearB de 2026, basados en 8.1 millones de pull requests de 4,813 equipos.
3. Menos de 1 hora de tiempo de recogida y menos de 3 horas de revisión caracterizan un flujo de pull requests de élite en el mismo conjunto de datos.
4. El 90 % de los profesionales de la tecnología utilizaba la IA en el trabajo según el informe DORA 2025, y más del 80 % afirmaba que aumentaba su productividad.
5. Una finalización de tareas un 55.8 % más rápida se midió en desarrolladores que usaban GitHub Copilot en un experimento controlado de 2023.
6. Una finalización alrededor de un 21 % más rápida se midió en 96 ingenieros de Google que usaban IA en un ensayo aleatorizado de 2024.
7. Un 19 % más lentos: desarrolladores de código abierto experimentados tardaron más en tareas reales con herramientas de IA en el estudio de METR de 2025, aunque creían haber sido un 20 % más rápidos.
8. Tiempos de revisión un 91 % más largos y un 98 % más de pull requests fusionadas registró Faros AI en 2025 en los equipos con uso intensivo de IA.
9. 10–15 % de mejora de productividad solo con asistentes de programación con IA, que sube al 25–30 % con un rediseño de los procesos de extremo a extremo, según el Technology Report 2025 de Bain.
10. El 16 % del tiempo de los desarrolladores se dedica a escribir código, según el State of Developer Experience 2025 de Atlassian; la mitad de los desarrolladores pierde 10 horas o más a la semana por fricciones organizativas.
11. Un 45 % por encima del presupuesto y un 7 % fuera de plazo es la media de los grandes proyectos de TI, con un 56 % menos de valor del previsto (McKinsey y la Universidad de Oxford).
12. El 80 % de las grandes organizaciones de ingeniería de software tendría equipos de platform engineering en 2026 según una previsión de Gartner, frente al 45 % de 2022.

¿A qué velocidad entregan los equipos empresariales? Benchmarks de entrega de DORA

Los equipos empresariales entregan a velocidades muy distintas: en la investigación de DORA de 2024, la quinta parte más rápida despliega bajo demanda con plazos inferiores a un día, mientras que la cuarta parte más lenta necesita de uno a seis meses para que un cambio llegue a producción. DORA (DevOps Research and Assessment, hoy parte de Google Cloud) realiza esta encuesta desde hace más de una década, lo que la convierte en el benchmark público más utilizado sobre el rendimiento de entrega de software.

DORA mide la velocidad con dos métricas — frecuencia de despliegue y plazo de entrega de los cambios — y la estabilidad con otras dos: tasa de fallos de los cambios y tiempo de recuperación tras un despliegue fallido. Los clústeres de rendimiento de 2024 son estos:

Fuente: DORA, Accelerate State of DevOps Report 2024. Los porcentajes son proporciones de encuestados, no de empresas.

Para los lectores de grandes empresas importan dos detalles. Primero, la velocidad y la estabilidad van de la mano: los equipos de élite tienen a la vez los plazos más cortos y las tasas de fallo más bajas, lo que contradice la creencia extendida de que ir más rápido significa romper más. Segundo, el clúster medio tiene una tasa de fallos de los cambios más baja (10 %) que el clúster alto (20 %). DORA lo explica porque algunos equipos compran estabilidad entregando con menos frecuencia, una contrapartida que suele romperse a medida que los sistemas crecen.

¿Qué cambió en el informe DORA 2025?

El informe DORA 2025, publicado en septiembre de 2025 como State of AI-assisted Software Development, sustituyó los cuatro clústeres clásicos por siete arquetipos de equipo basados en casi 5,000 respuestas a la encuesta y más de 100 horas de entrevistas. El mayor cambio fue la IA: por primera vez, su adopción se asociaba positivamente con el rendimiento de entrega, aunque seguía asociada negativamente con la estabilidad de la entrega.

En las grandes empresas, los arquetipos «frenados por los procesos» y «cuello de botella heredado» suman el 28 % de los encuestados. Son los dos puntos en los que la velocidad se pierde por la organización y la arquitectura y no por las competencias de los ingenieros, y ambos son típicos de grandes compañías con sistemas centrales de larga vida.

¿Qué descubrió DORA en 2024 sobre la IA y la velocidad de entrega?

En 2024, DORA observó que un aumento del 25 % en la adopción de la IA se asociaba a una caída del 1.5 % en el rendimiento de entrega y del 7.2 % en la estabilidad, aunque esa misma adopción elevaba la productividad individual un 2.1 %, la satisfacción laboral un 2.6 % y la calidad de la documentación un 7.5 %. La interpretación fue que la IA facilita producir lotes de cambios más grandes, y los lotes grandes son precisamente lo que DORA siempre ha asociado a entregas más lentas y arriesgadas. En 2025 el efecto sobre el rendimiento pasó a ser positivo, pero la penalización en estabilidad se mantuvo.

¿Qué es un buen cycle time? Estadísticas de benchmarks de ingeniería

Un buen cycle time para un equipo empresarial es inferior a una semana laboral, y los equipos de élite bajan de las 25 horas desde el primer commit hasta producción, según los Software Engineering Benchmarks 2026 de LinearB. El conjunto de datos abarca 8,109,244 pull requests de 4,813 equipos y 163,820 colaboradores en 42 países, lo que lo convierte en una de las mayores fuentes públicas de datos de velocidad a nivel de pull request.

El cycle time se divide en etapas, y cada etapa tiene su propio benchmark. Analizarlas por separado es la forma más rápida de descubrir dónde pierde días un equipo empresarial:

Fuente: LinearB, 2026 Software Engineering Benchmarks Report (umbrales P75 del nivel de élite).

La tabla explica por qué los cambios pequeños importan tanto. La recogida y la revisión son las etapas en las que esperan las pull requests, y la espera crece con el tamaño: un cambio de 100 líneas se revisa en minutos, uno de 1,000 líneas espera hasta que alguien tenga una tarde libre. Los equipos que reducen su cycle time suelen hacerlo encogiendo las pull requests y protegiendo el tiempo de revisión, no pidiendo a los ingenieros que escriban más rápido. Nuestra guía sobre CI/CD en el desarrollo de software aborda la parte del pipeline del mismo problema: la etapa de despliegue.

¿Cómo cambia el código generado por IA la velocidad de las pull requests?

El código generado por IA hace que las pull requests sean más grandes y más lentas de fusionar, según los datos de LinearB de 2026. Las pull requests asistidas por IA tenían 408 líneas en el percentil 75 frente a 157 líneas sin asistencia, y solo el 32.7 % de las pull requests generadas por IA se fusionaba en 30 días, frente al 84.4 % de las manuales. Al mismo tiempo, el 88.3 % de las organizaciones usaba herramientas de IA a diario o varias veces por semana, y el 44.7 % no medía formalmente su impacto.

Jellyfish vio el lado más optimista de la misma tendencia en su balance de 2025: cuando la adopción de la IA en un equipo pasaba del 0 % al 100 %, el cycle time mediano bajaba de 16.7 a 12.7 horas (un 24 % más rápido) y las pull requests por ingeniero subían de 1.36 a 2.9. La adopción de agentes de IA para la revisión de código creció del 14.8 % al 51.4 % de las empresas entre enero y octubre de 2025. Ambos conjuntos de datos son compatibles: los equipos que adoptan plenamente la IA y adaptan su proceso de revisión ganan velocidad, mientras que los que solo añaden código generado por IA a un proceso sin cambios crean una cola de revisión.

¿Son las grandes empresas más lentas que las startups al entregar software?

Las grandes empresas entregan software de forma mediblemente más lenta que las startups, pero la diferencia es menor de lo que muchos esperan y se debe a la carga organizativa, no a la capacidad de ingeniería. Los datos de LinearB analizados por DevPro Journal (3.6 millones de pull requests) situaban el cycle time de élite en las grandes empresas por debajo de 29 horas, frente a menos de 27 horas en las scale-ups y menos de 21 horas en las startups.

Fuente: DevPro Journal, «A Quantitative (and Actionable) Analysis of Enterprise Software Delivery Speed» (en inglés), enero de 2024, con datos de LinearB.

El mismo análisis concluyó que los equipos empresariales solo comparten alrededor del 70 % de su jornada, porque están repartidos en varios husos horarios. Solo eso alarga los tiempos de recogida y de revisión. Si se añaden los comités de aprobación de cambios, las revisiones de seguridad, los release trains compartidos y las dependencias entre decenas de servicios, las ocho horas adicionales de cycle time de élite se explican fácilmente.

DORA señala otros dos frenos propios de las grandes empresas. Las prioridades organizativas inestables se asociaban en 2024 a un riesgo de agotamiento un 40 % mayor, y los equipos obligados a usar una plataforma interna vieron caer su rendimiento un 8 % y la estabilidad de los cambios un 14 %. Es decir, las estructuras que las empresas añaden para ir más rápido pueden frenarlas cuando se imponen en lugar de adoptarse.

¿Hace la IA más rápido el desarrollo de software? Lo que muestran los estudios

La IA acelera las tareas de programación aisladas en experimentos controlados, normalmente entre un 20 y un 55 %, pero su efecto en la entrega empresarial de extremo a extremo es menor, y para desarrolladores experimentados en bases de código complejas puede llegar a ser negativo. La respuesta depende de lo que se mida: una sola tarea bien definida, la semana de un desarrollador o el recorrido de un equipo desde la idea hasta producción.

¿Por qué las mejoras en tareas no se convierten en una entrega más rápida?

Las mejoras de la IA en tareas concretas no se trasladan de forma directa a una entrega más rápida porque escribir código es solo una pequeña parte del ciclo de entrega. Bain calcula que escribir y probar código representa solo entre el 25 y el 35 % del tiempo que va de la idea al lanzamiento; el resto es descubrimiento, diseño, revisión, integración, aprobaciones y publicación. Un paso de programación un 50 % más rápido dentro de una franja del 30 % del calendario ahorra, como mucho, alrededor de un 15 %, y solo si las etapas posteriores siguen el ritmo.

Faros AI lo llama la «paradoja de productividad de la IA»: la producción individual aumenta mucho, pero las métricas a nivel de empresa apenas se mueven porque el código adicional se acumula en revisión y pruebas. Faros no encontró ninguna correlación significativa entre la adopción de la IA y las mejoras de entrega a nivel de empresa en sus datos de 2025. La encuesta de Bain apunta en la misma dirección: tres de cada cuatro empresas afirmaron que lo más difícil de adoptar la IA era cambiar la forma de trabajar, no desplegar las herramientas.

¿Dónde ahorra más tiempo la IA?

La IA ahorra más tiempo en trabajo bien definido y de baja complejidad, como la documentación, el código repetitivo y la estructura de las pruebas, y menos en el diseño complejo y la depuración en bases de código grandes y poco conocidas. Ese patrón recorre todos los estudios anteriores: el experimento de Copilot usó una pequeña tarea desde cero, mientras que METR utilizó repositorios grandes y maduros que los desarrolladores ya conocían bien. Para los equipos empresariales, esto sugiere orientar primero la IA a la documentación, las migraciones, la generación de pruebas y el código de integración repetitivo. Nuestro artículo sobre cómo desarrollan realmente los equipos con IA describe esos flujos de trabajo en detalle.

Estadísticas de adopción de la IA y de confianza en ella en los equipos de software

La IA forma ya parte del flujo de trabajo de casi todos los desarrolladores, pero la confianza en sus resultados es baja, lo que limita cuánta velocidad aporta en la práctica. Estas cifras de adopción y confianza explican por qué la revisión y la verificación se han convertido en el nuevo cuello de botella:

• El 84 % de los desarrolladores usa o piensa usar herramientas de IA, frente al 76 % de 2024, y el 51 % de los desarrolladores profesionales las usa a diario (Stack Overflow Developer Survey 2025).
• Solo el 3.1 % de los desarrolladores confía mucho en la precisión de los resultados de la IA, mientras que el 45.7 % desconfía activamente de ella; la opinión favorable bajó al 60 % (Stack Overflow 2025).
• El 66 % afirma que su mayor frustración son las respuestas de la IA que están «casi bien, pero no del todo», y el 45.2 % dice que depurar código generado por IA lleva más tiempo (Stack Overflow 2025).
• El 30 % de los encuestados del informe DORA 2025 tenía poca o ninguna confianza en el código generado por IA, y el usuario mediano trabajaba con IA unas 2 horas al día.
• El 99 % de los desarrolladores dice que la IA le ahorra tiempo y el 68 % ahorra más de 10 horas a la semana (Atlassian State of Developer Experience 2025).
• El 90 % de los ingenieros de software empresarial usará asistentes de programación con IA en 2028, frente a menos del 14 % a principios de 2024 (previsión de Gartner).

El contraste entre «el 99 % ahorra tiempo» y «el 3.1 % confía mucho en los resultados» resume el panorama de 2026. El tiempo que se ahorra al escribir se vuelve a gastar en parte al comprobar, y esa comprobación ocurre en la revisión de código, la etapa que ya limita el cycle time.

¿Cuánto tiempo dedican realmente a programar los desarrolladores de las grandes empresas?

Los desarrolladores de las grandes empresas dedican solo entre el 11 y el 16 % de su jornada a escribir código, según dos de los grandes estudios más recientes, por lo que las mayores mejoras de velocidad suelen venir de eliminar fricciones alrededor del código y no de programar más rápido. El State of Developer Experience 2025 de Atlassian, basado en 3,500 desarrolladores y responsables de seis países, situó la programación en el 16 % del tiempo.

Fuente: Microsoft Research, «Time Warp: The Gap Between Developers’ Ideal vs Actual Workweeks in an AI-Driven Era» (en inglés), ICSE SEIP 2025, encuesta a 484 desarrolladores de Microsoft. El tiempo restante se reparte entre otras actividades.

La fricción es la principal razón de que la proporción de programación sea tan baja. En el estudio de Atlassian, el 50 % de los desarrolladores perdía 10 horas o más a la semana por ineficiencias organizativas y el 90 % al menos 6 horas; las principales causas eran buscar información, adaptarse a nuevas tecnologías y los cambios de contexto. El 63 % afirmaba que sus responsables no entendían estos problemas, frente al 44 % un año antes.

La deuda técnica es la versión a largo plazo del mismo problema. El estudio Developer Coefficient de Stripe concluyó que, de una semana media de 41.1 horas, los desarrolladores dedicaban 17.3 horas al mantenimiento, de ellas 13.5 horas a la deuda técnica, y el 52 % señalaba los sistemas heredados y la deuda técnica como el principal obstáculo para la productividad. La cifra es de 2018, pero sigue siendo la medición más citada de cuánta capacidad absorbe el código antiguo, y coincide con el 11 % de encuestados de DORA 2025 clasificados como «cuello de botella heredado».

¿Con qué frecuencia se retrasan o se salen de presupuesto los proyectos de software empresarial?

Los grandes proyectos de software empresarial se retrasan o superan su presupuesto con más frecuencia de lo que cumplen: un estudio de McKinsey y la Universidad de Oxford sobre más de 5,400 proyectos de TI de más de $15 millones encontró una desviación media del 45 % en el presupuesto, del 7 % en el plazo y un 56 % menos de valor del previsto. Alrededor del 17 % de esos proyectos fue tan mal que llegó a amenazar la existencia de la empresa.

• 45 % de desviación media del presupuesto, 7 % de retraso y 56 % menos de valor del previsto en los grandes proyectos de TI (McKinsey y la Universidad de Oxford).
• Cada año adicional de duración del proyecto añadía aproximadamente un 15 % a la desviación de costes en el mismo estudio, por lo que los proyectos largos son desproporcionadamente arriesgados.
• El 31 % de los proyectos de software tuvo éxito, el 50 % tuvo problemas y el 19 % fracasó según los datos CHAOS 2020 del Standish Group; el éxito era del 16.2 % en 1994 y del 37 % en 2012.
• Los proyectos pequeños tienen éxito en torno al 90 % de las veces según los datos CHAOS, mientras que los muy grandes lo logran en menos del 10 %.
• El 73.8 % de los proyectos cumplió de media sus objetivos de negocio según el Pulse of the Profession 2024 del PMI.
• Los proyectos dirigidos por profesionales con gran visión de negocio cumplieron sus objetivos el 83 % de las veces, respetaron el plazo el 63 % y el presupuesto el 73 % de las veces, según la encuesta del PMI de 2025 a casi 3,000 profesionales.

El denominador común es el tamaño. Las desviaciones crecen con la duración y el alcance, y los proyectos con mejores resultados son los que se dividen en versiones pequeñas con valor propio. Es la misma lección que enseñan los datos de DORA y LinearB a escala de un solo cambio. Tenga en cuenta también que el 7 % de retraso subestima la demora que perciben los usuarios: los proyectos suelen cumplir sus fechas recortando alcance, y por eso el déficit de valor (56 %) es mucho mayor que la desviación de plazo. Para dimensionar un proyecto antes de empezar, consulte nuestra guía de estimación de proyectos de software.

Platform engineering, low-code y otras palancas de velocidad: estadísticas

El platform engineering es la palanca de velocidad que más han adoptado las grandes empresas: Gartner prevé que el 80 % de las grandes organizaciones de ingeniería de software tenga equipos de plataforma en 2026, frente al 45 % de 2022. Los datos de DORA muestran que el beneficio es real, pero depende de cómo se introduzca la plataforma.

El patrón es constante: las herramientas aceleran la entrega cuando eliminan esperas y pasos manuales, y la frenan cuando añaden procesos obligatorios. Una plataforma de golden path que convierte el camino correcto en el más fácil ayuda; una plataforma que todos los equipos deben usar sin importar si encaja perjudica. Lo mismo vale para la automatización del cloud, y por eso tratamos la ingeniería cloud y DevOps como parte de la velocidad de entrega y no como un trabajo de infraestructura aparte.

¿Cómo se mide la velocidad de entrega de la propia empresa?

La velocidad de entrega se mide registrando las cuatro métricas de DORA y las etapas del cycle time con sus propios datos durante al menos un trimestre, y comparando después las medianas con los benchmarks públicos anteriores. Las medias del sector solo son útiles cuando conoce su propia línea base. Una secuencia práctica es la siguiente:

1. Elija un alcance. Empiece por tres a cinco equipos responsables de servicios desplegables, no por toda la organización; las carteras mixtas ocultan los cuellos de botella.
2. Recoja las cuatro métricas de DORA. Obtenga la frecuencia de despliegue y el plazo de entrega de su sistema de CI/CD, y la tasa de fallos y el tiempo de recuperación de los registros de incidentes.
3. Divida el cycle time en etapas. Mida por separado el tiempo de codificación, recogida, revisión y despliegue con los datos de su control de versiones; la etapa más lenta es su primer objetivo.
4. Siga el tamaño de las pull requests. La mediana y el percentil 75 de líneas modificadas por pull request predicen los retrasos de revisión mejor que cualquier otra cifra aislada.
5. Añada una perspectiva de IA. Etiquete las pull requests asistidas por IA y compare su tamaño, tiempo de revisión y tasa de fusión con las demás, como hace LinearB.
6. Pregunte por las fricciones. Pregunte a los desarrolladores cuántas horas a la semana pierden en esperas, búsquedas y cambios de contexto; las cifras de Atlassian le sirven de referencia.
7. Revise cada trimestre y cambie una sola cosa cada vez. Trate cada mejora como un experimento y vigile las métricas de estabilidad con la misma atención que las de velocidad.

Evite convertir estas cifras en objetivos individuales. Tanto DORA como el marco SPACE advierten de que las métricas de entrega describen sistemas, no personas; en cuanto se evalúa a los ingenieros por su número de pull requests, ese número sube y la velocidad de entrega no. Nuestra guía sobre DevOps en el desarrollo de software recoge las prácticas que mejoran estas métricas de forma sostenible.

¿Qué significan estas estadísticas para los compradores de software empresarial en 2026?

Para las empresas que compran o encargan software empresarial en 2026, las estadísticas llevan a una conclusión: la velocidad de entrega depende del tamaño de los lotes, del flujo de revisión y de la fricción organizativa mucho más que de la plantilla o de las herramientas. Cuando evalúe un plan interno o un socio externo, estas son las preguntas que, según los datos, debería hacer:

• ¿Qué cadencia de publicación está prevista? Un plan con una única gran entrega al final arrastra el riesgo de desviación del 45 % de los grandes proyectos; las entregas mensuales o más frecuentes lo reducen.
• ¿Cómo se informará del plazo de entrega y de la tasa de fallos de los cambios? Un proveedor que no puede mostrar las métricas de DORA de sus proyectos actuales le pide que confíe en una promesa.
• ¿Cómo se revisa el código generado por IA? Las pull requests asistidas por IA más grandes y las revisiones más largas están bien documentadas; un equipo creíble tiene una norma para ambas cosas.
• ¿Qué parte del calendario es espera? Las aprobaciones, los entornos y las solicitudes de acceso consumen a menudo más tiempo de calendario que el propio desarrollo.
• ¿Cómo se divide el trabajo en versiones? Los datos CHAOS muestran que los proyectos pequeños tienen éxito unas nueve veces más a menudo que los muy grandes, así que pregunte cómo se dividirá el alcance en incrementos con valor propio.
• ¿Qué mide el equipo antes de la primera entrega? Una línea base tomada en el primer sprint hace verificables las afirmaciones posteriores sobre velocidad y saca a la luz pronto los entornos lentos y los pasos de aprobación.
• ¿Cómo se gestiona la integración con sistemas heredados? Los cuellos de botella heredados afectan a uno de cada nueve equipos en DORA 2025, y es en la integración donde más se retrasan los calendarios empresariales.

Estos criterios se aplican tanto a una plataforma nueva como a un programa de modernización o a un desarrollo con mucha integración. También explican por qué el mercado del desarrollo de software a medida se desplaza hacia socios capaces de mostrar datos de entrega y no solo tarifas por hora, y por qué las tendencias del desarrollo de software para 2026 están dominadas por el platform engineering y la gobernanza de la IA más que por nuevos lenguajes.

Preguntas frecuentes

Publicado el 25 de octubre de 2026. Fuentes: DORA, Accelerate State of DevOps Report 2024 (en inglés); DORA, State of AI-assisted Software Development 2025 (en inglés); LinearB, 2026 Software Engineering Benchmarks (en inglés); DevPro Journal, análisis de la velocidad de entrega empresarial (2024) (en inglés); Faros AI, The AI Productivity Paradox (2025) (en inglés); Jellyfish, 2025 AI metrics in review (en inglés); Peng et al., The Impact of AI on Developer Productivity (2023) (en inglés); Google, How much does AI impact development speed? (2024) (en inglés); METR (2025) (en inglés) y actualización de METR (2026) (en inglés); Stack Overflow Developer Survey 2025 (en inglés); Bain Technology Report 2025 (en inglés); Atlassian State of Developer Experience 2025 (en inglés); Microsoft, Time Warp (2025) (en inglés); Stripe, The Developer Coefficient (2018) (en inglés); McKinsey y la Universidad de Oxford, Delivering large-scale IT projects on time, on budget, and on value (2012); Standish Group CHAOS 2020; PMI Pulse of the Profession 2024 y 2025; previsiones de Gartner sobre asistentes de programación con IA, platform engineering y low-code. Las previsiones son proyecciones, no mediciones.