Harness engineering e loop engineering: qual è la differenza

Che cos’è un harness?

Da solo, un modello linguistico riceve un input e produce testo. Non può eseguire codice, non ricorda nulla da una conversazione all’altra e non può accedere a ciò che è emerso dopo il suo addestramento. Perché possa farlo, gli si costruisce intorno un apparato: un ciclo che lo chiama più e più volte, gli strumenti che può chiamare, i file che riceve a ogni sessione, i controlli che verificano il suo output. Questo apparato si chiama harness.

Tra le fonti che abbiamo letto, la definizione più ampia è nell’articolo di LangChain: «A harness is every piece of code, configuration, and execution logic that isn’t the model itself.» Cioè ogni pezzo di codice, ogni configurazione, ogni logica di esecuzione che non sia il modello stesso. Un livello del genere gira anche dentro gli agenti di programmazione: OpenAI chiama «Codex harness» il livello che fornisce il ciclo dell’agente e la logica di esecuzione; Anthropic chiama «agent harness» quello che fa funzionare Claude Code.

L’harness engineering è il lavoro di progettare questo apparato. Anche noi ne costruiamo uno: diffox è uno strumento di code review con IA che esamina le pull request. Gli esempi più sotto vengono dalla sua pipeline di review e dal loop che fa girare lungo una pull request (come funziona è in un articolo a parte).

Come le fonti definiscono l’harness engineering

Il termine è nuovo e le fonti che abbiamo letto non lo definiscono allo stesso modo. La tabella riporta ogni fonte con parole sue e la sua data.

Fonte: la pagina di ogni articolo, 15 ottobre 2026. Le citazioni sono in lingua originale.

Hashimoto descrive un’abitudine e, nello stesso paragrafo, scrive anche di non sapere se esista già un termine affermato. LangChain invece traccia un confine: tutto ciò che sta fuori dal modello è harness. Il primo ti dice che cosa fare, il secondo dove guardare.

Due dettagli non si vedono nella tabella. La formula «Agent = Model + Harness» compare nell’articolo di LangChain, non in quello di Hashimoto. E la parola «harness» è più vecchia del termine: il 26 novembre 2025 Anthropic aveva definito il Claude Agent SDK un «general-purpose agent harness». Nei cinque articoli di Anthropic che abbiamo letto l’espressione «harness engineering» non compare.

Che cosa cambi a ogni livello

I quattro termini non sono intercambiabili: sono quattro livelli uno dentro l’altro. Nella definizione di Anthropic, il prompt engineering indica i metodi per scrivere e organizzare le istruzioni per il modello. Il context engineering indica invece le strategie per scegliere e curare l’insieme di token che il modello ha davanti durante l’inferenza, comprese le informazioni che vi arrivano al di fuori del prompt. Il contesto è tutto ciò che il modello vede in quella chiamata.

Non abbiamo trovato una fonte primaria che attribuisca il context engineering a una sola persona. I due usi che abbiamo letto sono di giugno 2025: il 19 giugno Tobi Lütke ha scritto di preferire questo nome a «prompt engineering» («the art of providing all the context for the task to be plausibly solvable by the LLM»), e il 25 giugno Andrej Karpathy si è detto d’accordo. La definizione di Anthropic è del 29 settembre 2025.

L’harness engineering sta un livello più all’esterno. Non si ferma a ciò che il modello vede; progetta anche ciò che succede dopo la sua risposta: quali controlli passa l’output, come si divide il lavoro, che cosa cambia quando un errore si ripete. Ogni livello contiene il precedente: secondo LangChain, gli harness di oggi servono soprattutto a mettere in pratica un buon context engineering. Il loop engineering sta ancora più all’esterno: non progetta una singola esecuzione, ma le esecuzioni nel tempo. Gli dedichiamo una sezione a parte più sotto.

Di che cosa è fatto un harness

Gli articoli che abbiamo letto elencano le parti con nomi diversi. Ognuna delle sei voci qui sotto compare in almeno due fonti.

Al centro c’è il ciclo. Anthropic descrive gli agenti come modelli che usano strumenti in un ciclo, guidati dal feedback dell’ambiente. Nell’articolo sull’Agent SDK i passi del ciclo sono: raccogli il contesto, agisci, verifica il lavoro, ripeti. Strumenti e osservabilità mostrano al modello il risultato di ciò che ha fatto: nel repository descritto da OpenAI, l’agente può leggere log, metriche e tracce. I subagenti dividono il lavoro; secondo Anthropic ognuno prende un compito mirato e parte da una finestra di contesto pulita.

I controlli stanno a parte, perché non li scrive il modello: li scrivi tu. Secondo l’articolo sull’Agent SDK, il feedback migliore sono regole chiaramente definite per l’output, con la spiegazione di quale regola è stata violata e perché. OpenAI fa rispettare le sue regole di architettura in modo automatico, con linter personalizzati e test strutturali.

Che cos’è il loop engineering?

