Brooks’s Law: más agentes de IA no aceleran tu código

La ley de Brooks no desapareció, mutó

En 1975, Frederick P. Brooks Jr. formuló en The Mythical Man-Month una regla que sigue incomodando a cualquiera que gestione proyectos de software: "agregar personal a un proyecto atrasado lo hace más lento". La observación nacía de su experiencia dirigiendo el sistema OS/360 de IBM, y durante medio siglo se leyó como una advertencia sobre la coordinación humana.

La pregunta que plantea el blog j11g.com es la correcta para 2026: ¿sigue vigente cuando los "programadores" son agentes de IA que arrancan en milisegundos y no piden café? La respuesta corta es que sí, pero con otra cara. El cuello de botella no desapareció: se movió de gestionar personas a gestionar agentes. Y alguien —tú— sigue teniendo que definir qué es "terminado", revisar el código, cazar alucinaciones y coser las piezas.

El "problema del bebé" sigue en pie: nueve agentes no entregan un bebé en un mes. Las tareas secuenciales siguen siendo secuenciales.

Leíste lo que hace la IA. ¿Y en tu negocio?

Un agente de IA puede quedarse con parte de tu día: ordenar lo pendiente y pedirte el OK antes de actuar. El Kit «tu mano derecha con IA» trae un video de 11 minutos y una ficha para dejar al tuyo trabajando. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.

👥 Quiero el Kit →

¿Por qué sumar agentes no acelera el desarrollo de software?

Aquí los datos de 2026 son duros. Según el McKinsey Technology Trends Outlook 2026, recogido por CIO.com, el 89% de las empresas ya usa IA de forma regular, pero solo el 37% atribuye algún impacto positivo en su EBIT a sus programas de IA. La adopción corre muy por delante del retorno.

En desarrollo de software el patrón se repite. McKinsey encontró que solo una cuarta parte de las empresas que usan agentes de IA para programar logró acelerar de forma significativa sus ciclos de desarrollo. Y hay un dato que debería hacerte frenar: en el 30% de las compañías, la productividad cayó después de que los equipos empezaran a usar agentes de código.

La distribución del beneficio es brutalmente desigual. Alrededor del 80% de los desarrolladores que usan herramientas de IA logró aumentos de productividad de apenas un 3%. El 20% superior, en cambio, vio saltos del 55%. La diferencia no está en la herramienta: está en cómo se orquesta.

El problema no es generar código, es que el código sirva

McKinsey documenta una brecha que resume todo: la actividad de programación aumentó un 180% gracias a las herramientas de IA, pero el número de releases publicados creció solo un 30%. Se produce mucho más, se entrega apenas algo más.

El fenómeno tiene nombre: AI code slop. Según el informe State of AI Code Quality de Qodo, que encuestó a 500 desarrolladores y 300 líderes de ingeniería en Estados Unidos, el 89% de las organizaciones reportó algún incidente en producción relacionado con IA. Y solo el 3,7% de los líderes considera que sus procesos actuales alcanzan para mantener calidad y gobernanza a medida que los agentes asumen más trabajo.

El costo humano también sube: el 36,4% de los desarrolladores dice que revisar código generado por IA exige más esfuerzo cognitivo, no menos. Ahí está la ley de Brooks mutando en tiempo real: el trabajo de coordinación y verificación no desapareció, se trasladó.

A esto se suma el riesgo de seguridad. El informe 2026 GenAI Code Security de Veracode, que analizó más de 100 modelos, encontró que la tasa promedio de aprobación de seguridad del código generado por IA es del 56%. Casi la mitad del código pasa con vulnerabilidades.

La confianza es el otro cuello de botella

McKinsey reporta que alrededor del 46% de los desarrolladores desconfía activamente de la precisión de las herramientas de IA. Un tercio confía en principio, y solo el 3% tiene mucha confianza en los resultados.

