Hay dos maneras de trabajar con un modelo de lenguaje, y la diferencia no es de gusto.

La primera sostiene que el modelo ya es suficientemente bueno: cualquier estructura que le pongamos alrededor es fricción, burocracia, desconfianza disfrazada de ingeniería. «Dejalo trabajar», «no lo encorsetes», «cuanto menos prompt, mejor». La segunda sostiene algo más incómodo: el modelo es una pieza, y el sistema que lo rodea es el producto.

Este artículo defiende la segunda, y no por preferencia estética. Lo hace porque la evidencia de los últimos dos años es consistente y está publicada; porque la resistencia es más fuerte justo entre quienes usan los modelos más capaces, donde el costo de equivocarse es mayor; y porque hay un punto de entrada concreto para quien todavía no armó nada.

La primera escuela tiene un atractivo evidente: no exige nada. No hay que escribir reglas, ni versionar nada, ni decidir dónde están los límites. Cualquier resultado mediocre se explica solo: «el modelo todavía no está». Es una posición cómoda y, durante bastante tiempo, difícil de refutar.

Ya no. La evidencia pública de los últimos dos años apunta en una sola dirección: cuando el mismo modelo rinde distinto, lo que cambió fue el arnés.

El arnés (harness) es todo lo que no es el modelo: el prompt de sistema, las herramientas disponibles, el orden en que se ensambla el contexto, los límites de ejecución, los ganchos que interceptan algo antes de que salga mal, la verificación antes de dar una tarea por terminada. Addy Osmani lo define de la manera más limpia: «cada pieza de código, configuración y lógica de ejecución que no es el modelo».

Conviene separar tres capas que suelen confundirse:

• Ingeniería de prompt: cómo se le pide algo. La más superficial.
• Ingeniería de contexto: qué información entra en la ventana, cuándo y en qué orden.
• Ingeniería de arnés: todo lo anterior, más las herramientas, los límites y el bucle de ejecución.

El prompt es un subconjunto del contexto, y el contexto es un subconjunto del arnés. Discutir «prompting» cuando el problema está en el arnés es como cambiar el texto de un cartel cuando el problema es que no hay ruta.

Y conviene desarmar de entrada la objeción más común: que el arnés es burocracia. Burocracia es un trámite que existe para proteger a quien lo escribió. Un arnés es lo contrario: código que se ejecuta, que se puede borrar, y cuyo costo se puede medir. Si un componente no cambia ningún resultado, se saca. La diferencia entre un arnés y una regla de estilo es que el arnés se puede probar.

Anthropic publicó el experimento más citado sobre esto. Le dieron el mismo objetivo a dos configuraciones: un agente solo, y un arnés completo con tres roles —planificador, generador y evaluador— trabajando en bucle.

El agente solo terminó en 20 minutos y 9 dólares. El arnés completo tardó 6 horas y costó 200 dólares. La conclusión de Anthropic fue directa: «el arnés fue más de 20 veces más caro, pero la diferencia en la calidad del resultado era inmediatamente evidente».

Hay un detalle que suele omitirse: ese arnés después se afinó y bajó a 3 horas 50 minutos y 124,70 dólares. El arnés no es un costo fijo que se acepta: es un diseño que se ajusta. Y la frase que mejor resume por qué existe está en el mismo trabajo: «cada componente de un arnés codifica una suposición sobre lo que el modelo no puede hacer por sí solo».

Eso es lo que la primera escuela no quiere aceptar. Un arnés es un conjunto de suposiciones explícitas. Y las suposiciones explícitas se pueden discutir, medir y corregir. Las implícitas, no.

Hay una resistencia particular entre quienes trabajan con modelos de Anthropic, y tiene una lógica interna que conviene reconocer antes de refutarla.

Los modelos Claude están entrenados para ser agénticos: sostienen tareas largas, usan herramientas, se autocorrigen. Cuanto mejor es el modelo, más fácil es concluir que la estructura sobra —«este ya se arregla solo»—. La resistencia al arnés es, en el fondo, una forma de respeto por el modelo.

El problema es que Anthropic dice lo contrario, con sus propios datos. En Harnessing Claude's intelligence, Lance Martin ordena la práctica en tres patrones, y el primero es engañoso si se lee rápido: apoyarse en lo que Claude ya sabe. El ejemplo que da es Claude 3.5 Sonnet resolviendo 49% en SWE-bench Verified con solo dos herramientas: bash y edición de texto. Un arnés mínimo, pero un arnés al fin.

El segundo patrón es el que importa acá: adelgazar el arnés, no eliminarlo. Dejar que el propio modelo filtre las salidas de las herramientas subió BrowseComp de 45,3% a 61,6% con Opus 4.6. La compactación de contexto dejó a Sonnet 4.5 plano en 43%, mientras que Opus 4.6 llegó a 84%: la misma estrategia rinde distinto según qué tan bien la sostenga el modelo. Y una carpeta de memoria fuera de la ventana de contexto llevó un benchmark de 60,4% a 67,2%.

Ninguno de esos cambios toca el modelo. Todos son arnés.

