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 ahora mismo. El repositorio de GitHub cobusgreyling/loop-engineering superó las 9,600 estrellas en los dos primeros meses desde su aparición (a fecha de julio de 2026) y mostraba unas 11,600 el 2026-10-27, bajo la frase "Deja de escribir prompts. Diseña el bucle. Obtén una puntuación." En julio de 2026, su README agrupaba el cambio en seis bloques: programación, worktrees, skills, plugins y conectores, subagentes y memoria persistente almacenada fuera de la conversación. El README actual ya no incluye esa lista (comprobado el 2026-10-27), pero sigue guardando el estado del bucle en un archivo fuera de la conversación.

El repositorio menciona a Boris Cherny, responsable de Claude Code en Anthropic, como una de sus inspiraciones. La frase que se ha citado ampliamente es:

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,300 estrellas (a fecha de 2026-10-27) y nombra directamente los dos roles: un "arnés para el código base" 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 con 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 cron job que abra un ticket ya conoce el patrón. Lo nuevo es que el trabajador dentro del bucle ahora es no determinista, lo que cambia las tareas que debe realizar 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.

Activador: qué despierta al agente

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

Cree primero un usuario exclusivo para el agente. Ese usuario forma parte del límite de seguridad, por lo que es propietario de /srv/agent y de nada más:

sudo useradd --system --home-dir /srv/agent --shell /usr/sbin/nologin agent
sudo chown -R agent:agent /srv/agent

Después 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. Un servicio Type=oneshot se considera iniciado hasta que termina su script. Además, systemd desactiva de forma predeterminada el tiempo de espera de inicio para las unidades oneshot. Sin esta línea, un agente bloqueado mientras espera una entrada mantiene la unidad atascada para siempre en el estado de activación. Cada ejecución posterior del temporizador la encuentra todavía en ejecución y no inicia nada. Con la línea configurada, systemd termina la ejecución después de 30 minutos y la marca como fallida. Si alguna vez cambia la unidad al valor predeterminado Type=simple, TimeoutStartSec ya no cubre la ejecución en sí y RuntimeMaxSec= es la configuración que establece su límite. Consulte una ejecución con journalctl -u agent-loop.service -n 50.

Si controla el bucle con 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 termina inmediatamente con el estado 1 cuando el bloqueo está retenido. Así, la segunda ejecución desaparece sin competir con la primera. La misma configuración de servicio y temporizador de systemd se aplica a cualquier trabajo de larga duración en el equipo, use o no un agente.

Límite: dé a cada ejecución su propia copia

Un agente que edita su árbol de trabajo puede perder el trabajo 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 imprime 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 worktree, pero sólo si está limpio. Si el árbol contiene archivos sin seguimiento o archivos seguidos modificados, o contiene submódulos, git se niega hasta que se añade --force. Por eso, el script de control siguiente fuerza la eliminación sólo en la ruta que descarta la ejecución. git worktree prune elimina 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 incluye las credenciales. Un bucle que se ejecuta sin supervisión conserva tokens de larga duración, y cada ejecución ofrece una oportunidad de filtrarlos en un registro, un commit o el contexto de un modelo. Limite el token al único repositorio que toca el bucle y, cuando sea posible, manténgalo fuera del entorno que ve el shell del propio agente. Lea cómo mantener los secretos fuera de los agentes de IA antes de dar acceso de 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 ejecute también determina parte del límite antes de escribir nada, por lo que conviene leer cómo se compara el sandbox gestionado de Cowork con Claude Code en su propia máquina antes de decidir cuánto aislamiento debe configurar usted mismo.

Verificación: el control que hace segura la iteración

Esta es la parte que distingue una iteración de un trabajo 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 contra 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 explícita. La última línea no tiene --force a propósito: si la ejecución dejó archivos sin seguimiento o sin confirmar en el árbol, git se niega a eliminarlo y -e termina la ejecución con un error después del push, en lugar de borrar en silencio trabajo que nadie confirmó.

El bloque if ! npm test contiene la idea completa. El código de salida de una comprobación en la que ya confía, como la suite de pruebas o el comprobador de tipos, decide si la rama se publica o se destruye. Una iteración sin control produce trabajo que nadie tiene tiempo de revisar, lo que es peor que no producir trabajo. Una iteración con control produce una rama que ya superó el mismo nivel 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 lo que conviene combinar la comprobación con una instrucción permanente como la regla que hace que un agente aplique el cambio más pequeño que funciona, para mantener el diff lo bastante pequeño y que su revisión siga siendo económica.

Elija un control que falle de forma fiable. Una suite de pruebas que pasa con un diff vacío enseña a la iteración que no hacer nada es un resultado correcto. Los repositorios con pruebas débiles generan iteraciones débiles. Por eso, los repositorios destacados sitúan «preparar el código para los agentes» antes de «escribir la iteración». 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. Además, 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 su cuenta.

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 en tendencia

El repositorio sobre ingeniería de bucles enumera ocho patrones de producción (a fecha de 2026-10-27), y conviene leerlos como un menú, no como un manifiesto. Triaje diario. Un bucle ligero que se ejecuta como GitHub Action y no conserva ningún archivo de estado. Un asistente de pull requests que monitoriza los comentarios de revisión y responde a ellos. Un proceso de revisión de integración continua que recoge las compilaciones fallidas. Un proceso de revisión de dependencias. Un redactor de changelogs. Limpieza posterior a la fusión. Triaje de issues.

Todos comparten una tarea acotada con una condición de validación clara. "Corregir la compilación fallida" tiene una condición de éxito que la máquina puede leer. "Mejorar el código base" no la tiene, por lo que nunca se convierte en un bucle. Se convierte en un problema con una programación.

También comparten 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 redescubrirlo. También permite auditar posteriormente a un agente, porque el contexto del modelo desaparece en cuanto termina la ejecución. La coordinación en tiempo real utiliza un canal independiente, y una sesión de Claude Code puede pasar trabajo a otra en el mismo equipo mientras ambas siguen ejecutándose, pero nada de ese intercambio sobrevive a ninguna de las dos sesiones, por lo que el archivo sigue siendo la parte que se puede consultar después.

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 entorno aislado donde se ejecuta, la comprobación que acepta o rechaza su salida y el presupuesto que la finaliza. El bucle sigue necesitando un prompt adecuado. Sin embargo, el prompt deja de ser el elemento que se ajusta a diario, porque el control y el activador influyen más 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. Son útiles cuando se ejecutan varios bucles, pero no son un requisito de entrada para el primero.

¿Qué es un arnés para una base de código?

Es el conjunto de elementos que permite a un agente trabajar en un repositorio sin una persona presente: una configuración de un solo comando, pruebas que se ejecutan de forma no interactiva y fallan de forma explícita, un linter y un método para 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 de clonar el repositorio a obtener pruebas correctas 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 una unidad de systemd Type=oneshot como la anterior para terminar una ejecución bloqueada. En un servicio Type=simple, el equivalente es RuntimeMaxSec. Limite los reintentos dentro del script en lugar de repetir hasta obtener un resultado correcto. Establezca un límite de gasto estricto en la cuenta de la API, ya que 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 de forma silenciosa.

¿Qué trabajos conviene convertir primero en un bucle?

Elija un trabajo con una condición de aprobación legible por una máquina y un radio de impacto pequeño. Corregir una compilación fallida, actualizar una dependencia y regenerar un changelog son opciones válidas, porque una suite de pruebas o un diff puede demostrar el resultado. El trabajo abierto, como la refactorización o el diseño, todavía no es adecuado, porque no hay nada que el control pueda comprobar. Un bucle sin control es una forma costosa de generar deuda de revisión.