Releer a Brooks en tiempos de copilotos

Cincuenta años después de The Mythical Man-Month, muchas de sus ideas siguen resonando. Pero en la era de los copilotos, algunas empiezan a sonar distinto.

Hace medio siglo, Frederick P. Brooks publicó un libro que buscaba entender por qué escribir software era tan doloroso. Hoy vivimos en una era en la que escribir software parece más fácil que nunca. Pero… ¿lo es realmente?

Frederick P. Brooks Jr. (1931–2022) fue un pionero de la computación moderna y una figura clave en el desarrollo de la ingeniería de software como disciplina. Su mayor legado nació durante su paso por IBM, donde lideró uno de los proyectos más ambiciosos de la historia de la informática: el System/360.

En la década de 1960, Brooks fue responsable de dirigir el desarrollo tanto del hardware como del sistema operativo OS/360, una tarea titánica que lo enfrentó a desafíos técnicos, organizacionales y humanos. De esa experiencia surgieron las ideas que plasmaría en The Mythical Man-Month (1975), un libro que se convirtió en una biblia para generaciones de ingenieros de software.

Hoy, cincuenta años después de su publicación, vivimos en un mundo que Brooks no pudo anticipar del todo, pero que interpela directamente muchas de sus intuiciones: una era en la que LLMs colaboran con humanos para escribir código, sugerir diseños, depurar errores y hasta tomar decisiones arquitectónicas. En este artículo, propongo volver sobre algunas de sus ideas centrales y preguntarnos qué permanece, qué ha mutado, y qué podríamos (o deberíamos) desaprender en tiempos de copilotos.

¿Qué decía The Mythical Man-Month?

The Mythical Man-Month no es un manual técnico ni un libro de recetas. Es una colección de ensayos escrita por alguien que sobrevivió a un proyecto monstruoso —el sistema operativo OS/360 de IBM— y que quiso entender qué había salido tan mal. Su objetivo: darle lenguaje y marco a las frustraciones cotidianas de los equipos de software. Medio siglo después, muchas de sus ideas siguen resonando.

La Ley de Brooks

“Añadir más programadores a un proyecto retrasado lo retrasa aún más.”

Esta afirmación, tan paradójica como precisa, captura una de las grandes tensiones del desarrollo de software: el esfuerzo de coordinación crece más rápido que la productividad cuando el equipo se agranda. Brooks observó que incorporar nuevas personas a un proyecto en crisis no solo no resuelve el problema, sino que lo agrava. ¿Por qué? Porque quienes llegan deben ser capacitados, integrados, puestos al tanto del contexto, y porque toda decisión ahora debe incluir una voz más.

La Ley de Brooks no es un argumento contra el crecimiento, sino contra la ilusión de que más gente equivale automáticamente a más velocidad. En muchos casos, más personas significan más comunicación, más malentendidos, más refactorizaciones y más tiempo invertido en alinear criterios.

Y sin embargo, esta es una idea que merece ser revisitada a la luz del presente. ¿Qué pasa cuando quienes se incorporan no son personas, sino copilotos? ¿Sigue teniendo sentido esta ley si menos personas pueden producir más que nunca?

El “hombre-mes” es un mito

Brooks cuestionó una de las ideas más arraigadas en la gestión tradicional: que el trabajo intelectual puede dividirse y distribuirse como si fuera trabajo físico repetitivo. En las industrias tradicionales, tenía sentido hablar de “hombre-mes”: si una tarea consiste en ensamblar piezas o cavar zanjas, más personas trabajando en paralelo tienden a completar el trabajo más rápido. Pero el software no funciona así. No es una carretera que se puede construir por tramos independientes; es más cómo diseñar un mapa entero, donde cada decisión afecta al conjunto y lo redefine.

El problema es que escribir software implica una combinación de diseño, comprensión de dominio, toma de decisiones y sincronización con otros. No se puede simplemente fragmentar una tarea y asignarla en paralelo sin consecuencias. Algunos pasos son secuenciales. Otros, interdependientes. Muchos requieren contexto. Tratar el trabajo de software como si fuera un conjunto de tareas intercambiables lleva directamente a estimaciones equivocadas y cronogramas imposibles.

Coordinar cuesta, ¡mucho!

A medida que un equipo crece, la dificultad no está solo en repartir tareas, sino en mantener a todos en la misma página. Cada miembro adicional no suma una unidad de trabajo: agrega múltiples nuevos vínculos de comunicación, posibles malentendidos y decisiones que deben sincronizarse.

