Orquestar agentes de IA que programan: lo caro es leer, no escribir

Uso agentes de IA para escribir software de producción a diario. Al principio repartía el trabajo como lo haría en un equipo de personas: el modelo más capaz para lo difícil y uno barato para lo mecánico. Funcionaba, pero la factura no cuadraba con lo que yo creía que estaba pasando. Así que dejé de suponer y medí.

Lo que dicen 210.717 peticiones

Analicé 1.757 transcripciones de sesiones de agentes de código: 210.717 peticiones a la API y casi 60.000 millones de tokens. Primero hubo que deduplicar por identificador de mensaje, porque cada respuesta aparece entre 2 y 4 veces en el registro de streaming y, sin ese paso, todo sale el doble.

• La salida del modelo, lo que de verdad escribe, es el 0,23 % del total.
• El 96,7 % de la entrada es contexto que se reenvía en cada petición: de media, 272.725 tokens releídos para añadir 30 nuevos.
• Del contenido distinto que entra, el 85,5 % lo generan las herramientas. Solo la shell aporta el 75,8 % de los resultados.

Traducido: lo caro de un agente no es escribir código, es investigar para poder escribirlo. Cada grep, cada fichero abierto para entender un repo, se queda en el contexto y se vuelve a pagar en cada paso siguiente. En mis sesiones, cada resultado de herramienta se releía unas 158 veces antes de que la sesión terminara.

3 capas en vez de 2

Con ese dato, el reparto obvio estaba mal. No basta con poner a un modelo barato a escribir: si el modelo caro sigue explorando el repo para preparar el encargo, el gasto grande sigue donde estaba. El diseño que uso ahora tiene 3 capas:

• Dictado. El modelo más capaz entiende qué se quiere de verdad y escribe un único encargo, corto. No abre ficheros para prepararlo.
• Orquestación. Un agente intermedio, con un modelo barato y de contexto largo, localiza el repo, averigua qué rama está viva, corta el trabajo en piezas y escribe el prompt de cada worker.
• Ejecución. Una flota de agentes de código con modelos abiertos escribe el código y sus tests, en paralelo.

La regla que lo sostiene cabe en una línea: el encargo de arriba tiene que ser más corto que el prompt de un solo worker. Si no lo es, el modelo caro está haciendo el trabajo del orquestador y no hay ahorro. El modelo capaz vuelve a entrar al final, para revisar cada entrega a fondo, integrar y desplegar. Ahí sí compensa: revisar un diff es leer poco y decidir mucho.

El código de salida no es un veredicto

Lo que más tiempo me hizo perder no fue la calidad del código generado, fue creerme lo que decían los procesos. El orquestador terminaba con código 0 en al menos 4 situaciones en las que no había hecho nada: un 403 del proveedor devuelto como si fuera la respuesta, un 429 con 0 ficheros escritos, una respuesta truncada por el límite de salida y un timeout. Y el log de errores, vacío.

La salida fue cambiar la pregunta. Cada encargo produce un artefacto, un fichero concreto, y el lanzador lo borra antes de empezar. Al terminar solo cuenta una comprobación: el artefacto existe y no está vacío. El estado del proceso pasa a ser un dato de diagnóstico, no la respuesta.

El mismo principio vale para los despliegues. Tuve webs cuyo deploy terminaba con 0 mientras el CDN respondía 522 durante meses. Ahora el script de despliegue acaba pidiendo la URL pública y buscando un marcador en el HTML. Si no aparece, el despliegue ha fallado, diga lo que diga la subida.

Fallos que no son fallos

El proveedor de inferencia admite 5 peticiones en paralelo por cuenta, así que un 429 con la flota trabajando es lo normal. Tratarlo como avería llevaba a malas decisiones: bajar la flota, cambiar de modelo, quemar reintentos. Ahora un 429 es una cola: se espera y se reintenta sin gastar intentos. Lo que sí se corta rápido es lo que no se arregla esperando, como un 401 o un prompt vacío.

Donde sí se nota es en la latencia: con 5 encargos simultáneos, uno pequeño pasó de 274 a 887 segundos. El timeout se dimensiona para la contención, no para el caso ideal.

El truncado se resuelve troceando. Un script con su test en un solo encargo se cortó 2 veces seguidas; partido en 2 encargos, los dos salieron a la primera.

Lo que no delego

La verificación. Todo encargo de código va con TDD estricto: primero un test que falla y después lo mínimo para ponerlo en verde. Lo que llega sin ese test se devuelve. Con agentes esto deja de ser una preferencia de estilo y pasa a ser la forma más barata de saber si lo entregado hace lo que dice.

Y el texto que va a leer una persona. Probé a delegar la redacción de artículos en workers con buenos prompts y acabé tirando el trabajo entero: hora y media de flota sin una línea aprovechable. Revisar prosa mediocre cuesta más que escribirla.

Lo que me llevo

• Medir antes de repartir. Mi intuición decía que lo caro era generar código; los datos decían lo contrario.
• El modelo caro decide y revisa. No explora.
• Ningún agente se da por terminado por su código de salida: se mira el artefacto.
• Los límites del proveedor son parte del diseño, no incidencias.

Si estás montando algo parecido en tu equipo, o buscas a alguien que ya se ha peleado con esto en producción, escríbeme a [email protected].