Cos'è la loop engineering: definizione e componenti

Cosa significa progettare il ciclo

La progettazione del ciclo consiste nel definire il ciclo ripetitivo eseguito da un agente AI: cosa lo attiva, su cosa può intervenire, come viene verificato il suo output e cosa lo arresta. La progettazione dei prompt definisce un singolo messaggio per un modello. La progettazione del ciclo definisce il processo che invia migliaia di messaggi mentre dormi. L'unità di lavoro passa dal prompt al ciclo.

In breve: smetti di scrivere istruzioni e inizi a progettare un sistema di controllo. L'agente ha ancora bisogno di istruzioni valide, ma queste diventano un componente di un ciclo che viene eseguito secondo una pianificazione, opera su una copia isolata del codice, dimostra il risultato eseguendo un test e si arresta quando esaurisce il budget.

Perché il termine è comparso nel 2026

Il nome si sta affermando pubblicamente proprio ora. Il repository GitHub cobusgreyling/loop-engineering ha superato 9,600 stelle nei primi due mesi dalla comparsa (a luglio 2026), con lo slogan "Stop prompting. Design the loop. Get a score.". Raccoglie questo cambiamento in sei componenti fondamentali: pianificazione, worktree, competenze, plugin e connettori, sub-agenti e memoria persistente conservata al di fuori della conversazione.

Cita Boris Cherny, responsabile di Claude Code presso Anthropic:

Non invio più prompt a Claude. Ho loop in esecuzione che inviano prompt a Claude.

Un secondo repository, AI-Builder-Club/skills, si avvicina a 1,100 stelle (a luglio 2026) e definisce direttamente i due ruoli: un "codebase harness" che rende un repository sicuro per consentire a un agente di eseguire test e deploy, e un "loop engineer" che crea workflow che si attivano in risposta a un trigger, eseguono il lavoro e scrivono ciò che hanno appreso in un file condiviso, in modo che il loop successivo possa leggerlo.

Nessuno dei due repository ha inventato questa pratica. Chiunque abbia eseguito una build notturna, un linter nell'integrazione continua o un cron job che apre un ticket ne conosce già la struttura. La novità è che ora il worker all'interno del loop è non deterministico. Questo cambia ciò che deve fare l'infrastruttura circostante.

Le quattro parti di un ciclo

Ogni ciclo funzionante ha queste quattro parti. Se ne salta una, il ciclo può riattivarsi alle 3am.

• Trigger. L'evento che avvia un'esecuzione: un timer, un webhook, una nuova pull request, un alert.
• Boundary. I file, le credenziali e la rete a cui l'agent può accedere durante l'esecuzione.
• Verification. Un controllo con un exit code che decide se l'output dell'esecuzione viene conservato o scartato.
• Budget. Il limite di token, tempo e denaro che termina l'esecuzione, indipendentemente dal fatto che abbia avuto successo.

Riformulate queste quattro parti come domande: otterrete una revisione del progetto per qualsiasi agent che state per lasciare in esecuzione.

Trigger: cosa attiva l'agent

Un timer è il trigger più semplice. Su un server Linux, un timer systemd è preferibile a cron perché registra gli eventi, riprova secondo i criteri configurati e non avvia una seconda copia di un'unità ancora in esecuzione. Quest'ultima proprietà elimina il problema di sovrapposizione più comune nei loop dell'agent: due esecuzioni che modificano lo stesso branch.

Scrivi l'unità in /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

E il timer in /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 dovrebbe mostrare una colonna NEXT con un orario futuro e una colonna LEFT con il conto alla rovescia. Un risultato vuoto significa che il timer non è abilitato, perché enable senza --now lo pianifica solo per il boot successivo. TimeoutStartSec=1800 è più importante di quanto sembri: se un agent resta bloccato in attesa di input, l'unità rimane altrimenti attiva per sempre e il timer non verrà più attivato. Leggi un'esecuzione con journalctl -u agent-loop.service -n 50.

Se invece avvii il loop da cron, aggiungi un controllo personalizzato per impedire le sovrapposizioni, perché cron avvierà senza problemi una seconda copia:

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

flock -n termina immediatamente con lo stato 1 quando il lock è acquisito, quindi la seconda esecuzione termina senza produrre output invece di entrare in conflitto con la prima. La stessa configurazione del servizio e del timer systemd si applica a qualsiasi job a esecuzione prolungata sul server, che sia un agent oppure no.

Isolamento: assegna a ogni esecuzione una copia distinta

