Esto no es una historia de reducción de costos. Es una historia de claridad.
Todo CTO con el que hablo está haciendo alguna versión de la misma pregunta.
No en voz alta. No en el all-hands. Sino en las conversaciones más tranquilas — las que pasan después de la demo, después de la reunión con el board, después del tercer sprint consecutivo que de alguna manera terminó antes y aun así dejó a todos con una sensación vaga de incomodidad.
La pregunta es: ¿a cuántas personas realmente necesito en este equipo?
Es una pregunta incómoda porque suena a una pregunta de reducción de costos. Como si estuvieras buscando una excusa para reducir el headcount y usar la IA como cobertura.
Pero eso no es lo que la está generando. Lo que la genera es algo más honesto: la realización de que la estructura de equipo que usamos durante veinte años fue diseñada para un conjunto de restricciones que ya no existen. Y que reconstruirla para las restricciones que sí existen no es hacer más con menos.
Es hacer mejor con diferente.
El Equipo Clásico y Por Qué Tenía Sentido
El equipo Agile canónico de software se veía algo así:
- Product Manager — dueño del roadmap, gestiona stakeholders, define prioridades
- Business Analyst — traduce necesidades de negocio a requerimientos, hace de puente entre PM y dev
- Scrum Master — facilita el proceso, corre las ceremonias, remueve bloqueos
- 4 Developers — construyen el producto
- QA Engineer — valida que lo construido funciona según lo especificado
Ocho personas. La composición exacta variaba, pero la lógica era consistente.
Y la lógica era sólida — para su época.
Cada rol existía porque un costo de coordinación específico era alto. El BA existía porque la brecha entre el lenguaje de negocio y el lenguaje técnico era amplia y costosa de salvar informalmente. El Scrum Master existía porque el overhead de correr un proceso Agile disciplinado encima del trabajo de ingeniería era real. El QA existía al final porque la validación era una habilidad específica que requería foco dedicado. Los cuatro developers existían porque escribir código era lento, y la única forma de producir más era tener más personas escribiéndolo.
Cada rol era una solución a un problema genuino. El equipo de ocho fue una respuesta bien diseñada a las restricciones de 2001.
El Manifiesto Ágil fue escrito antes de que existiera el iPhone. Antes de que el cloud computing fuera mainstream. Antes de que las APIs estuvieran en todos lados. Antes de que la IA pudiera escribir código de producción.
Las restricciones cambiaron. La estructura del equipo no.
Qué Cambió Realmente la IA
Hay una forma tentadora pero incorrecta de pensar sobre lo que las herramientas de coding con IA hicieron al desarrollo de software.
La forma incorrecta: la IA hace a los developers más rápidos, así que necesitás menos de ellos.
La forma correcta: la IA eliminó el cuello de botella de la generación de código, lo que significa que el cuello de botella ahora está en otro lugar completamente.
Esta distinción importa enormemente para cómo estructurás el equipo.
Cuando la generación de código era el cuello de botella, la respuesta era más developers. Cuatro developers produciendo 200 líneas por día te daban 800. Ocho te daban 1,600. La matemática era lineal.
Con herramientas de IA, la generación de código es efectivamente gratuita. Un solo developer dirigiendo IA puede producir lo que cuatro developers producían manualmente. El cuello de botella ya no es cuánto código se escribe — es la calidad del juicio detrás del código.
¿Quién define el problema correcto a resolver? ¿Quién evalúa si la solución generada es realmente correcta? ¿Quién mantiene el modelo mental coherente del sistema? ¿Quién atrapa el edge case que el modelo generó con confianza pero incorrectamente?
Esas preguntas las responden personas, no modelos. Y de manera crítica, no las responden más personas — las responden mejores personas, operando con más claridad.
Por eso el equipo reestructurado es más chico pero no más barato en la forma en que esa palabra usualmente implica. No estás reemplazando personas con habilidades por una herramienta. Estás rediseñando el equipo alrededor de dónde la habilidad realmente importa ahora.
El Equipo de Tres
PM/PO: Una Persona, Dos Trabajos
En el equipo clásico, el Product Manager y el Business Analyst eran roles separados porque traducir requerimientos de negocio a especificaciones técnicas era un trabajo de tiempo completo. Requería idas y vueltas constantes, documentación extensa, y semanas de refinamiento antes de que un developer pudiera empezar a construir con confianza.
La IA colapsó ese costo de traducción dramáticamente.
Un PM/PO que puede articular qué necesita construirse en términos claros y específicos puede ahora usar IA para generar user stories, criterios de aceptación y especificaciones técnicas en minutos en lugar de días. El output no es perfecto — nunca lo es — pero es un borrador del 70% que puede refinarse en una fracción del tiempo original.
El resultado: una persona haciendo lo que antes requería dos, porque la parte más demandante de tiempo del rol del BA — el trabajo mecánico de traducción — ahora lo maneja la IA.
Pero acá está la implicación crítica: ese PM/PO necesita ser mejor, no solo más rápido. El BA solía absorber la ambigüedad durante semanas de iteración. Ahora esa ambigüedad tiene que resolverse al principio, porque la IA va a ejecutar requerimientos poco claros a velocidad de máquina en la dirección equivocada.
La claridad ya no es un nice-to-have. Es el input más importante de todo el sistema.
Senior Developer 1: El Tech Lead
Esta persona escribe menos código. Toma más decisiones.
Su función principal es el juicio arquitectónico — mantener el modelo mental coherente del sistema, tomar las decisiones sobre estructura y patrones que la IA puede sugerir pero no decidir, y evaluar el output de la generación de IA contra la realidad del codebase específico.
También es la compuerta de calidad. No en el sentido del QA engineer — llegaremos a eso — sino en el sentido de que su ojo experimentado es el último chequeo antes de que algo vaya a producción. Entiende no solo si el código funciona, sino si encaja, si es mantenible, si está creando un problema que va a aparecer en seis meses.
Este es el rol que el outage de Amazon de marzo de 2026 dejó visceralmente claro. Cuando el código generado por IA fue deployado sin la revisión senior adecuada, un outage de seis horas en su sitio principal de ecommerce siguió. La solución fue requerir sign-off de senior para todos los deployments asistidos por IA — un reconocimiento de que el juicio senior no es un cuello de botella a optimizar sino la capa de calidad crítica que hace seguro a todo el sistema.
Senior Developer 2: El Builder
El segundo developer es el motor del equipo — haciendo el grueso del trabajo de construcción con IA como copiloto activo.
Lo que hace diferente a este rol de un developer mid-level tradicional es el nivel de autonomía que requiere. Sin un BA en el equipo, esta persona necesita leer los requerimientos del PM y convertirlos directamente en decisiones de implementación sin una capa de traducción. Con el QA reestructurado, necesita generar e implementar tests como parte de su workflow, no como una fase separada.
Este no es un rol junior. El apalancamiento que provee la IA solo se materializa cuando la persona que la dirige tiene suficiente experiencia para reconocer cuándo el output está mal, cuándo el enfoque es arquitectónicamente problemático, y cuándo el modelo está resolviendo con confianza el problema equivocado.
Un developer junior con IA produce trabajo junior más rápido. Un senior developer con IA produce trabajo senior a una escala fundamentalmente diferente.
Qué Pasó con el QA
La desaparición del QA engineer de esta estructura de equipo requiere más explicación, porque es la más contraintuitiva.
Eliminar el QA no significa eliminar la calidad. Significa mover la calidad a donde realmente pertenece: al principio del proceso, no al final.
El modelo clásico de QA tenía una falla estructural que los practicantes conocían pero no podían fácilmente arreglar: para cuando un bug llegaba al QA, el costo de arreglarlo ya era alto. El developer había seguido adelante. El contexto estaba frío. Más fundamentalmente, el QA estaba testeando contra especificaciones que habían sido definidas separadamente, por personas que podían tener diferentes modelos mentales de qué significaba “correcto”.
El modelo reestructurado aborda esto desde la raíz.
Antes de que empiece el desarrollo: El PM/PO define los casos de prueba en lenguaje funcional, no técnico. No descripciones de tickets. Escenarios con inputs específicos y outputs esperados. “Cuando un usuario envía el formulario con un email inválido, ve este mensaje de error.” Estos casos se escriben antes de que se toque una sola línea de código — son la definición de done, explícita e inequívoca en el momento en que cambiarlos es barato.
Durante el desarrollo: El senior developer toma esos casos de prueba y los implementa como tests automatizados usando IA. El modelo genera el 80% del código de testing; el developer revisa y ajusta. El feature y su validación se construyen juntos, no en secuencia.
En la entrega: El PM/PO hace un functional walkthrough contra los casos que él mismo escribió. No una revisión técnica — una revisión de negocio. ¿Hace lo que dije que debía hacer? Si sí, está listo. Si no, la brecha es clara y específica, porque los criterios fueron claros y específicos desde el principio.
Sin rol dedicado de QA. Sin cuello de botella al final. Sin juego de culpas entre dev y QA sobre cuya interpretación era correcta.
La calidad no se elimina del proceso. Se distribuye a través de él — donde es más barata, más rápida y más efectiva.
Lo que los Números Realmente Significan
Una persona razonable podría pensar: este equipo es un 62% más chico. Eso suena a una reducción de costos con pasos extra.
Dejame ser directo sobre qué cambia y qué no.
Lo que se achica: El headcount. El overhead de coordinación. La cantidad de handoffs entre roles. El tiempo perdido en miscommunication entre BA y dev, entre dev y QA, entre Scrum Master y todos.
Lo que no se achica: La calidad de las personas. La inversión en esos tres individuos. La expectativa de su output.
Los senior developers en este modelo no están haciendo el 33% de lo que hacían cuatro developers antes. Están haciendo más — significativamente más — porque la IA expandió lo que un developer hábil puede ejecutar. El PM/PO opera a un nivel más alto de claridad y responsabilidad que el PM + BA del modelo anterior combinados.
Este equipo cuesta menos en headcount. Cuesta más en calidad individual. El intercambio vale la pena porque el apalancamiento que provee la IA escala con el juicio de la persona que la dirige — no con el número de personas en la sala.
Un senior developer mediocre con IA sigue siendo mediocre. Va a generar más código mediocre, más rápido, y lo va a aprobar con confianza.
Un gran senior developer con IA es un multiplicador de fuerza.
Los Nuevos Cuellos de Botella que Necesitás Conocer
Te haría un flaco favor si presentara este modelo como una mejora limpia sin trade-offs. Hay nuevos modos de falla que vale la pena entender antes de reestructurar.
El senior developer se convierte en el punto único de falla. En el equipo clásico, la responsabilidad de revisión estaba distribuida. En este modelo, se concentra. Cuando tu tech lead está agotado — y lo va a estar, porque operar como capa de juicio sobre generación a velocidad de IA es cognitivamente intenso — la compuerta de calidad se debilita.
Las fallas de claridad son catastróficas. En el modelo clásico, los requerimientos ambiguos se atrapaban y refinaban durante semanas de iteración del BA. En este modelo, se amplifican. La IA va a ejecutar sobre un requerimiento ambiguo a velocidad de máquina, en la dirección equivocada, antes de que nadie se dé cuenta de que el spec no estaba claro.
El contexto del sistema vive en menos cabezas. Con un equipo más chico, el conocimiento arquitectónico, las decisiones históricas, las razones por las que ciertos patrones fueron evitados — todo eso está concentrado en una o dos personas. Cuando se van, más se va con ellos. La documentación no es opcional en este modelo. Es un seguro.
Por Qué Esta Es una Historia de Claridad, No de Costos
Los equipos que implementan este modelo como un ejercicio de reducción de costos — reduciendo el headcount sin cambiar cómo trabajan las personas que quedan, de qué son responsables, o cómo se definen los requerimientos — van a fallar. Van a producir más código, más rápido, con más deuda técnica y más incidentes de producción que el equipo que reemplazaron.
Los equipos que lo implementan como un ejercicio de claridad — haciendo preguntas difíciles sobre dónde realmente vive el juicio, reestructurando roles alrededor de los nuevos cuellos de botella, invirtiendo profundamente en la calidad de las personas que quedan — van a construir algo genuinamente mejor.
Los equipos más chicos tienen menos problemas de alineación. Menos handoffs significan menos oportunidades de que los requerimientos se distorsionen en la traducción. Un PM/PO que escribe casos de prueba antes de que empiece el desarrollo produce requerimientos más claros que uno que se los pasa a un BA para interpretación. Un developer que construye tests junto con los features atrapa problemas más temprano y más barato que uno que despacha al QA al final del sprint.
El equipo clásico de ocho fue optimizado para un mundo donde la ejecución era el cuello de botella. El equipo de tres está optimizado para un mundo donde el juicio lo es.
La IA no solo hizo los equipos más chicos. Hizo la claridad más valiosa de lo que ha sido nunca.
Diego Fiorentin es el fundador de NextTo.ai, una consultora de IA que ayuda a empresas a implementar IA operacionalmente — primero el negocio, no la herramienta. Si estás pensando en cómo debería verse la estructura correcta de equipo para tu organización en un contexto asistido por IA, agendá una conversación →
