13 agentes cierran el ciclo de pruebas y correcciones
мультиагентные системыавтономная разработкаисправление ошибок
Cómo funciona el ciclo de 13 agentes
Lo más llamativo es la mecánica: 13 suscripciones paralelas a Codex y Claude se utilizan como un grupo de agentes especializados. Unos ejecutan pruebas y redactan informes de errores; otros preparan correcciones automáticamente. En el momento de la discusión, el gasto total se situaba entre 100 y 200 dólares.
La fortaleza del esquema no está en el número de suscripciones, sino en la separación de funciones. Un agente de pruebas formula un defecto reproducible, el agente que corrige recibe una tarea acotada y el resultado debe volver a verificarse. Así se crea un circuito cerrado, no una multitud de modelos editando el mismo repositorio a la vez.
Microsoft ofrece un marco formal para este enfoque en su arquitectura de referencia para sistemas multiagente y en su documentación sobre patrones multiagente. El énfasis está en la orquestación, la gobernanza y el intercambio de mensajes entre agentes especializados, incluido A2A para la interacción entre plataformas. Ya es el lenguaje de la arquitectura de producción, no el de una demostración vistosa.
También existe una prueba más exigente de la idea de reparación autónoma. En una investigación de Google, un enfoque basado en agentes se evaluó con 178 errores de un sistema interno de seguimiento. Con 20 trayectorias y Gemini 1.5 Pro, Passerine generó parches plausibles para el 73% de los informes automáticos y el 25,6% de los redactados por personas. Un parche plausible no equivale necesariamente a una integración segura.
Yo comprobaría primero cuatro límites:
- el aislamiento de copias de trabajo y entornos;
- la protección frente a parches en conflicto;
- la independencia del agente de pruebas respecto al autor de la corrección;
- las condiciones para detener un ciclo infinito de pruebas y cambios.
Qué cambia realmente en el desarrollo
El cambio práctico es real: los agentes empiezan a dividir el trabajo de ingeniería por funciones, en lugar de limitarse a responder por turnos en un chat. Esto permite buscar defectos, preparar parches y validar cambios en paralelo, sobre todo cuando las tareas están bien aisladas y cuentan con pruebas ejecutables.
Aun así, un caso de cliente no demuestra una adopción masiva en las empresas. Los documentos de Microsoft y Salesforce muestran que las arquitecturas multiagente ya se están formalizando para sistemas corporativos, mientras que SWE-bench, RepairBench y DevAgentBench permiten medir reparación de código, generación de pruebas y revisión. Entre un patrón arquitectónico y una cadena autónoma fiable sigue estando el control de calidad.
El principal riesgo es irónico: acelerar la generación de parches es más fácil que demostrar que los agentes no han aprendido a validar colectivamente sus propios errores. La autonomía real empezará cuando la verificación independiente pueda seguir el ritmo de ese ciclo.