AI
Loop engineering: progettare workflow affidabili attorno agli agenti AI di coding
Il loop engineering sposta l'attenzione dalla scrittura di singoli prompt alla progettazione di workflow ripetibili per gli agenti, con obiettivi espliciti, stato persistente, verifica e chiare condizioni di arresto.
Una tipica interazione con un agente AI di coding è sequenziale: si scrive un prompt, si esamina la response, si fornisce ulteriore contesto e si ripete. Questo approccio funziona per attività circoscritte, ma lo sviluppatore rimane responsabile di guidare ogni passaggio.
Il loop engineering modifica questo modello di controllo. Invece di fornire manualmente prompt all'agente per tutta la durata dell'attività, si progetta un workflow in grado di selezionare il lavoro, eseguirlo, verificare il risultato, registrare i progressi e decidere cosa fare dopo.
Il cambiamento importante non consiste semplicemente nell'eseguire ripetutamente lo stesso prompt. Un loop utile richiede struttura, limiti e prove che il lavoro sia stato effettivamente completato.
Dai prompt ai sistemi di controllo
Un prompt in genere descrive l'azione successiva. Un loop descrive un obiettivo e il processo per raggiungerlo.
Per esempio, chiedere a un agente di correggere un test non riuscito è un prompt. Un loop potrebbe invece:
- Leggere i risultati più recenti dei test.
- Selezionare un errore.
- Riprodurlo localmente.
- Esaminare il codice pertinente.
- Implementare una modifica circoscritta.
- Eseguire i test interessati e i controlli statici.
- Registrare il risultato.
- Continuare, fermarsi o richiedere assistenza in base alle prove raccolte.
Questo approccio ricorda l'automazione esistente basata su processi pianificati, webhook, code e pipeline CI. La differenza è che un agente può prendere decisioni adattive all'interno del workflow, come stabilire quali file esaminare o quale comando diagnostico eseguire.
Questa flessibilità è utile, ma rende ancora più importanti la verifica e i limiti operativi.
I componenti di un loop utile
Un loop pratico per l'ingegneria richiede normalmente diversi elementi.
Un trigger avvia il workflow. Potrebbe essere una pianificazione, una nuova issue, una build non riuscita, una segnalazione di errore o una request manuale.
Un obiettivo misurabile definisce ciò che deve diventare vero. «Migliorare il servizio di checkout» è troppo generico. «Far sì che la suite di correttezza del checkout venga superata senza modificarne l'API pubblica» fornisce al loop un risultato che può valutare.
Strumenti e contesto danno all'agente accesso al repository, ai test, ai comandi di build, all'issue tracker, ai log e alle convenzioni del progetto. Senza queste informazioni, l'agente deve indovinare come funziona il sistema.
Lo stato persistente registra il lavoro completato, i risultati attuali, i tentativi falliti e le attività rimanenti al di fuori di una singola conversazione con il modello. Può essere un file Markdown, una bacheca delle issue, un record di database o un altro archivio durevole. Lo stato persistente consente a un'esecuzione successiva di continuare senza ricostruire l'intera cronologia dal contesto della chat.
La verifica controlla l'output rispetto a criteri espliciti. Quando disponibili, sono da preferire controlli deterministici come compilazione, test, formattazione, convalida dello schema e soglie di prestazioni. Un agente revisore separato può aggiungere un'altra prospettiva, ma non dovrebbe sostituire i controlli oggettivi.
Le regole di arresto e di escalation impediscono al loop di proseguire all'infinito. Tra i limiti utili rientrano un numero massimo di tentativi, budget di token o di costo, timeout, ambiti di file limitati e condizioni che richiedono l'approvazione umana.
La verifica è il vero lavoro di ingegneria
La parte esecutiva di un loop è solitamente facile da descrivere: lasciare che l'agente esamini il problema e apporti una modifica. La parte difficile è definire cosa si intende per successo.
La dichiarazione di un agente secondo cui un'attività è completata non costituisce una prova sufficiente. Il loop dovrebbe raccogliere risultati che un altro processo o una persona possano esaminare. Per una modifica al codice, questi potrebbero includere:
- Il diff esatto prodotto
- I risultati dei test e della build
- L'output dell'analisi statica
- Le misurazioni delle prestazioni
- Un elenco di ipotesi e questioni irrisolte
- Un collegamento tra la modifica e l'issue da cui ha avuto origine
È inoltre utile separare chi realizza da chi controlla. Un agente può implementare la modifica, mentre un altro la esamina rispetto all'obiettivo e alle regole del progetto. Ciò riduce l'auto-conferma, sebbene aumenti la latenza e l'utilizzo del modello.
La revisione umana rimane importante quando la correttezza dipende dall'architettura, dagli obiettivi del prodotto, dalla sicurezza o dal contesto aziendale. I controlli automatizzati possono confermare che i test vengono superati. Non sempre possono stabilire se l'implementazione sia la modifica giusta per il sistema.
Iniziare con workflow circoscritti
Il loop engineering è più adatto ad attività ripetitive con risultati osservabili che a uno sviluppo vago e senza limiti definiti.
Tra i punti di partenza ragionevoli rientrano lo smistamento degli errori CI, la revisione degli aggiornamenti delle dipendenze, la riproduzione degli errori registrati, il controllo dei link nella documentazione o l'analisi dei test intermittenti. Questi workflow dispongono già di input, output attesi e strumenti di convalida consolidati.
La prima versione dovrebbe rimanere circoscritta: elaborare un elemento alla volta, lavorare in un branch isolato o in un Git worktree, richiedere il superamento dei test, limitare il numero di nuovi tentativi e produrre una pull request da sottoporre a revisione anziché effettuare automaticamente il merge.
L'ingegnere rimane responsabile
Un loop può ridurre le interazioni ripetitive con un agente di coding, ma non trasferisce la responsabilità. Un contesto inadeguato, criteri di completamento deboli o l'assenza di limiti consentono agli errori di ripetersi alla velocità della macchina, consumando al contempo altro tempo e altri token.
La parte utile del loop engineering non è quindi la generazione di codice senza supervisione. È la progettazione esplicita del sistema circostante: come entra il lavoro, cosa può modificare l'agente, come vengono mantenuti i progressi tra un'esecuzione e l'altra, come vengono verificati i risultati e quando una persona deve assumere il controllo.
La qualità dei prompt rimane importante all'interno di questo sistema. L'attività ingegneristica più ampia consiste nel decidere come prompt, strumenti, stato, controlli e giudizio umano operino insieme come un unico workflow controllato.
Riferimenti
- Loop Engineering — addyosmani.com
- The Art Of Loop Engineering — langchain.com
- What Is Loop Engineering — newsletter.pragmaticengineer.com