🧩 Fundamentos de Loop Engineering

La ingeniería de bucles es el enfoque en el que sistemas automatizados (bucles) activan, supervisan e iteran sobre agentes de IA en un ciclo continuo, sustituyendo el prompting manual de las personas.

Entender la definición precisa evita confusiones con la automatización genérica. El término tiene un significado específico en el contexto de los coding agents.

Basado en loops vs. basado en prompts. El humano define el sistema, no cada prompt. Analogía con cron jobs + agentes de IA.

Boris Cherny, Head of Claude Code, gestiona decenas de miles de agentes al día usando loops. No escribe prompts: arma sistemas que lo hacen por él.

La credibilidad de la fuente importa. Boris está en el centro del desarrollo de Claude Code y practica la ingeniería de loops a escala industrial.

Escala de miles de agentes por día. Prompting como sistema, no como interacción. Anthropic como referencia práctica.

Peter Steinberger creó OpenClaw y ejecuta loops que le dan instrucciones a Claude automáticamente, con orchestrator + workers y gestión externa del estado.

Es un caso real de implementación fuera de Anthropic. Muestra que el enfoque funciona para desarrolladores independientes, no solo para quienes crean la herramienta.

OpenClaw como harness. Separación entre orchestrator y worker. Estado externo (Postgres). Autonomía del agente.

En el prompting manual, la persona interactúa directamente con el agente en cada paso. En el enfoque loop-driven, la persona define el sistema una vez y el loop ejecuta N rondas automáticamente.

La distinción es fundamental para saber cuándo tiene sentido cada enfoque. Loop-driven no reemplaza el prompting manual en todos los casos.

Interacción síncrona frente a asíncrona. Costo de la atención humana. Escala frente a precisión. Equilibrio entre control y autonomía.

La ingeniería de bucles combina el concepto de tareas programadas (como los cron jobs en Linux) con la capacidad de razonamiento de los LLM. El bucle se activa y el agente decide qué hacer.

La analogía ayuda a desmitificarlo: no es magia, es automatización con una capa inteligente. Quien entiende los cron jobs ya tiene medio camino recorrido.

Trigger temporal frente a condicional. Job = sesión del agente. Exit condition = criterio de parada. Idempotencia.

El término Loop Engineering ganó fuerza después de que Boris Cherny describiera públicamente cómo Anthropic usa loops internamente. Cole Medin se pregunta: "¿merece su propio buzzword?"

Separar la señal del ruido. No todo lo que tiene nombre propio es revolucionario. Entender el contexto evita adoptar cosas a ciegas.

Ciclo de hype. Nombre como marketing. Sustancia frente a marca. Crítica honesta de Cole Medin.

El comando /loop define intervalos de ejecución para el agente, como "cada 5 minutos". Es el mecanismo de recurrencia que mantiene activo al agente.

Sin loop, el agente se detiene cuando termina una tarea. Con loop, se activa periódicamente para verificar si hay trabajo nuevo.

Intervalo de polling. Activación automática. Diferencia entre un ciclo y una ejecución única. Costo de tokens por ciclo inactivo.

/goal define un criterio objetivo de finalización. El agente sigue iterando hasta alcanzar el goal o agotar los intentos. Es la condición de salida del loop.

Sin un goal claro, el loop se ejecuta indefinidamente y gasta tokens sin resultados. El goal es lo que convierte un loop en algo útil.

Condición de salida explícita. Verificación automática de finalización. Alternativa y límites de reintentos. Meta frente a fecha límite.

/routines son tareas programadas con un schedule definido (p. ej., "cada hora, revisa la spec"). A diferencia del /loop genérico, las routines tienen un propósito específico y recurrente.

Las routines son el mecanismo más práctico para tareas de mantenimiento: code review periódico, sincronización de docs, health checks.

Programación tipo cron. Routine frente a loop ad hoc. Composición de múltiples routines. Prioridad entre routines en conflicto.

