Optimicé la parte del pipeline que no había que optimizar

El 11 de junio me senté a hacer una revisión completa del orquestador con dos objetivos concretos: mejorar la calidad del código que generaban los agentes y acelerar la cadena de trabajo.

Hice algo que recomiendo: antes de escribir el plan, definí cómo iba a medir si había servido. La métrica de éxito quedó escrita al principio del documento — duración por paso y proporción de tareas resueltas contra abandonadas.

Lo que no hice fue mirar los datos antes de escribir el diagnóstico. Escribí el diagnóstico leyendo el código, que es lo que uno hace naturalmente, y salió un plan de cinco puntos apuntando todos al mismo lugar.

El sospechoso obvio

Ese lugar era el ciclo de reintentos.

El razonamiento era sólido. Cuando un trabajo no pasa el control de calidad y hay que reintentarlo, se paga todo de nuevo: otro agente levantado, otra exploración del código, otra implementación, otro control. Es, con diferencia, la operación más cara del sistema. Y encima estaba mal implementada: descartaba la sesión anterior, así que el segundo intento arrancaba sin memoria del primero.

Todo eso era cierto. Los cinco puntos del diagnóstico estaban bien identificados. El plan arrancaba por hacer el reintento más inteligente y seguía con optimizaciones menores.

Después fui a la base de datos a buscar el número de base contra el cual iba a medir la mejora.

Lo que decían los datos

Encontré tres cosas que no encajaban con nada de lo que había escrito:

• Un solo item, en toda la historia del sistema, había llegado a generar retroalimentación de reintento.
• Cero abandonos. La rendición, que estaba cuidadosamente diseñada con su reporte estructurado de incidentes, nunca se había disparado.
• La tasa de aprobación en el primer intento era prácticamente del 100%.

El ciclo de reintentos que estaba por optimizar casi no corría. Había escrito un plan de mejoras para el camino menos transitado del sistema.

La explicación, cuando la busqué, tenía sentido: los errores no se estaban corrigiendo entre pasos del orquestador. Se corregían dentro del loop interno de cada agente, antes de que el trabajo llegara al control de calidad. El agente iteraba sobre su propio trabajo, se daba cuenta de sus errores y los arreglaba antes de entregar. Para el orquestador, eso es invisible: solo ve un paso que terminó bien.

Es decir, mi intuición no solo estaba equivocada sobre el tamaño del problema. Estaba mirando una capa del sistema donde el problema, sencillamente, no ocurría.

El número que reordenó el plan

En la misma consulta apareció el dato que cambió todo. El control de calidad —el paso que verifica cada tarea antes de cerrarla— corría unas 157 veces por semana, con un promedio de 5 a 8 minutos cada vez.

Ese era el costo dominante. No los reintentos, que casi no pasaban: la verificación, que pasaba siempre.

Y el dato aguantó el paso del tiempo. Hoy, mirando el acumulado, el control de calidad se llevó 3.463 dólares de los 11.968 que gastó el sistema en total. Un 29% de la factura concentrado en un solo paso.

El plan se reescribió esa misma tarde. Primero, paralelizar el control y cachear la suite de tests. El trabajo sobre los reintentos quedó relegado a mejora barata de robustez, para cuando el caso peor efectivamente ocurra.

Por qué la intuición apuntaba al lado equivocado

Estuve pensando bastante en por qué me había equivocado tan claramente, porque el error no fue de análisis: fue de percepción.

El reintento duele. Se ve en la pantalla, aparece como un ciclo que se repite, se siente como desperdicio mientras ocurre. Es visible, ruidoso y frustrante.

El control de calidad no dolía porque era rutina. Corría siempre, formaba parte del funcionamiento normal, y por eso mismo era invisible. Nadie mira dos veces un paso que hace lo que tiene que hacer.

Ahí está la trampa: en un sistema con agentes, lo caro casi nunca es lo que molesta. Lo que molesta son las excepciones, porque interrumpen. Lo caro es la rutina, porque se multiplica. Y sin telemetría por paso, terminás optimizando lo que te irrita en vez de lo que te cuesta.

Un detalle sobre cómo dejé escrito el error

Cuando reescribí el plan, no borré el diagnóstico original. Le agregué arriba una nota fechada con la recalibración: qué había creído, qué mostraron los datos y cómo cambiaba la prioridad.

Podría haber reescrito el documento y dejarlo prolijo, con el diagnóstico correcto desde el principio. No lo hice por una razón práctica: el diagnóstico equivocado sigue teniendo valor. Explica por qué el sistema está construido como está, y me recuerda que el razonamiento que lo produjo era razonable — leyendo el código, cualquiera habría llegado a la misma conclusión.

Un plan que oculta sus propios errores de diagnóstico se vuelve un documento de marketing interno. Uno que los deja a la vista, con la fecha, es un registro de cómo se aprendió algo.

Lo que vino después

Con el plan reordenado, la primera tarea era concreta y sonaba trivial: dejar de correr la suite completa de tests cuando el código no había cambiado.

Suena a optimización de manual. Tiene una trampa que casi me hace certificar como aprobado un código que nunca se probó, y de eso trata la próxima entrega.