Brooks ilustra esto con una fórmula simple pero poderosa: el número de canales de comunicación en un equipo de n personas es n(n–1)/2. Con 5 personas, hay 10 canales posibles. Con 10 personas, hay 45. Con 20, ya son 190. Y con 50 —una escala nada infrecuente en equipos modernos— estamos hablando de 1.225 canales de comunicación teóricos.

En la práctica, claro, no todos hablan con todos. Pero la sobrecarga mental y organizativa de coordinar trabajo complejo en grupos grandes es real. La consecuencia no es solo más reuniones: es más ambigüedad, más decisiones contradictorias, más trabajo re-hecho.

No hay balas de plata

Aunque esta idea se desarrolla más tarde en su célebre ensayo “No Silver Bullet” (1986), Brooks ya advertía en 1975 contra la tentación de buscar soluciones mágicas. El desarrollo de software, decía, no puede acelerarse indefinidamente con nuevas herramientas, lenguajes o técnicas.

Su distinción entre complejidad accidental (provocada por herramientas, bugs, sintaxis, entornos) y complejidad esencial (la que proviene del propio problema que intentamos resolver) sigue siendo fundamental. Las herramientas pueden pulirse. El problema en sí —lo que el software intenta modelar o resolver— muchas veces no.

Dicho eso, vale la pena reconocer que la inteligencia artificial, en particular los copilotos, sí están alterando el balance de esa ecuación. No porque eliminen la complejidad esencial, sino porque reducen drásticamente el costo de lidiar con la accidental. Lo que antes requería tres desarrolladores ahora puede resolverse con uno. Equipos chicos están logrando resultados antes reservados a estructuras mucho más grandes.

Esto no invalida la advertencia de Brooks, pero sí la matiza: no hay una bala de plata… pero puede que estemos por primera vez muy cerca de algo que se le parece peligrosamente. ¿Qué pasa si el problema no es más “necesitamos más manos”, sino “cómo diseñamos bien con tan pocas”?

El diseño necesita una mente clara

Uno de los principios más subestimados del libro es su defensa de la unidad de diseño conceptual. Para Brooks, el software de calidad no emerge del caos colaborativo, sino de una visión coherente y bien estructurada. No es que el trabajo en equipo esté mal, sino que requiere una arquitectura común.

Cuando muchos diseñan sin una visión clara, el resultado es un sistema que se siente inconsistente, lleno de excepciones y parches. Brooks propone que haya una (o pocas) voces responsables del diseño, como ocurre en la arquitectura, la literatura o el cine. Alguien que cuide el tono, el estilo, la estructura.

En la era de los copilotos, esta idea se vuelve aún más relevante: si cada desarrollador tiene su propio asistente, el riesgo de divergencia aumenta. Ya no es solo el equipo humano el que necesita alinearse, sino también sus herramientas automatizadas. Más que nunca, necesitamos claridad en la intención, consistencia en los patrones, y alguien —o algo— que mantenga la dirección del conjunto.

Paradojas para releer a Brooks con un copiloto al lado

¿Qué pasa cuando más manos sí hacen más?

Uno de los grandes traumas que inspiraron The Mythical Man-Month fue el tamaño. Brooks lideró en IBM un equipo con cientos de desarrolladores, ingenieros de sistemas, testers, analistas de requerimientos y gerentes. Era una maquinaria enorme, y sus fallas eran proporcionales a su escala: cuellos de botella, comunicación fragmentada, especificaciones que se volvían obsoletas antes de ser implementadas. En ese contexto, su diagnóstico fue certero: más manos no hacen más; a menudo, hacen menos.

Lo que Brooks no vivió —y difícilmente podría haber anticipado— fue que miles de empresas, fuera del mundo de las BigTech, llegarían a tener estructuras de desarrollo tan grandes como las que él “criticó” en los años 60. Startups de rápido crecimiento, corporaciones en proceso de transformación digital, unicornios… todos adoptaron el modelo de “más es mejor”. Irónicamente, lo hicieron muchas veces porque los problemas que enfrentaban eran los mismos que Brooks describía: errores de coordinación, deuda técnica, lentitud para iterar, desalineación entre producto y desarrollo.

