La herramienta que prometía riendas no tenía riendas propias — la frontera entre arnés y Reins

Image: AI generated

El 31 de marzo de 2026, Anthropic publicó por error los source maps junto con el paquete npm de Claude Code (v2.1.88). Faltaba una línea en .npmignore.¹ Esos 59,8 MB de source maps dejaron al descubierto unos 512.000 líneas de TypeScript sin ofuscar distribuidas en cerca de 1.900 archivos. Anthropic declaró que no se trataba de una brecha de seguridad sino de un error de empaquetado en el proceso de despliegue, un error humano, y recomendó a los usuarios fijar la versión a v2.1.87.

En el código que la gente pudo leer, una sola función del archivo print.ts tenía 3.167 líneas.²

El agente de código más vendido del mundo, la herramienta que nos publicita que tomemos las riendas del código — no había puesto riendas en sí misma.

No traigo esta ironía para burlarme. Todo lo contrario. Este incidente es la respuesta más nítida que he encontrado a una pregunta que durante mucho tiempo no supe responder con claridad.

“Reins Engineering, ¿no es al final harness engineering?”

Es una buena pregunta. Una pregunta afilada. Los dos se parecen. Ambos son algo externo al modelo. Ambos son estructuras no-modelo construidas en código. Ambos impiden que el agente haga cosas disparatadas. Por eso la sospecha de que “las riendas son solo una parte del arreo” es legítima.

Durante un tiempo no supe responderla con claridad. Cuando encontré la respuesta, esa misma respuesta resultó ser la descripción más precisa de qué es Reins. Y el incidente del leak la prueba en la práctica.

Primero: los dos no se oponen

Imagina el arreo de un caballo. La silla que va sobre el lomo, la brida, y las dos tiras que van desde la brida hasta las manos del jinete — las riendas.

Las riendas están enganchadas a la brida. No están fuera del arreo sino montadas como una pieza dentro de él. Por eso, si la pregunta es “¿arnés y Reins son claramente distintos, se oponen?”, la respuesta es no. Son partes de un mismo equipo.

Hay que empezar desde aquí. El eslogan habitual — “el arnés es la valla, las riendas son el control” — los enfrenta. En el momento en que los enfrentas, pierdes. Un solo argumento basta para derrumbarlo: “las puertas de verificación también son parte del arnés”. Y tiene razón. La CI, el typechecking, la test suite son andamiaje externo al modelo, y eso es exactamente lo que el arnés incluye.

Entonces hay que cambiar la pregunta. No si se oponen, sino dónde se separan.

¿Dónde se hace posible Reins? — tres capas de bucle

Antes de encontrar el punto de separación, hay que ver dónde se vuelve posible Reins por primera vez. Visto en capas de bucle, son tres.

① Bucle de chat       LLM → humano → LLM              Todo probabilístico. Reins imposible.
② Bucle agéntico      LLM → ejecución → observación → LLM    La ejecución toca tierra determinista → Reins posible.
③ Bucle Reins         ② + verificadores diseñados + trinquete   Reins completo.

En el bucle de chat no hay donde colocar la brida. Ni siquiera hemos montado el caballo. Mientras el LLM responde, el humano lee y vuelve a lanzar al LLM, ningún punto del ciclo es determinista. No hay bocado donde enganchar la señal.

El bucle agéntico coloca la silla. En el momento en que la ejecución entra — el compilador corre, los tests fallan, los archivos se escriben — el bucle pisa tierra determinista por primera vez. Por fin hay algo que agarrar.

Esa es la razón exacta por la que Claude Code triunfó de forma arrolladora. Al incorporar Bash, I/O de archivos y ejecución de tests — puertas deterministas dentro del bucle, casi por accidente — ya tenía un “Reins parcial” que no existía en la era del chat.

No es solo mi argumento. El HAL (Holistic Agent Leaderboard) de Princeton demostró con más de 21.000 ejecuciones agénticas que, con el mismo modelo pero cambiando solo el scaffold, la precisión sube o baja decenas de puntos porcentuales.³ El modelo fijo; lo que cambió fue la estructura que lo envuelve. Addy Osmani lo resume en una línea: “modelo decente + arnés excelente > modelo excelente + arnés malo.” También observó que el mismo Opus obtiene puntuaciones más altas dentro de un arnés personalizado que dentro de Claude Code.⁴

Hasta aquí llega el territorio que la industria llama “harness engineering”. Es un descubrimiento correcto. Y es exactamente el lugar donde se confunde con Reins, porque los dos producen resultados desde fuera del modelo.

Pero ② es solo la mitad accidental de Reins. Reins Engineering consiste en completar intencionalmente esa mitad: tomar las puertas que entraron por accidente, convertirlas en verificadores diseñados con trinquete y separación decisión/implementación, y elevar ② a ③. El discurso del arnés demuestra Reins, pero no lo sustituye.

Los tres ejes

Dos personas trabajan con el mismo caballo.

Una fabrica el arreo. Las dimensiones de la silla, la resistencia de la brida, la forma del bocado. Esto sirve igual para cualquier caballo, cualquier viaje. Una vez bien hecho, el mismo arreo sirve tanto para ir al norte como al sur. Quien lo fabrica es el artesano del arreo — no quien va a montar.

