El mapa para orientarte y entender la IA y sus engineerings – Parte 2

Harness Engineering

El tercer bloque sería el harness engineering. Esta es la parte más nueva y quizá la frontera con el context engineering todavía no está del todo definida y asentada.

Voy a empezar por lo que es y no por lo que contiene, porque creo que casi todo el mundo lo explica al revés y por eso acaba sonando a fontanería y a conversación de informáticos.

El término lo popularizó Mitchell Hashimoto, el cofundador de HashiCorp, a principios de 2026, y lo hizo describiendo un hábito propio que no tiene nada que ver con conectar cosas. Cada vez que la IA se equivocaba, en lugar de corregir el resultado a mano y seguir, se paraba a construir en el entorno de la IA algo que impidiera que ese error volviera a ocurrir. Una comprobación, una regla escrita, una herramienta nueva, un test.

Eso es el harness. No es el cableado del coche, es el sistema de frenos y la ITV. Y visto así deja de ser un asunto técnico de fontanería para convertirse en la respuesta directa a la pregunta que hace cualquier directivo: cómo consigo fiarme de esto.

Si tuviera que quedarme con una sola frase de todo el bloque sería esta: el harness es lo que garantiza que no pase lo que no quieres que pase.

Y ahí es donde vive la parte que más valor tiene para una empresa y de la que casi nadie habla, porque no es vistosa y no sale bien en una demo: los permisos que le das y sobre todo los que no le das, qué herramientas puede usar y con qué alcance, la diferencia enorme entre poder leer y poder escribir, las APIs que dejas deshabilitadas, en qué sistemas puede tocar y en cuáles no llega, y qué acciones exigen aprobación humana antes de ejecutarse.

Nada de eso es una recomendación al modelo. Es una limitación del entorno, y esa es toda la diferencia: no depende de que la IA se porte bien, ni de que haya entendido bien la norma, ni de que ese día el modelo esté fino. Una empresa que quiere meter IA en su operativa no necesita primero un discurso sobre modelos, necesita saber que hay cosas que el sistema directamente no puede hacer.

Debajo de esa idea sí está toda la capa de configuración y conexión, que es justo la que se suele enseñar primero: hooks, slash commands, capacidades base, búsqueda web, lectura de archivos, conectores con otras herramientas, MCPs, scripts tirando de API o CLI, y el software adicional que refuerza la conexión con el conocimiento, como los motores de recuperación, las memorias o las bases de datos vectoriales. Todo eso es lo que hay dentro del harness, pero no es lo que lo define.

De esa forma de verlo salen dos divisiones que me parecen las dos ideas más aprovechables de todo el bloque:

1- La primera la formularon Birgitta Böckeler y Chris Ford, de Thoughtworks, y separa el harness en dos tipos de pieza.

Las guías, que actúan antes: instrucciones, convenciones, ejemplos, permisos, documentación de referencia. Orientan el trabajo para que salga bien a la primera. Y los sensores, que actúan después: comprueban lo que se ha hecho y permiten corregirlo antes de que llegue a una persona o a un cliente. Un sensor puede ser determinista, como un test o una validación, o interpretativo, como otra IA revisando el trabajo de la primera con criterios escritos.

Mi observación de campo, y creo que es el diagnóstico más útil que puedo dar sobre este bloque: casi todas las empresas tienen guías, algunas mal escritas, y no tienen ni un solo sensor. Trabajan a ciegas y confían. Luego el sistema lleva tres meses degradándose y nadie se ha enterado.

2- La segunda división es de propiedad, y es una pregunta de compra. El harness interior es el que trae puesto la herramienta que contratas: su bucle, sus capacidades base, cómo gestiona la memoria, lo que viene de fábrica. No lo controlas y cambia cuando el proveedor decide. El harness exterior es el que montas tú encima: tus archivos de instrucciones, tus conexiones, tus comprobaciones, tus reglas.

Y la consecuencia enlaza directamente con lo que decía antes sobre soberanía digital: el harness exterior es tuyo y se va contigo si cambias de herramienta. El interior no. Cuanto más de tu fiabilidad dependa del interior, más atado estás sin haberlo decidido.

El famoso RAG