El tercer patrón es el que casi nadie quiere escuchar: fijar límites. La API de Claude es sin estado: el modelo no ve el historial de la conversación si no se lo damos. No es una limitación a lamentar; es una frontera del sistema, y el arnés existe para administrarla.

Si la resistencia al arnés tuviera un solo argumento, alcanzaría con los datos de arriba. Pero tiene cinco, y conviene responderlos en el orden en que aparecen.

• «El modelo ya es lo bastante bueno.» Es cierto, y no cambia nada. La pregunta no es si el modelo es bueno, sino si el sistema alrededor tolera que falle una vez de cada veinte. Un modelo excelente en una tarea suelta sigue siendo un modelo que se equivoca dentro de una cadena. El arnés no existe porque el modelo sea malo: existe porque es finito.
• «Es fricción, me hace más lento.» Al principio, sí: escribirlo cuesta. Lo que se gana no es velocidad por tarea, es que la tarea no haya que rehacerla. El arnés no se paga en el primer paso: se paga en el paso veinte.
• «Prefiero revisar yo.» Revisar funciona mientras el volumen lo permita. La revisión humana no escala con la cantidad de trabajo que el modelo produce, y es justo ahí donde se cae: se revisa bien lo primero y se aprueba por confianza lo último. Un gancho no se cansa a las seis de la tarde.
• «El arnés me limita.» Un arnés mal diseñado, sí. Por eso el punto de entrada es el arnés más chico posible. La restricción correcta no reduce el espacio de soluciones: saca del camino las que ya sabés que no querés.
• «A mí me funciona sin nada de eso.» Probablemente sea cierto. El problema es que hoy no tenés cómo saberlo, y esa es exactamente la brecha que mide el experimento que viene.

Ninguna de las cinco objeciones es tonta, y cuatro de las cinco se caen con el mismo argumento: sin arnés no hay forma de distinguir «me funciona» de «creo que me funciona».

Si el arnés fuera solo un lujo de laboratorio, alcanzaría con los benchmarks. Pero hay un experimento de campo que incomoda a los dos bandos.

METR hizo un ensayo aleatorizado con 16 desarrolladores experimentados sobre repositorios open source que conocían bien: 246 tareas en total. El resultado fue que, con IA, tardaron 19% más. No menos: más.

Lo interesante no es el 19%. Es la brecha. Antes del estudio, esos mismos desarrolladores esperaban ser 24% más rápidos. Después del estudio —habiendo visto sus propios números— seguían creyendo que la IA los había hecho 20% más rápidos.

Ahí está el punto. La percepción de productividad y la productividad no son la misma cosa, y sin arnés no hay forma de distinguirlas: no queda registro de cuántas veces el modelo rehízo algo que ya estaba, ni de cuánto costó cada corrección. El arnés es, antes que nada, el instrumento que hace visible lo que el entusiasmo esconde.

Corresponde el matiz, y METR lo pone por escrito: son 16 desarrolladores en repositorios grandes y maduros —el terreno donde la IA rinde peor—, y los autores explícitamente no afirman que la IA no acelere a la mayoría de los desarrolladores. Un seguimiento de 2026 encontró aceleración en el mismo escenario, pero el propio METR lo calificó de señal débil por sesgos de selección.

La lectura honesta no es «la IA no sirve». Es: el efecto es demasiado dependiente del arnés como para confiar en la intuición. Y si la intuición no sirve como instrumento de medida, lo único que queda es el instrumento que sí mide.

El experimento más limpio lo publicó LangChain. Fijaron el modelo —no lo cambiaron en ningún momento— y tocaron tres cosas: prompt de sistema, herramientas y middleware.

En Terminal Bench 2.0, su agente pasó de 52,8% a 66,5%: 13,7 puntos que salieron enteros del arnés. Eso lo llevó de afuera del Top 30 al Top 5 del ranking. Lo que encontraron es más útil que el número:

• Verificación obligatoria. El error más común no era escribir mal una solución: era escribirla, releerla y detenerse sin probarla. Agregaron un middleware que intercepta al agente antes de que termine y lo fuerza a verificar contra la especificación original, no contra su propio código.
• Inyección de contexto. Mapear directorios, herramientas y entorno por adelantado, en vez de dejar que el agente los descubra a los golpes.
• Presupuesto de tiempo. Los modelos son malos estimando cuánto llevan. Un aviso de tiempo restante los empuja a cerrar y verificar.
• Detección de bucles. Contar ediciones por archivo y avisar «estás en la décima variante del mismo enfoque roto».

Ninguna de esas cuatro cosas es una capacidad nueva del modelo. Las cuatro son decisiones de diseño del sistema que lo contiene. Y las cuatro son copiables hoy, en cualquier equipo, sin cambiar de proveedor.

El propio LangChain aporta además el contraejemplo que evita vender humo: ese arnés afinado para un modelo dio 59,6% con Claude Opus 4.6 —peor que con el modelo original—, porque los ajustes eran parches para las limitaciones de ese modelo. El arnés no se copia; se diseña. Es la prueba más fuerte de que el arnés es el objeto de trabajo, y no un accesorio comprado.