Un agente che modifica la working tree può sovrascrivere il lavoro non sottoposto a commit. I worktree di Git risolvono il problema con un costo ridotto: ogni esecuzione riceve una directory e un branch propri, condividendo lo stesso object store.

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

git worktree list stampa una riga per ogni tree, con relativo percorso, commit e branch. Al termine dell'esecuzione, git worktree remove /srv/agent/work/triage-01 elimina la directory e git worktree prune rimuove le voci la cui directory non esiste più. A questo punto i cicli paralleli sono sicuri, perché due agenti che lavorano su due branch e in due directory diverse non possono sovrascriversi a vicenda.

L'isolamento riguarda anche le credenziali. Un ciclo eseguito senza supervisione contiene token di lunga durata, e ogni esecuzione può esporne uno in un log, in un commit o nel contesto del modello. Limita il token al solo repository utilizzato dal ciclo, impedisci, quando possibile, che sia presente nell'ambiente visibile alla shell dell'agente e leggi come impedire che i segreti raggiungano gli agenti AI prima di assegnare a un ciclo l'accesso alla produzione. Per ottenere un isolamento maggiore, esegui l'intero ciclo su una VM temporanea da eliminare dopo ogni esecuzione.

Verifica: il controllo che rende sicuro il ciclo

Questa è la parte che distingue un ciclo da un cron job che digita comandi. L'output dell'agente è una proposta. Il controllo 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 svolge un lavoro reale in quello script. Senza -e, un git fetch non riuscito viene ignorato e l'esecuzione continua usando un origin/main obsoleto. Senza -u, un errore di battitura nel nome di una variabile viene sostituito da una stringa vuota e la pulizia viene quindi eseguita sul percorso errato invece di interrompersi con un errore evidente.

Il blocco if ! npm test contiene l'idea fondamentale. Il codice di uscita di un controllo di cui ti fidi già, la suite di test o il type checker, decide se il branch viene inviato o eliminato. Un ciclo senza controllo produce lavoro che nessuno ha tempo di esaminare, ed è peggio di non produrre alcun lavoro. Un ciclo con un controllo produce un branch che ha già superato lo stesso livello richiesto al branch di un contributore umano.

Scegli un controllo che segnali correttamente gli errori. Una suite di test che passa con un diff vuoto insegna al ciclo che non fare nulla è un risultato positivo. I repository con test poco efficaci producono cicli poco efficaci. Per questo i repository più popolari mettono "rendere il codebase pronto per gli agenti" prima di "scrivere il ciclo".

Budget: ce qui limite une exécution

Un agent qui réessaie indéfiniment génère une facture sans limite. Attribuez à chaque boucle une limite de temps réelle, imposée par TimeoutStartSec ci-dessus, un nombre de tentatives dans votre script et un plafond de dépenses imposé par le compte du fournisseur. Consignez ensuite le coût de chaque exécution afin de détecter la dérive d’une boucle avant l’arrivée de la facture. Contrôle des coûts pour un VPS d’agent toujours actif traite le suivi comptable, tandis que gestion du contexte conservé par un agent entre les tours traite le principal levier du coût par exécution : une boucle qui relit le même dépôt toutes les 30 minutes le paie toutes les 30 minutes.

Le coût explique pourquoi les boucles sont généralement préférables à une longue session. Une exécution qui démarre avec un contexte vierge, effectue une tâche précise, puis se termine conserve un contexte réduit. Une session laissée ouverte pendant huit heures conserve dans son historique toutes les erreurs précédentes et paie l’intégralité de la transcription à chaque tour.

I pattern codificati dai repository di tendenza

Il repository loop-engineering elenca sette pattern per la produzione, che vale la pena leggere come un menu, non come un manifesto. Triage giornaliero. Un assistente per le pull request che monitora i commenti di revisione e risponde. Un processo di pulizia dell'integrazione continua che rileva le build con esito negativo. Un processo di pulizia delle dipendenze. Una bozza del changelog. Pulizia post-merge. Triage delle issue.

Tutti hanno in comune un compito circoscritto con un criterio di passaggio chiaro. "Correggere la build che non riesce" ha una condizione di superamento che la macchina può leggere. "Migliorare la codebase" no, quindi non diventa mai un loop. Diventa un insieme disordinato di attività con una pianificazione.

Hanno anche una registrazione scritta. Entrambi i repository spostano lo stato fuori dalla conversazione e lo inseriscono nei file del repository: cosa è stato eseguito, cosa è stato rilevato, quale decisione è stata presa. Quel file è la memoria del loop e consente a un secondo loop di basarsi sul lavoro del primo invece di riscoprirlo. È anche il modo per verificare a posteriori l'operato di un agente, perché il contesto del modello scompare non appena l'esecuzione termina.

