Cos'è il loop engineering?

Il loop engineering è la pratica di progettare workflow agentici, o cicli, che guidano iterativamente gli agenti AI verso il completamento di obiettivi definiti dall'utente con un intervento umano minimo. Invece di richiedere un prompting umano ad ogni fase, i loop degli agenti permettono agli agenti di agire, osservare, prendere decisioni e iterare in modo dinamico fino al completamento di un compito. 

Per gli sviluppatori, il loop engineering riformula il loro ruolo dal prompt agli agenti AI verso uno in cui progettano sistemi automatizzati che richiedono, controllano e guidano gli agenti. All'interno di un ciclo ben progettato, un agente è in grado di ragionare, agire, esaminare i risultati delle sue azioni e adattare di conseguenza le azioni successive. 

Il loop engineering è una pratica emergente di agentic engineering che sostiene molti agenti di AI coding come IBM Bob, Claude Code e Codex di OpenAI. Il loop engineering ottimizza l'intero sistema di esecuzione, consentendo agli agenti di risolvere problemi complessi e in più fasi con una supervisione minima.

Il prompt engineering è la pratica di creare l'istruzione più efficace e ottimizzata per un modello di modelli AI. Il loop engineering progetta sistemi automatizzati che si auto-prompt e valutano il proprio lavoro fino al raggiungimento di un obiettivo specifico. 

Con il prompt engineering, gli esseri umani creano prompt, valutano i risultati e creano prompt successivi in ogni fase. Il loop engineering crea sistemi in gran parte automatizzati che affinano i propri prompt interni per ottenere risultati ottimali. Mentre le catene di prompt seguono una struttura rigida, i loop sono dinamici e flessibili. 

Il prompt engineering è adatto per interazioni una tantum o chiamate di singoli modelli. Il loop engineering è più adatto ad agenti di lunga durata che gestiscono workflow come la generazione autonoma di codice, la manutenzione software o l'esecuzione di attività in più fasi.

I loop degli agenti in genere seguono uno schema standard: 

1. Obiettivo
   
   
2. Azione
   
   
3. Osservazione
   
   
4. Adeguamento

Un obiettivo ricorsivo viene valutato ad ogni iterazione di un ciclo agentico, aiutando a mantenere l'agente concentrato nel compito prevenendo iterazioni inutili e controllando i costi dei token. Gli obiettivi ricorsivi forniscono agli agenti AI obiettivi espliciti, inclusi criteri di arresto chiari e verificabili. Dovrebbero essere specifici, adeguatamente definiti e suddivisi in sottocompiti testabili ove possibile. 

"Rendi più veloce il caricamento del mio sito web" è un'affermazione vaga, mentre "interrompi l'iterazione quando il codice supera tutti i test unitari e soddisfa i requisiti richiesti" fornisce all'agente un obiettivo misurabile e una chiara condizione di terminazione.

L'agente valuta il proprio obiettivo e i progressi compiuti, quindi agisce in modo da muoversi ulteriormente verso l'obiettivo. Un'azione potrebbe essere la generazione di codice, l'esecuzione di uno unit test o la correzione di un bug.

Il sistema agentico valuta il risultato dell'azione. Con la generazione automatica di codice, l'agente può eseguire un test di integrazione continua (CI) per vedere se il codice generato è positivo o negativo.

Sulla base dell'osservazione, il sistema valuta il feedback e apporta eventuali modifiche necessarie al suo approccio prima di riavviare il ciclo agentico.

I loop ben progettati possono operare con una supervisione minima pur rimanendo efficienti, affidabili e limitati. Sono processi efficienti che mantengono bassi i costi dei token, terminano quando dovrebbero e portano a risultati affidabili. Al contrario, i loop mal costruiti sono inefficienti e sprecano token a causa di ripetuti tentativi falliti, lavoro non necessario o ragionamenti errati. 

Quando progettano loop che diano buoni risultati, gli sviluppatori tipicamente includono: 

• Automazioni o pianificazione
  
  
• Hook
  
  
• Context engineering
  
  
• Accesso agli strumenti
  
  
• Worktrees
  
  
• Skill
  
  
• Subagenti
  
  
• Spine

La ripetizione è ciò che distingue i cicli dai prompt singoli. A seconda dell'assistente di codifica utilizzato, il looping viene gestito tramite automazioni o programmazione. Entrambi stabiliscono la cadenza del ciclo: dicono cosa fare e con quale frequenza. Ad esempio, gli sviluppatori utilizzano spesso GitHub Actions per pianificare o attivare cicli di agenti. 

I sistemi basati su Unix, come Linux o macOS, automatizzano le attività utilizzando uno scheduler temporale noto come cron job.

A differenza delle automazioni programmate, gli hook sono istruzioni attivate da eventi come la generazione di codice, la modifica di un file, la chiamata di uno strumento o il completamento di un'attività. Gli hook possono verificarsi prima o dopo l'evento associato. 

Gli sviluppatori utilizzano principalmente gli hook per sicurezza e qualità, ad esempio per far rispettare le policy, convalidare output e attivare automaticamente il workflow. Ad esempio, un hook di pre-commit potrebbe essere utilizzato per confrontare il codice rispetto agli standard prima che le modifiche vengano inviate al repository. 

Gli hook rimuovono attività come la governance e i controlli di qualità dagli agenti nel loop, riducendo i costi dei token e l'utilizzo del calcolo.

Ogni ciclo del loop genera dati, noti come contesto, che vengono utilizzati nei cicli successivi. Gli agenti AI moderni e i modelli linguistici di grandi dimensioni (LLM) hanno ampie finestre di contesto, il che significa che gli utenti possono input enormi quantità di dati contemporaneamente. Tuttavia, fornire un contesto eccessivo può ridurre la rilevanza, aumentare i costi e rendere più difficile per il modello identificare le informazioni più importanti. 

