Clase 5. IA con riendas — Introducción a Reins Engineering

Consejos clave — Con saber esto, ya puedes dar instrucciones

La limitación de las herramientas de codificación con IA es tener solo cercas (arnés) sin dirección (riendas). Los linters, formateadores y CI dicen “no salgas” pero no “ve en esta dirección.” El código llega a producción “limpio pero incorrecto.”

Principio fundamental: No cambies el modelo — agrega contratos. El mismo modelo se detiene en 40 o completa 527 dependiendo de la estructura de retroalimentación. Esperar un modelo más inteligente es gobierno de personas. Agregar bucles de verificación es estado de derecho.

Verifica ahora mismo:

Al agente: “Limpia el código. No cambies la funcionalidad.”

Después de que la IA termine la refactorización, verifica si las reglas que definiste (escritas en CLAUDE.md) siguen intactas. ¿Cambiaron las rutas de API? ¿Cambiaron los nombres de tablas de DB? ¿Cambió el formato de respuesta?

Con alta probabilidad algo habrá cambiado. La IA “ordena” y trata tus decisiones como detalles de implementación y los sobrescribe. Porque las decisiones están mezcladas dentro del código.

Recuerda los tres pilares de Reins:

• Retroalimentación determinística — No “parece algo raro” sino “line 41: nombre de campo no coincide”
• Bloqueo de trinquete — Bloquear cuando pasa, avanzar
• Separación de decisiones e implementación — Decisiones en SSOT, código es proyección desechable

Si falta cualquiera, la convergencia se rompe.

Prueba rápida

Abre la app de la Clase 1 con Claude Code. Luego pide:

Al agente: “Limpia el código. No cambies la funcionalidad.”

Después de que la IA termine la refactorización, verifica si las reglas definidas en la Clase 1 (escritas en CLAUDE.md) siguen intactas. ¿Cambiaron las rutas de API? ¿Los nombres de tablas de DB? ¿El formato de respuesta?

Con alta probabilidad algo habrá cambiado. La IA “ordena” y trata tus decisiones como detalles de implementación y los sobrescribe. Este es el núcleo de la Clase 5 — sucede porque las decisiones y la implementación están mezcladas dentro del código.

Por qué debes dar instrucciones de esta manera

Repaso de la clase anterior

En la Clase 4 experimentamos yongol de primera mano.

• Separamos las decisiones del código en 10 especificaciones declarativas (SSOT)
• Un operationId atravesó las 10 capas
• 287 reglas detectaron contradicciones entre capas
• Incluso modelos de 4.5B convergieron a 0 errores con retroalimentación de validate

Esta clase da un paso atrás y pregunta. ¿Por qué funciona esto?

yongol es una herramienta. Detrás de la herramienta hay un principio. Entender este principio te permite aplicar el mismo pensamiento incluso en situaciones sin yongol.

Cuatro eras

La codificación con IA ha atravesado cuatro cambios de paradigma. Cada era nació de las limitaciones de la anterior.

1a generación: Ingeniería de prompts — “Solo habla bien”

“Crea una app TODO con React.” “Crea un foro con FastAPI.”

La era de pensar que si escribes buenos prompts la IA construirá bien. Realmente funciona — una vez. El segundo prompt produce un patrón diferente. El tercero rompe el primero.

Limitación: Efímero. Los prompts se desvanecen. La IA no sabe qué decidiste en la siguiente conversación.

2a generación: Ingeniería de contexto — “Solo da buen contexto”

Escribe CLAUDE.md. Escribe requisitos.md. Escribe progreso.md. La IA lee estos archivos al inicio de cada conversación y recuerda decisiones previas.

Lo que aprendimos en la Clase 1 es esta etapa. Si los prompts son efímeros, los archivos son permanentes. Externalizar las decisiones mantiene el contexto entre sesiones.

Limitación: Evaporación. Incluso con contexto, la IA olvida las partes iniciales cuando las conversaciones se alargan. Si metes el contexto de 200 endpoints de golpe, la información intermedia se pierde. Se da el contexto pero no se obliga a seguirlo.