La otra persona lleva las riendas. Sabe este viaje. En qué cruce girar a la izquierda, cuál es el destino, cuándo se puede decir “hemos llegado”. El hilo que sostiene está enganchado al mismo arreo, pero las señales que envía cambian con cada viaje. Quien envía las señales no es el artesano sino el jinete.

Aquí están los tres ejes.

• Función. El arnés contiene — un límite que impide. Las riendas guían — hacia dónde ir y cuándo terminar.
• Vida útil. El arnés se fabrica una vez y se reutiliza en todas las tareas. Las riendas se diseñan de nuevo en cada tarea.
• Autoría. El arnés lo despacha el proveedor. Las riendas las escribe el arquitecto.

El bucle de Claude Code es idéntico sin importar cuál sea mi proyecto. Eso es el arnés. Lo fabricó Anthropic y es igual para todos los usuarios. Pero la definición de completado — “desalojo del inquilino = fotos de cinco ubicaciones designadas” — la escribí yo, para este dominio, directamente. Eso no está en ningún arnés. Eso son las riendas.

La dependencia fluye en una sola dirección

Si los dos fueran lo mismo, no podría separarse uno sin el otro. Separémoslos.

Arnés sin riendas. El agente funciona. No se detiene y sigue funcionando. Pero se pierde. Vaga por un campo sin marcador de objetivo ni veredicto de completado, hasta que decide “supongo que ya es suficiente” y para. Ya conocemos esto. Lo llamamos vibe coding.

Riendas sin arnés. Esto ni siquiera es posible. Llevas las riendas pero no hay brida donde engancharlas. No hay donde enviar la señal. Solo sostienes una cuerda en el aire.

La dependencia es unidireccional. Las riendas necesitan el arnés, pero el arnés no necesita las riendas. El arnés funciona sin riendas — solo funciona mal. Esta asimetría refuta limpiamente el argumento de que “los dos son lo mismo”. Si fueran lo mismo, separar uno debería derrumbar ambos, pero el arnés corre solo.

El único punto de superposición

¿Entonces no hay ninguna superposición real? La hay. Exactamente un punto.

Las puertas de verificación que se ejecutan. La CI corre dentro del bucle agéntico. Esa superficie de ejecución pertenece a los dos — es parte del arnés y también lo que las riendas enganchan. Ahí es donde nace la pregunta “¿no es eso el arnés?”. Sí, en ese punto exacto los dos apuntan a lo mismo.

Pero fuera de ahí se separan.

   Solo arnés              Intersección           Solo riendas
─────────────────   ─────────────────   ─────────────────
 Sandbox · permisos   Puerta de verif.    Definición de completado
 Cableado de tools    (checks ejecutados) Diseño anti-cheese
 Gestión de contexto                      Análisis proxy↔objetivo
 (contención sin direc.)  (superficie ejec.)  (intención sin sustrato)

El arnés tiene su propia contención sin dirección — el sandbox no dice hacia dónde ir, solo impide salir. Las riendas tienen su propia intención sin sustrato de ejecución — la definición de “qué es completado” existe antes de que haya una puerta que la ejecute. Ninguno contiene al otro por completo. Los dos se intersectan. No se contienen.

Por qué la pregunta sobre subconjuntos es incorrecta

“Entonces, ¿las riendas son un subconjunto del arnés?”

Para ser subconjunto, los dos tendrían que medirse con la misma vara. Pero el arnés se define por quién lo despacha y cuánto se reutiliza (eje del sustrato), mientras que las riendas se definen por qué hacen con la trayectoria (eje de la función). Los ejes son distintos.

Es como preguntar “¿el rojo es un subconjunto de lo pesado?”. Hay cosas rojas y pesadas (= puertas que se ejecutan), pero el color no puede contenerse en el peso. Las varas son distintas. La relación de subconjunto es en sí misma un error categorial aquí.

La relación correcta es esta: las riendas presuponen el arnés, pero no están contenidas en él. Una capa que se apoya encima no es una parte que se aloja adentro. Lo apoyado se extiende más allá del sustrato.

El punto de separación real — el cheese

Hasta aquí ha sido una conversación sobre estructura. Pero el lugar donde Reins se separa decisivamente del discurso del arnés es otro. El cheese (en español: “queso” — término de diseño de juegos, mantenemos la palabra inglesa).

Los diseñadores de juegos lo saben. “Mata a 10 ratones” es una misión tristemente célebre. Hay una brecha entre lo que la puerta verifica (10 ratones muertos) y lo que el diseñador realmente quería (que el jugador experimente el contenido), y el jugador explota esa brecha. A eso se le llama cheese. Es exactamente el mismo fenómeno que la investigación de seguridad en IA denomina “specification gaming” (especificación gaming) — un agente de carreras de barcos que en lugar de cruzar la meta da vueltas recogiendo ítems de puntos, o un agente de Tetris que pausa el juego indefinidamente para no perder nunca.⁵

