El mítico mes-agente

El año pasado, The Mythical Man-Month cumplió 50 años. La idea central de Fred Brooks —que añadir personas a un proyecto retrasado lo retrasa aún más— se convirtió en la ley fundacional de la planificación de software. Todos los PMs la han interiorizado. Cada estimación de capacidad de sprint está construida sobre ella.

Stripe la está sometiendo a pruebas de estrés en producción.

Según un informe de InfoQ sobre el despliegue de minions de código autónomo por parte de Stripe, los ingenieros de la empresa ahora ejecutan sistemas que producen miles de pull requests por semana. No decenas. No cientos. Miles —por semana— generados por procesos autónomos que no asisten a standups, no se quedan bloqueados en tickets de Jira y no necesitan "sincronizarse de forma asíncrona" con nadie.

Changelog lo dejó claro en su post Mythical Agent-Month: la vieja unidad de entrega de software —horas-persona, story points, capacidad de sprint— no encaja limpiamente con lo que está ocurriendo ahora. Y las implicaciones para la forma en que los equipos de producto planifican el trabajo son mayores de lo que la mayoría de las conversaciones sobre roadmaps están preparadas para asumir.

Cuando el cuello de botella no es el dev

La planificación de sprints siempre ha sido una negociación sobre la escasez. Tienes X ingenieros, Y días en un sprint, un margen de incertidumbre —y calculas qué cabe. La restricción siempre fue la atención humana: cuántas cosas puede un desarrollador tener en la cabeza, retomar y entregar antes de que el reloj de dos semanas llegue a cero.

Esa restricción se está reescribiendo en empresas como Stripe. Cuando los sistemas autónomos pueden generar miles de PRs a la semana, el cuello de botella se desplaza. Ya no es "¿podemos construir esto?" Se convierte en:

• ¿Podemos revisarlo? La capacidad de revisión humana pasa a ser el paso limitante.
• ¿Podemos especificarlo? Los requisitos vagos producen resultados vagos (y prolijos).
• ¿Podemos confiar en él? A volumen industrial de PRs, el coste de un merge malo se multiplica de otra manera.

El blog de GitHub declaró recientemente que la era de la "IA como texto" ha terminado —que la ejecución, no la generación, es ahora la interfaz principal. Ese encuadre cobra otro peso cuando ves a una empresa real ejecutarlo a la escala de Stripe. Esto no es un prototipo. Es un flujo de trabajo en producción que está redefiniendo cómo se hace el software.

Qué le hace esto a los roadmaps

La mayoría de los roadmaps de producto todavía se construyen en torno a la capacidad de entrega humana. "Tenemos cuatro ingenieros este trimestre, esto es lo que podemos entregar." Ese cálculo tenía sentido cuando la ingeniería era la restricción principal.

Pero si un equipo puede generar un orden de magnitud más de output del que puede razonar, revisar o desplegar de forma segura, la pregunta del roadmap cambia. Ya no planificas en torno a lo que puedes construir. Planificas en torno a lo que puedes absorber.

Eso requiere una habilidad completamente distinta. Implica:

Especificación más precisa. Los sistemas autónomos no te devuelven un ticket mal especificado. Producen output a partir de lo que se les da. La calidad de tu input —el PRD, los criterios de aceptación, los casos límite que has tenido la previsión de nombrar— determina si obtienes PRs útiles o 2.000 errores muy seguros de sí mismos.

Arquitectura de revisión deliberada. Si el volumen de PRs escala más rápido que la capacidad de revisión humana, necesitas un enfoque por niveles: verificaciones automatizadas que gestionen la validación rutinaria, revisión humana reservada para decisiones con verdadero peso arquitectónico. El artículo de InfoQ sobre Platform Engineering as Sociotechnical Excellence argumenta algo más amplio: las estructuras sociales en torno al software importan tanto como las técnicas. Eso es doblemente cierto cuando el volumen de output se dispara.

Replantear qué significa "terminado". Que un PR esté abierto no significa que una funcionalidad esté entregada. A alto volumen, la brecha entre "el código existe" y "el valor llega al usuario" se amplía. Los equipos de producto que confunden ambas cosas tendrán métricas de velocidad muy optimistas y clientes muy confundidos.

El problema de diseño organizativo del que nadie habla

El post de Changelog acuña "agent-month" en parte como un chiste, pero el chiste funciona porque nombra algo real: la presión de tratar el output autónomo como equivalente a la entrega humana. No lo es —pero el incentivo para fingir que sí lo es será intenso, especialmente en organizaciones donde el headcount de ingeniería está bajo presión.

Aquí está la tensión: si un sistema autónomo puede generar miles de PRs a la semana, el caso económico para grandes equipos de ingeniería cambia. Eso crea una dinámica política en la que a los PMs y a los managers de ingeniería se les pide simultáneamente que entreguen más y que justifiquen por qué necesitan el mismo headcount.

La respuesta honesta es que los requisitos de headcount cambian de forma, no necesariamente de tamaño. Necesitas menos personas escribiendo código repetitivo y más personas haciendo lo que los sistemas autónomos no pueden: marcar la dirección, tomar decisiones de juicio sobre trade-offs, mantener la capacidad del sistema de corregir el rumbo cuando algo se tuerce. Las horas-persona no desaparecen —se redistribuyen.

En la práctica, esto significa que los product managers necesitan mejorar en algunas cosas concretas:

• Escribir requisitos que sean verificables y acotados, no sugestivos y abiertos
• Entender cuál es realmente el ancho de banda de revisión de su equipo de ingeniería —y protegerlo como un recurso escaso
• Distinguir entre velocidad (PRs mergeados) y throughput (valor en manos de los usuarios)
• Resistir el encuadre de que "podríamos entregar más si simplemente confiáramos más en la automatización"

El número que debería quitar el sueño a los PMs

Miles de pull requests por semana generados por los sistemas autónomos de una sola empresa. Eso no es un benchmark que celebrar sin espíritu crítico —es una señal de que el sistema de entrega de software está produciendo output más rápido de lo que la mayoría de las organizaciones pueden evaluarlo con seguridad.

Brooks tenía razón en que añadir personas a un proyecto retrasado lo retrasa aún más. El corolario para este momento podría ser: añadir output autónomo a un roadmap mal especificado lo complica aún más. La restricción ha pasado de la generación al juicio, y el juicio no escala de la misma manera.

Los equipos que descubran cómo estructurar su planificación, revisión y especificación en torno a esta nueva realidad tendrán una ventaja real. Los que simplemente apunten al recuento de PRs y lo llamen velocidad tendrán un trimestre muy ajetreado y una retrospectiva muy confusa.