Cómo ser Harness Engineer: la ruta en 7 preguntas

Prompt engineer. Context engineer. Harness engineer. Loop engineer.

Cuatro etiquetas nuevas para la misma persona: la que consigue que un modelo de lenguaje haga trabajo que sirve.

Ninguna de las cuatro te la va a dar el departamento de recursos humanos. Te la das tú, y no el día que aprendes una herramienta nueva, sino el día que cambias la pregunta que le haces a la pantalla. Ahí está la gracia de todo esto: el escalón no es técnico, es de pregunta.

En este artículo vas a encontrar:

• Qué es exactamente un arnés (harness) y por qué es la pieza que más cambia el resultado
• Las 7 preguntas que marcan cada salto, en el orden en el que aparecen de verdad
• Qué pieza concreta del arnés resuelve cada pregunta: contexto, herramientas, verificación, bucle
• La palabra que le puedes pedir a tu agente para que deje de darte por bueno lo que no lo está
• Por qué parte del arnés que montas hoy hay que tirarlo, y cómo saber cuál

¿Qué es un harness y por qué esa etiqueta se ha puesto de moda? ¶

Harness se traduce como arnés. Y un arnés, en los parques, es esa cosa que le pones al crío para que se columpie.

Piénsalo un segundo. El columpio de toda la vida era una barra, dos cadenas y una tabla: libertad total y el coscorrón que te ganaras. El columpio con arnés sujeta al niño por los hombros y por la cintura. Se mueve menos. Llega menos alto.

Y sin embargo es el que dejas usar a tu hijo de tres años.

🔑 El arnés restringe el movimiento y a cambio hace posible el vuelo. Esa es toda la idea, y funciona igual con los modelos de lenguaje.

Un arnés de IA es todo lo que rodea al modelo para que pueda trabajar de forma útil: las herramientas que puede llamar, el acceso a los archivos, el contexto que recibe, los permisos que tiene, la memoria entre sesiones, las reglas del proyecto y las verificaciones que se le exigen. Si quieres el desglose pieza a pieza del ciclo interno, lo tienes desmenuzado en qué es un AI harness y cómo funciona por dentro.

El modelo por su cuenta ya viene con restricciones de fábrica. Si le pides una bomba, un arma biológica o dónde descargarte una película pirata, te dice que no. Están dentro del entrenamiento y del prompt de sistema, y aunque siempre hay quien las rompe, ahí están.

Pero esas restricciones son las de la casa que fabrica el modelo. No son las tuyas.

Tú no quieres impedir que fabrique explosivos. Tú quieres impedir que se invente un endpoint, que escriba un test que no prueba nada, que te monte una API que nadie ha pedido porque le sobraban tokens, o que te diga que ya está cuando no está. Quieres apretar las correas por tu lado.

Por eso Claude Code, Codex, OpenCode o Cursor no son modelos: son arneses con un modelo dentro. Todo eso que ves pasar cuando le pides algo (leer archivos, buscar, editar, ejecutar comandos, consultar un MCP, revisarse) es el arnés trabajando. Hay agentes deliberadamente pelados, como pi, que vienen casi vacíos justo para que veas la diferencia entre el modelo y lo que le has puesto encima.

Un Harness Engineer diseña y mejora ese entorno para que el agente trabaje con fiabilidad y autonomía. No para que escriba más rápido: eso ya lo hace. Para que no te la cuele.

Pregunta 1: ¿cómo consigo que la IA haga esto? ¶

Todo el mundo empieza aquí, y no pasa nada por estar aquí.

Tienes una idea (el Facebook de los criadores de cangrejo azul en aguas profundas, por decir algo), abres el agente, escribes un prompt y esperas. Sale algo. Falla. Escribes otro prompt. Vuelve a fallar. Escribes un tercero.

Esto es avanzar como los tiburones: hacia adelante siempre, resolviendo el error que tienes delante sin mirar el que viene detrás.