Mi propia puerta de arrendamiento también puede ser “cheeseada”. Cinco fotos verifican que “las fotos existen”, no que “el desalojo terminó bien”. ¿Y si el encargado solo fotografió paredes limpias? La puerta pasa. En el momento en que la medición se convierte en el objetivo, la medición se rompe — es la ley de Goodhart.⁶

Aquí está el núcleo. El arnés solo puede responder “¿pasó?” — si el test está en verde, si los tipos cuadran, si el esquema no está roto. Hasta ahí llega. Pero "¿ese pase captura el propósito?" es algo que el arnés nunca podrá responder. Porque qué es cheese solo se puede definir conociendo el propósito del dominio. Por qué las fotos de solo paredes limpias son un fraude, por qué las reglas se cumplieron pero el propósito se cerró solo en un 90% — eso solo lo sabe quien conoce para qué sirve este trabajo.

Esa persona es el jinete. Quien lleva las riendas.

Diseñar puertas que no puedan ser cheeseadas — anticipar los puntos donde el proxy no sigue al propósito — es inherentemente distinto en cada tarea, carga conocimiento de dominio y lo escribe el operador. Un arnés task-agnostic no puede dar esto. No es que no quiera: es que, al no conocer el dominio, sencillamente no puede tratarlo.

Aquí está el territorio propio de Reins Engineering que no existe en los discursos de harness engineering y agentic engineering. Ellos hablan de cómo fabricar mejor el arreo. Reins habla de por qué puerta enviar este viaje, sin que se rompa.

Entonces, de vuelta al incidente del leak

Volvamos a la ironía del principio. Ahora se ve por qué es evidencia y no burla.

El caballo era brillante. Opus es poder probabilístico puro. La silla también funcionaba — Claude Code es el mejor arreo del mundo y las cifras del HAL lo prueban. Pero el propio código que ese arreo construyó derivó exactamente hacia el modo de fallo previsto. Una función de 3.167 líneas. El muro de los 200 endpoints materializado en código. Y el propio leak fue la omisión de una línea en .npmignore — señal de que no había ninguna puerta sobre los artefactos de despliegue.

La empresa que fabrica el mejor arreo del mundo no lo puso en su propio establo.

Esto no es la antítesis; es la evidencia decisiva de la tesis. Las riendas no son un atributo que el modelo o el agente tiene, sino una disciplina que se aplica. Que el agente sea brillante y que el código que ese agente produce esté bajo riendas son dos cosas completamente distintas. Un modelo más grande no es la respuesta. Un arnés mejor tampoco. La respuesta es la disciplina de: sostener las riendas, definir directamente el completado de este viaje, diseñar puertas que impidan el cheese.

Entonces

El arnés hace que el caballo corra. Las riendas determinan por qué puerta enviarlo. El arnés se coloca una vez; las riendas se sostienen en cada momento. El arnés lo despacha el artesano; las riendas las tiene el jinete en la mano.

Los dos no se oponen. Son piezas distintas del mismo arreo. Pero distintas. Sin arnés, las riendas no pueden existir; sin riendas, el arnés se pierde. Y quien sabe si este trabajo terminó bien es siempre la mano que lleva las riendas.

La próxima vez que alguien pregunte “¿no es eso al final el arnés?”, responde así:

“El arnés lo despacha el proveedor; las riendas las diseño yo para este quest. Sin arnés no hay riendas, pero sin riendas el arnés solo vaga. Incluso la herramienta que nos dio las riendas no las tenía en su propio código — porque las riendas no se tienen: se aplican.”

Artículos relacionados

• IA con riendas: Reins Engineering — El origen del reframe puerta=riendas
• ¿Quién define “completado”? — Puertas anti-cheese, el taski como diseño de quest
• Por qué los agentes de código funcionan y por qué se rompen — “La generación puede ser probabilística; la verificación debe ser determinista”
• Por qué tu agente nunca para — Un sistema que puede detenerse = un sistema con completado definido
• Yongol: el muro de los 200 endpoints — La especificación que escribe el operador = las riendas en la práctica

Lecturas complementarias

Textos externos que profundizan — o abordan desde otro ángulo — la frontera que trata este artículo: arnés y riendas, cómo detenerse, especificaciones que pueden ser explotadas.

• How Coding Agents Work — Simon Willison — “Los agentes de código son arneses que envuelven un LLM.” La definición canónica del arnés; lectura recomendada antes de entrar al artículo.
• Agent Harness Engineering — Addy Osmani — Formaliza el arnés como disciplina de ingeniería. Trata las condiciones de terminación con el concepto de “sprint contract” — el punto de mayor solapamiento con este artículo.
• Reward Hacking in Reinforcement Learning — Lilian Weng — La columna vertebral teórica de la ley de Goodhart y el specification gaming. Explica desde la perspectiva de RL y RLHF por qué ocurre el cheese.
• Water Finds a Crack — Soren Johnson — “Dada la oportunidad, el jugador optimiza el juego hasta vaciarlo de contenido.” El arquetipo humano del reward hacking; un clásico del diseño de juegos.
• Effective Harnesses for Long-Running Agents — Anthropic — El primer afectado trata el fallo de “declarar completado sin haberlo terminado”. Condiciones de terminación y verificación determinista en un solo artículo.