El blog de desarrolladores de Google publicó el 2 de septiembre un artículo sobre ingeniería de harness, firmado por Shir Meir Lador. El texto define harness de forma muy directa: todo el conjunto de componentes deterministas que envuelven al modelo de lenguaje —la capa de orquestación, el sandbox de ejecución, la persistencia de estado y las herramientas de validación entran todos en esa definición.
El artículo abre con una cifra llamativa: en un producto experimental interno de OpenAI, la cantidad de código escrito a mano fue cero líneas; tres ingenieros construyeron y lanzaron una versión beta interna usando solo código generado por el modelo. La autora usa el ejemplo para plantear que el problema no está en la capacidad del modelo, sino en la estructura que lo mantiene dentro de un proceso controlable.
Riendas, anteojeras y pista de carreras
El artículo recurre a una metáfora hípica: el modelo es el caballo, el harness es la pista, las anteojeras y las riendas, encargados de que corra en una sola dirección.
"The harness is composed of all the deterministic components that wrap the LLM."
El harness está compuesto por todos los componentes deterministas que envuelven al modelo de lenguaje.
Esta definición traslada una parte del trabajo que antes se clasificaba como "prompt engineering". Para restringir el comportamiento del modelo solo hay dos caminos: escribirlo en el prompt o escribirlo en el código externo. El primero depende de que el modelo lo respete por sí mismo —cambiar de modelo obliga a reajustar todo—; el segundo es una restricción dura, que sigue funcionando aunque cambie la generación del modelo. En el último año, la mayoría de los equipos que construyeron productos con agentes probaron ambos caminos, y pagaron el precio de los dos. Esa línea del prompt que dice "no modifiques los archivos de prueba": hacia la trigésima ronda de un contexto largo, el modelo empieza a "ignorarla" selectivamente.
Tres principios de diseño
Límites estrictos. Encerrar al agente en un sandbox, sin darle ninguna oportunidad de tocar datos de producción. En la demostración del artículo, el agente solo puede escribir archivos dentro del directorio ./sandbox; las operaciones que se salen de ese límite simplemente no llegan a ejecutarse.
Bucle de reparación. Los errores no deberían pasarse directamente a una persona. Si una prueba falla, el harness devuelve el registro limpio al modelo para que corrija su propio código. Aquí el ADK 2.0 usa un flujo de trabajo basado en grafos: el propio paso de validación es un nodo de enrutamiento dentro del grafo; una ejecución fallida redirige automáticamente el flujo de control de vuelta al nodo de generación, sin necesidad de escribir a mano lógica de reintentos en el código de orquestación.
Estructura de repositorio descubrible por capas. En vez de escribir un archivo de instrucciones de miles de líneas y volcarlo de golpe sobre el agente, organizar el repositorio para que pueda ir profundizando capa por capa, descubriendo el contexto según lo necesite.
El Antigravity SDK que lo acompaña se encarga del lado del entorno local: delimita los márgenes del workspace y, al mismo tiempo, ofrece persistencia de memoria. Juntas, las dos herramientas cubren dos preguntas: "dónde corre el agente" y "cómo vuelve al buen camino cuando se equivoca".
El límite de cinco rondas y ese interruptor
El bucle de autocorrección de la demostración completa un ciclo entero: el agente escribe código dentro de un sandbox restringido, ejecuta las pruebas automáticamente, la prueba falla, el registro se reenvía, el agente corrige y vuelve a ejecutar. El límite se fija en cinco rondas; al llegar a ese tope, el harness corta el proceso, algo que la autora llama kill switch.
Ese cinco es el dato más práctico de todo el artículo. El modo de fallo típico de un bucle de autocorrección es que el modelo salte de un lado a otro entre dos estados de error, quemando tokens en cada ronda sin converger. Fijar un límite duro equivale a admitir de antemano que a veces el modelo no puede resolverlo, y devolver el problema a una persona antes de que sea tarde. Sin ese interruptor, un bucle descontrolado puede agotar todo el presupuesto en una noche sin supervisión.
Comparado con los frameworks de agentes que estuvieron de moda en la primera mitad de este año, el cambio de enfoque es bastante visible. Los frameworks de la primera generación hablaban sobre todo de orquestación: cómo encadenar varios agentes, cómo repartir tareas, cómo pasar mensajes. Ahora se habla de validación y límites: dónde ocurre la ejecución, cómo regresan los errores, cuándo detenerse. Lo primero resuelve si "funciona o no"; lo segundo resuelve si "se puede confiar en dejarlo correr sobre un proyecto real".
Para los equipos que no usan exactamente la pila de Google, el ADK 2.0 y el Antigravity SDK como herramientas concretas quizá no apliquen directamente, pero los tres principios sí se pueden adoptar tal cual. Sandbox, bucle de reparación, contexto descubrible por capas: cualquier agente de codificación construido internamente tiene que lidiar con estos tres puntos, la única diferencia está en diseñarlos desde el principio o parcharlos después de que borre los archivos de prueba una vez.
Fuentes: blog de desarrolladores de Google, CocoLoop, documentación de los proyectos ADK y Antigravity SDK; la definición de harness, los tres principios de diseño y el límite de cinco rondas se cotejaron con el artículo original, y las cifras de cero líneas de código manual y tres ingenieros se citan tal como aparecen en el texto.