El síntoma clásico de esta fase es la conclusión equivocada: “esta cosa es tonta y encima me engaña”. Era un diagnóstico razonable hace dos años. Hoy, con los modelos que tenemos, lo que suele fallar no es la inteligencia del modelo sino que está trabajando a ciegas: sin saber cómo está montado tu proyecto, qué convenciones usáis, qué se puede tocar y qué no.

Si estás en este escalón, lo peor que puedes hacer es cambiar de modelo buscando el que “sí funcione”. Lo que tienes que cambiar es la pregunta.

Guía interactiva gratis

Si todavía estás en la primera pregunta, este es tu mapa

Un curso-juego de 17 paradas donde eliges proyecto, agente y presupuesto sobre la marcha. La parada 3 separa modelo de arnés, la 10 va entera sobre la ventana de contexto y la 12 sobre por qué la IA miente. Sales con una checklist a tu medida.

Entra en el curso gratis →

Pregunta 2: ¿cómo se lo explico mejor? ¶

El salto aquí es moral antes que técnico: asumes que parte del problema es tuyo.

Es el momento en el que aparece el prompt engineer. Guías de prompting, plantillas, estructuras, trucos para conseguir precisión. Cada modelo publica las suyas, porque cada uno tiene su estilo y responde mejor a unas formas que a otras.

Y aquí va la frase que me llevo del episodio 350:

💡 El mejor prompt es el que no se escribe.

¿Te suena de algo? Es la misma frase que llevamos años diciendo sobre el código. El mejor código es el que no se escribe, porque no hay que mantenerlo. Con los prompts pasa igual: cada instrucción que repites en cada conversación es una instrucción que alguien tiene que acordarse de escribir, y ese alguien eres tú, veinte veces al día.

Lo interesante es que el prompting ha ido perdiendo peso solo. Las recomendaciones actuales de modelos como Opus van justo en dirección contraria a los trucos de hace dos años: dale la tarea entera de una vez al principio, no la trocees artificialmente y no le pidas que verifique, porque ya lo hace. Menos coreografía, más encargo claro.

Guarda esa pista. Vuelve al final del artículo con fuerza.

Pregunta 3: ¿qué necesita saber para hacerlo bien? ¶

Aquí nace el context engineer, y es el primer salto que se nota de verdad en los resultados.

La pregunta ya no es cómo se lo digo, sino qué información le falta que yo sí tengo.

El contexto de un agente son varias capas, y conviene distinguirlas porque no se tocan igual:

Lo primero que hace casi cualquier agente al arrancar es mirar qué hay en la carpeta. Un ls y a tirar del hilo. Van leyendo lo que necesitan, cuando lo necesitan, sin tragarse el repositorio entero: descubrimiento progresivo.

Y ahí está el error clásico de esta fase: si le doy todo, lo hará mejor.

No. Meterle un libro entero de Java no le enseña Java. Ya sabe Java. Lo que no sabe es cómo está organizado tu proyecto, qué decisiones de arquitectura tomasteis y por qué, qué librería está prohibida por una razón histórica que nadie documentó y qué convención de nombres usáis en los tests.

Eso es el contexto que importa. Lo escribes una vez, en el fichero de instrucciones, y deja de ocupar sitio en tu cabeza. Si quieres afinar qué regla va en el archivo global, cuál en el del proyecto y cuál en una skill, está desglosado en dónde vive cada regla de tu agente.

⚠️ Un fichero de instrucciones que crece sin límite deja de ser contexto y pasa a ser ruido. Si cada línea que añades le resta atención a las demás, revisar el archivo es tan importante como escribirlo.

Pregunta 4: ¿qué herramientas le faltan para poder hacerlo? ¶

Ahora que sabe lo que tiene que saber, empiezas a ver el otro límite: hay cosas que no puede hacer porque no tiene con qué.

Las herramientas básicas ya vienen dentro del arnés y las ves pasar en cada turno: leer archivos, escribirlos, editarlos, buscar patrones, ejecutar comandos, hacer reemplazos. En OpenCode o en pi se ven con más claridad que en ningún sitio, y por eso son tan buenos para aprender cómo funciona esto por dentro.

