Qué es harness engineering: qué cambia en tu empresa y qué empleo crea

El harness engineering es la disciplina de construir el entorno que rodea a un modelo de IA: las herramientas a las que puede llegar, los límites que no puede cruzar y los bucles de verificación que le permiten corregirse antes de entregar. La fórmula que se ha impuesto para describirlo es corta: un agente es el modelo más su harness.

Durante dos años la conversación giró alrededor del modelo: qué modelo, con qué ventana de contexto, afinado con qué datos y comparado contra qué benchmark de la semana. No era una conversación falsa. Se quedaba a mitad de camino. El modelo nunca fue el producto.

Hay un patrón que se repite en casi todos los pilotos de agentes que llegan a revisión. La demo funciona. El agente resuelve el caso que se le enseñó, delante de las personas que decidían el presupuesto. Y después, en producción, empieza a hacer cosas raras: reescribe un fichero que nadie le pidió tocar, se queda dando vueltas sobre el mismo error, o entrega algo que parece correcto y no lo es. Nadie cambió el modelo. Lo que faltaba era todo lo demás.

A ese hueco lo llamamos aquí la brecha del piloto: la distancia entre un agente que demuestra y un agente que sostiene. El harness es lo que la cierra, y BCG ya puso número a lo que cuesta no cerrarla: en 2025 medía que solo una cuarta parte de las empresas declaraba obtener valor relevante de la IA.

Qué es un harness y por qué el modelo dejó de ser el producto

Un harness es el arnés. La palabra conserva su sentido literal, el de la pieza que sujeta a un animal potente para que tire en la dirección correcta en lugar de arrastrar el carro por el barranco, y esa imagen describe con bastante exactitud lo que hace el andamiaje de un agente. Aplicado a un sistema de IA, es todo lo que hay entre el modelo y el trabajo real.

La versión de manual dice que basta con elegir bien el modelo y escribir buenos prompts. Es la parte cómoda de la respuesta. Por eso circula tanto. La versión observada es bastante menos agradable: dos equipos con acceso al mismo modelo, con el mismo presupuesto y con el mismo caso de uso obtienen resultados que no se parecen en nada, y la diferencia entera está en el andamiaje que cada uno se molestó en construir alrededor.

Martin Fowler lo formula con una frase que conviene leer despacio en su artículo sobre harness engineering: los harnesses son un intento de externalizar y hacer explícito lo que un desarrollador humano aporta sin darse cuenta. Todo el criterio tácito de un buen ingeniero (qué mirar antes de tocar, cuándo parar, a quién preguntar) hay que escribirlo en algún sitio para que una máquina lo respete.

Addy Osmani lo resume en Agent Harness Engineering desde el otro extremo: el andamiaje deja de ser un accesorio y pasa a ser un artefacto de ingeniería con su propio ciclo de vida. Se versiona. Se revisa. Se rompe cuando alguien lo cambia sin mirar.

Y el empujón que sacó el término del círculo de especialistas vino de dentro de un laboratorio. OpenAI publicó en febrero de 2026 su experiencia construyendo un producto en modo agent-first, y lo que describía no era un modelo mejor: era la forma de trabajar alrededor.

Las tres capas de un harness, y la que casi nadie monta

El consenso que ha emergido divide el harness en tres capas, y la distinción importa por una razón muy concreta: los equipos suelen construir con bastante solvencia las dos primeras y dejan la tercera aparcada para una fase posterior que casi nunca llega. Son estas.

Capa de información. Qué ve el modelo. Aquí entra la gestión de la ventana de contexto, la recuperación de ficheros, la memoria de estado entre turnos y la decisión, mucho menos trivial de lo que parece, de qué documentación tiene delante en el momento exacto en que decide. Es la capa más trabajada, porque su ausencia se nota al primer intento.

Capa de ejecución. Qué puede hacer. Herramientas disponibles, acceso a línea de comandos, integraciones por API, permisos de escritura, y cómo se lanzan y coordinan subagentes. Aquí es donde encaja el protocolo que estandariza esas conexiones, y lo tratamos aparte en qué es MCP y por qué es una decisión de infraestructura.

Capa de feedback. Cómo se da cuenta de que se equivocó. Tests, linters propios, comprobaciones de esquema y puertas de calidad que el agente está obligado a pasar antes de presentar su trabajo a un humano, de forma que el error se detecte dentro del bucle y no en la reunión donde alguien esperaba el resultado. Es lo que separa un agente que se autocorrige de uno que produce con enorme confianza cosas incorrectas.