L’harness si occupa di una singola esecuzione. Il loop engineering si fa una domanda in più: chi avvia l’agente, quando, e chi decide se il lavoro è finito? Il nome l’ha dato Addy Osmani in un articolo del 7 giugno 2026: «Loop engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead.» Cioè smettere di essere la persona che scrive all’agente un turno dopo l’altro, e progettare il sistema che lo fa al posto tuo.

A far nascere il termine sono state due frasi. Lo stesso giorno Peter Steinberger ha suggerito di smettere di scrivere prompt agli agenti e di progettare loop che li scrivano al posto nostro. Secondo quanto riporta Osmani, anche Boris Cherny, a capo di Claude Code, aveva detto: «My job is to write loops». Nessuno dei due usa l’espressione «loop engineering»; il nome l’ha dato l’articolo di Osmani.

Fonte: la pagina di ogni articolo, 15 ottobre 2026. Le citazioni sono in lingua originale.

Le parti su cui le fonti concordano sono sei. La rassegna le elenca così: esecuzioni avviate da un trigger, condizioni di arresto verificabili da una macchina, file di stato persistenti, subagenti verificatori, budget di token e punti di passaggio a un umano.

• Trigger. Ciò che avvia l’esecuzione: un timer o un evento.
• Condizione di arresto. Un criterio con cui la macchina può decidere che il lavoro è finito: i test passano, la lista è vuota.
• Stato. Ciò che resta scritto da un’esecuzione all’altra; sta fuori dalla finestra di contesto.
• Verificatore. Un controllore separato dall’agente che fa il lavoro.
• Budget. Un limite di turni o di token; superato quello, il loop si ferma.
• Passaggio a un umano. Il punto in cui il lavoro che il loop non sa risolvere passa a una persona.

L’articolo di Anthropic mostra tre delle parti insieme. Ogni volta che Claude Code vuole fermarsi, un modello valutatore separato controlla la condizione. Lo rimanda al lavoro finché l’obiettivo non è raggiunto o non si arriva al numero di turni che hai fissato. Come dice Osmani, così l’agente che scrive il codice non è quello che dà il voto al proprio lavoro.

Su un punto le fonti divergono: di quale ciclo parla «loop»? La rassegna distingue i due. Nel ciclo dell’agente, il modello chiama strumenti dentro una singola esecuzione e agisce in base al risultato; questo ciclo fa parte dell’harness. Il loop engineering, invece, si occupa delle strutture che avviano, controllano e riavviano queste esecuzioni nel tempo. Alcuni articoli di vendor usano la parola nel primo senso; anche il blog di ingegneria di Anthropic definisce l’harness «il ciclo che chiama Claude». In questo articolo, loop ha il secondo senso.

Nemmeno il termine è ancora consolidato. La stessa rassegna scrive che il dibattito non ha chiarito se il loop engineering sia una nuova disciplina, una tecnica di passaggio o un’etichetta di marketing. A luglio 2026 ne è stato persino proposto un successore, con il nome «graph engineering».

Com’è fatto un harness in uno strumento di code review

Come stanno insieme le parti lo mostra la pipeline di review di diffox. Una pull request passa per quattro fasi prima di diventare commenti; in ogni fase si vede un’idea di harness.

Contesto e assegnazione è ciò che l’harness dà al modello prima che si metta al lavoro. Gli agenti specializzati ricevono quattro cose: il diff, i file prima e dopo, la descrizione della pull request e, se c’è, il file delle regole del tuo repository (AGENTS.md o CLAUDE.md). Il file delle regole viene letto dal branch in cui la pull request verrà unita, non dal branch della pull request stessa; così una pull request non può cambiare le regole della propria review. Questa garanzia non viene da una frase nelle istruzioni, ma dal punto da cui si legge il file.

Revisione specialistica è la divisione del lavoro. «C’è un bug qui?» è una domanda ampia. diffox fa leggere la stessa modifica ad agenti specializzati. Il team ha 17 agenti specializzati; ognuno ha la propria istruzione e cerca una sola cosa: uno gli errori di logica, uno i problemi di concorrenza, uno i test che non verificano nulla.

Anche la forma dell’output la decide l’harness. Perché un rilievo conti, deve dire tre cose: che cosa afferma, che cosa va storto e in quale situazione, e il codice su cui si basa, citato alla lettera. Gli agenti non danno numeri di riga; diffox trova la riga da sé, cercando la citazione nel file.

Scegli e pubblica è un passo a sé. Ogni rilievo ha una classe: Critico, Avviso o Suggerimento. Sulla pull request arriva ciò che devi correggere, cioè i rilievi critici e gli avvisi. I suggerimenti restano per un po’ nella pagina Rilievi della console, e da lì puoi pubblicare quelli che vuoi. Una review non blocca mai un merge.

Una verifica che il modello non può aggirare a parole

La terza fase, verifica delle evidenze, è il punto in cui in questo esempio l’idea di harness si vede più chiaramente. Un modello linguistico può scrivere qualcosa di convincente e sbagliato: cita una riga che non è nel file, contesta codice che la pull request non ha toccato, ripete lo stesso problema tre volte con tre frasi diverse. Questa fase lega ogni rilievo al file stesso e non alla parola del modello.

Queste verifiche sono semplice codice, non una chiamata a un modello: allo stesso input danno ogni volta la stessa risposta.