Pero el trabajo real se sale de ahí enseguida. Quieres que mire la base de datos. Que lea los logs del backend. Que abra el navegador y compruebe si el formulario envía. Que consulte tu sistema de tickets.

Hay dos caminos y conviene saber cuándo usa cada uno:

1. Que se la construya sobre la marcha. Si detecta Postgres o MySQL, sabe cómo conectarse. Prueba credenciales estándar de desarrollo, y si no las encuentra, te pregunta. Para tareas puntuales suele sobrar con esto.
2. Que se la des tú. Aquí entran los MCP (Model Context Protocol), el estándar abierto que Anthropic publicó a finales de 2024 y que hoy soportan casi todos los agentes. Un servidor MCP conecta el mundo de las alucinaciones con el mundo donde dos más dos son cuatro siempre.

Esa es la diferencia real entre una respuesta y un dato: un script de Python que suma dos más dos no tiene opinión sobre el resultado.

Y luego están las skills, que son la pieza más interesante porque juegan en las dos categorías a la vez. Una skill aporta contexto (le dice cómo se hace algo concreto en tu casa) y aporta herramienta (puede traer scripts que hacen el trabajo determinista). Si siempre recortas los diez primeros segundos y los diez últimos de un vídeo, no le expliques el procedimiento cada vez: mete el script en la skill y que lo ejecute.

Contexto que se carga solo cuando hace falta, más código que hace lo que el modelo haría peor. Por eso las skills aguantan tan bien el paso de los meses.

Pregunta 5: ¿cómo sé que lo ha hecho bien? ¶

Esta es la pregunta que separa a quien usa agentes de quien los dirige.

Llega justo cuando has dejado de leer el código línea a línea. Y llega con un pellizco, porque el trabajo hay que entregarlo: al cliente, al equipo, a producción. La excusa de que el perro se comió los deberes se ha convertido en que la culpa la tiene Claude, o Gepeto, o quien sea.

La culpa puede tenerla él. El responsable sigues siendo tú.

El problema añadido es que estos sistemas están diseñados para que la conversación te resulte agradable. No te dicen “me he tropezado”. Te dicen “me he tropezado, pero ya lo he resuelto”. Siempre hay una solución al final del párrafo, y siempre suena convincente. Mi favorita: “ya tengo el mapeo completo de todo lo que necesito”.

Sobre cuánto revisar y con qué criterio ya nos peleamos en ¿necesitas revisar todo el código que genera la IA?. Aquí lo que toca es montar el aparato de control, y tiene dos mitades.

Lo determinista, que es lo de siempre y sigue funcionando:

• Tests, del tipo que sean, incluso los que se inventa el propio agente para comprobar en vivo lo que acaba de hacer
• Linters, que vigilan la forma
• Tipado: en proyectos con TypeScript o PHP moderno el propio agente se preocupa del tipado sin que se lo pidas, y un error de tipos es un error, no una opinión
• Logs: los del navegador, los del backend, los de la base de datos. Los sensores que rodean lo que estás ejecutando
• Integración continua, tests de arquitectura, tests de mutación, tests de penetración. Todos los tests del mundo van a parecer pocos

Lo no determinista, que es lo nuevo: que otro modelo revise el trabajo del primero. Prácticamente todos los agentes traen algo detrás de /review, y detrás de ese comando hay un prompt de revisión. No es una garantía, pero es una segunda opinión barata que pilla cosas que tú ya no miras.

Y ahora el truco que te llevas de aquí.

🛡️ Pídele evidencias. Literalmente esa palabra. “Dame evidencias de que esto funciona” cambia el tipo de respuesta que recibes: en vez de un resumen convincente, sale una traza, una salida de consola, una captura, un comando que puedes repetir tú.

No confíes en la respuesta. Exige la prueba.

Tu IA puede mentirte

¿Y si montamos el aparato de verificación entero, en directo?