Esa desconfianza no es un prejuicio: es una respuesta racional a un problema de verificación. Si el código generado "se ve convincente" —nombres limpios, estructura razonable, tests básicos que pasan— pero esconde una validación de permisos faltante o una consulta costosa a la base de datos, el revisor humano es el último filtro. Y ese filtro no escala al ritmo al que crece el volumen.

¿Cómo se orquesta esto sin volverte el cuello de botella?

La respuesta que emerge de las fuentes no es "menos agentes", sino mejor orquestación. El propio McKinsey señala que herramientas como LangGraph de LangChain aportaron los controles de orquestación y "human-in-the-loop" que hacían falta para guiar agentes en flujos largos. La clave es que el humano supervise puntos de decisión, no cada línea.

En Semgrep, según su cofundador y CTO, alrededor del 80% del código ya se escribe con IA internamente. Su respuesta fue exigir a los ingenieros un "plus one" sobre el código generado y usar bots para buscar bugs. La lección: la revisión se vuelve un sistema, no un acto heroico individual.

¿Qué significa esto para tu startup?

Si estás metiendo agentes en tu pipeline de desarrollo, estas son las decisiones que importan:

Define "terminado" antes de sumar agentes. La actualización de la ley de Brooks que propone el artículo original es exacta: "agregar agentes a un proyecto con requisitos poco claros te lleva a la respuesta equivocada más rápido". Sin criterios de aceptación explícitos, cada agente optimiza para algo distinto y se reescriben entre sí en un bucle veloz.
Mide resultados, no actividad. El 180% más de actividad de programación contra un 30% más de releases es la trampa. Tu métrica no puede ser líneas de código ni interacciones con el agente: tiene que ser releases que llegan a producción y funcionan.
Presupuesta el cómputo. McKinsey calcula que un solo flujo de agente requiere entre 5 y 30 veces más recursos de cómputo que una consulta típica de chatbot. En su encuesta, el 93% de los participantes se pasó del presupuesto de IA por este motivo. El ahorro en horas-persona puede evaporarse en la factura de infraestructura.
Pon verificación automática entre agentes. Cuando el volumen de cambios pasa de 4-5 por semana a 30, la revisión humana sola no alcanza. Necesitas agentes que revisen el código de otros agentes, con reglas claras de seguridad y pruebas con datos y tráfico realistas.

El contexto de mercado que confirma la tendencia

El dinero está apostando fuerte a esta categoría. Según McKinsey, en cifras recogidas por CIO.com, la inversión en proveedores de soluciones de desarrollo de software con agentes pasó de un nivel insignificante en 2023 a unos US$5.000 millones en 2025, y en el primer semestre de 2026 superó los US$61.000 millones, impulsada principalmente por la adquisición de Cursor por parte de SpaceX por US$60.000 millones en acciones. Las ofertas de empleo relacionadas crecieron un 221% entre 2024 y 2025.

Los grandes también se mueven. Meta presentó Muse Code, su primer agente de programación, desarrollado por Meta Superintelligence Labs y potenciado por el modelo Muse Spark 1.2, según reportó IBTimes. Meta lo posiciona como una alternativa más económica, con un modelo de pago por uso y un tier para contribuidores que, según la compañía, cuesta "más de 10 veces menos".

Conclusión

La ley de Brooks no envejeció: cambió de forma. En 1975 el enemigo era la coordinación entre personas; en 2026 es la coordinación entre agentes y la verificación de su output. Los datos de McKinsey, Qodo y Veracode apuntan al mismo lugar: la IA multiplica la producción de código, pero el valor se decide en la orquestación, la seguridad y la definición de qué significa "terminado".

Para un founder, la conclusión práctica es incómoda pero liberadora: no necesitas más agentes, necesitas mejores límites. El que define el problema con precisión y monta la verificación correcta captura el 55% de ganancia de productividad del top 20%. El que solo suma herramientas se queda con el 3% — o con la caída del 30%.