Qué es el diseño del ciclo de ejecución de IA

Qué significa diseñar el ciclo de ejecución

El diseño del ciclo de ejecución consiste en definir el ciclo repetitivo que ejecuta un agente de IA: qué lo activa, a qué puede acceder, cómo se comprueba su salida y qué lo detiene. El diseño de prompts configura un mensaje para un modelo. El diseño del ciclo configura el proceso que envía miles de mensajes mientras usted duerme. La unidad de trabajo pasa del prompt al ciclo.

La versión breve es la siguiente: deja de escribir instrucciones y empieza a escribir un sistema de control. El agente sigue necesitando instrucciones claras, pero estas se convierten en un componente de un ciclo que se ejecuta según un horario, trabaja en una copia aislada de tu código, demuestra su propio resultado mediante una prueba y se detiene cuando se agota un presupuesto.

Por qué apareció el término en 2026

El nombre se está consolidando públicamente en este momento. El repositorio de GitHub cobusgreyling/loop-engineering superó las 9,600 estrellas en los dos meses posteriores a su primera aparición (en julio de 2026), con la frase «Deje de escribir prompts. Diseñe el bucle. Obtenga una puntuación». Recoge este cambio en seis bloques: planificación, worktrees, skills, plugins y conectores, subagentes y memoria persistente almacenada fuera de la conversación.

Cita a Boris Cherny, responsable de Claude Code en Anthropic:

Ya no escribo prompts para Claude. Tengo bucles que escriben prompts para Claude.

Un segundo repositorio, AI-Builder-Club/skills, se acerca a las 1,100 estrellas (en julio de 2026) y nombra directamente los dos roles: un «arnés de código» que prepara un repositorio para que un agente ejecute pruebas y despliegues de forma segura, y un «ingeniero de bucles» que crea flujos de trabajo que se activan mediante un desencadenador, realizan el trabajo y escriben lo aprendido en un archivo compartido para que el siguiente bucle pueda leerlo.

Ninguno de los dos repositorios inventó esta práctica. Cualquiera que haya ejecutado una compilación nocturna, un linter en integración continua o un trabajo de cron que abra un ticket ya conoce su estructura. La novedad es que el trabajador dentro del bucle ahora no es determinista, lo que cambia las funciones que debe desempeñar la infraestructura que lo rodea.

Las cuatro partes de un bucle

Todo bucle operativo tiene estas cuatro partes. Si falta una, puede terminar despertándolo a las 3am.

• Disparador. El evento que inicia una ejecución: un temporizador, un webhook, una nueva solicitud de incorporación o una alerta.
• Límite. Los archivos, las credenciales y la red a los que el agente puede acceder durante esa ejecución.
• Verificación. Una comprobación con un código de salida que determina si se conserva o se descarta el resultado de la ejecución.
• Presupuesto. El límite de tokens, tiempo y dinero que finaliza una ejecución, haya tenido éxito o no.

Si convierte esas cuatro partes en preguntas, tendrá una revisión de diseño para cualquier agente que vaya a dejar en ejecución.

Disparador: qué activa el agente

Un temporizador es el disparador más sencillo. En un servidor Linux, un temporizador de systemd es mejor que cron porque registra los eventos, reintenta según la configuración indicada y no inicia una segunda copia de una unidad que todavía está en ejecución. Esta última propiedad elimina el error de solapamiento más común en los bucles de los agentes: dos ejecuciones modificando la misma rama.

Escriba la unidad en /etc/systemd/system/agent-loop.service:

[Unit]
Description=Agent loop: triage open issues
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
User=agent
WorkingDirectory=/srv/agent/repo
ExecStart=/srv/agent/bin/loop.sh
TimeoutStartSec=1800

Y el temporizador en /etc/systemd/system/agent-loop.timer:

[Unit]
Description=Run the triage loop every 30 minutes

[Timer]
OnBootSec=5min
OnUnitActiveSec=30min
Unit=agent-loop.service

[Install]
WantedBy=timers.target

