La ley de Brooks cumple 50 años y sigue teniendo razón

En 1975, Fred Brooks publicó El mítico hombre-mes e introdujo lo que pasó a conocerse como la Ley de Brooks: añadir mano de obra a un proyecto de software retrasado lo retrasa aún más. La idea clave era que el desarrollo de software no es como cavar una zanja, donde el doble de personas significa la mitad de tiempo. Implica comunicación, coordinación e integración que crecen en complejidad a medida que el equipo crece y, en cierto punto, el coste de añadir una nueva persona supera la producción que esta aporta.

Cincuenta años después, las herramientas han cambiado enormemente. Comunicación asíncrona, canales de CI/CD, infraestructura como código, arquitecturas modulares, revisión de código asistida por IA. La pregunta es si estas herramientas han dejado obsoleta la Ley de Brooks.

Los datos dicen que no. Han desplazado la curva (el tamaño del equipo en el que el coste de coordinación se vuelve problemático es mayor ahora que en 1975), pero la dinámica fundamental, de que las vías de comunicación crecen más rápido que la plantilla, sigue siendo cierta.

Las matemáticas no han cambiado

El número de vías de comunicación individuales en un equipo crece con n(n-1)/2. Con 5 personas: 10 vías. Con 10: 45. Con 20: 190. Con 50: 1.225. Este es un hecho matemático que ninguna herramienta puede cambiar. Cada vía es un punto potencial de coordinación, un posible malentendido, una posible reunión.

Las herramientas modernas reducen el coste por vía. La comunicación asíncrona significa que no todas las vías requieren tiempo síncrono. CI/CD detecta problemas de integración que antes requerían coordinación manual. Los contratos de API claros reducen la necesidad de debates interequipos sobre las interfaces. Pero reducir el coste por vía no cambia el número de vías, y este número crece lo suficientemente rápido como para que incluso las vías baratas resulten caras en su conjunto.

El análisis de datos de ingeniería reales de más de 100 empresas B2B (PanDev Metrics, 2026) confirma el patrón: los equipos pequeños (2-5 desarrolladores) dedican una mayor proporción de su día a programar, mientras que los equipos más grandes dedican proporcionalmente más tiempo a la coordinación. Los equipos que mejor escalan comparten tres rasgos: subequipos pequeños y autónomos, límites de propiedad claros e inversiones en procesos asíncronos que reducen el coste de coordinación por vía.

Lo que realmente cambian las herramientas modernas

Las herramientas modernas no rompen la Ley de Brooks, pero sí desplazan el punto de inflexión.

La comunicación asíncrona (Slack, Notion, Loom) reduce el coste de las reuniones al permitir que cierta coordinación ocurra sin que todos estén disponibles simultáneamente. Pero las herramientas asíncronas crean su propia carga de coordinación: más canales que monitorizar, más hilos que seguir, más notificaciones que procesar. La coordinación se traslada de las reuniones a la mensajería, y el coste total no disminuye necesariamente.

Los canales de CI/CD detectan problemas de integración automáticamente, reduciendo la necesidad de coordinación manual en torno a fusiones y despliegues. Esto reduce significativamente una categoría de costes de coordinación, pero no aborda las categorías más importantes: transferencia de contexto, toma de decisiones y uso compartido del conocimiento.

Las arquitecturas modulares (microservicios, APIs bien definidas) reducen el acoplamiento entre equipos, permitiéndoles trabajar de forma más independiente. Esta es la mitigación más eficaz porque reduce el número de vías que realmente soportan tráfico de coordinación. Pero la arquitectura modular requiere una inversión inicial significativa, y los límites entre módulos crean sus propias necesidades de coordinación.

La documentación autogenerada reduce el coste de la transferencia de contexto al hacer que el conocimiento esté disponible sin requerir la presencia de la persona que lo posee. Esto aborda directamente una de las tres causas de sobrecoste identificadas por Brooks (siendo las otras dos la formación y la integración). Cuando una persona nueva puede leer la documentación en lugar de preguntar al equipo existente para situarse, la carga de incorporación que identificó Brooks se reduce sustancialmente.