Y esta última es la que se queda sin construir. El motivo es incómodo pero simple: es la única de las tres que no mejora la demo, así que en una priorización hecha contra la fecha de la presentación siempre pierde frente a algo que se pueda ver. Un agente sin capa de feedback demuestra igual de bien. Falla después.

Qué cambia esto dentro de tu empresa

Cambia dónde está el cuello de botella. Si el modelo se sustituye editando una línea de configuración, y hoy en la mayoría de arquitecturas se sustituye editando una línea de configuración, la ventaja competitiva no puede vivir en cuál elegiste el trimestre pasado. Vive en el andamiaje. Es lo único que no viene de fábrica.

Eso mueve tres cosas dentro de una organización, y ninguna de las tres es un asunto de herramientas.

Mueve la propiedad. El harness no es del equipo de IA, o no solo: la capa de ejecución toca identidad, permisos y red, y la de feedback toca la cadena de integración continua junto al criterio de calidad de cada dominio del negocio. Un harness construido entero por la gente que entrena modelos sale fuerte en información y hueco en las otras dos. Pasa casi siempre.

Mueve lo que hay que evaluar cuando incorporas capacidad de fuera. Preguntar por experiencia con un framework concreto dice poco. Rotan cada trimestre. Lo que de verdad discrimina es si la persona ha montado puertas de verificación que hayan llegado a parar algo antes de producción, si sabe explicar con precisión qué dejó deliberadamente fuera del alcance del agente y si puede argumentar por qué esa frontera estaba donde estaba.

Y mueve el criterio de cuándo parar. Un agente sin límites explícitos no es más capaz: es menos predecible. Decidir qué no puede tocar, con qué permisos corre y en qué momento tiene que devolver el control a una persona es trabajo de ingeniería de pleno derecho, no una restricción que se añade al final si sobra tiempo en el sprint.

600 ofertas españolas piden harness y ninguna lo llama así

Hasta aquí el argumento. Ahora el dato. Analizamos el mercado laboral tech español con nuestro propio sistema de análisis y encontramos 21.836 ofertas activas entre el 14 de junio y el 19 de agosto de 2026, de las que 18.425 llevan las skills etiquetadas una por una.

De ese universo, 622 piden LangChain. Censamos 600 de ellas, una por una, y el resultado dibuja la disciplina antes de que exista el título.

Análisis de mercado de Shakers, n=600 sobre 622 ofertas declaradas, España, junio a agosto de 2026.

Tres lecturas salen de esa tabla.

La primera es que el trabajo existe y el nombre no. Cero ofertas lo nombran. Casi dos de cada tres piden sus componentes. Quien busque vacantes escribiendo el término en un portal de empleo no encontrará nada y concluirá que el mercado no existe, cuando lo que no existe es la etiqueta.

La segunda es dónde vive ese trabajo. De las 600 ofertas, solo 17 se clasifican como Cloud y DevOps, mientras 227 caen en roles nuevos de la era IA. Traducido: la responsabilidad del harness se está cargando sobre perfiles de IA y no sobre gente de plataforma. Eso explica bastante bien por qué la capa de feedback se queda a medias.

La tercera es ese 19 % que pide modelo y framework sin nada debajo: 113 empresas describiendo un agente que quieren poner en marcha sin mencionar en ningún punto de la oferta dónde va a correr, con qué permisos ni cómo se va a comprobar que lo que devuelve es correcto. Es el implementation gap escrito en un anuncio de empleo.

Un dato del mercado general cierra el argumento. En las 21.836 ofertas españolas, CI/CD aparece 4.541 veces y LangChain 622. Siete veces más demanda para la fontanería que para el framework de agentes. El mercado ya está pagando por la capa de feedback, aunque todavía no la asocie a la palabra harness.

Qué oportunidades abre para quien construye

Si estás en el lado de ejecutar, esta es la parte que te toca, y la conclusión es más favorable de lo que parece.

No exige empezar de cero. El perfil sale de dos sitios que ya existen. Si vienes de plataforma o de SRE, ya sabes de contenedores, de puertas de calidad y de por qué un sistema se cae a las tres de la mañana, y lo que te falta es entender cómo decide un agente y en qué punto conviene interrumpirlo. Si vienes de desarrollo con LLM, tienes el modelo y la orquestación, y te falta la disciplina operativa que el 64 % de esas ofertas ya reclama.

Sobre qué priorizar, el censo responde sin ambigüedad: dentro de las 600 ofertas, Python aparece en el 84 %, Docker en el 37 %, CI/CD en el 36 % y Kubernetes en el 27 %. Nada de eso es exótico. Es el repertorio de siempre apuntado a un problema nuevo.