Durante décadas, el camino para resolver estos problemas fue escalar: sumar equipos, crear squads, diseñar layers de liderazgo técnico, y construir procesos para sostener esa complejidad. El resultado fue una industria en la que cientos o miles de personas escriben software en paralelo… muchas veces sin saber bien qué, ni porqué, ni para quién.

Pero ahora, algo está cambiando. La IA generativa está permitiendo a equipos pequeños hacer lo que antes requería decenas o cientos de desarrolladores. No porque elimine el trabajo, sino porque acelera sus tramos más costosos y repetitivos. El salto de productividad no es lineal: no se trata de que una persona con un copiloto rinda un 30% más. En algunos casos, rinde diez veces más. Produce, itera, prueba y refactoriza sin pedir permiso ni perder el foco.

Esto no significa que todos los equipos grandes desaparecerán. Las grandes tecnológicas seguirán requiriendo arquitecturas humanas complejas. Pero para la mayoría de las empresas “normales”, el incentivo a escalar en número ya no es tan claro. Lo que antes se resolvía con más manos, hoy puede abordarse con menos… y con mucha más potencia.

Entonces, ¿qué pasa cuando más manos sí hacen más? Quizás la pregunta ya no sea esa. Quizás ahora sea: ¿qué pasa cuando menos manos hacen muchísimo más que antes?

¿Y si la bala de plata llegó… en forma de copiloto?

En 1986, Brooks escribió su célebre ensayo “No Silver Bullet”, donde afirmaba con convicción que no había —ni habría— una tecnología capaz de multiplicar la productividad del software por un factor de 10 en una década. Era una respuesta directa a la obsesión de la industria con encontrar “la próxima gran cosa”: un lenguaje, una metodología, una herramienta que hiciera que todos los problemas desaparecieran.

La fuerza de su argumento radicaba en una distinción simple pero poderosa: lo que ralentiza el desarrollo no es solo la herramienta, sino la naturaleza intrínseca del problema. Aunque podemos reducir la complejidad accidental —los bugs, el código repetitivo, la fricción del entorno de desarrollo—, la complejidad esencial —entender el dominio, tomar decisiones de diseño, negociar prioridades— sigue ahí, irreductible.

Y sin embargo, en 2025, la sensación de haber encontrado algo cercano a esa bala de plata es real. Los copilotos no son magia, pero muchas veces lo parecen. Reducen barreras de entrada. Producen código a gran velocidad. Asisten a desarrolladores junior y senior por igual. Permiten avanzar más rápido, con menos fricción, y en muchos casos con menos personas.

En este nuevo contexto, no es que Brooks haya quedado obsoleto, sino que su advertencia necesita una lectura más matizada. Tal vez no haya una bala de plata para todos los problemas, pero puede que sí haya herramientas que —sin ser mágicas— desbloqueen órdenes de magnitud de productividad en ciertos contextos. Especialmente en equipos pequeños, autónomos y bien organizados.

La verdadera pregunta ya no es si la IA es una solución mágica. Es otra, más inquietante: ¿qué sucede cuando una herramienta no resuelve todo… pero resuelve lo suficiente como para replantear los principios sobre los que se diseñaban equipos, cronogramas y productos?

¿Puede una IA mantener una visión conceptual?

Uno de los aportes más sólidos de The Mythical Man-Month es la defensa de lo que Brooks llamó “unidad de diseño conceptual”: la idea de que el software, como todo artefacto complejo, necesita una visión clara y coherente detrás. No basta con que funcione: debe ser comprensible, extensible, mantenible. Y para eso, alguien —o un pequeño grupo— debe encargarse de sostener la integridad conceptual del diseño.

En los años 70, esa advertencia tenía una lógica clara: si muchos diseñaban sin hablar entre sí, el resultado era un sistema caótico, lleno de inconsistencias y excepciones. Hoy, esa lógica no sólo sigue vigente: se vuelve más urgente en la era de los copilotos.

Porque aunque podamos usar el mismo modelo de lenguaje —el mismo LLM, el mismo copiloto—, los resultados que genera no son neutros ni homogéneos. Cada desarrollador lo interpela de forma distinta: con distintos prompts, estilos, convenciones y decisiones tácitas.

Los LLMs no son determinísticos: operan sobre probabilidades y pueden comportarse de manera impredecible –estocásticamente–, incluso usando el mismo modelo y el mismo prompt. Lo que antes se fragmentaba entre personas, ahora se fragmenta entre personas más su copiloto. El riesgo ya no es solo que el equipo esté desalineado, sino que el propio entorno automático potencie esa desalineación.

