Diseño y Revisión de Bucles
Premisa. Un LLM es un sistema de avance: prompt → tokens de salida, sin una dirección integrada hacia el objetivo a través de los pasos. Para que se comporte como un sistema orientado a objetivos, se envuelve un bucle de retroalimentación a su alrededor. Este skill te ayuda a escribir ese bucle correctamente y a revisarlo para que no se descontrole.
Cuándo usarlo / no usarlo
Úsalo cuando:
- Quieras asignar una tarea repetitiva a un agente que se ejecuta una y otra vez (escribir→probar, probar→corregir, corregir→verificar…).
- Ya tengas un bucle y te preocupe que gire sin rumbo, haga trampas o ejecute una respuesta incorrecta hasta el final.
No lo uses para:
- Una tarea única → simplemente hazla; no le pongas un bucle alrededor.
- Un temporizador / sondeo simple → usa
/loop; no se necesita diseño. - Cómo cablear la arquitectura del bucle (tuberías → DAGs, recuperación a largo plazo) → esa es la capa de mecanismo; consulta
autonomous-loops/continuous-agent-loop. Este skill solo cubre «si el objetivo es correcto y si se descontrolará» — no vuelve a explicar el mecanismo.
Línea roja premisa: dos niveles de retroalimentación
| Nivel | ¿Quién lo posee? | ¿Qué hace? |
|---|---|---|
| Ejecución (bajo) | máquina / agente | Mide «qué tan lejos del objetivo literal» y lo reduce a cero. La máquina es fuerte aquí. |
| Juicio (alto) | humano | Decide «si este objetivo en sí mismo es correcto, si debe cambiar, si debe detenerse». La máquina no puede salir de su propio bucle para cuestionar el objetivo. |
Un termostato puede retroalimentar «qué tan lejos de 26°C», pero cuando tienes fiebre y quieres 28°C no puede juzgar si 26 es el objetivo correcto — simplemente avanza hacia 26. «Qué ajustar hoy» siempre es decisión humana. Entregar el juicio / la aprobación / el último interruptor a la máquina = eliminar la retroalimentación de alto nivel = corre, rápido y fuerte, hacia un objetivo que nadie cuestionó → salida incorrecta.
Acción 1 — Escribir un bucle (5 pasos)
Paso 0 · Restar primero: ¿Realmente deberías construirlo? (compuerta de 4 condiciones, cualquier fallo = veto)
① la tarea se repite semanalmente o más ② la verificación puede automatizarse ③ el presupuesto de tokens lo soporta ④ el agente tiene herramientas que realmente se ejecutan y ven el resultado
Fallar en alguna → no construyas un bucle; hazlo manualmente o de otra forma.
Lo que detiene a la mayoría no es «puedo escribir un bucle», sino «si mi repositorio se lo merece». Un repositorio que se merece un bucle tiene una línea base de conciliación (muestra dorada / total upstream) + pruebas + un guardia de lint. Un repositorio que no se merece un bucle solo verá sus errores amplificados por uno.
Paso 1 · Definir un objetivo decidible por máquina (la parte difícil — el bucle vive o muere aquí)
Todo el bucle depende del comparador: «¿ya terminó?» El comparador solo funciona si tu condición de salida puede ser juzgada sí/no por una máquina.
- Malo: Vago («hazlo bien», «escríbelo más nítido») → el comparador no puede juzgar → o nunca pasa (atascado reintentando) o adivina (pasa/bloquea al azar).
- Bueno: Decidible («las 96 pruebas unitarias en verde Y se produce un registro de cambios», «los campos del módulo-02 llenos, pytest pasa, la lógica de negocio intacta») → una verificación lo resuelve; el bucle converge limpiamente.
Marco de cinco puntos para el objetivo:
- El criterio de terminación es verificable por máquina.
- Las condiciones de límite se definen junto con el criterio de terminación («lo que NO debe hacer») — anti-Goodhart; faltan límites = licencia para hacer trampa.
- Tiene una retroalimentación de fallo — límite de reintentos N + escalar a un humano cuando se excede.
- El objetivo está en capas.
- Preferir conciliación sobre aserción para el criterio de terminación — anclar a un hecho externo (muestra dorada / total upstream / conciliación financiera / números de back-office de la plataforma) antes que a tus propias aserciones. «Todas las pruebas pasan» puede ser manipulado (aflojar aserciones, falsificar mocks, tragar excepciones); «diferencia con la referencia < 0.01» no puede.
Autoverificación: lee el objetivo a alguien que no conozca el dominio — ¿puede ejecutar un comando y decir si está terminado? Si no, no es lo suficientemente decidible. Vuelve atrás.
Paso 2 · Elegir el tipo de bucle
| Tu tarea | Tipo de bucle (cibernético) | Cómo se detiene |
|---|---|---|
| Tiene una prueba clara de «terminado» (escribir hasta terminar / procesar un lote de imágenes) | servo (bucle cerrado estilo /goal) | se detiene al alcanzar el objetivo |
| Sin punto final, debe mantener un estado (alerta de inventario / verificación de salud programada) | regulador (termostato estilo /loop) | nunca se detiene; actúa solo ante cambios (banda muerta suprime ruido) |
| Muestreo periódico, detenerse en una condición (vigilar un PR hasta que CI esté en verde) | regulador con salida | se detiene cuando la condición de salida se cumple |
| Debe «asegurar que algo ocurra a tiempo» | envuelve lo anterior en /schedule | cron lo ejecuta |
Regla general: prueba clara de «terminado» → servo; debe seguir manteniendo, sin punto final → regulador; debe «ocurrir a tiempo» → envuelve un regulador en programación.
Paso 3 · Elegir un esqueleto
Tipo de mantenimiento (cuidar algo que existe) → despacho basado en documentos. El bucle no es «ejecutar una verificación fija en un temporizador», sino «leer un documento en un temporizador, y despachar solo cuando el documento cambió». El documento es la cola de tareas + máquina de estados + interfaz humana. Tres disciplinas: ① la columna de problema es solo de escritura humana, la columna de resultado es solo de escritura del bucle, el estado avanza en un solo sentido y nunca retrocede; ② el código de salida es final (si el script dice exit 1, el script gana); ③ el estado avanza solo hasta «esperando verificación» — la celda de «terminado» solo la cambia un humano. El bucle es el trabajador, no el oficial de aceptación.
Tipo greenfield (construir desde cero) → planificar / construir / juzgar, tres roles.
| Rol | Hace | Clave |
|---|---|---|
| Planificar | descomponer el objetivo en una especificación + condiciones de aceptación decidibles | la aceptación debe ser juzgable por script |
| Construir | escribir según la especificación | no debe cambiar las condiciones de aceptación |
| Juzgar | ejecutar la aceptación de forma independiente; pasar → detenerse, fallar → devolver la razón del fallo a Construir | independiente + determinista |
Tres reglas de hierro (todas apuestan por el juez): ① el juez debe ser independiente — no el mismo agente que Construir (calificar tu propia tarea siempre infla); ② reglas deterministas — pytest / diff de conciliación / type check / diff, nunca «parece correcto»; ③ Construir no puede editar las condiciones de aceptación para pasar. Tres reintentos fallidos → escalar a un humano.
Paso 4 · Agregar amortiguación (contra oscilación / descontrol)
Límite de reintentos, parada forzada, humano cambia el último interruptor = amortiguación. La retroalimentación negativa sin amortiguación oscila (el bucle de Ralph-Wiggum: girar en el lugar, quemar tokens).
Paso 5 · Implementar en tres etapas (no ir completamente automático el primer día)
① Ejecutarlo una vez manualmente (te obliga a declarar exactamente «cómo decide el juez») → ② endurecerlo en un skill / subagentes de Claude Code (un Claude principal que bucea, despachando planificar/construir/juzgar) → ③ colgarlo en cron para automatización completa.
Acción 2 — Revisar un bucle (lista de verificación = cinco modos de fallo)
Ejecuta el bucle en cada fila. Si alcanza alguna = este bucle fallará; devuélvelo. Estos cinco son experiencia negativa (problemas) — valen más que reglas positivas.
| # | Modo de fallo (cómo se rompe) | Pregunta de revisión (un golpe = rojo) | Anticuerpo |
|---|---|---|---|
| 1 | El objetivo es un lugar común correcto → gira, quema dinero | ¿La condición de salida puede ser juzgada sí/no por máquina? ¿O es «gestionarlo bien / hacerlo bueno»? | Reemplazar con una condición de resultado decidible (Acción 1·Paso 1) |
| 2 | «Verificación» escrita como «verificar si se ve bien» → el agente dice con confianza que está bien y se detiene | ¿El juez es el propio acusado? ¿La verificación se basa en «parece correcto» o en reglas deterministas? | Conciliar + reglas de código de salida + juez independiente |
| 3 | (el peor) Solo se basa en «todas las pruebas pasan» → el agente elimina las pruebas | ¿Hay un límite («lo que NO debe hacer»)? ¿O solo un criterio de terminación? | Criterio de terminación + límite juntos (el anticuerpo Goodhart) |
| 4 | Cuenta con que el agente pregunte durante la ejecución → no lo hará; ejecuta la respuesta incorrecta hasta el final | ¿Hay algún punto de «aclarar solo en tiempo de ejecución»? | Precargar cada aclaración; resolverlo una vez antes del lanzamiento |
| 5 | CLAUDE.md inflado + memoria obsoleta → cuanto más rápido buclea, más errores comete | ¿Los documentos/memoria de los que depende están frescos? ¿Quién los mantiene? | Memoria en capas + lint periódico |
Más tres líneas rojas (violar cualquiera = no permitido ir automático):
- Mantener el juicio con el humano. La aceptación / la celda de «terminado» la cambia un humano; el bucle no es el oficial de aceptación.
- La responsabilidad no se transfiere. Cualquier cosa cuyo fallo no puedas permitirte (fusionar el PR equivocado / publicar lo incorrecto / asignar mal el dinero) → no delegues la autoridad automáticamente.
- Advertencia contraintuitiva. Cuanto más «auto-mejorante / reescribe-sus-propias-reglas» sea un bucle, más estricta necesita la revisión humana (para ver en qué reescribió las reglas) — no más laxa. La máquina es demasiado rápida para interceptar después del hecho, por lo que el juicio humano debe estar antes de la acción (una puerta dura), no como un parche posterior.
Ejemplo práctico — revisar un bucle de «mantenimiento nocturno»
Quieres un bucle que se ejecute cada noche y arregle las pruebas que fallen.
- Objetivo ingenuo: «hacer que todas las pruebas pasen.» → Autoverificación del Paso 1 falla: este es el cebo para el modo de fallo #3.
- Objetivo decidible (corregido): «todas las pruebas en verde Y ningún archivo de prueba eliminado o debilitado Y cobertura no reducida Y se produce un registro de cambios.» Ahora el límite está definido junto con el criterio de terminación.
- Tipo: servo con límite de reintentos de 3 (Paso 2 + Paso 4).
- Esqueleto: planificar/construir/juzgar — el juez es la ejecución de CI independiente, nunca el agente corrector (Paso 3).
Ahora ejecuta la lista de verificación de revisión, y captura lo que la versión ingenua habría omitido:
- #3 alcanzado → el «todas las pruebas pasan» ingenuo permite que el agente elimine una prueba fallida para «ganar». Corregido por el límite «ningún archivo de prueba eliminado/debilitado».
- #2 alcanzado → si el agente corrector también juzgara su propia corrección, se aprobaría a sí mismo. Corregido por «juez = CI independiente, determinista».
- #4 alcanzado → si una corrección es ambigua, el agente no se detendrá a preguntar a las 2 a.m.; confirmará una suposición. Corregido por precarga: las correcciones ambiguas se dejan para el humano, no se adivinan.
- Línea roja → el bucle abre un PR pero no lo fusiona automáticamente; el humano cambia el último interruptor (la responsabilidad no se transfiere).
El bucle ingenuo y el bucle revisado difieren en cuatro líneas de restricción — y esa es la diferencia entre «despertarte con un conjunto de pruebas eliminado» y «despertarte con un PR limpio».
Cierre en una línea
La parte difícil de escribir un bucle no es «puedo escribir un bucle», es definir un objetivo que una máquina pueda conciliar — decidible, acotado, basado en conciliación. El controlador debe ser determinista y externo; mantén el juicio y el estándar con el humano; el sistema tiende hacia la entropía, así que mantenlo. Un bucle solo recompensa a alguien que ya lo ha pensado. Cuenta con que piense por ti, y felizmente pensará mal, contigo, a escala.
Linaje: retroalimentación de dos niveles de Wiener (The Human Use of Human Beings, 1950) para la división juicio/ejecución y líneas rojas; el patrón planificar/construir/juzgar de Loops explained de Anatoli y Loop Engineering de Addy. Capa de mecanismo (cómo cablear la arquitectura del bucle): consulta
autonomous-loops/continuous-agent-loop. Este skill no reimplementa el mecanismo; cubre solo la definición del objetivo y la prevención de descontrol.