3a generación: Ingeniería de arnés — “Solo enciérrala en estructura”

Linters, formateadores, CI/CD, estructura de proyecto, guías de codificación. Cercas que impiden al agente salir.

Lo que aprendimos en la Clase 3 es parte de esta etapa. Tests Hurl, Git, CI/CD — son cercas. CI rechaza si la IA rompe funcionalidades existentes.

Limitación: Sin dirección. Las cercas dicen “no salgas” pero no “ve en esta dirección.” Lo que el agente haga dentro de la cerca — sobrescribir lógica existente, cambiar tipos, saltar transiciones de estado — los linters pasan. Los formateadores pasan. CI pasa. El código llega a producción “limpio pero incorrecto.”

4a generación: Reins Engineering — “Dale dirección”

No cercas sino riendas.

Lo que experimentamos en la Clase 4 es esta etapa. yongol validate no dice “no salgas” sino “aquí hay una desalineación, corrígelo así.” Retroalimentación con dirección. Hechos determinísticos. Contratos que la IA no tiene más remedio que seguir.

La diferencia entre cercas y riendas

Para entender intuitivamente esta diferencia, imagina montar a caballo.

Arnés (cerca): Construye una cerca alrededor del rancho. El caballo deambula libremente dentro. Puede pastar, dar vueltas en círculos o dormir. Lo único garantizado es que no puede salir. Pero no hay garantía de llegar al destino.

Riendas: Monta el caballo y toma las riendas. Tira a la derecha, va a la derecha. Tira a la izquierda, va a la izquierda. El caballo corre libremente — pero tú controlas la dirección. Llegas al destino.

La mayoría de las herramientas de codificación con IA de la industria hoy están en la etapa de cerca. Linters, formateadores, CI/CD, guías de codificación — todas dicen “hazlo dentro de este límite.” El agente da vueltas dentro de la cerca. El código está limpio, pero nadie sabe si va en la dirección prevista.

Reins Engineering dice “ve en esta dirección.” Cuando validate dice “desalineación aquí”, la IA corrige en esa dirección. Las riendas llegan al destino sin restringir la libertad.

La investigación muestra que la complejidad del código aumenta permanentemente un 41% tras la adopción de herramientas de codificación con IA¹, y la estabilidad de entrega disminuye a medida que crece la adopción de IA². Evidencia de que solo las cercas no son suficientes.

Los tres pilares de Reins

Reins Engineering se compone de tres principios.

Pilar 1: Retroalimentación determinística

Dale a la IA hechos, no opiniones.

Mala retroalimentación: “Esto parece algo raro” Buena retroalimentación: “line 41: field name mismatch, expected ‘user_id’, got ‘userId’”

¿Cuál es la diferencia? La mala retroalimentación deja margen para que la IA adule. “Creo que se ve bien, es un mejor patrón.” La buena retroalimentación no tiene margen para adulación. Los números y las ubicaciones no son emociones.

El experimento de ordenar 1,000 palabras lo confirmó cuantitativamente:

Lo que yongol validate hace en la Clase 4 es exactamente esto. “El CancelReservation de SSaC llama a Reservation.SoftDelete, pero no hay método SoftDelete en las consultas sqlc.” No es opinión. Es hecho. La única respuesta posible de la IA es “lo corrijo.”

La investigación muestra que la instrucción procedimental “haz TDD” en realidad empeora la regresión, mientras que proporcionar archivos de prueba específicos como contexto reduce la regresión en un 70%³. Las instrucciones no previenen la regresión — los hechos sí.

Pilar 2: Bloqueo de trinquete (Ratchet Pattern)

Bloquear cuando la verificación pasa.

Piensa en una llave de trinquete. Los dientes enganchan en una sola dirección. Giras y avanza; sueltas y se detiene pero no retrocede. Ratchet Pattern aplica este mecanismo al control de agentes.

Item 1: Verificación mecánica → PASS → Bloqueo → Siguiente
Item 2: Verificación mecánica → FAIL → Reintentar (con retroalimentación)
Item 2: Verificación mecánica → PASS → Bloqueo → Siguiente
...
Item N: PASS → Completado. Detener.

