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, y no en el all-hands. Aparece en las conversaciones más tranquilas, las de después de la demo, después de la reunión con el board, después del tercer sprint seguido que de alguna manera terminó antes y aun así dejó a todos con una incomodidad vaga.
La pregunta es: ¿a cuántas personas realmente necesito en este equipo?
Es incómoda porque suena a una pregunta de reducción de costos, como si estuvieras buscando una excusa para bajar el headcount y usar la IA de cobertura.
Pero no es eso lo que la mueve. Lo que la mueve es algo más honesto: la estructura de equipo que usamos durante veinte años se diseñó para restricciones que ya no existen, y reconstruirla para las 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 más o menos 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 se mantenía.
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 técnico era amplia y cara de salvar de manera informal. El Scrum Master existía porque correr un proceso Agile disciplinado tenía un overhead real. El QA estaba al final porque la validación era una habilidad distinta que necesitaba foco dedicado. Los cuatro developers existían porque escribir código era lento, y la única forma de producir más era poner más gente a hacerlo.
Cada rol resolvía un problema real. El equipo de ocho era una respuesta bien diseñada a las restricciones de 2001.
El Manifiesto Ágil se escribió antes del 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 lo que las herramientas de coding con IA le hicieron al desarrollo de software.
La versión incorrecta: la IA hace más rápidos a los developers, así que necesitás menos.
La versión precisa: la IA eliminó el cuello de botella de la generación de código, y eso corre el cuello de botella a otro lado completamente.
Esa distinción importa muchísimo 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, generar código es prácticamente gratis. Un solo developer dirigiendo IA puede producir lo que cuatro producían a mano. El cuello de botella ya no es cuánto código se escribe; es la calidad del juicio detrás de él.
¿Quién define el problema correcto a resolver? ¿Quién decide si la solución generada es realmente correcta? ¿Quién sostiene el modelo mental coherente del sistema a medida que evoluciona? ¿Quién atrapa el edge case que el modelo generó con confianza y mal?
Esas preguntas las responden personas, no modelos. Y no más personas, sino mejores personas trabajando con más claridad.
Por eso el equipo reestructurado es más chico sin ser más barato en el sentido habitual. No estás cambiando gente capaz por una herramienta. Estás rediseñando el equipo alrededor de dónde importa la habilidad ahora.
El Equipo de Tres
PM/PO: Una Persona, Dos Trabajos
En el equipo clásico, PM y BA eran roles separados porque convertir requerimientos de negocio en especificaciones técnicas era un trabajo de tiempo completo. Requería idas y vueltas constantes, mucha documentación y semanas de refinamiento antes de que un developer pudiera arrancar con confianza.
La IA colapsó ese costo de traducción.
Un PM/PO que puede decir con claridad y precisión qué hay que construir ahora usa IA para redactar user stories, criterios de aceptación y especificaciones técnicas en minutos en vez de días. El output no es perfecto, nunca lo es, pero es un borrador del 70% que se refina en una fracción del tiempo original.
Una persona haciendo lo que antes necesitaba dos, porque la parte más lenta del rol del BA, el trabajo mecánico de traducción, ahora lo maneja la IA.
Pero la implicación clave es que ese PM/PO tiene que ser mejor, no solo más rápido. El BA absorbía la ambigüedad a lo largo de semanas de iteración. Ahora esa ambigüedad hay que resolverla al principio, porque la IA va a ejecutar requerimientos poco claros a velocidad de máquina y 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 y toma más decisiones.
Su función principal es el juicio arquitectónico: sostener 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 IA contra la realidad de este codebase en particular.
También es la compuerta de calidad. No en el sentido del QA engineer, ya llegamos a eso, sino en que su ojo experimentado es el último chequeo antes de que algo salga a producción. Ve no solo si el código funciona, sino si encaja, si es mantenible, si está sembrando un problema que aparece en seis meses.
Este es el rol que el outage de Amazon de marzo de 2026 dejó visceralmente claro. Se deployó código generado por IA sin la revisión senior adecuada, y siguió un outage de seis horas en su sitio principal de ecommerce. La solución fue exigir sign-off de un senior en 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 que mantiene seguro a todo el sistema.
Senior Developer 2: El Builder
El segundo developer es el motor del equipo, haciendo el grueso de la construcción con la IA como copiloto activo.
Lo que lo diferencia de un developer mid-level tradicional es la autonomía que exige. Sin un BA en el equipo, esta persona lee los requerimientos del PM y los convierte directo en decisiones de implementación, sin capa de traducción. Con el QA reestructurado, genera e implementa tests como parte de su propio workflow, no como una fase aparte.
No es un rol junior. El apalancamiento que da la IA solo aparece cuando quien la dirige tiene experiencia suficiente para reconocer cuándo el output está mal, cuándo el enfoque es arquitectónicamente frágil y cuándo el modelo está resolviendo con confianza el problema equivocado.
Un junior con IA produce trabajo junior más rápido. Un senior con IA produce trabajo senior a una escala completamente distinta.
Qué Pasó con el QA
La desaparición del QA engineer de esta estructura es la que más explicación necesita, porque es la más contraintuitiva.
Sacar el QA no significa sacar la calidad. Significa mover la calidad a donde pertenece: al principio del proceso, no al final.
El modelo clásico de QA tenía una falla estructural que todos conocían pero no era fácil de arreglar: para cuando un bug llegaba al QA, arreglarlo ya era caro. El developer ya había seguido, el contexto estaba frío, y el QA testeaba contra especificaciones definidas por separado, por gente que podía tener otro modelo mental de qué era «correcto».
El modelo reestructurado ataca 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, sino 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.» Esos casos son la definición de done, explícita e inequívoca mientras cambiarlos todavía es barato.
Durante el desarrollo: el senior developer implementa esos casos como tests automatizados usando IA. El modelo genera alrededor del 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 recorre el feature contra los casos que él mismo escribió. No una revisión técnica, una 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 quién interpretó bien.
La calidad no se saca del proceso. Se reparte por él, donde es más barata, más rápida y más efectiva.
Lo que los Números Realmente Significan
Alguien razonable podría decir: este equipo es un 62% más chico, lo que suena a una reducción de costos con pasos extra.
Así que voy a ser claro sobre qué cambia y qué no.
Lo que se achica: el headcount, el overhead de coordinación, la cantidad de handoffs entre roles y el tiempo perdido en malentendidos, entre BA y dev, entre dev y QA, entre el Scrum Master y todos.
Lo que no se achica: la calidad de las personas, la inversión en esos tres individuos y la expectativa sobre su output.
Los senior developers de este modelo no hacen el 33% de lo que hacían cuatro. Hacen más, bastante más, porque la IA expandió lo que un developer hábil puede ejecutar. El PM/PO opera con más claridad y responsabilidad que el PM y el BA del modelo anterior juntos.
Este equipo cuesta menos en headcount y más en calidad individual. El intercambio vale la pena porque el apalancamiento de la IA escala con el juicio de quien la dirige, no con la cantidad de gente en la sala.
Un senior mediocre con IA sigue siendo mediocre. Va a generar más código mediocre, más rápido, y aprobarlo con confianza.
Un gran senior con IA es un multiplicador de fuerza.
Los Nuevos Cuellos de Botella que Necesitás Conocer
Te haría un flaco favor si te vendiera esto como una mejora limpia sin trade-offs. Hay nuevos modos de falla que conviene entender antes de reestructurar.
El senior developer se vuelve el punto único de falla. En el equipo clásico, la responsabilidad de revisión estaba repartida. Acá 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 se vuelven catastróficas. En el modelo clásico, los requerimientos ambiguos se atrapaban en semanas de iteración del BA. Acá se amplifican: la IA va a ejecutar un requerimiento ambiguo a velocidad de máquina, en la dirección equivocada, antes de que nadie note 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 se evitaron ciertos patrones, todo se concentra en una o dos personas. Cuando se van, se va más con ellas. 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 implementen esto como una reducción de costos, bajando el headcount sin cambiar cómo trabajan los 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 implementen como un ejercicio de claridad, haciéndose preguntas difíciles sobre dónde vive realmente el juicio, reestructurando roles alrededor de los nuevos cuellos de botella, invirtiendo a fondo en la gente que queda, van a construir algo genuinamente mejor.
Los equipos más chicos tienen menos problemas de alineación. Menos handoffs significan menos chances 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 interpretar. 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 estaba 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 que nunca.
Diego Fiorentin es el fundador de Next2AI, 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 →
