Bucle Gauntlet
El método detrás de Claude of Duty, generalizado para cualquier trabajo que un agente pueda inspeccionar. Un solo prompt produjo aproximadamente 55,000 líneas de un shooter jugable con estilo AAA sin intervención humana. El modelo no fue el factor diferenciador. El bucle lo fue.
Ciclo principal:
Dividir → construir → juzgar contra un estándar externo → repetir.
Método de Matt Shumer. Ver references/origin.md.
Contrato de ejecución
Tú ejecutas este protocolo. El usuario no.
Cuando esta habilidad se active, no entregues un prompt, un plan para aprobación ni una descripción de cómo sería un Bucle Gauntlet. Establece el estándar, descompón el objetivo, genera constructores y críticos, ejecuta las rondas y entrega el artefacto terminado.
El usuario dio un objetivo una vez. Todo lo demás es tu responsabilidad.
- No hagas preguntas aclaratorias. Cada incógnita es una decisión que tomas y registras en el resumen final.
- Elige el estándar tú mismo. Enúncialo en una oración y continúa. Nunca preguntes qué referencia usar.
- Enruta los modelos tú mismo. Elige el modelo y el esfuerzo de razonamiento para cada agente secundario según lo que ofrezca el arnés. Nunca le preguntes al usuario qué modelo usar y nunca dejes todo en la configuración predeterminada de la sesión.
- No informes nada a mitad de la ejecución. El progreso va al archivo de progreso en vivo, no a la conversación.
- Interrumpe solo por una credencial bloqueada, un recurso pago faltante o una instrucción que pueda causar daño.
Si el usuario solicita explícitamente ser consultado en puntos de control, respeta eso. En ausencia de esa señal, ejecuta hasta completar.
Cuándo aplica
Tres condiciones:
- La solicitud es crear o mejorar algo, no responder una pregunta.
- La salida se puede inspeccionar objetivamente: renderizar, ejecutar, abrir, medir, probar, leer.
- Más de una ronda es asequible.
Omítelo para consultas, correcciones de una línea y explicaciones. Cuesta cómputo real y solo vale la pena cuando la calidad importa más que la velocidad.
Manual de ejecución
1. Detectar el arnés
Lee references/harness-setup.md y elige la configuración antes de hacer cualquier otra cosa. Determina si los críticos provienen de subagentes paralelos, sesiones separadas o pases con separación estricta. Nunca anuncies este paso, solo adáptate.
Mientras estés ahí, enumera los modelos y las configuraciones de esfuerzo de razonamiento que este arnés expone. No puedes enrutar lo que no has listado.
2. Establecer el presupuesto y la tabla de enrutamiento
El bucle multiplica las llamadas. Si no se enrutan, cada una hereda el modelo y esfuerzo de la sesión, y una bifurcación de ediciones mecánicas se ejecuta en un modelo de frontera con el máximo razonamiento sin obtener beneficio.
Lee references/model-routing.md y decide, de una vez, antes de construir:
- Los niveles. Asigna los modelos disponibles a T0 (un comando, sin modelo), T1 (pequeño y rápido), T2 (intermedio), T3 (frontera con alto esfuerzo).
- La tabla. Qué rol obtiene qué nivel: el líder y cada llamada de juicio en T3, la construcción estándar en T2, las ediciones mecánicas y la contabilidad en T1, cualquier cosa que un comando pueda verificar en T0.
- El presupuesto. Respeta el del usuario si lo dio; si no, establece uno y reserva aproximadamente una cuarta parte para los críticos.
Dos reglas anulan cualquier ahorro. El juicio nunca se enruta al nivel más barato, porque un crítico débil aprueba temprano y cancela el método. Y una pieza que depende del gusto o la novedad comienza en un nivel alto, porque un constructor barato que pierde cuatro rondas cuesta más que uno caro que gana en una.
Registra la tabla en el archivo de progreso. No la anuncies y no pidas al usuario que la apruebe.
3. Establecer el estándar
El estándar decide si la ejecución funciona o no. No son estándares: "hazlo increíble", "calidad de producción", "sigue las mejores prácticas". Un estándar es un artefacto o medición externa real con el que se pueda comparar la salida y perder.
Elige uno usando references/quality-bars.md, que cubre trabajo visual, frontend, interfaz de producto, backend, móvil, escritura, sistemas de diseño, investigación, datos y marketing.
Reglas:
- Inspeccionable dentro de la ejecución. Una captura de pantalla guardada en el espacio de trabajo, una URL que puedas abrir, un conjunto de pruebas que se ejecute, un archivo que puedas leer. No es un estándar recordado del entrenamiento.
- No necesita ser alcanzable. Claude of Duty nunca superó a Call of Duty. El estándar existe para evitar que la ejecución se conforme con "bueno para IA".
- Superado en la primera ronda significa que era demasiado bajo. Súbelo y continúa.
Obtén o genera los artefactos del estándar ahora, antes de cualquier construcción, y almacénalos en el espacio de trabajo para que cada crítico pueda acceder a ellos.
4. Tomar el objetivo, no la implementación
No prescribas tu propia arquitectura de antemano y no aceptes una descomposición inventada antes de mirar el artefacto. Reformula el destino y deja que la forma emerja.
Si el usuario fijó una pila tecnológica o una arquitectura, esa es una restricción real. Respétala y deja todo lo demás abierto.
5. Dividir el trabajo
Divide el objetivo en las piezas más pequeñas que se puedan mejorar y juzgar por separado, y decide cuáles ejecutar en paralelo.
La granularidad es la palanca. "Mejorar el sitio" es intratable. "Hacer que esta sección de precios supere a la sección de precios de referencia" es un problema que puedes atacar hasta ganar. Lo mismo para "hacer que p95 supere los 120 ms bajo esta carga" y "hacer que este párrafo sea al menos tan claro como este párrafo de referencia".
6. Construir y juzgar, nunca en el mismo contexto
Para cada pieza, un constructor y un crítico separados. Siempre contextos diferentes, nunca el mismo agente.
El constructor vio cada decisión y recuerda por qué las tomó, lo que lo hace excelente para explicar por qué el resultado es razonable. Razonable no es el objetivo.
Instrúyelos usando assets/delegation-templates.md. El crítico recibe el objetivo, el estándar, las restricciones y el artefacto real. Nunca recibe la transcripción del constructor, la explicación del constructor ni qué lado es el nuestro.
Enruta cada generación a medida que la haces, usando la tabla del paso 2. Haz las tres preguntas antes de cada constructor: ¿el éxito es verificable por un comando (sin modelo, ejecútalo)?, ¿el estado objetivo ya está completamente especificado (modelo más pequeño, esfuerzo mínimo)?, ¿o cerrar la brecha requiere decidir cómo se ve lo bueno (frontera)? Los críticos que juzgan el gusto son siempre de frontera; los críticos que verifican un número ejecutan primero el comando y solo necesitan un modelo pequeño para informarlo.
Procedimiento completo en references/critic-protocol.md. Esenciales: comparación A/B ciega, inspeccionar lo real, veredicto binario, nombrar la brecha más grande, devolverla.
7. Seguir repitiendo
Nunca establezcas un número fijo de rondas. Cualquier ronda final acordada se convierte en un techo.
Detente cuando ocurra una de estas condiciones y registra cuál:
- El usuario lo da por terminado desde el archivo de progreso.
- Las ganancias por ronda dejaron de ser relevantes para el objetivo.
- Se agotó el presupuesto de cómputo, medido contra el presupuesto establecido en el paso 2.
Sube una pieza de nivel solo con evidencia: dos pérdidas consecutivas en la misma brecha aumentan su esfuerzo, una tercera aumenta su modelo. Una pieza que comienza a ganar vuelve a bajar por el resto de la ejecución. Al gastar el 80% del presupuesto, deja de agregar rondas a piezas que ya están ganando y pon el resto en la pieza más alejada del estándar.
Si la misma brecha sobrevive tres rondas consecutivas, detén esa pieza y vuelve a decidir a nivel de líder. Es estructural, o el estándar es incorrecto para esa pieza, o constructor y crítico están midiendo cosas diferentes. Gastar más en ese punto es la forma más común de quemar un presupuesto en nada.
8. Mantener un archivo de progreso en vivo
Mantén una página HTML simple o un archivo markdown en el espacio de trabajo, actualizado a medida que el trabajo se completa: capturas de pantalla, borradores, resultados de pruebas, veredictos ronda por ronda, brechas abiertas. No especifiques demasiado el formato e indica al usuario dónde está en tu primera línea de salida.
Esto existe para que el usuario pueda observar sin interrumpir. La interrupción cuesta una ventana de contexto y rompe el bucle.
9. Pase de suavizado entre oleadas
Cuando muchos agentes editan partes separadas de un artefacto, las partes se vuelven individualmente buenas y colectivamente incoherentes.
Al final de cada oleada importante, genera un agente nuevo para inspeccionar el resultado completo, resolver conflictos y hacer que parezca una sola cosa. No rediseña nada.
Útil, no esencial. Lo esencial sigue siendo: dividir, construir, juzgar, repetir.
Cierre de la ejecución
Entrega el artefacto, luego un breve resumen que contenga:
- El estándar utilizado y por qué.
- Cuánto avanzó el trabajo contra él.
- La última brecha no cerrada, que es la transferencia para quien lo retome.
- Suposiciones hechas en lugar de preguntas no formuladas.
- Qué condición de detención finalizó la ejecución.
- Lo que costó: rondas ejecutadas, aproximadamente dónde se fue el presupuesto y cualquier pieza que consumió una gran parte sin avanzar.
Sin elogios para el trabajo. Los veredictos del crítico ya dijeron todo lo que importa.
Antipatrones
| Síntoma | Solución |
|---|---|
| Entregar al usuario un prompt para que lo ejecute él mismo | Ejecuta el protocolo, ese es el punto |
| "¡Esto se ve genial!" del constructor | Genera un crítico con contexto limpio, sin historial |
| El crítico lee un informe en lugar del artefacto | Obliga a inspeccionar la salida real |
| Estándar subjetivo ("de clase mundial", "nivel Apple") | Reemplázalo con un artefacto concreto que puedas abrir |
| Descomposición fijada antes de ver el artefacto | Deja que la forma emerja del trabajo |
| "Haz 3 iteraciones" | Bucle abierto con una condición de detención explícita |
| Preguntar qué referencia usar | Elige una, justifícala en una oración, continúa |
| Actualizaciones de estado en la conversación | Archivo de progreso en vivo |
| Partes buenas, todo incoherente | Pase de suavizado al final de la oleada |
| Estándar superado en la primera ronda | El estándar era demasiado bajo, súbelo |
| Misma brecha sobrevive tres rondas | Escala, es estructural |
| Cada agente hereda el modelo y esfuerzo de la sesión | Enruta cada generación: frontera para juicio, pequeño para trabajo mecánico |
| Modelo de frontera con máximo esfuerzo renombrando una variable | T1 con esfuerzo mínimo, o un comando sin modelo |
| Crítico barato, para ahorrar una ronda | Regla cero. Un crítico débil aprueba temprano y cancela el método |
| Constructor barato en una pieza que depende del gusto | Cuatro rondas perdedoras cuestan más que una victoria cara |
| Subir de nivel porque una pieza se siente difícil | Escala por veredictos repetidos, no por corazonadas |
| Presupuesto del crítico gastado en rondas de construcción adicionales | La reserva no es un fondo común. El juicio se lo lleva. |