Harness engineering: qué es (y por qué ya lo practicas sin saberlo)

Si no montas tu proyecto de software con agentes, skills y prompts, parece que ya no hace falta ingeniería.

DANIEL ALARCÓN
Software Architect

En cualquier proyecto de inteligencia artificial que llega a producción hay una parte del trabajo que no aparece en las demos ni en los titulares: la que sostiene el sistema por dentro cuando deja de ser una prueba de concepto. Esa parte tiene nombre propio, harness engineering, y antes de asumir que es una disciplina que hay que aprender desde cero, conviene entender qué es en realidad, como si la ingeniería de software tradicional se hubiera quedado obsoleta de la noche a la mañana.

Por eso organicé una sesión de Knowledge Sharing, para repasar algunas de las piezas que componen ese harness y defender algo que, contado así, suena menos vistoso: la ingeniería sigue ahí detrás, y no ha cambiado tanto como parece. Lo que ha hecho es evolucionar, para dar cabida a los trade-offs nuevos que trae la IA, mientras el criterio de fondo sigue siendo el mismo que aplicábamos antes, en otros contextos, con otros nombres. El título que le di a la charla, «Learning harness engineering (again?)», ya adelantaba por dónde iba a ir la conclusión.

Harness engineering: qué es en la práctica

El concepto de harness engineering hace referencia a todo lo que rodea al modelo: el sistema que lo hace fiable, auditable y sostenible en producción. Al desmenuzarlo, aparece algo inesperado: buena parte de ese trabajo ya sabíamos hacerlo, porque este mismo efecto —la promesa de que una tecnología elimina la complejidad, seguida de la aparición de roles nuevos para gestionar la complejidad que en realidad seguía ahí— ya se ha dado antes.

Un buen ejemplo es la nube: en 2010 la promesa era que con AWS ya no haría falta saber de infraestructura, y década y media después han aparecido roles que antes no existían —SRE, DevOps, platform engineer, FinOps, DevSecOps, MLOps— porque alguien tenía que ocuparse de la complejidad que el cloud escondía debajo de esa promesa. Con la IA está pasando lo mismo, y el harness engineering es precisamente esa complejidad.

Aquí van algunas de esas piezas clásicas, con las que seguramente ya llevas tiempo trabajando sin ponerles esa etiqueta:

• El modelo como API. Un LLM, reducido a lo esencial, es una API lenta —segundos, no milisegundos—, cara —el coste depende del uso, no de la capacidad reservada— y no determinista, porque la misma pregunta puede devolver dos respuestas distintas. Que conviva todo eso en una sola llamada obliga a recuperar patrones de otras dependencias externas poco fiables: colas, rate limiting, streaming y enrutar a un modelo más barato cuando el caro no hace falta. La alternativa —un frontend directo contra el LLM, sin backend ni límites— es la forma más rápida de llevarte un susto con la factura.
• Gestión de costes. Llevamos años de FinOps en la nube, revisando el gasto antes de desplegar. Lo que cambia con un proyecto de IA es la unidad sobre la que presupuestas —por funcionalidad o agente, no por base de datos o cómputo—, lo que lleva a decisiones como un switch que baje a un modelo más barato si un pico de peticiones amenaza el presupuesto del mes.
• Observabilidad. Sigue la misma lógica de siempre, solo que a las métricas clásicas —latencia, errores, número de peticiones— se suman los tokens de cada llamada y la traza de qué herramienta ha llamado el modelo. Langfuse da justo esa trazabilidad, pensada para un sistema no determinista.
• Seguridad. El prompt injection es la evolución del SQL injection —cuelan instrucciones a través de una entrada mal saneada—, y conviene revisar el OWASP Top 10 para aplicaciones LLM para saber qué vectores cubrir primero. La fuga de datos vía prompt es el mismo problema de scope de siempre: el vector de ataque es distinto, pero el modelo de amenaza detrás es el de toda la vida.
• Testing. Sigue existiendo, solo que ahora un test unitario se llama eval: pares input-output que puntúas para detectar cuándo un cambio en el prompt empeora las respuestas. Sin evals tienes una demo bonita que nadie puede llevar con garantías a producción.

Hasta aquí, la parte del harness que probablemente ya conocías, aunque nunca la hubieras llamado así. La que de verdad toca aprender de cero empieza con algo que suena tan sencillo que ni parece ingeniería.

Chunking, vector store y reranking: el RAG como harness engineering aplicado

Si quieres ver esa parte nueva en su forma más pura, el mejor ejemplo es un RAG: el «hola mundo» de cualquier proyecto de IA empresarial. Metes la documentación de un cliente en una base de datos vectorial y dejas que pregunten sobre ella en lenguaje natural. Suena trivial hasta la primera decisión: cómo divides los documentos antes de indexarlos.

1. Tamaño fijo: cortas el documento en trozos iguales. Simple, pero puede partir un párrafo por la mitad y devolverte solo media respuesta.
2. Partición semántica: un LLM divide el contenido por tema. Más coherente, pero menos predecible —unos chunks acaban siendo un párrafo y otros cinco páginas— y con el coste de pasar cada documento por un modelo antes de indexarlo.
3. Por estructura: divides por párrafos o encabezados reales. Funciona de maravilla con Markdown y bastante peor con tablas o formatos no estructurados.

Ninguna opción es universalmente mejor. Cuanto más pequeño el fragmento, más precisa la recuperación pero menos contexto; cuanto más grande, al revés. Decidir esto para un cliente concreto —conocer sus documentos, qué le van a preguntar— es ingeniería, por mucho que suene a «cortar un texto en trozos».

