Aunque usan el mismo modelo, la calidad de los resultados varía entre equipos. En uno, la IA completa una refactorización; en otro, una persona debe corregir incluso los cambios simples.
La diferencia no está en la redacción del prompt, sino en el entorno de ejecución que envuelve al modelo: el arnés (harness).
En una frase, la ingeniería de arneses consiste en diseñar el bucle completo en el que el modelo usa herramientas, valida los resultados y trabaja con feedback. Si la ingeniería de prompts es «cómo pedir las cosas», la ingeniería de arneses es «cómo preparar un lugar de trabajo eficaz».
En este artículo veremos qué es exactamente un arnés, cuáles son sus componentes y cómo evaluar uno bueno.
Empecemos por el resumen clave.
- Un arnés es un bucle de ejecución que envuelve al modelo. Sus componentes son las herramientas, los permisos, la gestión del contexto y el feedback.
- El rendimiento de un agente = inteligencia del modelo × calidad del arnés.
- La clave de un buen arnés es un bucle de feedback que permita al modelo comprobar sus propios resultados.
- La esencia de agentes de programación como Claude Code y Cursor es precisamente el arnés.
¿Qué es exactamente un arnés?
Originalmente, un arnés es el conjunto de aparejos que se coloca a un caballo. No aumenta su fuerza, sino que la convierte en una tarea útil: tirar de un carro.
El término «arnés de pruebas» tiene el mismo origen.
Lo mismo ocurre con el arnés de un LLM. Mantiene el modelo (la inteligencia) sin cambios y se refiere a todo el software que lo envuelve para convertir esa inteligencia en trabajo real.
En concreto, incluye lo siguiente.
- Capa de herramientas: las funciones que el modelo puede invocar, como leer y escribir archivos, ejecutar el shell y buscar.
- Capa de permisos: las políticas sobre qué preguntar y ejecutar, y qué aprobar automáticamente.
- Capa de contexto: qué mostrar al modelo, qué ocultar y cuándo resumir.
- Capa de bucle: la estructura iterativa que convierte los resultados de las herramientas en la siguiente acción y define cuándo terminar.
Llamamos a Claude Code o Cursor «herramientas de programación con IA», pero el modelo en sí es el mismo que está detrás de la API. La esencia del producto es el arnés.
Rendimiento = modelo × arnés
Ya son comunes los casos en que la puntuación de un benchmark varía mucho con el mismo modelo. En las tablas de clasificación de benchmarks de agentes, un mismo modelo puede diferir en decenas de puntos porcentuales de tasa de éxito según el arnés.
La razón es sencilla: las tareas de los agentes son cadenas de decenas de llamadas a herramientas, y el arnés interviene en cada etapa.
| Cuando el arnés es malo | Cuando el arnés es bueno |
|---|---|
| Vierte todos los resultados de las herramientas en el contexto. | Transmite solo las partes necesarias, resumidas. |
| Repite el mismo intento aunque falle. | El mensaje de error se convierte en la entrada del siguiente intento. |
| Determina que el trabajo terminó basándose en la afirmación del modelo. | Verifica con pruebas y compilaciones, y termina solo cuando pasan. |
Los modelos cometen errores de forma probabilística. El papel del arnés no es eliminarlos, sino hacer que se filtren durante la validación y que el modelo los corrija por sí mismo.
Tres condiciones de un buen arnés
Desde la perspectiva práctica, la calidad de un arnés se reduce a tres condiciones.
Primero, un bucle de feedback verificable. Si el modelo modifica el código, hay que ejecutar las pruebas y mostrarle el resultado.
Así como no confiamos en código escrito sin compilarlo, un agente sin feedback solo acumula confianza infundada. Por eso los mayores beneficios de adoptar agentes aparecen en bases de código con buenas pruebas.
Segundo, gestionar el presupuesto de contexto. La ventana de contexto es finita, pero los resultados de las herramientas llegan sin límite.
Recortar salidas largas, resumir contenido antiguo y aislar las tareas de exploración en subagentes son responsabilidades del arnés.
Tercero, una ruta de fallo segura. Las políticas de permisos y el sandbox deben definir el «alcance en el que un error se puede recuperar».
Por ejemplo, aprobar automáticamente las operaciones reversibles y preguntar a una persona solo para las destructivas.
Relación con la ingeniería de prompts
No significa que la ingeniería de prompts haya dejado de ser útil. Simplemente opera en otra capa.
El prompt optimiza una sola solicitud. El arnés optimiza un bucle formado por decenas de solicitudes consecutivas. La redacción del prompt del sistema pasa a ser un subconjunto del diseño del arnés.
El centro de atención se ha desplazado de «qué decir» a «qué entorno proporcionar». Cuanto mejor es el modelo, más fuerte es esta tendencia: las instrucciones pueden acortarse, pero el valor de las herramientas y del bucle de validación aumenta.
Conclusión
Si los resultados del agente no te convencen, revisa el arnés antes de perfeccionar el prompt. Comprueba si el modelo puede verificar sus resultados, si el contexto está lleno de información irrelevante y si los fallos conducen al siguiente intento.
En el próximo artículo trataremos la ingeniería de contexto, que profundiza exclusivamente en la capa de contexto.

![Imagen de portada de [Diseño de agentes #1] Ingeniería de arneses: después del prompt](/assets/images/posts/e5b7d384-3107-41fb-a62e-34369bc15f27/harness-engineering-1.jpg)