Los números muestran la diferencia real:

Agente autónomo:  40 / 527  (7.6%)  — El agente declara "listo"
Trinquete CLI:   527 / 527 (100%)  — La máquina declara "quedan 487"

Mismo modelo. Mismo proyecto. La diferencia es quién decide “listo.”

Pilar 3: Separación de decisiones e implementación

Lo que experimentamos directamente en la Clase 4. Cuando las decisiones se sacan del código, la IA no puede confundir decisiones con detalles. La supervivencia de las decisiones se vuelve independiente del tamaño del modelo.

Cómo funcionan los tres pilares juntos

Los tres pilares no funcionan por separado. Funcionan juntos.

La IA edita SSOT                      ← Pilar 3: Separación de decisiones e implementación
  ↓
yongol validate devuelve errores       ← Pilar 1: Retroalimentación determinística
  ↓
La IA corrige errores
  ↓
validate pasa → bloqueo trinquete      ← Pilar 2: Bloqueo de trinquete
  ↓
A la siguiente funcionalidad

Si falta alguno, la convergencia no se garantiza.

Symbolic Feedback Loop — Los rieles más que el tren

Organizando todo hasta ahora en una estructura:

LLM genera → Herramienta determinística juzga → Resultado retroalimentado al LLM → Repetir

Esto se llama Symbolic Feedback Loop.

¿Por qué “Symbolic”? Porque la retroalimentación consiste en símbolos específicos como números, nombres de archivo, números de línea. No “parece algo raro” sino “línea 41, debería ser user_id pero dice userId.” No juicio humano en lenguaje natural sino juicio determinístico de máquina.

El mainstream actual de la industria es diferente. La IA valida la IA. Un LLM escribe código, otro LLM lo revisa. Esto se llama LLM Feedback Loop. Analogía: un borracho preguntándole a su amigo borracho “¿estoy borracho?” Ambos son probabilísticos, así que los errores se acumulan.

Symbolic Feedback Loop es diferente. go test no alucina. yongol validate no adula. La medición de cobertura no miente. Las herramientas determinísticas dan la misma salida para la misma entrada cada vez.

“No cambies el modelo — agrega contratos”

Esta es la tesis central de Reins Engineering.

El mismo modelo se detiene en 40 o completa 527. El mismo modelo editando código crudo causa drift, editando SSOT converge a 0 errores. El mismo modelo sin retroalimentación se estanca al 60-70% de cobertura, con retroalimentación alcanza el 100%.

La diferencia no es el modelo sino la topología de retroalimentación.

Como analogía: gobierno de personas vs estado de derecho.

El gobierno de personas depende de un rey sabio. Si el rey es inteligente, el país funciona bien; si es tonto, colapsa. Esperar un modelo más inteligente es gobierno de personas. “GPT-6 lo arreglará.”

El estado de derecho depende de la ley. Sea el rey inteligente o tonto, con ley el sistema funciona. Agregar contratos es estado de derecho. “Si validate lo detecta, cualquier modelo converge.”

La humanidad ya conoce esta respuesta. Promesas escritas con sangre. La razón por la que 8,000 millones de humanos coexisten en un planeta no es porque los humanos sean buenos — es porque existe la ley.

La IA no es diferente.

Las restricciones son contratos

Para que el estado de derecho funcione, se necesitan tres condiciones:

1. Verificable. Se puede determinar mecánicamente si hubo violación.

2. La violación está definida. No “no escribas mal código” sino “si este campo y aquel campo tienen tipos incompatibles, es violación.” Discreto. O es violación o no.

3. Se puede hacer cumplir. La violación tiene consecuencias. Cuando yongol validate falla, la generación de código se rechaza. Una promesa sin consecuencias no es promesa — es deseo.

Cada sistema que funciona tiene promesas. Si las promesas son verificables, las violaciones están definidas y se pueden hacer cumplir — el sistema converge.

Orden suficiente dentro de libertad suficiente. Esa es la proporción áurea.

