Che cos'è la progettazione di un loop AI?

Cosa significa progettare un loop

La progettazione di un loop consiste nel definire il ciclo ripetitivo eseguito da un agente AI: cosa lo attiva, quali risorse può modificare, come viene verificato il suo output e cosa ne interrompe l'esecuzione. La progettazione dei prompt modella un singolo messaggio inviato a un modello. La progettazione del loop modella il processo che invia migliaia di messaggi mentre dormi. L'unità di lavoro passa dal prompt al loop.

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 eseguito secondo una pianificazione, che opera su una copia isolata del codice, verifica il proprio risultato tramite un test e si interrompe 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 sua comparsa (a luglio 2026), con lo slogan "Stop prompting. Design the loop. Get a score.". Raccoglie questo cambiamento in sei elementi costitutivi: pianificazione, worktree, competenze, plugin e connettori, sub-agent e memoria persistente conservata al di fuori della conversazione.

Riporta una citazione di Boris Cherny, responsabile di Claude Code presso Anthropic:

Non scrivo più prompt per Claude. Ho loop che scrivono prompt per Claude.

Un secondo repository, AI-Builder-Club/skills, si avvicina a 1,100 stelle (a luglio 2026) e identifica direttamente i due ruoli: un "codebase harness" che rende un repository sicuro per consentire a un agente di eseguire test e deployment, 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 le funzioni che deve svolgere l'infrastruttura circostante.

Le quattro parti di un loop

Ogni loop funzionante ha queste quattro parti. Se ne manca una, il loop può svegliarti alle 3 del mattino.

• Trigger. L’evento che avvia un’esecuzione: un timer, un webhook, una nuova pull request o un alert.
• Boundary. I file, le credenziali e la rete che l’agent può raggiungere durante quell’esecuzione.
• Verification. Un controllo con un codice di uscita che determina se l’output dell’esecuzione viene conservato o eliminato.
• Budget. Il limite di token, tempo e denaro che termina l’esecuzione, indipendentemente dal fatto che abbia avuto successo.

Rileggi questi quattro elementi sotto forma di domande: otterrai una revisione della progettazione per qualsiasi agent che stai per lasciare in esecuzione.

Trigger: cosa risveglia l'agente

Un timer è il trigger più semplice. Su un server Linux, un timer systemd è preferibile a cron perché registra gli eventi, riprova secondo le impostazioni definite e non avvia una seconda istanza di un'unità ancora in esecuzione. Quest'ultima caratteristica elimina il problema di sovrapposizione più comune nei loop degli agenti: 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 indica che il timer non è abilitato, perché enable senza --now lo pianifica soltanto per il boot successivo. TimeoutStartSec=1800 è più importante di quanto sembri: se un agente resta bloccato in attesa di input, l'unità rimane altrimenti attiva per sempre e il timer non viene più eseguito. Per leggere un'esecuzione, usa journalctl -u agent-loop.service -n 50.

Se invece usi cron per eseguire il loop, aggiungi un controllo personalizzato per impedire le sovrapposizioni, perché cron avvia senza problemi una seconda istanza:

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

flock -n termina immediatamente con stato 1 quando il lock è già detenuto. In questo modo la seconda esecuzione termina senza produrre output e non entra in conflitto con la prima. La stessa configurazione di un service e di un timer systemd si applica a qualsiasi processo di lunga durata sul server, indipendentemente dal fatto che sia un agente.

Confine: assegnate a ogni esecuzione una copia separata

Un agent che modifica il working tree può sovrascrivere il lavoro non ancora sottoposto a commit. I worktree di Git risolvono il problema con costi ridotti: ogni esecuzione riceve una directory e un branch propri, condividendo un unico 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 loop paralleli diventano sicuri, perché due agent che operano su due branch in due directory diverse non possono sovrascriversi a vicenda.

Il confine riguarda anche le credenziali. Un loop eseguito senza supervisione conserva token di lunga durata e ogni esecuzione può esporne uno in un log, in un commit o nel contesto del modello. Limitate il token all'unico repository toccato dal loop, impedite quando possibile che sia presente nell'ambiente visibile alla shell dell'agent e consultate come impedire che i secret siano esposti agli agent AI prima di concedere a un loop l'accesso all'ambiente di produzione. Per una separazione più rigida, eseguite l'intero loop su una VM usa e getta da eliminare dopo ogni esecuzione. Anche lo strumento scelto definisce parte del confine prima ancora di scrivere il loop; conviene quindi leggere come il sandbox gestito di Cowork si confronta con Claude Code sul proprio computer prima di decidere quanta parte dell'isolamento implementare autonomamente.

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 effettivo 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 espanso in una stringa vuota e la pulizia viene quindi eseguita sul percorso errato invece di terminare con un errore esplicito.

Il blocco if ! npm test contiene l’intera idea. Il codice di uscita di un controllo già affidabile, ad esempio la suite di test o il type checker, decide se il branch viene pubblicato oppure eliminato. Un ciclo senza controllo produce lavoro che nessuno ha il tempo di revisionare, ed è peggio che 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. Un controllo superato non dice nulla sulla quantità di codice modificata dall’agente. Per questo conviene associarlo a un’istruzione permanente come la regola che impone all’agente di applicare la modifica minima funzionante, così il diff resta abbastanza piccolo da poter essere revisionato rapidamente.

Scegli un controllo che segnali correttamente gli errori. Una suite di test che supera l’esecuzione su un diff vuoto insegna al ciclo che non fare nulla è un risultato positivo. I repository con test deboli producono cicli deboli. Per questo i repository più seguiti mettono “rendere il codebase pronto per gli agenti” prima di “scrivere il ciclo”. Se vuoi sapere se la suite rileverebbe davvero una regressione invece di limitarsi a eseguire le righe interessate, il mutation testing è il controllo che fornisce la risposta. Un agente che restituisce un report di evidenze rieseguibile invece di chiederti di leggere il diff trasforma inoltre quella risposta in qualcosa che puoi verificare autonomamente.