sudo systemctl daemon-reload
sudo systemctl enable --now agent-loop.timer
systemctl list-timers agent-loop.timer

systemctl list-timers debería mostrar una columna NEXT con una hora futura y una columna LEFT con la cuenta atrás. Un resultado vacío significa que el temporizador no está habilitado, porque enable sin --now lo programa sólo para el siguiente arranque. TimeoutStartSec=1800 es más importante de lo que parece: si un agente se bloquea esperando entrada, la unidad permanecerá activa indefinidamente y el temporizador no volverá a ejecutarse. Consulte una ejecución con journalctl -u agent-loop.service -n 50.

Si controla el bucle desde cron, añada su propio mecanismo para evitar solapamientos, porque cron iniciará sin problemas una segunda copia:

*/30 * * * * /usr/bin/flock -n /tmp/agent-loop.lock /srv/agent/bin/loop.sh

flock -n sale inmediatamente con el estado 1 cuando el bloqueo está retenido. Así, la segunda ejecución termina silenciosamente en lugar de competir con la primera. La misma configuración del servicio y el temporizador de systemd se aplica a cualquier tarea de larga duración del servidor, sea un agente o no.

Límite: cada ejecución debe tener su propia copia

Un agente que modifica el árbol de trabajo puede perder los cambios que aún no ha confirmado. Los worktrees de Git resuelven este problema con un coste bajo: cada ejecución obtiene su propio directorio y su propia rama, y todos comparten un único almacén de objetos.

cd /srv/agent/repo
git worktree add -b loop/triage-01 /srv/agent/work/triage-01 origin/main
git worktree list

git worktree list muestra una línea por cada árbol con su ruta, commit y rama. Cuando termina la ejecución, git worktree remove /srv/agent/work/triage-01 elimina el directorio y git worktree prune limpia las entradas cuyo directorio ha desaparecido. A partir de aquí, los bucles paralelos son seguros, porque dos agentes en dos ramas y dos directorios no pueden sobrescribirse entre sí.

El límite también se aplica a las credenciales. Un bucle que se ejecuta sin supervisión conserva tokens de larga duración, y cada ejecución puede filtrarlos en un registro, un commit o el contexto del modelo. Limite el token al único repositorio que utiliza el bucle. Cuando sea posible, manténgalo fuera del entorno que ve el shell del propio agente y lea cómo mantener los secretos fuera de los agentes de IA antes de conceder acceso a producción a un bucle. Para establecer una separación más estricta, ejecute todo el bucle en una VM desechable que pueda destruir después de cada ejecución. La herramienta que utilice también determina parte del límite antes de escribir nada, por lo que conviene leer cómo se compara el sandbox administrado de Cowork con Claude Code en su propia máquina antes de decidir cuánto aislamiento debe implementar usted mismo.

Verificación: el control que hace seguro el bucle

Esta es la diferencia entre un bucle y un trabajo de cron que escribe comandos. La salida del agente es una propuesta. El control decide.

#!/usr/bin/env bash
set -euo pipefail

repo=/srv/agent/repo
branch="loop/$(date -u +%Y%m%dT%H%M%SZ)"
tree="/srv/agent/work/$(basename "$branch")"

cd "$repo"
git fetch --quiet origin
git worktree add -b "$branch" "$tree" origin/main
cd "$tree"

# the agent's own command runs here, in non-interactive mode

if ! npm test; then
  echo "gate failed: discarding $branch" >&2
  cd "$repo"
  git worktree remove --force "$tree"
  exit 1
fi

git push origin "$branch"
cd "$repo"
git worktree remove "$tree"

set -euo pipefail realiza un trabajo real en ese script. Sin -e, se ignora un git fetch fallido y la ejecución continúa sobre un origin/main obsoleto. Sin -u, un error tipográfico en el nombre de una variable se expande a una cadena vacía y la limpieza se ejecuta sobre la ruta incorrecta en lugar de fallar de forma visible.

