Cohere presenta cómo abaratar un equipo de agentes de programación

Un banco de pruebas controlado

Cohere, según cuenta en su blog, montó un banco de pruebas controlado y puso a trabajar en él equipos de agentes de programación. Quería responder a una pregunta: si un equipo de agentes es una nueva forma de gastar cómputo, ¿cómo hay que organizarlo para que sea a la vez eficaz y eficiente?

El punto de partida, según Cohere, es que en tareas de programación difíciles los equipos bien organizados superan a un único agente, con mejoras de hasta unos 10 puntos porcentuales, pero a un coste entre 3 y 7 veces mayor. Por eso, añade la empresa, la cuestión no es si más agentes ayudan, sino cómo hacer que ese cómputo extra cuente.

Reconstruir programas desde cero

Cohere afirma que ProgramBench es un buen banco de pruebas para ver qué fases ganan con agentes extra, porque cada tarea exige las tres: averiguar qué hace el programa, escribirlo y comprobarlo frente al original.

Los agentes usan tres modelos de la familia GPT-5.6 —Luna, Terra y Sol—, de menor a mayor capacidad y coste. Salvo que se indique otra cosa, según Cohere, cada configuración se ejecutó tres veces sobre las 200 tareas de ProgramBench, y las cifras son medias de esas tres ejecuciones.

Las fases en que el jefe usa trabajadores

Para averiguar dónde compensan los trabajadores, Cohere afirma que pidió al jefe que delegara una única fase y se encargara él de las otras dos. Si delegaba la planificación, los trabajadores ejecutaban el programa para conocer su comportamiento y redactaban un plan; el jefe implementaba y verificaba.

La planificación ganó con claridad, según Cohere. Entre los equipos cuyo jefe sigue trabajando mientras espera a sus trabajadores, delegar únicamente esa fase dio la misma recompensa que delegarlas todas, a la mitad de coste. Si la eficiencia se mide como la recompensa ganada sobre el agente individual de referencia por cada 100 dólares de coste añadido, la planificación fue unas dos veces más eficiente que la segunda mejor fase.

Cohere sostiene que la razón está en el diseño de la prueba: el programa original es una caja negra y su comportamiento hay que descubrirlo ejecutándolo. Los trabajadores de planificación lo exploran en paralelo, cada uno una parte distinta, y después el jefe escribe el código con una idea mucho más completa de lo que tiene que construir.

El reparto de papeles entre modelos

Cohere mantuvo a Sol como jefe y sustituyó sus trabajadores de planificación por Luna, un modelo mucho más barato. El equipo resultante cedió unos pocos puntos frente al formado íntegramente por Sol, pero, según la empresa, medido frente al agente individual conservó el 47,5 % de la mejora de ese equipo con solo el 13,9 % de su coste extra, de modo que cada dólar adicional rindió más del triple de mejora en la recompensa que con trabajadores Sol.

El jefe sí importa, sostiene Cohere. Con los trabajadores fijos en Luna, la recompensa subió cada vez que mejoraba el jefe, de Luna a Terra y de Terra a Sol, y un jefe Terra con ayudantes Luna no llegó a lo que consigue un agente Sol trabajando sin equipo.

Aumentar el número de trabajadores

Cohere también probó a fijar el tamaño del equipo: un jefe Sol con dos, cuatro, ocho o dieciséis trabajadores Luna. Los equipos de planificación, según la empresa, mejoraron al crecer, y el de dieciséis se quedó a menos de dos puntos de los equipos formados solo por Sol con un coste mucho menor.

Con la implementación y la verificación no pasó lo mismo: mejoraron de dos a cuatro trabajadores y luego empeoraron un poco. La explicación, según Cohere, es que cada planificador ejecutaba el programa de referencia unas siete veces fuera cual fuera el tamaño del equipo, así que más planificadores enseñaban al jefe más comportamiento del programa. Los implementadores extra, en cambio, recibían trozos cada vez más finos del plan, y el jefe no comprobaba el programa combinado más a menudo.

Una práctica para tu trabajo

Lo que sigue es una propuesta de práctica, no un experimento realizado: imitar a pequeña escala el método que Cohere afirma haber seguido, que consiste en cambiar una única decisión de diseño cada vez y comparar cada equipo con un agente individual de referencia, tarea por tarea.

Primero, fija una tarea concreta, sus entradas y un criterio de éxito comprobable, y mide la base con un único agente: calidad, coste total y tiempo. Después cambia únicamente el modelo de una fase —por ejemplo, la exploración y la planificación— y vuelve a medir lo mismo, contando también el trabajo que haya que rehacer. Decide por la mejora conseguida por cada euro añadido, que es el criterio de eficiencia que presenta Cohere, y no por el gasto total.

Y no des por hecho que lo que más rinde es planificar: en ProgramBench, según Cohere, la planificación compensó porque la especificación hay que descubrirla, pero en otras tareas el cuello de botella puede estar en otro sitio. En otra de sus pruebas, lo que más ayudó fue delegar la implementación.