Dove falliscono i cicli

I problemi sono banali e si ripetono tra i team.

• Nessun controllo. L'output si accumula, nessuno lo esamina, la fiducia crolla e il ciclo viene disattivato.
• Sovrapposizione. Due esecuzioni sullo stesso branch o due agenti nello stesso working tree producono conflitti che l'agente tenta poi di risolvere.
• Deriva silenziosa. Il ciclo continua a superare i controlli perché la verifica è troppo debole per rilevare un errore.
• Ambito illimitato. Un trigger che si attiva a ogni commit in un repository molto utilizzato diventa un problema di costi entro un giorno.

La soluzione è sempre la stessa: ridurre il lavoro, rendere il controllo più rigoroso e registrare l'esecuzione. Se non sai descrivere in una frase la condizione di superamento, il lavoro non è pronto per essere automatizzato.

Primi passi senza conoscere la terminologia

Non serve un framework. Un piccolo server Linux sempre attivo, un repository Git la cui suite di test fallisce quando dovrebbe, un timer systemd e uno script shell che contiene un if formano un ciclo completo. È davvero da qui che la maggior parte delle persone dovrebbe iniziare, perché le domande di progettazione trovano risposta eseguendo il sistema, non scegliendo uno strumento. Quando un ciclo è stabile, eseguirne un secondo richiede soprattutto un altro timer e un altro worktree. Consulta come eseguire un agente di coding basato sull’AI su un VPS per la configurazione di base e le opzioni attuali per gli agenti AI self-hosted se vuoi eseguire l’agente stesso su hardware sotto il tuo controllo.

FAQ

L'ingegneria dei loop è diversa dall'ingegneria dei prompt?

L'ingegneria dei prompt ottimizza un singolo messaggio: formulazione, esempi e formato dell'output. L'ingegneria dei loop ottimizza il ciclo che circonda il messaggio: il trigger che avvia un'esecuzione, la sandbox in cui viene eseguita, il controllo che accetta o rifiuta l'output e il budget che la interrompe. Nel loop serve comunque un buon prompt. Tuttavia, il prompt non è più l'elemento da ottimizzare giorno per giorno, perché il gate e il trigger hanno un effetto maggiore sul risultato.

Serve un framework per creare un loop di agent?

No. Un timer di systemd, un git worktree per ogni esecuzione, uno script shell che termina con un comando di test e un limite di spesa sull'account del provider coprono ogni parte della definizione. I framework aggiungono interfacce di pianificazione, formati per la memoria condivisa e instradamento tra più agent, utili quando si eseguono diversi loop. Non sono però un requisito iniziale per il primo loop.

Che cos'è un harness per una codebase?

È l'insieme degli elementi che consentono a un agent di lavorare in un repository senza la presenza di una persona: una configurazione eseguibile con un solo comando, test eseguibili senza interazione che segnalano chiaramente gli errori, un linter e un metodo per eseguire il deploy o visualizzare in anteprima una modifica. Il termine deriva dalla stessa ondata di repository del 2026 da cui proviene l'ingegneria dei loop. Il test pratico è semplice: se un nuovo contributore umano non riesce a passare dal clone a test superati con un solo comando, non può riuscirci neppure un agent.

Come posso impedire a un loop di agent di generare una fattura elevata?

Imposta un limite in tre punti. Configura TimeoutStartSec sull'unità systemd, in modo che un'esecuzione bloccata venga terminata. Limita i retry nello script, invece di eseguire il loop fino al successo. Imposta un limite di spesa rigido sull'account API, perché è l'unico limite che l'agent non può aggirare con le parole. Registra poi il costo di ogni esecuzione, perché un loop il cui costo raddoppia di solito è un loop il cui ambito si è ampliato senza che nessuno lo notasse.

Quali attività conviene trasformare per prime in un loop?

Scegli un'attività con una condizione di superamento leggibile dalla macchina e un raggio d'azione ridotto. La correzione di una build non riuscita, l'aggiornamento di una dipendenza e la rigenerazione di un changelog sono attività adatte, perché una suite di test o un diff possono dimostrare il risultato. Le attività non delimitate, come il refactoring o la progettazione, non sono ancora adatte, perché non esiste nulla che il gate possa verificare; inoltre, un loop senza gate è un metodo costoso per accumulare debito di revisione.