La ley de Brooks dice que añadir personas a un proyecto retrasado lo retrasa más. Su mutación en la era de la IA es más afilada: añadir agentes a un proyecto con requisitos poco claros no solo lo hace más lento, sino que hace llegar antes a la respuesta equivocada. Eso es el dolor. Tienes un proyecto con requisitos que nunca se fijaron, y alguien decide resolverlo lanzando varios agentes. Cada agente produce a velocidad de máquina, así que no esperas más tiempo por una respuesta correcta: esperas menos tiempo por una respuesta segura, coherente y completamente equivocada.

En el desarrollo clásico, la confusión es un cuello de botella. Un equipo humano solo puede avanzar a cierta velocidad, y sus malentendidos tardan en salir a la superficie. Con los agentes de IA, el cuello de botella desaparece, pero la confusión se queda. Cada agente completa su parte en minutos, y como los requisitos eran poco claros, cada parte incorpora la misma ambigüedad de una manera distinta. La integración de esas partes multiplica los errores en lugar de corregirlos.

En el día a día, esto se ve como un esprint a ninguna parte. Le pides a un agente que genere una funcionalidad, y te devuelve un código que parece plausible. Le pides a otro que lo revise, y lo aprueba porque comparte el mismo modelo mental equivocado. Añades un tercero para que escriba pruebas, y las pruebas pasan contra el comportamiento incorrecto. Todo el ciclo se siente productivo hasta que alguien lee los requisitos, o lo que queda de ellos.

La raíz del problema no son los agentes. Es que nadie obliga a que la salida se compare con algo estable. Cuando los requisitos son borrosos, los agentes rellenan los huecos con suposiciones. Más agentes significa más suposiciones, y cada suposición parece una decisión para el siguiente agente.

El patrón que rompe este ciclo es hacer que la IA se revise a sí misma. En la práctica, consiste en introducir en el flujo un momento donde la salida del agente se vuelve contra sí misma: que declare los requisitos que infirió, que enumere las suposiciones que asumió, y que compruebe si su respuesta realmente los satisface. Una segunda pasada, un prompt distinto o una autoevaluación deliberada detecta el hueco antes de que viaje más lejos.

La verificación tiene que ser concreta. Preguntar «¿estás seguro?» no basta. El agente necesita comparar su respuesta con la petición original, exponer contradicciones y señalar los detalles que faltan. Cuando los requisitos son poco claros, la verificación más importante es la primera: «¿Qué supusiste exactamente sobre lo que te pedí?» Esa pregunta obliga al agente a poner sobre la mesa los requisitos que estaban ocultos.

Una vez aplicas ese patrón, la mutación de la ley pierde los dientes. Sigues pudiendo añadir agentes, pero no quedan libres para producir salida sin revisión. Cada agente tiene un punto de control obligatorio donde se examina su propio razonamiento. Eso cambia la dinámica: en lugar de acelerar hacia la respuesta equivocada, los agentes empiezan a converger hacia un entendimiento común corregido.

El efecto práctico es que el proyecto se vuelve más lento en los primeros minutos y más rápido después. El paso más lento es aquel en que el agente se detiene y revisa su propio trabajo. Ese paso es exactamente el que evita que la cascada de malentendidos plausibles se convierta en la entrega final.

Sentirás la tentación de saltarte la revisión porque parece tiempo perdido. El agente ya te dio una respuesta, y suena convincente. Pero si los requisitos no están claros, cada respuesta es una suposición con marca de tiempo. La revisión no es un trámite; es la única manera de convertir a los agentes en detectores de confusión en lugar de multiplicadores de ella.

El patrón es bastante simple para usarlo hoy: haz que la IA se revise a sí misma. No confíes en la primera salida, no añadas más agentes esperando que uno tenga suerte; haz que la autoverificación sea un paso obligatorio en el bucle de cada agente. Ese es el camino a través del dolor. No define mágicamente los requisitos que faltan; los expone, y te da la oportunidad de corregirlos antes de que la respuesta equivocada se convierta en el entregable.