Masterclass sobre cómo revisar y verificar lo que programan los agentes: ciclo anticaos, skills de revisión, pruebas en navegador con Playwright, casos Gherkin y revisión adversarial entre modelos. El método completo, no la fe.

Ver la masterclass →

Incluye casos Gherkin y revisión adversarial entre modelos

Pregunta 6: ¿por qué he tenido que intervenir yo otra vez? ¶

Este es el momento exacto en el que te conviertes en Harness Engineer, y suele llegar de mal humor.

Estás mirando la pantalla y te das cuenta de que has hecho las mismas cinco cosas que ayer. Recordarle que se lea el archivo de configuración antes de tocar nada. Pedirle que ejecute los tests. Pedirle que te explique por qué ha elegido esa librería. Decirle otra vez que en este repositorio las migraciones van aparte.

Y la pregunta cae sola: ¿qué pinto yo repitiendo esto?

Cada intervención humana repetida es una pieza del arnés que todavía no existe. Esta es la tabla de conversión:

La regla es simple y aguanta bien: si lo has dicho tres veces, ya no es una instrucción, es una pieza que falta.

Ojo, que aquí hay un matiz que se pasa por alto. No toda intervención hay que automatizarla. Si intervienes porque el agente se está saliendo de madre en una decisión de diseño que cambia cada semana, eso no es una pieza que falta: eso es tu trabajo. Lo que se automatiza es lo repetido y estable, no lo importante.

Pregunta 7: ¿cómo consigo que me necesite menos? ¶

Fíjate en el giro. Durante seis preguntas has intentado controlar mejor al agente. Aquí lo que quieres es lo contrario: que te necesite menos veces.

Es el territorio del loop engineer. Un bucle en el que el agente sabe qué tareas tiene pendientes, las ejecuta, verifica el resultado y sigue con la siguiente sin pedirte permiso en cada paso.

Ya no quieres estar mirando comando a comando, entre otras cosas porque quieres tener tres o cuatro cosas en marcha a la vez. De ahí que hayan aparecido herramientas tipo Orca o los tableros de escritorio que te muestran de un vistazo qué está haciendo cada agente y en qué fase está cada tarea. Ahí es donde te hace falta una sala de control, y el patrón manager/worker, los guardarraíles y cómo medir si el sistema funciona los tienes desarrollados en cómo montar un sistema de agentes autónomos.

Lo que quieres de un bucle bien montado:

1. Que siga solo mientras pueda seguir
2. Que te pregunte únicamente cuando la decisión sea tuya de verdad
3. Que cuando ni eso haga falta, decida con lo que ya le has dado
4. Que te deje el resultado en un formato que puedas comprobar sin reconstruir su razonamiento: evidencias en Markdown, el servidor levantado en la página que hay que mirar, la imagen generada, la pull request lista

Es la palabra que lleva meses dando vueltas: software factory. Una fábrica de software razonablemente autónoma donde tú aprietas un botón de vez en cuando, como Homer Simpson en la central. En los artículos suena más bonito de lo que es, pero la dirección es esa.

🔑 No se trata de controlar más al agente. Se trata de que necesite menos de ti. Son cosas distintas y llevan a arneses distintos.

¿Y si todo este arnés ya no hiciera falta? ¶

Aquí es donde el episodio 350 se pega un tiro en el pie a propósito, y es la parte que más me gusta.

Has montado el contexto, las skills, las tools, los verificadores, el bucle. Y entonces llega la pregunta incómoda: ¿sigue haciendo falta todo esto?

Hace unos días el autor de Clean Code, Robert C. Martin, contaba algo parecido: lleva mucho tiempo construyendo el arnés perfecto, con la meticulosidad que te puedes imaginar en alguien que se pasó una carrera entera explicando cómo organizar el código. Y su conclusión reciente era que buena parte de ese andamiaje ya no hace falta, porque los agentes han mejorado hasta hacer solos cosas que antes había que dictarles paso a paso.

Y no es una anécdota aislada. Las pistas están en la documentación de los propios modelos:

• La guía de prompting de Opus te pide que no le mandes verificar, porque ya lo hace
• Las herramientas nuevas empiezan a traer utilidades para reconvertir ficheros de instrucciones y skills escritos para modelos anteriores, porque ahora sobran explicaciones que antes eran imprescindibles

Tiene toda la lógica del mundo. Millones de peticiones diarias son, de una forma o de otra, material de entrenamiento. Todo lo que el gremio ha estado explicándole trabajosamente a los modelos durante dos años acaba absorbido dentro del modelo.

Así que el trabajo del Harness Engineer tiene dos caras, y solo hablamos de una:

• Añadir lo que falta: contexto, herramientas, reglas, verificaciones
• Quitar lo que ya sobra: la regla que el modelo cumple sin que se la digas, el verificador que duplica algo que el agente ya hace, el paso manual que existía porque hace ocho meses no había alternativa

La segunda cara da menos satisfacción que la primera, porque montar cosas mola y desmontarlas no. Pero es el mismo músculo que usábamos escribiendo todo el código a mano: refactorizar, borrar lo que sobra, quitar el parche que tapaba un agujero que ya no existe.

Tu arnés es código. Envejece igual que el código.

¿Qué piezas del arnés se caen primero? ¶

No hay una lista oficial, pero después de unos meses tocando esto el patrón se repite. Las piezas que primero se vuelven prescindibles son las que explican cómo se hace algo genérico. Las que aguantan son las que explican cómo se hace algo aquí.

La prueba para saber si una pieza sigue viva es barata: quítala y haz la misma tarea dos veces. Si el resultado no empeora, ya no te hacía falta. Si empeora, la devuelves y además ahora sabes para qué servía, que no es poco.

¿Por dónde empiezas, si empiezas mañana? ¶

No hace falta que te montes tu propio agente desde cero para entender cómo funciona esto. Lo que sí hace falta es dejar de mirar la respuesta y empezar a mirar el proceso.

Tres cosas concretas para esta semana:

1. Lee lo que hace, no solo lo que responde. Qué archivos abre, en qué orden, qué herramienta llama. Si trabajas con un agente que lo enseña todo (OpenCode es el mejor para esto), en dos sesiones aprendes más sobre arneses que en diez artículos.
2. Apunta tus intervenciones repetidas durante tres días. Sin automatizar nada todavía. Solo la lista. Cuando la mires el jueves, el arnés que te falta está escrito ahí.
3. Pide evidencias en cada tarea que entregues. Es gratis, cambia el tipo de respuesta que recibes y te devuelve algo que puedes comprobar sin volver a leer el código entero.

Y una cuarta, que es más incómoda: cada mes, borra algo del arnés. Una regla, un paso, un verificador. Comprueba si pasa algo.

Empezamos preguntando cómo consigo que la IA haga esto. Hemos acabado preguntando qué puedo cambiar en el sistema para que la próxima vez lo haga sin mí.

Y por el camino, equivocarse experimentando con esto sigue costando muy poco. Nunca hemos tenido un sitio donde probar ideas raras con tan poco que perder.

¿Cuál de las siete preguntas te estás haciendo tú esta semana?

TL;DR ¶

• 🎢 Un harness es todo lo que rodea al modelo (contexto, herramientas, permisos, memoria, reglas, verificaciones) y restringe el movimiento para hacer posible el trabajo, igual que el arnés de un columpio
• 🪜 El itinerario tiene 7 preguntas: cómo lo consigo, cómo se lo explico, qué necesita saber, qué herramientas le faltan, cómo sé que lo ha hecho bien, por qué he intervenido yo y cómo consigo que me necesite menos
• 🧾 La palabra “evidencias” es el mejor atajo de verificación: cambia un resumen convincente por una prueba que puedes repetir
• 🔁 Cada intervención humana repetida tres veces es una pieza del arnés que todavía no existe: contexto, regla, skill, hook, tool o subagente
• 🧹 La otra mitad del trabajo es retirar: las piezas que explican lo genérico caducan, las que explican tu casa aguantan