El giro de la era de la IA

Investigaciones recientes introducen un giro que Brooks no habría previsto. En la era de la IA, cada persona de un equipo puede dirigir agentes de IA que amplifican su producción individual. Un solo ingeniero con herramientas de IA puede producir código a un ritmo que antes requería dos o tres ingenieros.

La conclusión ingenua es que la IA rompe la Ley de Brooks porque se necesita menos gente. La conclusión más matizada, de un artículo de 2026 sobre el "Cuello de botella de la novedad", es que la IA podría en realidad empeorar la Ley de Brooks.

El razonamiento: si la producción amplificada de cada persona aumenta la carga de integración de todos los demás miembros del equipo, entonces el coste marginal de coordinación de añadir a la persona n+1 crece con la capacidad del agente. Un equipo de cinco ingenieros, cada uno de los cuales utiliza agentes de IA para producir el triple de código, sigue necesitando integrar ese código, revisarlo, probarlo y mantener la coherencia en todo el sistema. La carga de integración escala con la producción total, y la IA aumenta la producción total por persona.

La predicción práctica: las organizaciones mejoradas con IA deberían converger hacia equipos más pequeños y autónomos en lugar de equipos más grandes. Un equipo de 5 ingenieros con IA puede igualar la producción de un equipo de 50 sin IA, incurriendo en un coste de coordinación mucho menor. Esto es coherente con el patrón emergente de pequeñas empresas emergentes mejoradas con IA que superan a organizaciones de ingeniería tradicionales más grandes.

La implicación práctica

La Ley de Brooks se cita a menudo como una advertencia (no añadas personas a un proyecto retrasado), pero su implicación más profunda es prescriptiva: invierte en reducir el coste de coordinación en lugar de aumentar la plantilla.

Las inversiones que reducen el coste de coordinación son las mismas que han sido eficaces desde que Brooks escribió sobre ellas, actualizadas para las herramientas modernas:

Límites e interfaces claros entre equipos, para que cada equipo pueda trabajar de forma autónoma. El modelo de equipo de dos pizzas es la expresión organizativa de esto.

Documentación que reduzca la carga de incorporación y transferencia de contexto, de modo que las nuevas personas pasen a ser productivas sin consumir el tiempo del equipo existente.

Conocimiento accesible que ponga la información a disposición de los usuarios bajo demanda, de modo que la coordinación no requiera una comunicación síncrona.

Procesos que priorizan lo asíncrono que reduzcan la carga de reuniones, de modo que la coordinación se realice por escrito en lugar de en tiempo real.

Brooks tenía razón en 1975, y la idea fundamental no ha cambiado. El coste de comunicación crece más rápido que el tamaño del equipo. La única pregunta es cuánto de ese coste estás dispuesto a aceptar frente a cuánto estás dispuesto a invertir para reducirlo.

Preguntas frecuentes

¿Ha superado alguna empresa realmente la Ley de Brooks? Las empresas han desplazado la curva significativamente a través de una arquitectura modular, límites claros entre equipos y una documentación sólida. Los equipos de dos pizzas de Amazon son el ejemplo más citado. Pero la dinámica subyacente (las vías de comunicación crecen con n²) no se ha eliminado. Se ha gestionado.

¿Significa esto que nunca debemos escalar los equipos? Significa que el escalado debe ir acompañado de una inversión proporcional en infraestructura de coordinación. Añadir personas sin añadir documentación, límites claros y procesos asíncronos es donde la Ley de Brooks golpea con más fuerza.

¿Qué tamaño deben tener los equipos? Las investigaciones señalan sistemáticamente que el rango óptimo para los equipos autónomos es de 5 a 8 personas. Por encima de 8, considera la posibilidad de dividirlos en subequipos con interfaces claras. El modelo de equipo de dos pizzas ofrece un marco práctico.

Lecturas relacionadas: El problema del escalado del conocimiento, Cómo escalar un equipo de ingeniería, Por qué tu equipo se está volviendo más lento, El impuesto de coordinación. Páginas relacionadas: Documentación autogenerada, Para equipos de ingeniería.