Sobre el RAG merece la pena que me detenga, porque es justo donde más se discute la frontera y donde yo mismo he afinado la posición. El RAG no es una cosa, son dos, y se parten exactamente por la línea que separa estos dos bloques.

Lo que se indexa y con qué calidad, es decir el corpus, su curación y su estructura, es context engineering. El motor que lo encuentra, es decir el troceado, los embeddings, la base vectorial, la reordenación y la sincronización del índice, es harness engineering.

Es el mismo corte que aplico a las herramientas conectadas: la descripción de una herramienta es contexto, porque es lo que lee el modelo para decidir si la usa; la conexión es harness, porque es fontanería.

Y no es una distinción de vocabulario, es de gestión. Cada mitad se compra a gente distinta, se paga con dinero distinto y se rompe de forma distinta. El motor tiene proveedores, precio de mercado y alguien a quien llamar cuando falla. La curación no tiene proveedor: la haces tú o no se hace.

Al principio de este texto he dicho que «prompt engineering» me parecía un nombre demasiado pomposo, nacido del hype, y que me sonaba al ya caducado «nivel alto de ofimática» de los currículums. Sería un poco cínico por mi parte no aplicarme el mismo rasero aquí.

«Harness engineering» es un término de principios de 2026. Tiene meses de vida. Y hay gente seria sosteniendo, con argumentos razonables, que no es más que un nombre nuevo para cosas que la ingeniería de sistemas lleva décadas haciendo: plataforma, middleware, fiabilidad, planos de control. Puede que tengan bastante razón.

¿Por qué lo uso entonces? Porque creo que hay una diferencia con el caso del prompting, y es esta: el prompt engineering nombraba una habilidad de usuario, y esas caducan al generalizarse. El harness engineering nombra una capa de arquitectura, con presupuesto, con dueño y con métrica propia. Y esa capa existe la llames como la llames.

Así que yo me quedo con la idea y no me caso con la etiqueta. Si dentro de dos años esto se llama de otra forma, me parecerá bien. Con lo que sí me casaría es con lo de debajo: sin límites y sin sensores no hay fiabilidad, y sin fiabilidad no hay proyecto, solo demo.

Loop y graph: las dos que aparecen cuando dejas de ser solo usuario

Con esos tres bloques está cubierto el mapa de alguien que usa la IA para trabajar. Pero el mapa no se acaba ahí, y prefiero decirlo a dejar la sensación de que esto son tres cajas y ya está.

Cuando la IA deja de responderte y empieza a operar sola aparecen dos capas más. No las he pintado en el diagrama a propósito, porque no son zonas nuevas del mapa: son lo que ocurre dentro de la herramienta de IA cuando gana autonomía.

El loop engineering es el diseño del bucle del que hablaba en el bloque de asistentes y agentes. Cómo la IA se llama a sí misma, cómo decide cuál es el siguiente paso, cómo elige qué herramienta usa, cómo comprueba si ha terminado y, sobre todo, cuándo se para. Es lo que convierte un asistente en un agente, y es también donde se decide cuánto margen tiene para equivocarse antes de que alguien se entere.

El graph engineering es el escalón siguiente: varios agentes trabajando coordinados, en paralelo o repartiéndose un objetivo, con alguno orquestando al resto. Lo que en el bloque de asistentes eran disfraces que la misma herramienta se ponía y se quitaba, aquí pasan a ser piezas distintas funcionando a la vez.

No voy a profundizar más en estas dos, y es deliberado. Siguiendo con la comparación del coche: prompting, context y harness son cosas de conductor, y quien conduce debería entenderlas. Loop y graph ya son cosas de mecánico. Está bien saber que existen, para qué sirven y en qué momento aparecen, sobre todo para reconocer de qué te están hablando cuando alguien te venda un «sistema multiagente» y para preguntar lo único que importa: quién frena eso y cuándo.

Y me aplico aquí el mismo rasero que acabo de aplicarme con el harness: si «harness engineering» tiene meses de vida, «loop» y «graph» tienen menos y están bastante menos asentados. Los uso porque nombran dos cosas que existen y que no tenían nombre corto, no porque sean etiquetas cerradas.