El bloque if ! npm test contiene toda la idea. El código de salida de una comprobación fiable, como la suite de pruebas o el comprobador de tipos, decide si la rama se publica o se elimina. Un bucle sin control produce trabajo que nadie tiene tiempo de revisar, lo cual es peor que no producir trabajo. Un bucle con control produce una rama que ya superó el mismo criterio que debe superar la rama de un colaborador humano. Un control correcto no indica cuánto código modificó el agente para llegar a ese resultado. Por eso conviene combinar la comprobación con una instrucción permanente como la regla que hace que un agente aplique el cambio funcional más pequeño, que mantiene el diff lo bastante pequeño para que revisarlo siga siendo barato.

Elija un control que falle de forma honesta. Una suite de pruebas que pasa con un diff vacío enseña al bucle que no hacer nada es un resultado válido. Los repositorios con pruebas débiles producen bucles débiles. Por eso los repositorios destacados ponen «preparar el código base para agentes» antes que «escribir el bucle». Si quiere saber si su suite detectaría realmente una regresión en lugar de limitarse a ejecutar las líneas, las pruebas de mutación son la comprobación que responde a esa pregunta. Un agente que devuelve un informe de evidencias que se puede volver a ejecutar, en lugar de pedirle que lea su diff, convierte esa respuesta en algo que puede confirmar por sí mismo.

Presupuesto: qué detiene una ejecución

Un agente que reintenta indefinidamente genera una factura sin límite. Dé a cada bucle un límite de tiempo de reloj, aplicado mediante TimeoutStartSec; establezca un número máximo de reintentos dentro del script; y configure un límite de gasto en la cuenta del proveedor. Después, registre el coste de cada ejecución para detectar una desviación del bucle antes de que aparezca en la factura. Control de costes para un VPS con un agente siempre activo trata el aspecto contable, y gestión del contexto que un agente conserva entre turnos cubre la palanca individual más importante para controlar el coste por ejecución, porque un bucle que vuelve a leer el mismo repositorio cada 30 minutos lo paga cada 30 minutos.

El coste es la razón por la que los bucles suelen ser preferibles a una sesión larga. Una ejecución que empieza desde cero, realiza una tarea concreta y termina mantiene reducido su contexto. Una sesión abierta durante ocho horas conserva en su historial todos los errores anteriores y paga todo el texto de la transcripción en cada turno.

Los patrones que codifican los repositorios de referencia

El repositorio loop-engineering enumera siete patrones de producción, y conviene leerlos como un menú, no como un manifiesto. Triage diario. Un asistente para pull requests que supervisa los comentarios de revisión y responde a ellos. Un proceso de CI que recoge las compilaciones fallidas. Un proceso de revisión de dependencias. Un generador de borradores de changelogs. Limpieza posterior a la integración. Triage de incidencias.

Todos tienen en común una tarea limitada y una condición de control evidente. «Corregir la compilación fallida» tiene una condición de aprobación que la máquina puede leer. «Mejorar la base de código» no la tiene, por lo que nunca se convierte en un bucle. Se convierte en un problema desordenado con una programación.

También tienen en común un registro escrito. Ambos repositorios sacan el estado de la conversación y lo guardan en archivos del repositorio: qué se ejecutó, qué encontró y qué decidió. Ese archivo es la memoria del bucle y permite que un segundo bucle continúe el trabajo del primero en lugar de descubrirlo de nuevo. También permite auditar un agente posteriormente, porque el contexto del modelo desaparece en cuanto termina la ejecución. La coordinación en tiempo real usa un canal independiente, y una sesión de Claude Code puede entregar trabajo a otra en el mismo equipo mientras ambas siguen ejecutándose, pero nada de ese intercambio permanece después de que termina cualquiera de las dos sesiones, por lo que el archivo sigue siendo la parte que se puede consultar más tarde.

Dónde fallan los bucles

Los fallos son previsibles y se repiten en distintos equipos.

