Qué es la ingeniería de bucles en agentes de IA

Qué significa la ingeniería de bucles

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

En resumen: deja de escribir instrucciones y empieza a escribir un sistema de control. El agente sigue necesitando instrucciones adecuadas, pero estas se convierten en un componente de un ciclo que se ejecuta según un horario, trabaja en una copia aislada de su 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á fijando públicamente en este momento. El repositorio de GitHub cobusgreyling/loop-engineering superó las 9,600 estrellas en los dos meses posteriores a su aparición inicial (a fecha de julio de 2026), con el lema "Stop prompting. Design the loop. Get a score." Reúne este cambio en seis componentes: programació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 (a fecha de julio de 2026) y nombra directamente los dos roles: un "codebase harness" que prepara un repositorio para que un agente ejecute pruebas y despliegues de forma segura, y un "loop engineer" 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 cron job que abra un ticket ya conoce esta estructura. Lo nuevo es que el worker del bucle ahora es no determinista, lo que cambia las funciones que debe realizar la infraestructura que lo rodea.

Las cuatro partes de un bucle

Todo bucle operativo tiene estas cuatro partes. Si falta una, el bucle puede despertarte a las 3am.

• Disparador. El evento que inicia una ejecución: un temporizador, un webhook, una nueva solicitud de incorporación, 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, tenga éxito o no.

Si conviertes esas cuatro partes en preguntas, tienes una revisión de diseño para cualquier agente que vayas a dejar en ejecución.

Activador: qué inicia el agente

Un temporizador es el activador más sencillo. En un servidor Linux, un temporizador de systemd es mejor que cron en este caso porque registra la actividad, permite configurar los reintentos 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 agentes: dos ejecuciones editando 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 debe mostrar una columna NEXT con una hora futura y una columna LEFT con una cuenta regresiva. Un resultado vacío significa que el temporizador no está habilitado, porque enable sin --now lo programa solo para el siguiente arranque. TimeoutStartSec=1800 es más importante de lo que parece: si un agente se bloquea esperando una entrada, la unidad permanecerá activa indefinidamente y el temporizador no volverá a activarse. Consulte una ejecución con journalctl -u agent-loop.service -n 50.

Si ejecuta 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 trabajo de larga duración en el equipo, independientemente de que sea un agente o no.

Límite: cada ejecución tiene su propia copia

Un agente que modifica tu árbol de trabajo puede perder el trabajo sin confirmar. Los worktrees de Git resuelven este problema de forma económica: cada ejecución obtiene su propio directorio y su propia rama, y comparte 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 ya no existe. A partir de este punto, 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 de un modelo. Limita el token al único repositorio que utiliza el bucle, evita que esté en el entorno que puede ver el propio shell del agente cuando sea posible y lee cómo mantener los secretos fuera de los agentes de IA antes de conceder acceso de producción a un bucle. Para obtener una separación más estricta, ejecuta todo el bucle en una VM desechable que puedas destruir después de cada ejecución.

Verificación: el control que hace seguro el bucle

Esta es la parte que distingue un bucle de 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 usando 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 contra la ruta incorrecta en lugar de fallar de forma explícita.

El bloque if ! npm test contiene toda la idea. El código de salida de una comprobación en la que ya confías, como tu conjunto de pruebas o tu 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 que 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.

Elige un control que falle correctamente. Un conjunto de pruebas que pasa con un diff vacío enseña al bucle que no hacer nada es un resultado correcto. Los repositorios con pruebas débiles producen bucles débiles. Por eso, los repositorios en tendencia colocan «preparar el código para agentes» antes de «escribir el bucle».

Presupuesto: qué detiene una ejecución

Un agente que reintenta indefinidamente genera una factura sin límite. Establece para cada bucle un límite de tiempo real, aplicado por TimeoutStartSec; un número máximo de reintentos dentro del script; y un límite de gasto aplicado por la cuenta del proveedor. Registra también el costo de cada ejecución para detectar que un bucle se desvía antes de que llegue la factura. Control de costos para un VPS de agente siempre activo explica la contabilidad, y gestión del contexto que un agente conserva entre turnos explica la principal variable individual del costo por ejecución, porque un bucle que vuelve a leer el mismo repositorio cada 30 minutos lo factura cada 30 minutos.

El costo es una de las razones por las que los bucles suelen ser mejores que una sesión larga. Una ejecución que empieza desde cero, realiza una tarea específica y termina mantiene pequeño el contexto. Una sesión abierta durante ocho horas conserva en su historial todos los errores anteriores y cobra toda la transcripción en cada turno.

Los patrones que codifican los repositorios en tendencia

El repositorio loop-engineering enumera siete patrones de producción. Conviene leerlos como un menú, no como un manifiesto. Clasificación diaria de incidencias. Un asistente de pull requests que supervisa los comentarios de revisión y responde a ellos. Un proceso de limpieza de integración continua que recoge las compilaciones fallidas. Un proceso de limpieza de dependencias. Un redactor de registros de cambios. Limpieza posterior a la combinación. Clasificación de incidencias.

Todos tienen en común una tarea concreta 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 tienen en común un registro escrito. Ambos repositorios extraen 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. Permite que un segundo bucle aproveche el trabajo del primero en lugar de volver a descubrirlo. También permite auditar un agente posteriormente, porque el contexto del modelo desaparece en cuanto termina la ejecución.

Dónde fallan los bucles

Los fallos son poco llamativos y se repiten en distintos equipos.

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

Todos tienen la misma solución: reduzca el trabajo, haga más precisa la comprobación y registre la ejecución. Si no puede describir la condición de éxito en una sola frase, el trabajo aún no está listo para automatizarse.

Primeros pasos sin la terminología

No necesita un framework. Un pequeño servidor Linux siempre encendido, un repositorio git cuyo conjunto de pruebas falle cuando debe fallar, un temporizador de systemd y un script de shell que contenga un if forman un ciclo completo. Ese es realmente el punto de partida adecuado para la mayoría, porque las decisiones 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 de 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

¿Es diferente la ingeniería de bucles 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 el 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. El prompt debe seguir siendo bueno dentro del bucle. Sin embargo, 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 programación, formatos de memoria compartida y enrutamiento entre varios agentes. Son útiles cuando se ejecutan varios bucles. No son un requisito inicial para crear el primero.

¿Qué es un arnés para un codebase?

Es el conjunto de elementos que permite a un agente trabajar en un repositorio sin la presencia de una persona: una configuración de un solo comando, pruebas que se ejecutan de forma no interactiva y fallan de forma explícita, un linter y una forma de desplegar o previsualizar un cambio. El término procede de la misma oleada 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 clon del repositorio a unas pruebas correctas con un solo comando, un agente tampoco puede hacerlo.

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

Establece límites en tres lugares. Configura TimeoutStartSec en la unidad de systemd para que una ejecución bloqueada finalice. Limita los reintentos dentro del script en lugar de repetirlos hasta obtener éxito. Establece un límite de gasto estricto en la cuenta de la API, porque ese es el único límite que el agente no puede eludir mediante argumentos. Después, registra el coste de cada ejecución, porque un bucle cuyo coste se duplica normalmente es un bucle cuyo alcance se amplió de forma silenciosa.

¿Qué trabajos conviene convertir primero en un bucle?

Elige un trabajo con una condición de aprobación legible por una máquina y un radio de impacto reducido. Corregir una compilación fallida, actualizar una dependencia y regenerar un changelog son opciones adecuadas, porque un conjunto 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.