La respuesta corta es: el arnés más chico que mantenga al agente en una trayectoria recuperable.

Ese criterio ordena todo lo demás. No se trata de agregar capas hasta que algo funcione, sino de mover cada restricción al lugar donde no dependa de la buena voluntad del modelo:

• Lo que debe cumplirse siempre va al mecanismo, no a la prosa. Pedirlo en el prompt es una sugerencia; un gancho que intercepta la salida es una regla.
• Cada componente paga su costo. Cada guardarraíl es una suposición sobre una limitación actual, y las limitaciones cambian de versión en versión. Los parches viejos se vuelven lastre.
• La verificación se diseña aparte. «Terminado» no puede ser lo que el agente cree; tiene que ser algo que se comprueba desde afuera.
• La memoria vive fuera de la ventana. Lo que importa se persiste: el contexto es un recurso que se agota, no un depósito.
• El arnés se versiona. Si las reglas no están escritas en un solo lugar y con dueño, no hay arnés: hay costumbre.

En draweb escribimos las reglas como mecanismo, en un solo lugar, y las espejamos a cada copiloto que usa el equipo. No por prolijidad: por la misma razón que en LangChain, un cambio de arnés que no está escrito no se puede medir, y lo que no se mide se atribuye al modelo.

La confiabilidad se compone igual que el interés: multiplicando. Veinte pasos al 95% dan 36%. La única manera de sostener una cadena larga no es pedirle al modelo que sea perfecto, sino diseñar el sistema para que un paso malo no arruine los otros diecinueve.

El obstáculo real no es la falta de convicción: es que «armá un arnés» suena a proyecto. No lo es. Se empieza por el componente que más devuelve y menos cuesta, y se agrega el siguiente solo cuando el anterior ya no alcanza.

Un orden posible, de menor a mayor esfuerzo:

1. Escribí las reglas en un solo lugar. Un archivo, con dueño, versionado. Si viven repartidas entre la cabeza de cada uno y prompts sueltos, no hay arnés: hay costumbre.
2. Hacé que se cumplan solas. Mové lo que no se negocia del prompt al mecanismo: un chequeo que corre antes de commitear, un validador de esquema, un límite de alcance en las herramientas.
3. Exigí verificación externa. Que «terminado» no sea lo que el agente cree. El error más común que encontró LangChain no era resolver mal: era resolver, releer y no probar.
4. Poné el contexto donde corresponde. Lo que el agente necesita saber en cada paso, en el paso; no todo al principio. El contexto es un recurso que se agota.
5. Persistí la memoria fuera de la ventana. Lo que importa sobrevive a la sesión; el resto se descarta sin culpa.
6. Medí antes de agregar. Cada guardarraíl nuevo es una suposición sobre una limitación actual. Si no mueve ningún número, es lastre.

Nada de esto exige cambiar de modelo, comprar nada, ni reescribir el producto. Exige una tarde de decisiones explícitas, y la disciplina de mantenerlas en un solo lugar.

La discusión de fondo nunca fue si el modelo es bueno. Fue si estamos dispuestos a escribir lo que esperamos de él. Un arnés es, literalmente, eso: las suposiciones que ya tenés, puestas donde se pueden ejecutar, medir y discutir con otro.

Delegar todo al criterio del modelo es delegar también la responsabilidad de lo que salga. La alternativa no es desconfiar del modelo: es hacerse cargo del sistema que lo contiene. Y esa decisión no la toma el modelo.

• Anthropic Engineering — Harness design for long-running application development. El experimento planner / generator / evaluator: 20 min y u$s 9 contra 6 h y u$s 200; el arnés afinado a 3 h 50 min y u$s 124,70. anthropic.com/engineering/harness-design-long-running-apps
• Anthropic Engineering — Effective context engineering for AI agents. Por qué el contexto es un recurso finito: «context rot», presupuesto de atención y las relaciones n² entre tokens. anthropic.com/engineering/effective-context-engineering-for-ai-agents
• Lance Martin / Claude — Harnessing Claude's intelligence. Los tres patrones: apoyarse en lo que el modelo sabe, adelgazar el arnés y fijar límites. 49% en SWE-bench Verified con bash + editor; BrowseComp de 45,3% a 61,6%; memoria de 60,4% a 67,2%. claude.com/blog/harnessing-claudes-intelligence
• METR — Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. 16 desarrolladores, 246 tareas, 19% más lento, con la brecha entre lo esperado (+24%) y lo percibido (+20%). metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study
• LangChain — Improving Deep Agents with harness engineering. Terminal Bench 2.0 de 52,8% a 66,5% con el modelo fijo; y el contraejemplo de 59,6% con otro modelo. langchain.com/blog/improving-deep-agents-with-harness-engineering
• Addy Osmani — Agent Harness Engineering. La definición operativa del arnés y la tesis de que un modelo decente con un gran arnés le gana a un gran modelo con un arnés malo. addyosmani.com/blog/agent-harness-engineering