El sesgo de adulación no es un defecto sino un activo

El sesgo de adulación más citado como el mayor defecto de la IA — en la estructura Reins se convierte en un activo. Dale opiniones y adula, pero dale hechos determinísticos y acepta dócilmente y corrige. Por qué es así se cubre en detalle en la Clase 7.

La verdadera razón por la que los agentes de codificación funcionan

Mismo modelo. El modelo que alucina en el chat web envía funcionalidades de 200 líneas de una vez en Claude Code. El modelo no se volvió más inteligente de repente. Lo que cambió fue la estructura.

Reins Engineering convierte este accidente en intención. No “funciona porque casualmente hay pruebas” sino “la convergencia está garantizada al diseñar conscientemente puertas de verificación.”

Resumen — Qué recordar de esta clase

1. Cuatro eras. Prompt → Contexto → Arnés → Riendas. Cada era nacida de los límites de la anterior. Las cercas (arnés) no dan dirección. Las riendas dan dirección.

2. Tres pilares. Retroalimentación determinística, bloqueo de trinquete (Ratchet Pattern), separación de decisiones e implementación. Los tres deben estar presentes para garantizar convergencia.

3. Symbolic Feedback Loop. LLM genera, herramientas determinísticas juzgan, resultados retroalimentados al LLM. Los rieles importan más que el tren.

4. No cambies el modelo — agrega contratos. El mismo modelo se detiene en 40 o completa 527 dependiendo de la topología de retroalimentación. No gobierno de personas sino estado de derecho.

5. El sesgo de adulación es un activo. Dale opiniones y adula, dale hechos y acepta. Retroalimentación determinística + LLM adulador = bucle con convergencia garantizada.

Ejercicio: Distinguir decisiones de detalles

Objetivo: Abre tu proyecto mentalmente y encuentra dónde se mezclan decisiones y detalles.

Pregunta 1: ¿Cuáles son las “decisiones” en tu proyecto?

Piensa en las cosas que le dijiste a la IA que “construya.” Entre ellas, las que designaste “esto debe ser así” son decisiones. Por ejemplo:

• “El login usa email” — Decisión
• “La contraseña debe tener 8+ caracteres” — Decisión
• “El nombre de variable es userEmail” — Detalle

Escribe 3 decisiones y 3 detalles.

Pregunta 2: ¿Las decisiones escritas en CLAUDE.md fueron sobrescritas en el código?

Creaste CLAUDE.md en la Clase 1. Debería haber reglas escritas ahí. ¿La IA alguna vez ignoró esas reglas e hizo las cosas diferente? Si es así, eso es exactamente drift por la mezcla de decisiones y detalles.

Pregunta 3: ¿Qué si esas decisiones estuvieran fuera del código?

Si esas decisiones estuvieran en especificaciones separadas en vez de código, ¿la IA podría haberlas sobrescrito? Lo que yongol hace en la Clase 4 es exactamente esto. Sacar las decisiones del código para prevenir fundamentalmente que la IA las confunda con detalles y las sobrescriba.

Adelanto de la próxima clase

En la Clase 5 entendimos los principios de Reins. En la Clase 6 profundizamos en el Ratchet Pattern. El método concreto para hacer que un agente que se detiene en 40 complete 527. Principios del trinquete, aplicación en tareas masivas e implementación práctica del Symbolic Feedback Loop.

Artículos relacionados

• Reins Engineering — IA con riendas
• La topología de retroalimentación importa más que el IQ del modelo
• Las restricciones son contratos

Curso completo de Reins Engineering

Fuentes

1. Carnegie Mellon University, MSR 2026 — 41% de aumento permanente en complejidad de código tras adopción de herramientas de codificación con IA.
2. Google DORA Report, 2025 — 7.2% de disminución en estabilidad de entrega por cada 25% de aumento en adopción de IA.
3. TDAD, ACM AIWare 2026 — La instrucción procedimental “haz TDD” (6.08% → 9.94%) empeora la regresión; proporcionar archivos de prueba específicos como contexto (6.08% → 1.82%) reduce la regresión un 70%.