Harness

El 28 de octubre GitHub anunció la disponibilidad general de Copilot Fusion. En vez de escoger un modelo para cada tarea, eliges Fusion y el sistema decide qué modelos y patrones de ejecución utilizar. La documentación de GitHub describe opciones como resolver con un modelo, escalar una respuesta para que otro la revise o generar una respuesta y pedir a otro modelo que la critique.

El modelo sigue importando, pero cambia la pregunta. Durante estos últimos años hemos comparado nombres y versiones: ¿cuál razona mejor?, ¿cuál escribe mejor código?, ¿cuál tiene más contexto? Ahora aparece otra pregunta, más arquitectónica: ¿qué sistema decide cómo usar modelos, datos y herramientas para completar el trabajo?

En un artículo anterior sobre qué es un harness y dónde vive, expliqué por qué dos herramientas con el mismo modelo pueden comportarse de forma distinta. Aquí quiero dar un paso más: ¿qué cambia cuando el propio sistema empieza a elegir y combinar modelos?

Cuando comparamos herramientas de IA solemos empezar por el modelo. Que si este modelo razona mejor, que si aquel tiene más contexto, que si el nuevo benchmark lo coloca tres puntos por encima del anterior. Es lógico: el nombre del modelo es la parte visible, la que aparece en la documentación, en los selectores y, por supuesto, en el marketing.

Pero hay una pregunta que cada vez me parece más importante: cuando dos herramientas utilizan el mismo modelo y producen resultados muy diferentes, ¿qué estamos comparando realmente?

La respuesta corta es que no estamos usando solo un modelo. Estamos usando un sistema completo alrededor de él: instrucciones, contexto, memoria, herramientas, permisos, formatos de entrada y salida, bucles de validación, reintentos y condiciones de parada. A ese andamiaje se le suele llamar harness.

Y ese harness puede convertir un modelo competente en una herramienta muy útil o en un compañero que lleva veinte minutos leyendo archivos irrelevantes con una seguridad en sí mismo francamente admirable.