La paradoja es que usamos la misma herramienta, pero el resultado puede ser radicalmente distinto según quién la use y cómo. El copiloto aprende de tu historial, tu contexto, tu estilo. ¿Eso es potencia o es dispersión? ¿Estamos reforzando buenas prácticas o profundizando sesgos individuales?

Volver a Brooks nos recuerda que el diseño (arquitectura) no es solo una suma de líneas de código bien escritas, sino una estructura coherente que debe sostenerse a lo largo del tiempo. Si cada desarrollador (y su copiloto) decide por su cuenta, es muy probable que terminemos con un sistema funcional, pero ilegible. Y peor: inmantenible.

Los copilotos no resuelven la necesidad de una arquitectura clara. De hecho, la vuelven más crítica que nunca. Porque cuanto más fácil es escribir código, más fácil se vuelve producir desorden. La velocidad sin dirección no es progreso: es caos disfrazado de eficiencia.

¿Coordinar menos… o coordinar distinto?

Una de las promesas más seductoras de la inteligencia artificial en el desarrollo de software es la reducción del esfuerzo de coordinación. Si un copiloto puede generar funciones enteras, sugerir test cases, documentar código, e incluso hacer pull requests, entonces muchas tareas que antes requerían colaboración humana directa ahora pueden resolverse de forma más autónoma y silenciosa.

Pero aquí es donde aparece la trampa: menos fricción no siempre significa mejor coordinación. Lo que desaparece de la superficie —reuniones, revisiones, dependencias explícitas— no siempre desaparece del sistema. A veces simplemente se vuelve invisible, hasta que emerge en forma de bugs, incidentes, deuda técnica o decisiones contradictorias.

Brooks nos alertó sobre el costo de la coordinación cuando los equipos crecen. Pero lo que no vivió —y lo que ahora enfrentamos— es una situación donde ese costo parece desaparecer gracias a la IA. Y ese “parecer” es lo peligroso. Porque si asumimos que el copiloto resuelve la necesidad de comunicarnos, planificar, consensuar o diseñar juntos, lo que estamos haciendo no es optimizar el proceso, sino abandonarlo.

La paradoja, entonces, no es si necesitamos coordinar menos, sino si necesitamos coordinar distinto. Los copilotos no son simplemente otra herramienta más en la caja. No encajan cómodamente en el esquema clásico de “desarrollador – tarea – herramienta – entrega”. Son agentes activos, que producen, sugieren y, en algunos casos, completan tareas antes de que el equipo humano siquiera las discuta.

Por eso, abrazar estas herramientas sin repensar el proceso completo de desarrollo es un error profundo. No basta con añadir IA al flujo actual. Necesitamos revisar los rituales: ¿qué sentido tiene una daily cuando el grueso del trabajo se hace entre el dev y su copiloto? ¿Cómo cambian las revisiones de código cuando el código no fue escrito directamente por la mano humana, sino sugerido por una IA? ¿Qué rol debe cumplir el copiloto en el proceso de revisión de código? ¿Cómo evolucionan los criterios de calidad, los acuerdos de diseño, las definiciones de done?

Los copilotos interpelan no sólo nuestra productividad, sino también nuestras formas de trabajar. La coordinación no ha muerto. Pero tal vez ya no sea la misma. O tal vez esté a punto de cambiar en formas que aún no comprendemos del todo. La historia se sigue escribiendo, y con ella, nuestras prácticas.

Si no leyeron The Mythical Man-Month, ahora es el momento. No por nostalgia, sino porque muchas de las preguntas que planteaba —sobre personas, equipos, errores, tiempo, diseño— siguen sin respuesta. Pero ahora tenemos copilotos para intentarlo de nuevo. Como sucede con todo gran clásico en cualquier disciplina del conocimiento, su mensaje no caduca: sobrevive a generaciones, se resignifica con cada cambio de época, y nos interpela una y otra vez —sobre todo cuando creemos que ya tenemos todas las respuestas.

¿Y vos? ¿Ya conocías a Brooks? ¿Qué ideas creés que siguen vigentes en la era de los copilotos? Me encantaría saber cómo están viviendo esta transición quienes hoy diseñan, escriben o gestionan software con la ayuda de la IA.