Los tres primitivos no funcionan de forma aislada. Un sistema típico combina /loop como heartbeat, /goal como criterio de salida y /routines como tareas de mantenimiento paralelas.

Entender la composición es el paso de "sé qué hace cada pieza" a "puedo armar un sistema funcional".

Pipeline como grafo. Dependencias entre bloques. Prioridad de ejecución. Diagnóstico cuando falla un bloque.

El plan.md es el documento markdown que define las tareas que procesará el loop. Funciona como un contrato: el orchestrator lo lee, ejecuta cada elemento y lo marca como completado.

Un plan.md mal redactado genera loops ineficientes. La calidad del input determina la calidad del output, incluso en sistemas automatizados.

Estructura de la lista de tareas. Granularidad ideal de las tareas. Criterios de aceptación por elemento. Control de versiones del plan.

Loop sin exit condition (se ejecuta para siempre), objetivo vago («haz algo bueno»), rutina que entra en conflicto con el loop principal. Son trampas que consumen tokens sin dar resultados.

Evitar estos errores desde el principio ahorra dinero y frustración. La mayoría de quienes empiezan cae en las mismas trampas.

Loop infinito. Objetivo ambiguo. Conflicto de rutinas. Max iterations como red de seguridad. Límites de presupuesto.

El orchestrator es la sesión de agente que lee la spec, decide qué tareas ejecutar, inicia workers y valida los resultados. No ejecuta código directamente.

El orchestrator es el punto de falla más crítico. Si toma malas decisiones, todos los workers producen basura. Entender su función es esencial.

Separación de responsabilidades. Decisión vs. ejecución. Modelo del orchestrator (puede ser más económico). Lógica de reintentos en el orchestrator.

Los workers son sesiones de agente que reciben una tarea específica del orquestador y la ejecutan. Pueden ejecutarse en paralelo usando worktrees para aislarse.

Los workers son donde ocurre el trabajo real. Entender cómo aislarlos, monitorearlos y recopilar resultados es la parte práctica de la ingeniería de loops.

Worktrees como sandbox. Paralelismo real. Recopilación de resultados. Tiempo de espera límite del worker. Aislamiento del estado.

En vez de depender de la context window del LLM para mantener el estado, el loop guarda el estado en una base de datos externa (Postgres, Neon). Esto evita el context bloat y permite resumir sesiones.

Context bloat es la causa #1 del deterioro en loops largos. El estado externo es la solución arquitectónica que hace viables los loops a escala.

La base de datos como fuente de verdad. La context window como caché, no como almacenamiento. Neon branching para workers. Esquema del state store.

Flujo: entra la spec -> el orquestador planifica -> inicia workers -> los workers ejecutan -> los resultados vuelven al state -> el orquestador valida -> siguiente ola o finalización.

Visualizar el flujo completo ayuda a depurar cuando algo sale mal. Cada paso es un posible punto de falla que necesita tratamiento.

La ronda como unidad de trabajo. Fan-out (orchestrator -> workers). Fan-in (workers -> orchestrator). Validación entre rondas.

Con estado externo, si el agente falla a mitad de una ronda, el orchestrator puede reanudar desde donde se quedó. El estado en la base de datos sobrevive a caídas, timeouts y desconexiones.

Los loops largos inevitablemente fallan en algún momento. La durabilidad es lo que diferencia un juguete de un sistema de producción.

Punto de control en el almacén de estado. Reanudar desde el último estado válido. Idempotencia de los workers. Limpieza de workers huérfanos.

La observabilidad es la capacidad de ver lo que el loop está haciendo en tiempo real: decisiones del orchestrator, progreso de los workers, costo acumulado y errores.

Sin observabilidad, ejecutas un loop a ciegas. "Corres durante un día y vuelves a encontrar un desastre" es el síntoma de falta de monitoreo.

Agent Control Plane. Seguimiento de costos por ronda. Registro de decisiones del orchestrator. Puntos de control con intervención humana.