Una puerta que no cuenta el dinero no es una puerta
Mi pipeline sabía decirte si el trabajo estaba bien. No sabía decirte que esa respuesta había costado cuatro horas y ocho intentos fallidos.
Tenía en el pipeline unas puertas de las que estaba orgulloso. Criterios, umbrales, un revisor que no era el autor, un veredicto capaz de decir que no.
Luego les hice una pregunta que no supieron responder: ¿esto cuánto ha costado?
Que el artefacto estaba a la altura, eso lo sabían. Si llegar hasta ahí había llevado cuarenta minutos o cuatro horas, doce dólares o doscientos, ni idea. Una aprobación limpia al primer intento y una ejecución que cruza la meta a rastras en el décimo asalto contra el mismo problema sin resolver les parecían la misma cosa.
Y no lo son. Solo una de las dos es un sistema que funciona.
El límite que acota lo que no toca
Tenía límites de iteración: diez vueltas por fase como mucho. Aquello parecía control. No lo es. Un límite de iteraciones acota cuántas veces gira el bucle, no lo que cuesta cada vuelta, y en mi pipeline una ronda de revisión se abre en abanico sobre ocho verificadores que corren en paralelo. Ese paso, él solo, puede costar más que todas las fases anteriores juntas, y ahí no hay límite que se entere.
Así que escribí un libro de cuentas. Presupuesto declarado antes de empezar. Se comprueba al pasar de una fase a otra y en cada vuelta atrás, nunca a media faena. Si cruzas una arista estando ya por encima del techo, la ejecución se para con un veredicto explícito, en vez de llegar al final calladita y pasarte la factura.
Lo que subestimé fue el análisis de ruta. Contabiliza el gasto que no movió la ejecución hacia delante — todo lo que se comieron los intentos terminados en una vuelta atrás — y marca los motivos que se repiten. Ese último número escuece. Una ejecución que aprueba al décimo reintento idéntico es una ejecución fallida con una medalla prestada, y mis informes de antes no lo enseñaban por ninguna parte.
Por qué esto vale más de lo que parece
Hay un estudio de marzo que me obligó a repensar qué le añado a un agente y por qué.
A un agente de programación le dieron una sola cosa de más: un mapa de qué pruebas cubren qué código, entregado como fichero de texto plano, para leerlo y ya está. Las regresiones — pruebas que antes pasaban y dejaron de pasar — bajaron del 6,08% al 1,82%. Un 70% menos con un fichero.
El mismo estudio tenía una segunda rama. En lugar del mapa, instrucciones de procedimiento: trabaja con las pruebas por delante, cíñete a esta disciplina. Las regresiones subieron al 9,94%. Peor que no tocar nada.
Dale contexto al agente, no procedimiento. Decirle cómo comportarse empeoró las cosas, y se puede medir. Decirle qué es cierto las mejoró un 70%. Cada instrucción que me apetece escribir pasa ahora por ese filtro antes que por ningún otro.
Por eso mismo el presupuesto vive en el fichero de estado y no en un prompt que le pide al agente que tenga cuidado con el dinero. Nadie cuida un número que no ve.
Si tienes agentes corriendo y no sabes decir cuánto te costó la semana pasada, no gobiernas un sistema autónomo: acumulas factura. Yo construyo la pieza que sabe decir que no. Escríbeme qué sistema tienes y qué fecha límite manejas.