Auditoría de arnés IA: por qué el arnés importa más que el modelo

Llevo meses dándole a la misma tecla con clientes y conmigo mismo: el modelo no es el problema. Cambias de Opus a Sonnet, de Sonnet a otro, y la sensación de “esto a veces funciona y a veces no” sigue ahí. La lotería no la rompe un modelo mejor. La rompe el arnés: el conjunto de archivos, reglas, scripts y subagentes que viven en tu repo y obligan al modelo a ir en la dirección correcta.

Hace poco audité mi propio arnés con una metodología que llamo harness-audit. Lo que encontré me cambió la forma de trabajar —y, muy concretamente, me bajó la factura de tokens. Este es el resumen para emprendedores: qué es un arnés, por qué importa más que el modelo, y cómo medir el tuyo.

El punto de partida El modelo es el caballo, el arnés son las riendas

Un LLM solo es un caballo potente pero alocado: genera miles de líneas, toma decisiones impredecibles, termina en sitios donde no querías. El arnés son las riendas. Sin arnés, cada sesión es una lotería; con arnés, es un proceso repetible.

Esto tiene una consecuencia comercial que casi nadie nombra:

El modelo es un commodity que cambia cada tres meses. El arnés que construyes encima es tuyo y permanece.

— el principio que organiza todo andrami

Cuando aterriza el siguiente modelo, le cambias el cerebro a tu sistema en una tarde. Tus procesos, tus reglas, tu rastro de auditoría siguen intactos. Por eso en el enfoque de andrami la pregunta nunca es “¿qué IA elegimos?”, sino “¿qué infraestructura montamos para no depender de ninguna?”.

Por qué no basta con prompts El contexto se degrada mucho antes de llenarse

La intuición popular es: “con 1 millón de tokens de contexto, ya estamos tranquilos”. Falso. La calidad empieza a degradarse cerca del 20% de uso del contexto y se vuelve crítica entre el 40 y el 48%. Llenar la ventana no te hace más listo: te hace más caro y más errático.

Y hay otra trampa, la del “más es mejor”. Cuando Vercel rediseñó su agente D0, quitó herramientas en vez de añadir: pasó de 16 herramientas a básicamente Bash + el sistema de ficheros. Resultado: 3× más rápido, 47% menos tokens, y la tasa de éxito subió del 80% al 100%.

La metodología Los cuatro pilares de un arnés sano

harness-audit evalúa cuatro cosas. No son teoría: cada una se traduce en archivos concretos del repo.

1. Arnés en código. Un punto de entrada portable (AGENTS.md, ≤ 200 líneas), un script de preflight que valida antes de cada commit, convenciones de memoria. Si tu conocimiento vive en la cabeza de una persona y no en el repo, no tienes arnés.
2. Separación de roles (multi-agente). Un implementador que escribe y un revisor que audita —y que es independiente: recibe el resultado, nunca el razonamiento del que lo escribió. Esa independencia es la clave del siguiente número.
3. Verificación automática. Lint, tipos, tests que fallan cuando el código se rompe (no tests de teatro). El agente no termina porque diga que terminó; termina cuando el arnés pudo validar que terminó.
4. Loop design. Una rúbrica ejecutable, condiciones de parada explícitas y una memoria que madura. Es el pilar más reciente y el que más rendimiento da.

El dato que justifica al revisor independiente

Cuando un modelo se revisa a sí mismo, acierta el 62% —y un 28% de sus aprobaciones de “código correcto” están en realidad mal. Casi 1 de cada 3. Cuando la revisión la hace un sub-agente independiente, el acierto sube al 89% y los falsos positivos caen al 7%.

27 puntos de precisión no salen de un modelo más grande. Salen de separar quien escribe de quien verifica.

El cambio de paradigma De escribir prompts a diseñar loops

El viejo flujo era: humano escribe un prompt detallado → modelo responde → humano evalúa → repite. El nuevo es distinto:

Diseñas una meta, una rúbrica, un verificador y una memoria. El modelo corre solo. El entorno le da feedback (tests, comandos, métricas). El modelo se auto-corrige. Repite hasta que la rúbrica converge o salta una condición de parada.

La habilidad ya no es escribir el prompt perfecto. Es diseñar el loop. Y aquí hay un riesgo que conviene decir en voz alta: una rúbrica mala con un modelo excelente produce un loop seguro de sí mismo y equivocado. La rúbrica hace más trabajo que el modelo.

La memoria, además, madura por etapas: de anotar “probé X y no funcionó”, a explicar por qué falló, a marcar hechos como verificados, a destilarlos en reglas generales, y por fin a consultarlas antes de actuar. En las pruebas, los agentes que llegan a esa última etapa —consultar su propia memoria— pasan del 60% al 91% de éxito entre las primeras y las últimas sesiones. Los que se quedan en “anotar fallos” no mejoran nunca.

Lo que me ahorra dinero Cómo el arnés baja la factura de tokens

Aquí está la parte que de verdad le importa a un emprendedor. Un arnés bien diseñado economiza de tres formas, y las he medido en mi propio trabajo:

• Modelo por rol, no un modelo para todo. Reparto el trabajo 10/80/10: el premium —su cerebro, hoy Fable 5— planifica y revisa los extremos donde una decisión lo cambia todo; el workhorse, rápido y barato (Opus 4.8), se traga el 80% de ejecución; y un modelo mínimo (Haiku) corre los chequeos mecánicos, el preflight. No pago cerebro caro para teclear boilerplate. Cuando cambien los modelos, cambio el reparto; el arnés sigue igual.

• Menos vueltas en falso. Cada sesión-lotería que termina en “casi, pero no” se paga en tokens. La verificación automática corta esas vueltas: el loop no avanza con código roto, así que no quemo contexto persiguiendo un error que un test habría cazado gratis.
• Contexto disciplinado. Sesiones cortas y memoria consultable en vez de arrastrar 200k tokens degradados. Menos relleno, menos coste, mejor calidad.

Qué hacer con esto Tu código IA: ¿arnés o lotería?

Si tu equipo ya usa Claude Code, Cursor o similar en producción y la sensación es de inconsistencia —a veces brillante, a veces desastre— el problema casi nunca es el modelo. Es que no hay arnés, o el que hay está inflado y sin verificación.

Lo bueno: es medible. Puedes auditar el tuyo —AGENTS.md (o su ausencia), separación de roles, qué se verifica de verdad, si la memoria se consulta— y salir con un plan de remediación concreto. Eso es exactamente lo que hago en una Radiografía de código IA, y el primer diagnóstico toma pocos minutos.

Los modelos seguirán rotando cada tres meses. El arnés que construyas se queda. Empecemos por saber en qué punto está el tuyo.

Llévatelo El skill harness-audit, abierto

La metodología de este artículo vive como un skill de Claude Code que puedes correr en tu propio repo: audita tu arnés contra los cuatro pilares y te devuelve una rúbrica ejecutable con un plan de remediación. Lo abrí en GitHub — déjame dónde enviártelo y te muestro el enlace para verlo y clonarlo.