Il context engineering è la pratica di progettare sistemi che forniscono i dati di cui il modello AI ha bisogno minimizzando al contempo il contesto in eccesso. Le strategie includono il riassunto delle iterazioni dei loop precedenti per la compressione del contesto e l'uso di markdown per migliorare la strutturazione del contesto.

I loop engineer utilizzano comunemente server MCP (Model Context Protocol) insieme ad altre API e integrazioni per consentire agli agenti di eseguire azioni autonome tramite connettori e strumenti. Senza accesso agli strumenti, gli agenti possono solo descrivere le proprie azioni, anziché agire direttamente sui sistemi esterni.

Gli agenti di codifica utilizzano strumenti per eseguire codice, accedere ai file system, eseguire comandi nel terminale o nella shell, interrogare database ed eseguire test. L'agent harness engineering è la pratica emergente di progettare ambienti di esecuzione completi attorno a un agente per creare sistemi persistenti e autocorrettivi.

I worktree consentono la ramificazione in modo che più agenti possano lavorare in parallelo senza influire sul lavoro dell'altro. I worktree git permettono a più directory di lavoro di condividere un unico repository, abilitando rami paralleli senza duplicare la cronologia del repository. Gli agenti non uniranno i branch finché il codice non sarà testato, revisionato da un essere umano o finché un altro criterio determinato dall'utente non sarà soddisfatto.

Le skill includono conoscenze specifiche di progetto relative a un singolo workflow ricorrente. Gli agenti fanno riferimento al file delle skill quando svolgono il compito associato. Alcuni assistenti di codifica formattano le skill come cartelle contenenti un file skill.md con istruzioni e metadati. In confronto, i file di istruzioni a livello di progetto come agents.md coprono l'intero repository. 

Senza skill, gli utenti devono includere il contesto del progetto in ogni sessione o far indovinare agli agenti cosa devono fare (rischiando che gli agenti sbaglino). Le skill possono essere condivise tra progetti e repository sotto forma di plug-in.

L'agente primario può delegare agenti specializzati noti come sottoagenti per svolgere un ruolo specificato, come ricerca, esplorazione, implementazione o verifica. Un buon loop engineering utilizza una struttura maker/checker con un agente che controlla il codice di un altro per migliorare la qualità del codice. 

Sebbene i subagenti aumentino l'uso dei token, un subagente di verifica separato con le proprie istruzioni in genere fornisce una maggiore garanzia di qualità rispetto al fatto che l'agente di codifica controlli il proprio codice. Alcune piattaforme di codice utilizzano un subagente separato per monitorare l'avanzamento delle attività e determinare quando viene soddisfatta la condizione di risoluzione.

I loop includono una spine: uno stato o una memoria persistente per tenere traccia dell'avanzamento del progetto e prevenire la ripetizione degli errori. Ad ogni loop, l'agente aggiunge i risultati delle sue azioni a uno stato persistente, memorizzare o a un tracker di progetto come un file markdown o una scheda lineare. La spine mantiene lo stato e il contesto per informare le iterazioni future.

Anche i loop più robusti e resilienti richiedono il coinvolgimento umano. Le organizzazioni ottengono il massimo valore dall'AI quando la utilizzano per accelerare la distribuzione del software e si affidano agli esseri umani per la qualità, la sicurezza e i risultati aziendali. 

Un approccio human-in-the-loop aiuta a evitare le insidie più pericolose della generazione automatica di codice, come il codice non verificato, il debito di comprensione, il debito di intento e la resa cognitiva.

Un checker agent è comunque solo un agente, e gli sviluppatori umani sono in ultima analisi responsabili di tutto il codice distribuito. Una governance dell'AI efficace richiede una supervisione umana non solo per verificare che il codice funzioni, ma anche per non esporre dati sensibili o violare regolamenti pertinenti.

Il divario tra la quantità totale di codice in un sistema e il grado in cui gli esseri umani lo comprendono è noto come debito di comprensione. Man mano che gli agenti scrivono più codice e gli esseri umani ne controllano meno, il debito di comprensione aumenta. 

Mentre il debito tecnico tradizionale deriva da scorciatoie deliberate, il debito di comprensione è passivo. Il debito di comprensione si accumula rapidamente a causa della velocità con cui gli agenti generano il codice, e spesso in modo silenzioso, perché il codice supera i test automatici. Se non si interviene, le organizzazioni spesso si ritrovano con un debito di comprensione significativo quando gli sviluppatori devono eseguire il debug di errori in produzione, implementare modifiche importanti o rispondere a incidenti.

Il debito d'intenti è la perdita di spiegazioni concrete che illustrino la logica alla base di un sistema. A meno che non sia esplicitamente dettagliato in luoghi come file agents.md e skill.md, l'intento dello sviluppatore è difficile da dedurre in modo affidabile per gli agenti. Senza di essa, gli agenti possono finire per ottimizzare le proprie azioni per obiettivi strategici sbagliati, apportando modifiche al codice che sono tecnicamente valide ma contrarie agli obiettivi del progetto.

Man mano che gli esseri umani diventano sempre più dipendenti dall'AI, diventano più suscettibili alla resa critica: l'esternalizzazione del pensiero critico all'AI. Mentre l'offloading cognitivo rappresenta la supervisione verificata dall'uomo degli output generati, la resa cognitiva è la completa perdita del controllo. 

Quando gli sviluppatori accettano senza esitazione gli output del ciclo, il debito di comprensione aumenta rapidamente.