Equipos de una pizza: qué organiza distinto cuando cada persona rinde el doble
Hay una frase que empieza a circular en las reuniones de ingeniería: "pasamos de equipos de dos pizzas a equipos de una". La metáfora es vieja —la de Bezos: ningún equipo debería ser tan grande que dos pizzas no alcancen para alimentarlo—, pero el adjetivo es nuevo. Y el adjetivo es lo que importa: no achicaron las pizzas, cambió lo que una persona puede mover.
La tentación con este tipo de frases es tratarlas como moda, sonreír y seguir. Pero hay evidencia detrás, y hay una trampa detrás de la evidencia.
Qué cambió de verdad
Los números que sostienen la moda son difíciles de ignorar. La investigación interna de Anthropic reporta que sus ingenieros usan Claude en el 60% de su trabajo y perciben un aumento de productividad del 50%, con un salto de 2 a 3 veces respecto de un año atrás. El dato más interesante no es ese: el 27% de ese trabajo asistido por IA son tareas que no se habrían hecho de otra manera. No es que hagan lo mismo más rápido. Es que aparece una categoría nueva de trabajo que antes no justificaba las horas.
En el otro extremo, el estudio de campo de Harvard y Wharton en P&G encontró que individuos usando IA rindieron tan bien como equipos que no la usaban, y que los equipos con IA superaron a los que no la usaban en producir ideas de primer nivel. Es decir: una persona con buena palanca empezó a equivaler a un equipo.
Y el DORA 2025 confirma la adopción generalizada: el 90% de los profesionales técnicos usa IA en su trabajo y más del 80% cree que le aumentó la productividad.
Con esos datos, la conclusión aparente es obvia: contraten menos, aprieten más.
Esa conclusión es probablemente la lectura incorrecta.
La trampa: "más chicas" no es "más baratas"
En las organizaciones que lo hacen bien, el equipo no se achica porque se recorte gente. Se achica porque creció la salida de cada persona. Son dos cosas distintas con consecuencias opuestas.
Cuando el achicamiento viene del recorte, la narrativa de la IA funciona como coartada: "con estas herramientas, cuatro alcanzan". Lo que no se pregunta es si cuatro alcanzan para lo que se les pide hoy, ni quién absorbe la revisión, ni quién responde el fin de semana. El resultado es un equipo más chico y más frágil, que descubre el problema seis meses después, cuando se va la única persona que entendía el sistema.
Cuando el achicamiento viene de la palanca, el equipo se achica porque la coordinación ya no justifica el peso. Y ahí las leyes viejas siguen vigentes: Brooks seguía teniendo razón al decir que agregar gente a un proyecto tarde lo hace más lento, y Conway seguía teniendo razón al decir que los sistemas terminan pareciéndose a las organizaciones que los construyen. Los equipos chicos no están de moda porque sean baratos. Están de moda porque el costo de coordinación crece más rápido que el beneficio de sumar personas. La IA no derogó esas leyes; las hizo más caras de ignorar.
El impuesto que nadie ponía en la planilla
El DORA publicó en marzo de 2026 un análisis profundo sobre 1.110 respuestas abiertas de ingenieros de Google, y el hallazgo incómodo es este: mayor adopción de IA se correlaciona con más throughput y con más inestabilidad, al mismo tiempo.
El motivo es un impuesto que no estaba contemplado: el tiempo ahorrado escribiendo se reasigna a auditar. Verificar es una tarea cognitiva distinta de crear. Un ingeniero lo resume así: gasto menos tiempo escribiendo código y más tiempo vigilando lo que la IA está intentando hacer.
Y hay una asimetría cruel: quien genera rápido trasladó su velocidad a quien revisa. Un PR de 2.000 líneas llega en diez minutos; revisarlo cuesta lo de siempre. La productividad del autor se convierte en carga cognitiva del revisor.
A eso se suman dos tensiones que el informe nombra con precisión:
- La paradoja del expertise. Bajar la barrera de entrada ayuda a entrar y perjudica a aprender. Si la IA confirma tus primeras suposiciones sin importar si son arquitectónicamente sanas, y vos no tenés el dominio para verificarlo, obtenés velocidad con falsa confianza.
- El hueco del workflow. Prototipar es instantáneo; llevar eso a producción —casos borde, integración con sistemas internos, datos propios— devuelve buena parte del tiempo ahorrado.
La frase que resume todo el informe: la IA es un amplificador. Magnifica las fortunas de los equipos ordenados y las disfunciones de los desordenados. Un equipo con APIs claras, tests y buena infraestructura obtiene un colaborador. Uno con tooling fragmentado y datos en silos obtiene deuda técnica a mayor velocidad.
Ideas para intentar (y cómo saber si funcionaron)
Nada de esto se resuelve con una política de "usen IA". Se resuelve con experimentos chicos y medibles. Estas son las que valdría la pena probar primero:
1. Reemplazar el límite de personas por un dueño por capacidad. En vez de "el equipo tiene que ser de cinco", preguntar: ¿quién es dueño de esta capacidad de negocio de punta a punta? Si esa persona puede moverlo con agentes, el equipo es esa persona y su entorno de soporte. Señal de que funcionó: bajan las reuniones de coordinación sin bajar la velocidad de entrega.
2. Mover la revisión al autor. El feedback de IA sobre el código debe llegar mientras se escribe, no al PR. Y construir agentes de revisión que apliquen los estándares del equipo antes de que un humano tenga que mirarlo. Señal: baja el tiempo de review y no suben los bugs en producción.
3. Lotes pequeños obligatorios. Es la contramedida más efectiva contra el volumen generado por IA. Si el PR supera un umbral fijo (pongamos 400 líneas), se parte. Sin excepción. Señal: el tamaño medio de PR baja y la tasa de comentarios por PR baja también.
4. Presupuesto de revisión por persona. Si cuatro personas generan como ocho, el cuello de botella es la revisión. Limitar cuántos PR revisa alguien por día y tratar el exceso como un problema de proceso, no de esfuerzo. Señal: desaparece la cola de PR sin tocar los plazos de entrega.
5. Medir impacto, no output. Dejar de mirar líneas de código o PRs cerrados —métricas que la IA infla trivialmente— y mirar throughput e inestabilidad (DORA), más una lectura cualitativa de calidad. Señal: las métricas siguen subiendo cuando la IA baja, lo que revela qué estaba causando qué.
6. Horas de lucha productiva. Reservar tiempo deliberado para resolver a mano lo que la IA resolvería, y parear seniors con juniors en las decisiones de arquitectura generadas por IA. No es nostalgia: es la única forma de que exista alguien capaz de verificar dentro de cinco años. Señal: la capacidad del equipo para detectar errores de la IA no baja pese al aumento de volumen.
7. Llevar el ratio humano-agente. Microsoft WorkLab ya lo propone como métrica de gestión: qué porcentaje de tu salida viene de trabajo directo y qué tanto de trabajo asistido o agenciado. Nadie sabe aún cuál es el ratio correcto. Pero no se puede corregir lo que no se mide. Señal: dejás de discutir opiniones y empezás a discutir números.
Lo que de verdad está en juego
La pregunta no es si los equipos van a ser más chicos. Es si vamos a entender por qué.
Si la respuesta es "porque la IA reemplaza gente", el resultado va a ser un equipo más liviano, más estresado y con más deuda, porque nadie revisó el impuesto de verificación ni el hueco entre prototipo y producción. Es el mismo error de siempre con un disfraz nuevo: confundir una herramienta que amplifica con una herramienta que sustituye.
Si la respuesta es "porque una persona con buena palanca coordinaba mal con cuatro más", entonces el equipo chico no es un recorte: es una decisión de diseño. Y las decisiones de diseño se cuidan —con límites de tamaño, con revisión temprana, con presupuesto de atención, con formación continua.
El equipo de una pizza no es la respuesta. Es una pregunta mejor formulada: cuánto le cuesta a una persona coordinar, y cuánto puede cargar antes de que la velocidad de hoy se convierta en el incidente del trimestre. Esa respuesta no la da ninguna tendencia. La da el equipo, medido, cada pocos meses, con honestidad.
Y mientras tanto, vale la pena acordarse de algo que la narrativa del "cada vez menos gente" tiende a olvidar: que alguien haya aprendido a hacer en dos horas lo que antes tomaba dos días no dice nada sobre si esa tarea valía la pena hacer, ni sobre quién va a responder cuando algo de ese trabajo falle un viernes a la mañana.