• La citazione del rilievo viene cercata nel file. Una citazione che non si trova non ha una riga da indicare; se la riga trovata non è in ciò che la pull request ha modificato, il rilievo è fuori ambito.
• I rilievi che fanno la stessa obiezione nello stesso punto vengono uniti in uno solo.
• Se un rilievo dice che il codice contraddice un testo, anche la sua seconda citazione viene cercata parola per parola.

Il modello non può convincere la verifica della citazione: la verifica non valuta argomentazioni, cerca la citazione nel file.

Si può anche far controllare un modello da un altro modello, ma il risultato resta il giudizio di un modello. Anthropic scrive che il suo modello valutatore, nei primi tentativi, trovava problemi reali, poi si convinceva che non fossero importanti e approvava il lavoro. Per questo verificare con il codice ciò che il codice può verificare è una parte a sé; la domanda che richiede un giudizio resta al modello.

In un piccolo progetto la stessa idea sta in poche righe. L’esempio qui sotto non è il codice di diffox; mostra lo schema.

# ESEMPIO: cerca nel file la citazione data dal modello
def quote_exists(finding: dict, files: dict[str, str]) -> bool:
    quote = finding.get("quote", "").strip()
    source = files.get(finding.get("file", ""), "")
    return bool(quote) and quote in source

Il loop che gira lungo una pull request

Una singola review attraversa un harness; una pull request, invece, attraversa molte review. Il codice viene scritto, diffox lo esamina, il codice cambia, si fa di nuovo il push. Che il codice lo scriva una persona o un agente di programmazione, questo è un loop, e ognuna delle sue sei parti ha in diffox un corrispettivo nel codice.

La vera lezione di questo loop sta in due scelte. La prima: il verificatore non conta una modifica come un successo. Quando le righe di un rilievo cambiano, in fondo al commento si scrive solo in quale commit sono cambiate. Non si scrive mai «corretto», perché il codice riscritto può contenere ancora il bug. Anche un articolo scientifico di giugno 2026 pone la stessa condizione alla regola di arresto: non scambiare mai un errore per un successo.

La seconda: la condizione di arresto la scegli tu. Le review automatiche si fermano a un limite per pull request; il limite lo cambi nella scheda Impostazioni della console. Dopo il limite, chiedi una nuova review menzionando diffox in un commento. Anche la decisione sul merge è tua: una review non blocca mai un merge. È qui che il loop passa il lavoro a una persona.

Come un harness cresce con gli errori

Un harness non si costruisce una volta per poi lasciarlo lì. Nella descrizione di Hashimoto le strade sono due: per gli errori semplici una riga nel file delle regole, per il resto uno strumento programmato. Scrive che ogni riga del file delle regole del suo progetto nasce da un cattivo comportamento di un agente.

L’articolo di OpenAI racconta lo stesso ciclo in un team: tutto il codice del prodotto lo scrive Codex, gli ingegneri costruiscono l’ambiente. Quando l’agente fa fatica, lo trattano come un segnale: si trova ciò che manca (uno strumento, una protezione, della documentazione) e lo si aggiunge al repository. Quando la documentazione non basta, la regola passa nel codice. Il file delle regole resta breve: un AGENTS.md di circa 100 righe, un indice e non un’enciclopedia.

C’è anche la direzione opposta. Secondo Anthropic, ogni parte di un harness è un presupposto su qualcosa che il modello non sa fare da solo, e può invecchiare man mano che i modelli migliorano. Quando arriva un nuovo modello, l’harness si riesamina; la parte che non è più portante si toglie.

Sviluppando questo strumento, nel nostro repository da questo ciclo sono nate tre abitudini:

• Ogni regola sta accanto all’errore che l’ha fatta scrivere. Una regola senza il suo motivo la cancella il primo a cui dà fastidio.
• Di un test ci si fida dopo averlo visto diventare rosso quando si annulla la correzione. Anche un test che non verifica nulla appare verde.
• Quando cambia un controllo scritto in codice, la versione vecchia e quella nuova si rieseguono sui risultati già salvati. Non serve una nuova esecuzione a pagamento; ogni caso in cui le due versioni divergono si vede uno per uno.

Da dove cominciare nel tuo progetto

Per cominciare non devi scegliere un framework né cambiare modello. Dentro l’agente di programmazione che usi gira già un harness; tu gli aggiungi le parti del tuo progetto.

Prima guarda l’errore, poi scegli il rimedio più economico. Per gli errori semplici il primo rimedio è una riga nel file delle regole. Se l’errore si ripete nonostante la regola, porta la regola nel codice: una regola del linter, un test, uno script. Il consiglio generale di Anthropic vale anche qui: trova la soluzione più semplice e aumenta la complessità solo quando serve.

Anche quando costruisci il tuo primo loop l’ordine è lo stesso: prima verifica che una singola esecuzione sia affidabile, poi scrivi la condizione di arresto e il limite. Il consiglio di Anthropic è chiaro: fermarsi quando l’obiettivo è raggiunto o quando si arriva al numero massimo di turni; per gestire l’uso dei token, i confini del loop devono essere netti.