Qué es esta página
Una guía de diagnóstico para un síntoma que se está volviendo frecuente: un equipo empieza a desarrollar más rápido, y el trabajo terminado se acumula antes de llegar a producción. El equipo lo nombra, casi siempre, como "se nos está acumulando en QA".
La tesis de esta página es que esa frase describe por lo menos tres problemas distintos, que se ven iguales desde afuera y tienen curas incompatibles entre sí. Aplicar la cura equivocada no es neutro: consume el capital político que se necesitaba para la cura correcta.
Esta página no cubre las buenas prácticas de integración continua ni la mecánica de dónde corren los tests automatizados. Eso está en una página aparte.
1. El fenómeno existe y está medido
Antes de diagnosticar conviene establecer que no es una impresión del equipo.
DORA Report 2025 (Google Cloud, con ThoughtWorks entre los colaboradores del reporte):
- 90% de adopción de IA en desarrollo de software, con una mediana de dos horas diarias de interacción por persona.
- La adopción de IA pasó a correlacionar positivamente con throughput, revirtiendo el hallazgo de 2024.
- Y al mismo tiempo mantiene su asociación con mayor inestabilidad de entrega.
- El reporte atribuye esto a que los sistemas de entrega no evolucionaron para manejar con seguridad el desarrollo acelerado por IA.
- La formulación del reporte que describe el síntoma: sin gestión del flujo de valor, la IA produce "bolsones localizados de productividad que son absorbidos por el caos aguas abajo".
- Hallazgo asociado: trabajar en lotes pequeños amplifica los beneficios de la IA y reduce la fricción.
El contra-argumento, que vale más que la confirmación. Steve Fenton sostiene en The New Stack que la industria está discutiendo el cuello de botella equivocado:
- El reporte de GitLab de 2026 indica que 85% cree que la IA movió el cuello de botella a code review.
- Fenton contrapone datos de despliegue: más del 90% de los equipos despliega en lotes en lugar de cambio por cambio; 50% tiene entre 2 y 10 cambios esperando por lote; 25% tiene entre 11 y 50.
- Su argumento: si los cambios se acumulan después de haber pasado review, entonces review no es la restricción real.
- Su crítica metodológica: la investigación de la industria "se detiene en el punto donde el código se mergea", justo antes de donde está el problema.
La conclusión útil de tener las dos lecturas juntas no es cuál tiene razón. Es que el síntoma es real y su ubicación no es obvia ni siquiera con datos de industria. Por eso hace falta diagnosticar antes de intervenir.