Harness Engineering: el concepto que faltaba nombrar
Llevamos dos años discutiendo qué modelo es mejor y muy poco tiempo discutiendo lo que de verdad define el resultado: el arnés que lo rodea.
Le pusieron nombre y me parece bien: harness engineering. Diseñar el sistema dentro del cual un modelo opera. Herramientas, permisos, bucles, presupuesto, verificación, observabilidad. Todo lo que no es el modelo.
Por qué el arnés importa más que el modelo
Comparación honesta: el mejor modelo disponible sin herramientas, sin acceso al repo y sin poder ejecutar nada, contra un modelo del año pasado con herramientas, tests que puede correr y un AGENTS.md decente. El segundo entrega trabajo utilizable; el primero entrega opiniones bien redactadas.
Los modelos convergen y se abaratan cada seis meses. El arnés es tuyo, es específico de tu sistema y es donde queda tu ventaja. Es también la parte que ningún proveedor te puede vender empaquetada, porque depende de tu repo, tus datos y tu tolerancia al riesgo.
Las piezas del arnés
Herramientas. Qué puede hacer, con qué granularidad. Una herramienta ejecutar_sql es cómoda y aterradora; consultar_ordenes_por_cliente es aburrida y auditable. El diseño de la superficie de herramientas es diseño de API, con las mismas reglas de siempre y un usuario más creativo que el habitual.
Permisos y blast radius. Qué puede tocar y qué pasa si se equivoca. Rama en vez de main, entorno efímero en vez de staging compartido, credenciales de solo lectura por defecto. La pregunta de diseño no es “¿se va a equivocar?” —se va a equivocar—, es “¿cuánto cuesta cuando lo haga?”.
Bucle y criterio de término. Actuar, observar, corregir, parar. Sin un criterio de término explícito y verificable, un agente itera hasta que se acaba el presupuesto y entrega algo que “parece terminado”.
Presupuesto. Tokens, tiempo, dinero, reintentos. Un límite duro convierte un problema económico en un error manejable.
Evaluación. Un set de tareas representativas de tu sistema con resultado verificable. Sin esto, cambiar de modelo o de prompt es superstición con changelog.
Observabilidad. Trazas de qué herramienta se llamó, con qué argumentos, qué devolvió. Cuando algo salga mal —y va a salir mal— eso es lo que vas a leer, no la conversación.
Las métricas que sí sirven
Dejamos de medir “calidad de la respuesta”, que no significa nada, y medimos:
- Costo por tarea completada, no por token.
- Tasa de éxito al primer intento sobre el set de evaluación.
- Intervenciones humanas por tarea: cuántas veces alguien tuvo que rescatar el proceso.
- Blast radius promedio: cuántos archivos, servicios o registros toca un cambio típico.
- Tiempo hasta detectar el error, que es el que realmente determina cuánto duele.
Ninguna de estas es sobre el modelo. Todas son sobre el arnés.
Es infraestructura, no prompt engineering
El prompt engineering fue una etapa: la creencia de que la palabra mágica correcta desbloqueaba el resultado. El harness engineering es lo contrario: asumir que el modelo es un componente no determinista, mediocre en promedio, y construir un sistema que igual produzca resultados confiables. Que es, palabra por palabra, lo que hacemos con las redes, los discos y los humanos desde hace décadas.
La disciplina no es nueva. Solo cambió el componente al que hay que ponerle el arnés.