• Sin control. La salida se acumula, nadie la revisa, se pierde la confianza y el bucle se desactiva.
• Solapamiento. Dos ejecuciones en una rama o dos agentes en el mismo árbol de trabajo generan conflictos que después el agente intenta resolver.
• Deriva silenciosa. El bucle sigue superando las comprobaciones porque el control es demasiado débil para detectar un fallo.
• Alcance sin límites. Un activador que se ejecuta con cada commit en un repositorio con mucha actividad se convierte en un problema de costes en un solo día.

Todos tienen la misma solución: reduzca la tarea, haga más precisa la comprobación y registre la ejecución. Si no puede describir la condición de aprobación en una sola frase, la tarea todavía no está preparada para automatizarse.

Primeros pasos sin terminología específica

No necesita un framework. Un servidor Linux pequeño y siempre activo, un repositorio de git cuyo conjunto de pruebas falle cuando debe fallar, un temporizador de systemd y un script de shell que incluya un if forman un ciclo completo. Ese es realmente el punto de partida adecuado para la mayoría, porque las cuestiones de diseño se resuelven ejecutando el sistema y no eligiendo una herramienta. Cuando un ciclo es estable, ejecutar un segundo ciclo consiste principalmente en añadir otro temporizador y otro worktree. Consulte cómo ejecutar un agente de IA para programación en un VPS para la configuración básica y las opciones actuales de agentes de IA autoalojados si quiere ejecutar el propio agente en hardware que controla.

FAQ

¿La ingeniería de bucles es diferente de la ingeniería de prompts?

La ingeniería de prompts optimiza un mensaje: redacción, ejemplos y formato de salida. La ingeniería de bucles optimiza el ciclo que rodea al mensaje: el activador que inicia una ejecución, el sandbox donde se ejecuta, la comprobación que acepta o rechaza su salida y el presupuesto que la finaliza. Dentro del bucle sigue siendo necesario un buen prompt. El prompt deja de ser el elemento que se ajusta a diario, porque el gate y el activador tienen más efecto en el resultado.

¿Necesito un framework para crear un bucle de agente?

No. Un temporizador de systemd, un git worktree por ejecución, un script de shell que termine con un comando de prueba y un límite de gasto en la cuenta del proveedor cubren todos los elementos de la definición. Los frameworks añaden interfaces de planificación, formatos de memoria compartida y enrutamiento entre varios agentes, que resultan útiles cuando se ejecutan varios bucles. No son un requisito para crear el primero.

¿Qué es un harness para un codebase?

Es el conjunto de elementos que permite a un agente trabajar en un repositorio sin una persona presente: una configuración que se ejecuta con un solo comando, pruebas que se ejecutan de forma no interactiva y fallan de forma visible, un linter y una forma de desplegar o previsualizar un cambio. El término procede de la misma ola de repositorios de 2026 que la ingeniería de bucles. La prueba práctica es sencilla: si un nuevo colaborador humano no puede pasar del clone a las pruebas en verde con un solo comando, un agente tampoco puede.

¿Cómo evito que un bucle de agente genere una factura elevada?

Establezca límites en tres lugares. Configure TimeoutStartSec en la unidad de systemd para que una ejecución bloqueada termine. Limite los reintentos dentro del script en lugar de repetirlos hasta obtener éxito. Establezca un límite de gasto estricto en la cuenta de la API, porque ese es el único límite que el agente no puede superar mediante argumentos. Después, registre el coste de cada ejecución, porque un bucle cuyo coste se duplica suele ser un bucle cuyo alcance se ha ampliado sin que nadie lo advierta.

¿Qué trabajos conviene convertir primero en un bucle?

Elija un trabajo con una condición de éxito legible por una máquina y un radio de impacto reducido. Corregir una build fallida, actualizar una dependencia y regenerar un changelog cumplen esos requisitos, porque una suite de pruebas o un diff pueden demostrar el resultado. El trabajo abierto, como una refactorización o un diseño, todavía no cumple esos requisitos, porque no hay nada que el gate pueda comprobar y un bucle sin gate es una forma costosa de generar deuda de revisión.