Dos cosas sí cambian y merecen atención deliberada. La primera es aprender a diseñar verificación automática para trabajo no determinista, que se parece bastante menos de lo que uno espera a escribir tests para código que ante la misma entrada devuelve siempre la misma salida. La segunda es el criterio de alcance: poder argumentar qué se deja fuera. Eso no se acredita con un certificado. Se demuestra contando un caso.

Y hay una ventaja de calendario que conviene no desperdiciar. Cuando una disciplina todavía no tiene nombre en las ofertas, tampoco tiene filtros automáticos, ni cribas por palabra clave, ni esa exigencia de años de experiencia que ningún candidato del mundo puede cumplir. Ese hueco se cierra rápido. En cuanto el título aparezca en los anuncios, aparecerán con él los requisitos de cinco años en algo que existe desde hace dieciocho meses.

Si quieres ver cómo se está pidiendo hoy en España, el desglose por rol está en qué piden las ofertas de AI Engineer, y el panorama de equipo en agentes IA para empresas.

Qué no es harness engineering

El término está en su fase de máxima elasticidad, ese momento en que todo el mundo lo usa para nombrar lo que ya estaba haciendo. Conviene delimitar.

No es prompt engineering con nombre nuevo. El prompt trabaja sobre un turno de conversación y persigue una salida mejor; el harness trabaja sobre el ciclo completo de una tarea larga y persigue un sistema capaz de corregirse solo antes de que nadie lo revise. Se solapan poco.

No es exactamente lo mismo que context engineering, aunque medio sector los use como sinónimos intercambiables. El contexto es la capa de información y es una de las tres, de manera que un harness la contiene pero añade encima qué puede ejecutar el agente, con qué permisos lo ejecuta y cómo se comprueba después lo que hizo. La diferencia no es cosmética.

No tiene relación con Harness, la plataforma comercial de entrega de software. Comparten la palabra y nada más, y esa colisión de nombre es la razón de que buscar el término devuelva resultados mezclados.

Y no resuelve el problema de fondo. Fowler es explícito y merece repetirse: un harness externaliza el criterio humano hasta cierto punto y solo hasta ahí, de modo que por muy elaborado que sea el andamiaje sigue haciendo falta alguien que entienda qué está construyendo y para qué. No hay atajo ahí.

Lo que no sabemos es cuánto de esto sobrevive a la próxima generación de modelos. Si un modelo acaba gestionando por sí solo su contexto y su propia verificación, una parte del andamiaje que hoy se escribe a mano dejará de tener sentido y quien haya construido su perfil solo sobre esa mecánica se quedará mirando. La capa de feedback parece más difícil de delegar. Alguien tiene que decidir qué cuenta como correcto. Y esa decisión es del negocio.

Preguntas frecuentes sobre harness engineering

¿Es lo mismo harness engineering que prompt engineering?

No. El prompt engineering optimiza una interacción concreta con el modelo y trabaja sobre el texto de entrada. El harness engineering construye el entorno completo alrededor del agente: qué herramientas tiene, qué límites respeta y qué comprobaciones tiene que pasar antes de entregar. Un buen prompt dentro de un harness inexistente sigue produciendo un sistema poco fiable.

¿Harness engineering y context engineering son lo mismo?

No, aunque se solapan. El context engineering se ocupa de qué información ve el modelo, que es una de las tres capas del harness. Las otras dos son la de ejecución, que define qué acciones puede realizar, y la de feedback, que define cómo se verifica el resultado. El harness es el conjunto.

¿Hace falta un perfil dedicado o lo puede llevar el equipo actual?

Depende de dónde estén las tres capas hoy. Si el agente ya corre en producción con permisos de escritura y no hay comprobaciones automáticas antes de la entrega, el hueco es real y no se cubre con horas sueltas del equipo de IA. Lo que suele funcionar es un equipo mixto: alguien de plataforma que aporte la capa de feedback junto a quien ya conoce el dominio del agente.

¿Tiene algo que ver con Harness, la plataforma de CI/CD?

No. Harness es una empresa de entrega de software y harness engineering es una disciplina de ingeniería de agentes IA. Comparten el nombre por coincidencia. Al buscar información sobre la disciplina conviene añadir agentes o IA al término para evitar resultados de la plataforma.

¿Qué se pide hoy en España para un puesto de este tipo?

El título no existe todavía en las ofertas españolas, así que hay que buscar por componentes. En un censo de 600 ofertas que piden LangChain, 381 exigen además contenedores, integración continua o infraestructura como código, y CI/CD aparece siete veces más que LangChain en el conjunto del mercado. El repertorio es Python, Docker, CI/CD y Kubernetes aplicados a agentes.