Preguntas frecuentes ¶

¿Qué es un Harness Engineer?

Es quien diseña y mantiene el entorno que rodea a un modelo de IA (herramientas, contexto, permisos, memoria, reglas y verificaciones) para que un agente de código trabaje con fiabilidad y autonomía. No optimiza el modelo: optimiza todo lo demás.

¿Harness engineering es lo mismo que prompt engineering?

No. El prompt engineering trabaja sobre el mensaje que le mandas al modelo. El harness engineering trabaja sobre el sistema completo donde ese mensaje ocurre: qué información tiene disponible, qué puede ejecutar, qué tiene prohibido y cómo se comprueba el resultado. El prompt es una pieza del arnés, no el arnés.

¿Necesito construir mi propio agente para ser Harness Engineer?

No. Claude Code, Codex, OpenCode o Cursor ya traen un arnés dentro; tu trabajo es ampliarlo y ajustarlo con contexto, skills, herramientas y verificaciones propias. Construir un agente desde cero sirve para aprender cómo funciona por dentro, no es un requisito.

¿Qué diferencia hay entre context engineer y harness engineer?

El context engineer se centra en qué información necesita el modelo para hacer bien la tarea. El harness engineer incluye eso y además las herramientas, los permisos, la verificación y el bucle de trabajo. El contexto es una capa del arnés.

¿Qué es un loop engineer?

Es el escalón siguiente: diseñar bucles donde el agente identifica tareas, las ejecuta, verifica el resultado y continúa sin intervención humana en cada paso. El objetivo deja de ser controlar mejor y pasa a ser necesitar menos supervisión.

¿Cómo verifico que un agente de IA ha hecho bien su trabajo?

Con dos capas. La determinista: tests, linters, tipado, logs del navegador y del backend, integración continua. La no determinista: que otro modelo revise el trabajo, normalmente detrás de un comando /review. Y en ambos casos, pedir evidencias concretas en vez de aceptar un resumen.

¿Por qué los agentes dicen que algo está terminado cuando no lo está?

Porque están entrenados para producir respuestas satisfactorias y coherentes, y una respuesta que termina en solución resulta más satisfactoria que una que termina en duda. No es mala fe, es la forma de la respuesta. Por eso la verificación se diseña fuera del modelo.

¿Las skills son contexto o herramientas?

Las dos cosas. Una skill aporta contexto acotado (cómo se hace algo concreto en tu proyecto) y puede aportar herramientas (scripts deterministas que hacen el trabajo repetitivo). Esa doble naturaleza es lo que las hace duraderas frente a otras piezas del arnés.

¿Merece la pena montar un arnés si los modelos mejoran cada pocos meses?

Sí, con una condición: revisarlo. Las piezas que explican cosas genéricas caducan según mejoran los modelos, pero las que describen tu proyecto, tus límites y tus decisiones no las va a aprender ningún modelo por su cuenta. Retirar piezas obsoletas es parte del trabajo.

¿Cómo sé qué parte de mi arnés ya no hace falta?

Quítala y repite la misma tarea dos veces. Si el resultado no empeora, esa pieza ya no aportaba nada. Si empeora, la devuelves y ahora sabes exactamente qué estaba sosteniendo.

Fuentes ¶

• Cómo demonios te haces Harness Engineer — Web Reactiva 350, el episodio que da origen a este artículo
• Claude Code docs — memoria, ajustes, skills y comandos del agente
• Introducing the Model Context Protocol — Anthropic, el estándar abierto para conectar agentes con herramientas y datos
• Especificación de Model Context Protocol, cliente, servidor y tipos de capacidades
• OpenCode docs, el agente open source donde mejor se ven las herramientas en acción
• Cómo empezar con la IA para crear proyectos de software — Web Reactiva 344

🧨 Última oportunidad para recibir la dinamita que mereces sobre programación con IA el próximo domingo: Suscríbete gratis a Web Reactiva en https://webreactiva.com/newsletter