Budget: cosa interrompe un'esecuzione

Un agente che ritenta senza fine genera costi senza limite. Imposta per ogni ciclo un limite basato sul tempo reale, applicato tramite TimeoutStartSec, un numero massimo di tentativi nello script e un limite di spesa imposto dall'account del provider. Registra poi il costo di ogni esecuzione, così puoi rilevare una deriva del ciclo prima che compaia in fattura. Controllo dei costi per un VPS con agente sempre attivo illustra la gestione contabile, mentre gestione del contesto che un agente mantiene tra i turni tratta il principale fattore che incide sul costo di ogni esecuzione: un ciclo che rilegge lo stesso repository ogni 30 minuti lo paga ogni 30 minuti.

Il costo è il motivo per cui i cicli sono generalmente preferibili a una sessione unica e prolungata. Un'esecuzione che parte da zero, svolge un'attività circoscritta e termina mantiene ridotto il contesto. Una sessione lasciata aperta per otto ore conserva nella cronologia tutti gli errori precedenti e addebita l'intera trascrizione a ogni turno.

I pattern che i repository più in voga hanno codificato

Il repository loop-engineering elenca sette pattern per la produzione. Vale la pena leggerli come un menu, non come un manifesto. Triage quotidiano. Un supervisore delle pull request che controlla i commenti di revisione e risponde. Un processo di supervisione della continuous integration che prende in carico le build non riuscite. Supervisione delle dipendenze. Stesura delle note di rilascio. Pulizia post-merge. Triage delle issue.

Hanno in comune un'attività circoscritta e un criterio di verifica evidente. «Correggi la build non riuscita» ha una condizione di superamento che la macchina può leggere. «Migliora il codebase» non ce l'ha, quindi non diventa mai un loop. Diventa un insieme disordinato di attività con una pianificazione.

Hanno in comune anche un registro scritto. Entrambi i repository spostano lo stato fuori dalla conversazione e lo inseriscono nei file del repository: che cosa è stato eseguito, che cosa è stato rilevato, che cosa è stato deciso. 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 agent, perché il contesto del modello scompare non appena l'esecuzione termina. Il coordinamento in tempo reale avviene su un canale separato e una sessione di Claude Code può passare il lavoro a un'altra sullo stesso host mentre entrambe sono ancora in esecuzione, ma nulla di quello scambio sopravvive alla chiusura delle sessioni. Per questo, il file resta l'elemento da consultare in seguito.

Dove i loop falliscono

I problemi sono banali e si ripetono in team diversi.

• Nessun controllo. L’output si accumula, nessuno lo revisiona, la fiducia viene meno e il loop viene disattivato.
• Sovrapposizione. Due esecuzioni sullo stesso branch o due agent nello stesso working tree generano conflitti che l’agent tenta poi di risolvere.
• Deriva silenziosa. Il loop continua a superare i controlli perché la verifica è troppo debole per rilevare il problema.
• Ambito illimitato. Un trigger che si attiva a ogni commit in un repository molto utilizzato si trasforma in un problema di costi nel giro di un giorno.

La correzione è la stessa in tutti i casi: ridurre il lavoro, rendere il controllo più preciso e registrare l’esecuzione. Se non puoi descrivere in una frase la condizione di superamento, il lavoro non è pronto per essere automatizzato.

Per iniziare senza il gergo

Non serve un framework. Un piccolo server Linux sempre acceso, un repository Git la cui suite di test fallisce quando deve fallire, un timer systemd e uno script shell che contiene un if completano il ciclo. È il punto di partenza consigliato nella maggior parte dei casi, perché le scelte progettuali 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. Vedere come eseguire un agente AI per la programmazione su un VPS per la configurazione di base e le opzioni attuali per agenti AI self-hosted se si vuole eseguire l’agente stesso su hardware sotto il proprio 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. All'interno del loop serve comunque un buon prompt. Tuttavia, il prompt non è più l'elemento da ottimizzare ogni giorno, perché il gate e il trigger incidono maggiormente sul risultato.

Mi 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 tutti gli elementi della definizione. I framework aggiungono interfacce di scheduling, formati per la memoria condivisa e instradamento tra più agent, utili quando si eseguono diversi loop. Non sono però un requisito per iniziare con il primo.

Che cos'è un codebase harness?

È l'insieme degli elementi che permettono a un agent di lavorare in un repository senza la presenza di una persona: una procedura di configurazione eseguibile con un solo comando, test eseguiti senza interazione e con errori espliciti, un linter e un metodo per distribuire o visualizzare in anteprima una modifica. Il termine appartiene alla stessa ondata del 2026 di repository in cui è nata l'ingegneria dei loop. La verifica pratica è semplice: se un nuovo collaboratore umano non riesce a passare dal clone ai test verdi con un solo comando, non può riuscirci nemmeno 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 tentativi direttamente nello script, invece di ripetere il ciclo fino al successo. Imposta un limite di spesa rigido sull'account API, perché questo è l'unico limite che l'agent non può aggirare con le proprie risposte. Registra quindi il costo di ogni esecuzione: quando il costo di un loop raddoppia, di solito significa che il suo ambito si è ampliato senza controllo.

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 limitato. La correzione di una build in errore, l'aggiornamento di una dipendenza e la rigenerazione di un changelog sono tutte attività adatte, perché una test suite o un diff possono dimostrare il risultato. Le attività aperte, come il refactoring o la progettazione, non sono ancora adatte: non c'è nulla che il gate possa verificare e un loop senza gate è un modo costoso per accumulare debito di revisione.