Qué es la ingeniería de harness, clave en la era de la IA
Si ha usado un agente de IA para programar, probablemente ya haya visto una escena parecida.
Al principio parece muy inteligente, pero en cuanto el trabajo se alarga un poco, pierde el contexto, toca archivos que no debe y dice “ya está” sin haber probado nada.
Muchos equipos, en ese punto, culpan solo al modelo. Pero varios textos recientes están diciendo algo distinto. El problema no está solo en el modelo, sino en todo el entorno en el que trabaja el modelo. Diseñar ese entorno es precisamente lo que llamamos ingeniería de harness.
Dicho de forma sencilla, es esto.
Un buen agente de IA no se construye solo con un buen modelo.
Hace falta también un buen conjunto de herramientas, buena documentación, buenos flujos de validación y un buen entorno de trabajo.
Qué es la ingeniería de harness
La definición más simple es esta: diseñar todo lo que está fuera del modelo.
LangChain lo explica con la fórmula “Agent = Model + Harness”. Si el modelo es la inteligencia, el harness es el sistema que convierte esa inteligencia en trabajo real. Aquí entran el prompt de sistema, las herramientas, el sistema de archivos, el navegador, el sandbox, los bucles de validación y los subagentes.
Mitchell Hashimoto lo plantea de una manera más práctica. Si un agente repite el mismo error, no basta con insistir en el prompt: hay que corregir AGENTS.md, añadir scripts o sumar herramientas para que ese error no vuelva a ocurrir. En otras palabras, no arregle el fallo solo con prompting; arréglelo con sistema.
En resumen, la ingeniería de harness responde a preguntas como estas:
- Qué documentos debe leer primero el agente
- Qué herramientas debe poder usar
- Hasta dónde puede modificar cosas de forma segura
- Cómo debe recordar el estado anterior cuando el trabajo se alarga
- Quién decide que algo está “terminado” y con qué criterio
Por qué la ingeniería de harness importa ahora
Antes, mucha gente usaba la IA como un chatbot que respondía preguntas.
Ahora, cada vez más equipos le están encargando tareas largas.
- Corrección de bugs
- Desarrollo de funciones
- Organización de documentación
- Aplicación de cambios tras code review
- Verificación antes del despliegue
- Tareas operativas repetitivas
El problema es que este tipo de trabajo no se resuelve con una sola respuesta.
Anthropic describe así el problema central de los agentes que trabajan durante mucho tiempo: el agente necesita operar a lo largo de varias sesiones, pero cuando empieza una sesión nueva ya no recuerda la anterior.
Es como si cada día llegara un desarrollador distinto al equipo sin saber qué se hizo ayer. Es normal que la productividad caiga y que los mismos errores se repitan.
Por eso hace falta un harness.
No se trata solo de lograr que la IA piense mejor, sino de crear una estructura que le permita continuar el trabajo de forma fiable.
Cuando un buen entorno de trabajo importa más que un buen modelo
La razón por la que la ingeniería de harness está llamando tanto la atención es simple.
Con el mismo modelo, el rendimiento puede cambiar bastante si cambia el harness.
LangChain explica que logró mejorar de forma notable el rendimiento en benchmarks de programación cambiando solo el harness y manteniendo el mismo modelo. OpenAI también describe que, en flujos de desarrollo basados en Codex, la productividad subió cuando el agente pudo leer documentación, usar herramientas y llegar hasta un PR, en lugar de limitarse a que una persona escribiera código a mano.
Esto importa bastante.
La ventaja competitiva no va a depender solo de qué modelo use una empresa,
sino de lo bien que diseñe el entorno en el que ese modelo trabaja.
De qué está hecho un harness en la práctica
1. Documentación breve y precisa
Muchos equipos intentan empezar metiendo todas las reglas en un único AGENTS.md enorme.
Pero OpenAI cuenta que ese enfoque no funcionó bien. Cuando el documento es demasiado largo, la información importante se pierde, y cuanto más envejece, menos fiable resulta.
Por eso apareció otra forma de organizarlo.
- Dejar en
AGENTS.mdsolo una guía breve - Llevar el detalle a una estructura ordenada dentro de
docs/ - Hacer que el agente use esa guía para encontrar solo el documento que necesita
Es como dar primero un mapa y un índice, en vez de entregar una enciclopedia entera.
2. Sistema de archivos y Git
LangChain considera el sistema de archivos uno de los elementos más importantes del harness.
La razón es sencilla.
- Permite guardar resultados intermedios
- Permite sacar contexto largo a archivos
- Permite que la siguiente sesión retome el estado anterior
- Permite que varios agentes y personas colaboren en el mismo espacio de trabajo
Git también es clave.
Permite rastrear qué cambió, volver atrás si algo sale mal y ayudar a que un agente recién incorporado entienda rápido los cambios recientes.
3. Herramientas de ejecución y sandbox
Por naturaleza, un modelo recibe texto y devuelve texto.
Ejecutar código, instalar paquetes, abrir un navegador o validar una interfaz no son capacidades propias del modelo. Son capacidades que le da el harness.
Por eso, un buen harness suele incluir cosas como estas.
- Una herramienta general de ejecución como
bash - Un runner de tests
- Automatización de navegador
- Consulta de logs
- Capturas de pantalla
- Un entorno sandbox aislado
Con estas herramientas, el agente deja de ser una entidad que solo “piensa” y pasa a ser una entidad que comprueba y corrige por sí misma.
4. Memoria y acceso a información actualizada
Un agente no recuerda por sí solo lo que queda fuera de su ventana de contexto.
Por eso, las reglas importantes, el historial del proyecto y el estado reciente deben quedar guardados en archivos para que la siguiente sesión pueda volver a leerlos.
Además, como el modelo puede no conocer información posterior a su entrenamiento, también hacen falta herramientas de búsqueda web o de contexto externo. Versiones de librerías, documentación reciente o estado actual del sistema son cosas que el harness debe suministrar.
5. Bucles de validación
Mitchell Hashimoto insiste especialmente en este punto.
Hay que hacer que los errores del agente se detecten lo más rápido posible.
Por ejemplo:
- Ejecutar tests automáticamente
- Comparar capturas de pantalla de la UI
- Añadir lint y validadores estructurales
- Devolver al agente los logs de error para que corrija
Un buen harness no deja que el fallo se descubra mucho después. Crea una estructura que le dice al agente, mientras trabaja, que se ha equivocado.
Por qué se vuelve todavía más importante en tareas largas
La ingeniería de harness brilla especialmente en las tareas de larga ejecución.
Anthropic propone dos roles para este tipo de trabajo.
- Un agente de inicialización que prepara el entorno en la primera ejecución
- Un agente de programación que avanza paso a paso en cada sesión posterior
La idea central es no intentar hacerlo todo de una sola vez.
En la fase de inicialización, se puede:
- Crear un script de arranque como
init.sh - Crear un archivo de registro del progreso
- Organizar la lista de funcionalidades en JSON
- Dejar preparada la base que leerán las siguientes sesiones
Después, en cada sesión, el agente de programación puede:
- Revisar el directorio actual y su estado
- Leer el log de progreso y el historial de Git
- Elegir una sola tarea de la lista de funcionalidades
- Registrar el avance al terminar
En el fondo, esto se parece mucho a una buena forma de trabajar en equipos humanos.
La ingeniería de harness no consiste en hacer magia con IA, sino en trasladar al sistema una buena manera de trabajar.
Por qué aparecen tanto skills, subagentes y hooks
Hay términos que se repiten mucho en los textos recientes: skills, sub-agents y hooks.
Todos intentan resolver, al final, el mismo problema.
Ahorrar contexto sin perder capacidades útiles.
HumanLayer dice que si metemos todas las herramientas y todo el conocimiento desde el inicio en el prompt de sistema, el rendimiento incluso puede empeorar. Por eso cobran importancia las skills, que permiten cargar solo el paquete de conocimiento necesario en el momento adecuado. A esto lo llaman “progressive disclosure”, es decir, divulgación progresiva.
Los subagentes funcionan de manera parecida.
Lo importante no es tanto la persona ficticia o el rol, sino la separación del contexto. Si se envía una subtarea a otra sesión, el agente principal no necesita cargar con todo el proceso intermedio.
Los hooks son todavía más decisivos.
Por ejemplo, si el agente dice que terminó, un hook puede lanzar automáticamente los tests y, si fallan, obligarlo a volver a trabajar. Es un mecanismo de control mucho más fuerte que un prompt.
Al final, la ingeniería de harness también es una forma de no confiar ciegamente en la IA
Aquí conviene no confundirse.
La ingeniería de harness no es una técnica para confiar más en la IA, sino también una técnica para no confiar en ella de forma ingenua.
Un buen harness parte de supuestos como estos.
- El modelo puede perder el contexto
- El modelo puede declarar terminado algo demasiado pronto
- El modelo puede generalizar mal una regla
- El modelo puede desestabilizarse en salidas largas
Por eso los buenos equipos no piensan “el modelo ya se encargará solo”.
Lo que hacen es anticipar dónde puede fallar y construir una estructura que reduzca esos fallos.
Esa mirada es importante.
La ingeniería de harness no se parece tanto a celebrar la IA como a gestionar su inestabilidad en un entorno real de trabajo.
Por dónde conviene empezar en la práctica
No hace falta construir algo enorme desde el principio.
De hecho, suele ser más realista empezar así.
1. Anote los errores que el agente comete con frecuencia
Por ejemplo:
- Dice que terminó sin ejecutar tests
- Repite comandos incorrectos
- Incumple una y otra vez las reglas del proyecto
- Intenta tocar demasiado a la vez
2. Cree una contramedida por cada error
Por ejemplo:
- Añadir una regla breve a
AGENTS.md - Añadir un script de validación frecuente
- Añadir un flujo de navegador para revisar la UI
- Añadir un hook que obligue a pasar tests antes de cerrar la tarea
3. Convierta la documentación en un mapa, no en un manual interminable
- Una guía breve
- Documentación detallada pero estructurada
- Un registro de progreso que conserve el estado reciente
- Una lista de funcionalidades y criterios de cierre
4. Pase del criterio humano al criterio del sistema para definir “terminado”
No “parece que más o menos ya está”, sino cosas como estas:
- Tests aprobados
- Revisión en navegador completada
- Lista de funcionalidades actualizada
- Logs sin anomalías
Solo con estas cuatro medidas, el rendimiento percibido del agente puede cambiar bastante.
Por qué será todavía más importante en adelante
Los modelos van a seguir mejorando.
La planificación, el razonamiento, la escritura de código y la autorrevisión también seguirán avanzando.
Aun así, muchos textos coinciden en algo.
Aunque el modelo mejore, la importancia del harness probablemente no desaparecerá.
Porque el trabajo real siempre ocurre dentro de un entorno.
- Cada empresa tiene un codebase distinto
- La estructura documental cambia de un equipo a otro
- Las políticas de seguridad son distintas
- Los criterios de validación son distintos
- Los flujos de colaboración también cambian
Es decir, por muy bueno que llegue a ser el modelo, seguirá existiendo la tarea de conectarlo con la realidad concreta de cada equipo. Ese punto de conexión es el harness.
Cierre
La expresión ingeniería de harness puede sonar como otra palabra de moda.
Pero, en el fondo, la idea es bastante simple.
En vez de esperar a que la IA se vuelva más inteligente,
se trata de diseñar el lugar de trabajo para que la IA se equivoque menos.
Un buen agente no nace de un único prompt brillante.
Nace de buena documentación, buenas herramientas, buena validación, buenos flujos de trabajo y buenos hábitos de registro.
Por eso, en la era de la IA, puede que las personas más valiosas no sean solo las que mejor usan el modelo.
También serán cada vez más importantes quienes diseñan el entorno en el que el modelo puede trabajar bien, es decir, quienes construyen el harness.