Después vienen más decisiones del mismo tipo. Qué base de datos vectorial usar depende de si necesitas algo rápido para validar una idea o algo que escale desde el primer día: no es la misma decisión montar una prueba de concepto que un sistema que va a recibir tráfico real desde el minuto uno.

La forma de recuperar la información tampoco es única: puedes buscar por similitud de vectores, que es el enfoque por defecto, o combinarlo con búsqueda por keyword cuando el contenido tiene muchos identificadores o acrónimos que el embedding por sí solo no distingue bien. Y una vez recuperados los candidatos, todavía queda reordenarlos (reranking) para que los más relevantes lleguen primero al modelo. Es, en el fondo, la misma conversación que ya teníamos hace años al elegir entre Postgres, MongoDB o Cassandra, solo que ahora el vector es la variable nueva sobre la mesa.

MCP, agentes y el problema de diseñar herramientas para un modelo

El RAG no es la única pieza nueva del harness: diseñar herramientas (tools) para un agente vía Model Context Protocol es otra, y en esta es en la que tuve que corregir el rumbo más de una vez. Un tool equivale a un endpoint: expones una funcionalidad para que algo la use. La diferencia es que ese «algo» decide si usarla interpretando su descripción en lenguaje natural, algo que antes se resolvía con un simple contrato técnico.

Me pasó con un caso muy concreto. Había implementado un tool de un servidor MCP cuya descripción decía, literalmente, que «renderizaba una imagen»:

tool: render_image
description: "Renderiza una imagen"

En mi caso, el agente llamaba a ese tool, recibía los datos y daba la tarea por completada sin mostrar nada en pantalla. Tardé una tarde entera en dar con el motivo: el modelo entendía que, si el tool «renderiza», alguien más ya se había encargado de mostrarla. La solución fue cambiar la descripción.

tool: render_image
description: "Devuelve una imagen ya renderizada, lista para pintar en el chat"

Con un LLM de por medio, el contrato de una herramienta deja de ser solo técnico y pasa a ser también semántico. Antes, si la descripción de un endpoint no era perfecta, el desarrollador se las apañaba mirando el propio endpoint; con un tool de un agente conviene ser mucho más preciso, porque si el modelo puede interpretar tu descripción de otra manera, es bastante probable que acabe haciéndolo.

Antes de entrar en el diseño de agentes propiamente dicho, conviene tener claro qué es un agente de IA y cómo funciona el bucle que lo mueve. Hecho ese repaso, con los agentes pasa algo parecido a diseñar una máquina de estados: hay que decidir cuántas veces puede reintentar una llamada antes de cortar el bucle, qué modelo mínimo necesita cada agente concreto —no todos infieren igual de bien qué herramienta usar en tareas complejas, por bien escrito que esté el prompt— y cómo vas a auditar después lo que hizo.

Cuando un agente orquesta a otros subagentes, el problema se multiplica en vez de sumarse: cada nivel de la jerarquía puede fallar por su cuenta, y detectar dónde se rompió la cadena exige trazabilidad real sobre lo que intentó cada nivel, más allá de un simple registro de errores. Todo esto se protege con guardrails de entrada y salida, para no dejar pasar datos privados o instrucciones maliciosas ni devolver algo fuera de lugar, sabiendo que cada capa añade coste y latencia.

Las decisiones que te convierten en ingeniero de harness

No existe un título ni una certificación que te convierta en ingeniero de harness: lo eres en el momento en que empiezas a resolver este tipo de disyuntivas con un cliente real, como estas:

• ¿Levanto un modelo propio en una máquina reservada o uso una API externa a cambio de depender de un tercero?
• ¿El problema se resuelve con un buen prompt, necesita un RAG porque el cliente quiere respuestas ancladas a su documentación, o hace falta fine-tuning?
• ¿Ataco la tarea con un modelo grande que lo resuelva todo, o la descompongo en piezas pequeñas con un modelo específico cada una?

Cada una de estas preguntas esconde, además de la técnica, una decisión de negocio. Levantar un modelo propio, por ejemplo, retrasa el lanzamiento pero da control total sobre los datos; apoyarte en una API externa lo acelera a cambio de ceder parte de ese control a un tercero. Esa lectura —qué estás dispuesto a ceder a cambio de qué— es la que separa a quien simplemente conecta una API de quien hace harness engineering.

El vibecoding ha bajado la barrera de entrada para escribir código. Confundir esa accesibilidad con la desaparición de la ingeniería sale caro: el criterio sobre cómo trocear documentos para un RAG, el diseño semántico de un tool o el momento en que un modelo pequeño es suficiente viene de haber pasado antes por el problema, muchas veces a base de errores como el del tool anterior.

La dificultad se ha trasladado de escribir código a tomar estas decisiones, y ahí sigue haciendo falta alguien con criterio para tomarlas. En el fondo es la misma idea que el paralelismo con la nube del principio: la ingeniería no ha cambiado tanto como parece, ha evolucionado para dar cabida a los trade-offs que trae la IA.

En la grabación completa de esta sesión entro en más detalle sobre cómo trazamos en Orbitant el coste y la calidad de un agente con herramientas como Langfuse o Mastra, y respondo en directo a la pregunta que más debate generó en el equipo: si el modelo importa tanto como la descripción de la herramienta a la hora de decidir si un agente la usa o no.