Un debate abierto sobre el tamaño de las squads de IA
Con el auge de los agentes de código, se ha abierto un debate sobre el tamaño de las squads de IA. Una parte del mercado considera que la squad podrá reducirse con el tiempo al solo Product Builder, que gestionaría la roadmap de producto y dirigiría él mismo a los agentes encargados de producir el código.
Esta perspectiva no es descabellada. Nuestra propia lectura de los niveles de la IA engineering muestra una reducción progresiva de los equipos:
Nuestras experiencias de campo confirman además que las ganancias son mayores en equipos muy reducidos. El modelo de factory autónoma, con un solo piloto, figura en nuestra trayectoria, pero con un horizonte de 2029-2030 y bajo la condición de madurez de la gobernanza y de la gestión del riesgo.
Sin pretender adelantarnos al futuro, tres realidades nos hacen hoy escépticos sobre la viabilidad de una squad que descanse en una sola persona.
1. La realidad de la squad: una presión que se concentra en las personas
La automatización acelera la producción, pero no elimina el trabajo humano: lo desplaza. Con ciclos de 2,5 días a 1 semana, el cuello de botella ya no es el desarrollo sino la especificación, la validación y el arbitraje. Estas etapas siguen siendo humanas: la IA produce, el Product Builder verifica antes de entregar, y nada se comparte sin esa revisión.
Cuanto más acelera la fábrica, más aumenta la carga de revisión y arbitraje para quienes la supervisan. Ya lo constatamos en squads de dos personas (un Product Builder, un desarrollador), donde la presión del casi tiempo real es fuerte y el riesgo de agotamiento, real. Con una sola persona, ya no hay doble mirada sobre la producción de la IA, y cada ausencia se convierte en un riesgo para la continuidad del producto.
2. La realidad de las competencias: dos exigencias raramente reunidas
Product Builder y AI Engineer son nuevos oficios. El Product Builder debe ir más lejos que el PO de la era ágil: visión de producto, discovery hasta el prototipado, diseño operativo, dirección del delivery y de la adopción. El AI Engineer debe dominar la arquitectura, la calidad y la seguridad para poder validar lo que producen los agentes. Una squad de una sola persona supone reunir estos dos niveles de exigencia en un mismo perfil.
Ahora bien, desde hace cinco ediciones del Barómetro Niji, las organizaciones señalan la dificultad de contar con PO/PM de buen nivel en el modo ágil. En 2025, solo el 36 % de ellas declaraba dominar las competencias de producto. Como la exigencia es mayor en un modelo de IA, estos perfiles tendrán que construirse (itinerarios, trayectorias, coaching) en lugar de esperarse.
3. La realidad de las empresas: un arbitraje entre óptimo y riesgo
Las factories producen y mantienen el SI que hace funcionar la empresa: de él dependen la cifra de negocio, los procesos y la producción. El Barómetro 2026 identifica como primer riesgo la brecha entre la velocidad de evolución de la IA y el tiempo necesario para que las organizaciones se adapten. En 2026, solo el 23 % anticipa el impacto de la IA en sus competencias, y solo una de cada seis ha construido un plan de transformación. La cuestión más compleja será, por tanto, la transformación de los equipos y la definición de la GPEC asociada, mucho antes que la del tamaño ideal de la squad de IA.
En este contexto, nos parece poco probable que las empresas pasen directamente de una feature team de 8 a 10 personas a un equipo de una persona, responsable en solitario de la continuidad de la actividad. El tamaño de los equipos será un compromiso entre la optimización ideal (una o dos personas) y el control del riesgo. En un primer momento, pasar de 8-10 a 3-4 personas ya supone una evolución importante, y sigue siendo un factor de tranquilidad.
Lo que hay que retener
Nuestro modelo objetivo se basa en squads ajustadas de 3 a 4 personas (Product Builder, AI Lead Engineer, AI Engineer), apoyadas por una Design Authority y un cockpit de dirección compartidos para la arquitectura, el design system, la ciberseguridad, el FinOps y el soporte. El despliegue se hace por etapas, empezando por una factory dedicada en paralelo a las factories existentes. El tamaño de las squads está llamado a reevaluarse en cada etapa, a medida que la gobernanza, las competencias y las herramientas demuestren su solidez.
Dicho de otro modo, todo se juega en el ritmo. Hasta dónde reducir los equipos cuenta menos que la velocidad a la que la organización puede absorber esa reducción sin poner en riesgo ni a los equipos ni a la actividad.
