Clase 6. Si pasa, se bloquea — Principios y aplicación masiva del Ratchet Pattern

Consejos clave — Con saber esto, ya puedes dar instrucciones

El núcleo del trinquete es una sola frase: Cada vez que agregas una funcionalidad, hurl –test debe pasar antes de avanzar. Eso es el trinquete. Como un engranaje que no gira en reversa, un test que pasa una vez no se rompe.

No confíes en “todo listo.” La IA es optimista. Hace solo 40 de 527 funciones y declara “listo.” Verifica con números — cuando TODO es 0, está listo. Hasta entonces, no está listo.

Al dar tareas masivas al agente:

Al agente: “Ejecuta tsma next, escribe tests para la función TODO. Si el test pasa, avanza a la siguiente función con tsma next. Repite hasta que aparezca All functions complete!”

Esta repetición es todo. tsma next decide la siguiente tarea, un verificador (go test, hurl –test, etc.) juzga pass/fail, y la máquina declara “listo.” La IA solo genera.

No instruyas métodos — instruye contratos. No “haz TDD” sino “este test debe pasar.” Intentar enseñar metodología la confunde. Solo dale las condiciones a cumplir.

Si el agente muere a mitad de sesión, no pasa nada. Ejecuta tsma next de nuevo y continúa desde la última función procesada. El progreso se preserva.

Prueba rápida

Abre la app de la Clase 1 con Claude Code y pide:

Al agente: “Agrega 3 funcionalidades en orden. Después de agregar cada funcionalidad, ejecuta hurl –test tests/ para asegurarte de que todos los tests existentes pasen antes de avanzar. Si algo falla, arréglalo para que pase primero.”

Observa mientras el agente trabaja:

• ¿La 2a funcionalidad rompe el test de la 1a? — Debe arreglar antes de avanzar
• ¿La 3a rompe la 1a y la 2a? — Igual, arregla primero
• Que el test pase es el criterio de completitud, no la declaración “todo listo”

Esto es el trinquete. Hurl de la Clase 3 ya estaba sirviendo como el verificador del trinquete.

Por qué debes dar instrucciones de esta manera

Resumen de las 5 clases anteriores

En la Clase 5 aprendimos los tres pilares de Reins Engineering. Dirigir con contratos determinísticos, bloquear con trinquetes, separar decisiones de implementación. Hoy profundizamos en el trinquete — el más esencial de los tres pilares.

El trinquete es el corazón técnico de Reins Engineering. Entiéndelo y todo lo demás sigue.

“Todo listo”

¿Recuerdas el caso 40 vs 527 de la Clase 5? Mismo modelo, mismo proyecto, mismas 527 funciones — el agente autónomo se detiene en 40 (7.6%), pero con el trinquete completa 527.

La Clase 5 explicó por qué ocurre esta diferencia. Esta clase desarma cómo el trinquete lo fuerza, descomponiendo la estructura.

Los LLMs son buenos generando. Pero no se puede confiar en que juzguen si están listos.

Quitar el juicio de completitud al agente y entregarlo a la máquina.

La llave de trinquete

Solo tres reglas:

1. Mostrar solo un ítem a la vez. El agente no puede elegir saltarse algo.
2. Debe pasar para avanzar. No se puede saltar.
3. Detenerse cuando todo pase. “Todo listo” lo dice la máquina.

Cinco principios

Principio 1. La condición de terminación es mecánica — pass/fail. No “se ve bien.”

Principio 2. PASS es inmutable — Los ítems aprobados no se reabren. Solo avanza.

Principio 3. El LLM solo genera — ¿Qué corregir? La máquina decide. ¿Pasó o falló? La máquina juzga. ¿Qué sigue? La máquina informa. ¿Terminó? La máquina declara.

Principio 4. Eliminar la autoridad de juicio de terminación del agente — Cuando el LLM dice “listo”, se detiene en 40. Cuando la máquina dice “listo”, se detiene en 527.

Principio 5. El verificador debe ser determinístico — Cuatro condiciones: determinístico, verificable por máquina, reanudable, retroalimentación localizada.

Estudio TDAD — La instrucción “haz TDD” tiene efecto contrario

“Haz TDD” instruyó un método. El LLM se confunde imitando la forma de TDD. “Este test debe pasar” instruyó un contrato. El LLM sabe exactamente qué hacer.

