Por qué los equipos multiagente grandes se estancan
Cuando los agentes LLM comenzaron a usarse masivamente en el desarrollo, muchos equipos siguieron un camino lógico, pero no siempre funcional: reunir a la mayor cantidad posible de «especialistas» algorítmicos y asignarles roles. Uno escribe código, otro busca vulnerabilidades, un tercero verifica escenarios. El problema es que cada agente nuevo aporta cada vez menos valor: en tareas a nivel de repositorio completo, los costos de coordinación rápidamente superan la ganancia de tener «manos adicionales».
La reacción a esto fue un movimiento en la dirección opuesta: los agentes se convirtieron en subagentes — herramientas obedientes que se invocan bajo demanda y no entablan diálogo. Este enfoque elimina el caos, pero también destruye el principal recurso del trabajo colectivo: ya nadie cuestiona las decisiones ajenas y, por lo tanto, los errores pasan desapercibidos.
El punto de equilibrio: cooperación mínima
Eric S. Qiu y Joyce Gill abordaron la búsqueda del punto medio en su trabajo «Adversarial Review: Structured Disagreement for Grounded Agentic Code Review» (arXiv:2608.18167, categorías cs.AI y cs.SE; presentado el 16 de agosto de 2026, aceptado en el ICML 2026 Workshop on DL4C). Su hipótesis es simple: se puede conservar la simplicidad de la arquitectura de subagentes, pero añadiéndole una cooperación mínima — un único nodo donde las opiniones de los agentes chocan deliberadamente.
El resultado es el protocolo Adversarial Review (AR). Los autores evitan deliberadamente construir una jerarquía compleja o multiplicar los roles. En su lugar, trabajan tres participantes:
- el agente codificador prepara los cambios en el código;
- el revisor evalúa si esos cambios son correctos;
- el crítico audita no el código, sino la propia revisión, y encuentra sus puntos débiles.
El crítico no se limita a decir «no estoy de acuerdo» — plantea un desacuerdo estructurado: señala fragmentos concretos del código que no respaldan las conclusiones del revisor. Y solo cuando este ciclo se completa, el agente principal recibe permiso para realizar las correcciones.
Qué mostraron las pruebas
El efecto del desacuerdo se ve claramente en los resultados de los benchmarks.
En LiveCodeBench, AR mostró el mayor porcentaje de ejecuciones exitosas entre todos los métodos probados. Un detalle importante: para lograrlo bastaron tres agentes, mientras que la variante base que AR superó usaba cinco.
En SWE-PRBench, todo resultó más interesante. La versión ingenua del protocolo reveló inesperadamente un modo de fallo que los autores denominaron falso consenso: los agentes convergían hacia una opinión común sin tener pruebas suficientes para ello. Es decir, incluso un desacuerdo diseñado explícitamente puede degenerar en un formal «de acuerdo con todos». Esto se soluciona con una iteración del prompt, donde el requisito de discutir y justificar el desacuerdo se especifica explícitamente — tras ese ajuste, el método ocupó el primer lugar en F1.
Finalmente, en SWE-bench Verified, AR volvió a mejorar los resultados de los enfoques base. Esto es importante porque las tareas a nivel de repositorio son una escala de complejidad completamente distinta a la de funciones aisladas: los cambios en un módulo pueden romper decenas de módulos vecinos.
Conclusión: la fuerza no proviene del número de votos, sino del derecho a objetar
Los autores llegan a una conclusión contraintuitiva, pero respaldada por los experimentos: una revisión de código eficaz no requiere ni un equipo grande ni esquemas de comunicación complejos. Basta con que el desacuerdo sea:
- mínimo — un único punto de conflicto, no un chat interminable;
- estructurado — cada participante tiene una función clara y definida;
- basado en evidencia — la objeción se apoya en hechos del código, no en preferencias subjetivas.
La lección práctica para quienes construyen pipelines de agentes: no intenten resolver el problema añadiendo roles. Es mejor integrar en el proceso una etapa obligatoria de duda — y permitir que un agente cuestione formalmente las conclusiones de otro. El valor de la revisión no se determina por la cantidad de votos, sino por la presencia de alguien capaz de objetar con fundamento.
