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.

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.

Fui a buscar el número.

En las clasificaciones públicas aparece de vez en cuando el mismo modelo corriendo bajo dos harnesses distintos. La distancia entre uno y otro va de tres a ocho puntos porcentuales. Ahora deja el harness quieto y cambia el modelo de debajo. La puntuación se mueve veinticinco.

Si te quedas ahí, la conclusión se escribe sola: el harness casi da igual, compra un modelo mejor y vete a casa.

Solo que no es eso lo que nos quita el sueño

Esos benchmarks miden una tarea, dentro de un contenedor, que pasa o no pasa. Nadie en producción duerme mal por una tarea dentro de un contenedor.

Se duerme mal por otras cosas. Un sistema que se viene abajo cada pocos días. Un resultado que el martes que viene ya no sale igual. Un veredicto que después no hay quien audite. Una ejecución que informa de éxito y resulta que el fichero que dice haber tocado se lo ha inventado.

Pues para eso — estabilidad, reproducibilidad, auditabilidad — no existe ningún benchmark público. El intento más cercano que he encontrado tiene tres semanas, y su propia auditoría preregistrada terminó sin conclusión.

Donde sí hay cifras, no son pequeñas. Un estudio recortó las regresiones un 70% dándole al agente un único fichero de contexto. Otro midió un 9,5% menos de tareas fallidas al meter un crítico que revisa el plan antes de ejecutarlo. Los dos son cambios de harness. Ninguno de los dos sale en una clasificación.

De momento, entonces, el trabajo es tuyo. Mide lo que de verdad te importa — cada cuánto se cae el sistema, cuánto trabajo vuelve para rehacerse, cuántas veces un veredicto aguanta la revisión — porque nadie lo va a publicar por ti.

Mi propia web estuvo tres semanas sirviendo una versión dos commits por detrás. Y yo, tan tranquilo.

Lo que pasó, por orden. El 6 de agosto subí dos cambios a una subpágina. Arrancaron tres despliegues. Los tres fallaron. Cada uno anotó una duración de build de cero milisegundos y el mensaje «Page build failed.». Ni un detalle, ni un aviso, nada en el correo.

Cero milisegundos quiere decir que el build ni llegó a empezar, así que mi código no tenía nada que ver. Se había caído algo más arriba.

¿Y la web? La web, estupenda. HTTP 200, certificado en regla, todo cargando. Seguía sirviéndose el último build correcto, igual que el día anterior. El fallo no tenía superficie visible por ningún lado. Desde fuera, desde mi navegador, desde el de cualquiera: una web sana.

Lo descubrí porque andaba enredando con otra cosa y miré el estado de los despliegues por curiosidad.

El paralelismo que incomoda

Es el mismo modo de fallo contra el que levanto puertas todos los días. Solo que llegó por un flanco que yo no había defendido.

El agente informa de éxito. Las pruebas pasan. El diff se ve limpio. Todo lo que asoma en la superficie dice que el trabajo está hecho, y la única forma de saber lo contrario es comprobar algo que quien informa no controla: abrir la aplicación de verdad, consultar el estado de verdad, contrastar con algo que el optimizador no alcance.

Ese reflejo lo tenía con los agentes. Con mi propio pipeline de despliegue, no. Y ahí estaba, veintiún días sirviendo contenido rancio sin decir ni mu.

El arreglo, por cierto, consistió en quitar, no en añadir. La web es HTML plano y aun así cada despliegue la pasaba por un motor de plantillas que nunca hizo falta: 165 segundos para publicar medio megabyte. Un fichero vacío después, el despliegue es una copia de ficheros y tarda 19 segundos. Nueve décimas partes del tiempo se iban en un paso cuya única aportación real era poder fallar.