No instruyas métodos — instruye contratos.

tsma — La herramienta práctica del trinquete

tsma es una herramienta CLI que aplica Ratchet Pattern a proyectos. Soporta Go, TypeScript y Python. El agente necesita conocer un comando:

$ tsma next

Este solo comando conduce todo el bucle. Repite hasta que aparezca “All functions complete!”

Las instrucciones para el agente son 6 líneas:

1. Ejecutar tsma next
2. Si TODO — leer la función y escribir test
3. Si el test falla — leer el error y corregir el test
4. Si aparecen ramas no cubiertas — agregar tests que cubran esas ramas
5. Si PASS/DONE — la siguiente función aparece automáticamente
6. Repetir hasta "All functions complete!"

Resultados medidos con 527 funciones

TODO es 0. Las 527 funciones fueron procesadas.

Lo importante es el hecho de que TODO es 0. El trinquete empujó al agente hasta el final.

La retroalimentación es la señal de gradiente

Retroalimentación débil:  "Test falló"           → LLM corrige sin dirección
Retroalimentación media:  "Cobertura 65%"        → LLM refuerza aproximadamente
Retroalimentación fuerte: "line 41, 44, 70 sin cubrir" → LLM cubre exactamente esas ramas

Mismo modelo. Una línea de “line 41 not covered” actúa como señal de gradiente.

Los agentes mueren. El progreso sobrevive.

Los agentes siempre caen. Límites de tokens, errores de red, desconexiones de sesión. No puedes procesar 527 funciones en una sesión.

El trinquete almacena persistentemente el estado de progreso. tsma lo registra en .tsma/session.json.

Agente A: Procesa funciones 1~200 → muere por límite de tokens
Agente B: tsma next → continúa desde 201
Agente C: tsma next → continúa desde 401

Los agentes son desechables. El progreso se acumula.

Cambiar el verificador crea una herramienta diferente

Un patrón. El verificador determina el dominio.

Resumen clave

1. Los LLMs generan bien pero no pueden juzgar completitud. Dicen “listo” en 40.
2. Entregar el juicio de completitud a la máquina completa 527. Esto es Ratchet Pattern.
3. No instruyas métodos — instruye contratos. No “haz TDD” sino “este test debe pasar.”
4. La resolución de la retroalimentación determina la precisión de la corrección. “line 41 sin cubrir” es 10x más efectivo que “falló.”
5. Los agentes mueren pero el progreso se preserva. session.json es el checkpoint.
6. Cambiar verificadores crea una herramienta diferente. Un patrón, el verificador determina el dominio.

En la Clase 7 profundizamos en el principio de por qué funciona este trinquete.

Ejercicio: Completar 20 tests con el trinquete (tsma)

Objetivo: Seleccionar 20 funciones de un proyecto existente, aplicar trinquete con tsma, completar 20/20.

Requisitos: tsma instalado, proyecto (Go, TypeScript o Python)

Instalar: Dile al agente “instala tsma.” Si tsma --help muestra salida, la instalación está completa.

Paso 1: Indexación

$ cd tu-proyecto
$ tsma next

En la primera ejecución, tsma indexa todas las funciones del proyecto.

Paso 2: Dar instrucciones de trinquete al agente

Dile a Claude Code:

Ejecuta tsma next, escribe tests para la función TODO.
Si el test pasa, avanza a la siguiente función con tsma next.
Si aparecen ramas no cubiertas, agrega tests que las cubran.
Repite hasta "All functions complete!"

Paso 3: Observar

Mientras el agente trabaja, observa:

• ¿El agente intenta saltarse algo? → El trinquete lo fuerza a quedarse en la función actual
• ¿Diferencia de cobertura con y sin retroalimentación? → Sube tras retroalimentación con números de línea
• ¿Cuántos intentos para convertir a PASS? → Normalmente 1-2

Paso 4: Verificar resultados

$ tsma status

TODO en 0 significa completitud.

Experimento comparativo (opcional):

Con las mismas 20 funciones, dile al agente “escribe tests para estas 20 funciones” sin tsma. Ve en cuántas se detiene.

Artículos relacionados

• Ratchet Pattern
• tsma — Línea de defensa contra regresiones de código legado
• Por qué los agentes de codificación funcionan y por qué se derrumban

Curso completo de Reins Engineering

Fuentes

1. 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%.