Harness engineering: come gli agenti AI imparano a migliorare il sistema che li fa funzionare

Il primo sistema AI capace di migliorare sé stesso non assomiglierà per forza a una mente che riscrive il proprio cervello. Potrebbe essere un programma che legge i propri errori, cambia il modo in cui lavora e conserva la modifica solo se supera i test.

Immagina un agente incaricato di correggere un bug. Legge il repository, formula un’ipotesi e avvia in background una suite di test che richiederà venti minuti. Poi continua a esplorare. Il contesto si riempie, la conversazione viene compressa e, quando i test finiscono, l’agente non torna più a leggerne l’esito. Non ha dimenticato come si programma. Ha perso il filo di un processo che lui stesso aveva avviato.

La prima reazione sarebbe chiedere al modello di «prestare più attenzione». Ma il problema non vive necessariamente nei suoi pesi. Può essere nel sistema che lo circonda: nessun registro dei processi attivi, nessuna notifica persistente, nessuna regola che obblighi a controllare un lavoro prima di dichiarare concluso il compito.

Modificare quel sistema — aggiungere un comando per elencare i processi, salvare lo stato su file, inserire un controllo prima dell’uscita — può rendere lo stesso modello molto più affidabile. Non gli abbiamo insegnato una nuova nozione di informatica. Gli abbiamo costruito un ambiente nel quale è più difficile perdere ciò che già sa fare.

Quell’ambiente operativo si chiama harness. È il codice che decide cosa vede il modello, quali azioni può compiere, come riceve i risultati, dove conserva gli artefatti, quando deve fermarsi e chi stabilisce se il lavoro è riuscito. Il modello propone la prossima azione; l’harness la inserisce in un processo che può durare minuti, ore o giorni.

Per anni questa parte è sembrata semplice colla: un prompt, qualche parser, una lista di strumenti e una manciata di tentativi automatici. Oggi non basta più. Cambiare il livello esterno può muovere risultati, costi e affidabilità anche quando i pesi del modello restano identici. La ricerca più recente compie un passo ulteriore: tratta l’harness come un oggetto che l’agente può osservare, modificare e valutare.

I risultati sono già abbastanza grandi da meritare attenzione. Su Terminal-Bench-2, Self-Harness porta uno dei modelli testati dal 40,5% al 61,9% su uno split di regressione usato durante la selezione; Agentic Harness Engineering passa dal 69,7% al 77,0% dopo dieci iterazioni. Sono esperimenti circoscritti, non una misura universale dell’intelligenza. Ma mostrano che modificare il sistema attorno al modello può cambiare sensibilmente ciò che il modello riesce a portare a termine.

Qui comincia una forma concreta di miglioramento ricorsivo, molto meno fantascientifica di quanto suggerisca il nome. Il sistema raccoglie le proprie traiettorie, individua errori ricorrenti, propone una modifica limitata e la sottopone a prove separate. Se il risultato migliora senza regressioni, la conserva. Altrimenti la scarta e registra il fallimento.

La condizione decisiva è semplice: chi propone la modifica non può controllare anche la definizione di successo. Se test, budget e permessi diventano riscrivibili, l’agente non sta più imparando a lavorare meglio. Sta imparando a spostare la porta.

Questo articolo parte dalla sintesi di Lilian Weng, Harness Engineering for Self-Improvement, e segue una tesi precisa: il valore dell’harness non consiste soltanto nel far emergere più capacità da un modello. Consiste nel rendere il suo comportamento osservabile, falsificabile e cumulativo.

Il modello non è tutto il sistema

Un modello linguistico, isolato, riceve una sequenza e predice come continuarla. Un agente aggiunge il tempo: osserva un ambiente, sceglie un’azione, vede cosa è successo, aggiorna il piano e agisce di nuovo.

obiettivo → contesto → modello → azione → ambiente → osservazione
                 ↑                              │
                 └──────── prossimo turno ─────┘

Il diagramma sembra banale finché non si guarda dentro ogni freccia. Chi decide quali file entrano nel contesto? Un errore del compilatore torna intero o viene riassunto? Dove finisce l’esito del processo avviato in background? Dopo una compressione della conversazione, come viene ricostruito lo stato? Quando un test fallisce, il sistema riprova, cambia strategia o si ferma? E soprattutto: chi stabilisce che la risposta sia corretta?

Sono decisioni di progetto, non proprietà astratte dell’intelligenza.

OpenAI chiama agent loop il nucleo di Codex che orchestra utente, modello e strumenti. Nel resoconto sul proprio esperimento agent-first descrive un prodotto interno con circa un milione di righe di codice scritte da Codex, secondo una stima pari a un decimo del tempo manuale. Il dato più interessante non è lo slogan «zero codice scritto a mano», ma il lavoro rimasto agli esseri umani: rendere il repository leggibile dagli agenti, codificare i vincoli architetturali, costruire cicli di feedback e ripulire l’entropia prodotta da un ritmo di sviluppo così alto. Le persone dirigono; gli agenti eseguono. (agent loop, esperimento harness engineering)

Anthropic arriva a una conclusione simile studiando compiti che attraversano più finestre di contesto. Un agente senza memoria persistente comincia ogni sessione come un ingegnere entrato a metà turno. La soluzione sperimentata è quasi disarmante: una prima sessione prepara ambiente e artefatti; quelle successive leggono il piano, lavorano per incrementi verificabili e lasciano un file di avanzamento pulito a chi verrà dopo. Nessuna memoria neurale nuova. File, test e disciplina nel passaggio di consegne. (Effective harnesses for long-running agents)

La capacità che osserviamo appartiene quindi allo stack intero:

modello di base
├── comportamento appreso nel post-training
├── formato dei messaggi e degli strumenti
├── selezione e descrizione delle azioni
├── costruzione e compressione del contesto
├── memoria e artefatti persistenti
├── flusso di lavoro, tentativi e parallelismo
├── valutatori, test e osservabilità
└── permessi, sandbox e supervisione

Anche un benchmark agentico misura questo insieme, sebbene sulla riga del risultato compaia spesso soltanto il nome del modello. Un harness migliore può alzare il punteggio senza rendere il trasformatore più competente in senso generale; un modello nuovo può invece funzionare peggio dentro procedure calibrate sul comportamento precedente. Le due leve interagiscono.

Tre idee poco futuristiche che funzionano

La letteratura usa nomi nuovi, ma le soluzioni più robuste assomigliano alla buona ingegneria del software.

La prima idea è un flusso di lavoro capace di osservare il proprio risultato:

pianifica → esegui → misura → diagnostica → modifica → riesegui

Il repository autoresearch di Andrej Karpathy lo riduce all’essenziale. Un agente modifica un piccolo esperimento di addestramento, lo esegue per cinque minuti, controlla la metrica, conserva o scarta la modifica e riparte. Il ricercatore non programma ogni singolo esperimento: scrive program.md, il contratto dell’organizzazione di ricerca automatizzata.

La parte che rende credibile il ciclo non è l’autonomia, ma il criterio di verifica — l’oracle — capace di dire se il candidato sia davvero migliore. Senza quel segnale, «itera finché migliori» significa soltanto «continua a produrre variazioni finché una sembra convincente». Servono uno stato noto, azioni consentite, una misura del risultato e una regola di arresto o ripristino. Se uno di questi elementi cambia a metà, non sappiamo più se il guadagno venga dall’idea, da più calcolo o da una prova diventata più facile.

La seconda idea è usare il filesystem come memoria persistente. Un compito lungo genera più informazioni di quante ne possano stare utilmente nel prompt: log, differenze tra versioni, report, schermate, risultati dei test e tentativi scartati. Il contesto dovrebbe contenere l’indice e lo stato attivo; il dettaglio può restare nei file ed essere recuperato quando serve. Una decisione importante non deve sopravvivere come frase sepolta in cinquantamila token: deve diventare un artefatto versionato.

Memoria e contesto non sono sinonimi. La memoria è ciò che il sistema può recuperare; il contesto è ciò che il modello vede adesso. Questa distinzione riduce i costi e lascia una traccia. Se una conclusione rimanda a un test e a una modifica salvati, un essere umano può ricostruirla. Se vive soltanto nella prosa transitoria del modello, resta una spiegazione senza prova.

La terza idea è rendere ispezionabile anche il parallelismo. Più agenti aiutano quando le ipotesi sono indipendenti, ma più conversazioni non equivalgono a più coordinamento. Ogni collaboratore deve avere un risultato delimitato, una responsabilità non sovrapposta e un output persistente. Chi coordina deve poter avviare, interrogare, interrompere e integrare il lavoro. Altrimenti il parallelismo moltiplica il rumore — e rende ancora più facile dimenticare quel processo in background da cui siamo partiti.

Un buon harness non deve fingere di essere intelligente. Deve rendere facile usare l’intelligenza disponibile e rendere evidente quando non basta.

Dall’istruzione al sistema che migliora il sistema

All’inizio ottimizzavamo una stringa: ruolo, esempi, ragionamento richiesto, formato della risposta. Poi la domanda è diventata quale evidenza mostrare al modello, in quale forma e in quale momento.

Agentic Context Engineering tratta il contesto come un manuale operativo che evolve dalle traiettorie. Un generatore produce esperienza, un revisore estrae indicazioni da successi e fallimenti, un curatore aggiorna elementi strutturati senza riscrivere ogni volta un prompt monolitico. La modifica incrementale cerca di non perdere dettagli utili durante le sintesi ripetute. Meta Context Engineering sale di un altro livello: non cambia soltanto il contenuto, ma la funzione che decide come cercarlo, selezionarlo, filtrarlo e presentarlo.

Il passo successivo riguarda l’ordine delle operazioni. Automated Design of Agentic Systems e AFlow trasformano ruoli, ramificazioni e verifiche in uno spazio di ricerca. Un meta-agente propone programmi o grafi di lavoro, li esegue e conserva le varianti migliori.

L’harness engineering allarga ancora la superficie: non solo prompt e ordine delle azioni, ma strumenti, componenti intermedi, memoria, coordinamento, interpretazione degli output e gestione degli errori. Il sistema può aggiungere un comando, cambiare la rappresentazione di un log, introdurre un punto di ripristino o separare responsabilità prima confuse. Il codice è particolarmente adatto a questa ricerca perché una proposta può essere versionata, eseguita, confrontata e annullata.

Infine può cambiare anche il meccanismo che propone e seleziona gli harness. A quel punto non cerchiamo più soltanto la procedura migliore, ma il processo che sa trovare procedure migliori con le prove e il budget disponibili. È qui che la parola ricorsivo acquista un significato concreto. Ed è qui che un errore di misura diventa più pericoloso: una scorciatoia sbagliata può essere incorporata nel metodo che sceglierà gli esperimenti futuri.

Quando un fallimento diventa una modifica

Torniamo al nostro agente. La suite di test finisce, ma lui non la controlla. Un singolo episodio dice poco: potrebbe essere distrazione casuale. Se però la stessa dinamica compare in decine di traiettorie, il sistema può formularla in modo più utile.

“Timeout” è soltanto il risultato. “Non ha controllato un processo attivo” descrive il comportamento. “Il flusso di lavoro non rappresenta i processi asincroni come stato persistente” individua un meccanismo modificabile. È a quest’ultimo livello che una diagnosi può diventare codice.

Meta-Harness parte da un problema vicino: gli ottimizzatori testuali comprimono il feedback troppo presto. Tre righe possono dire che un candidato ha fallito e cancellare proprio il dettaglio che spiega perché. Il sistema affida a un agente di programmazione una directory con codice, punteggi e traiettorie delle versioni precedenti. La storia non entra tutta in un prompt gigantesco: l’agente la esplora attraverso file e comandi. Ogni candidato diventa un piccolo repository accompagnato dalle prove dell’esperimento.

Lo studio riporta risultati su compiti diversi: nella classificazione testuale online, +7,7 punti rispetto a un sistema forte di gestione del contesto usando quattro volte meno token; nel ragionamento matematico con recupero di informazioni, un harness trovato in un ambiente migliora in media di 4,7 punti su 200 problemi di livello IMO, su cinque modelli non usati durante la ricerca; nella programmazione agentica, i candidati superano i sistemi progettati a mano considerati su TerminalBench-2.

Non è la prova di un harness universale. La ricerca e la valutazione finale su TerminalBench usano gli stessi 89 compiti: gli autori controllano che le stringhe dei compiti non trapelino, ma non ottengono così una generalizzazione pulita su dati mai visti. Il risultato sui cinque modelli esterni appartiene invece all’esperimento matematico. Nel proprio perimetro, Meta-Harness mostra qualcosa di più circoscritto: una storia degli esperimenti ben organizzata può valere più della sua sintesi aggressiva, e alcune scelte su come costruire il contesto possono trasferirsi da un modello all’altro.

Self-Harness fa partecipare lo stesso modello che esegue i compiti al miglioramento del proprio harness. Prima raccoglie le traiettorie e raggruppa gli errori per causa. Poi mostra al proponente una superficie modificabile delimitata, esempi di comportamento sano da preservare e le modifiche già tentate. Infine prova ogni candidato sia sui casi che dovrebbero migliorare sia su uno split di regressione nascosto al proponente.

Questo confine conta più dell’autonomia. Senza di esso, il modo più facile di salire in classifica potrebbe essere aumentare il budget, sostituire il modello, indebolire la verifica o inserire eccezioni per i compiti già visti.

Su Terminal-Bench-2 lo studio riporta miglioramenti su quello split per tutti e tre i modelli provati: 40,5% → 61,9% per MiniMax M2.5, 23,8% → 38,1% per Qwen3.5-35B-A3B e 42,9% → 57,1% per GLM-5. Le traiettorie restano nascoste al proponente, ma i punteggi vengono consultati a ogni iterazione per decidere quali modifiche promuovere. È dunque un insieme di selezione e regressione, non un test finale indipendente.

Agentic Harness Engineering, o AHE, aggiunge una richiesta importante: ogni modifica deve dichiarare in anticipo quale errore correggerà, quale comportamento sano conserverà e quale regressione potrebbe introdurre. L’osservabilità riguarda i componenti modificabili, l’esperienza raccolta nelle traiettorie e le decisioni che portano da un errore a una modifica. La previsione trasforma una differenza nel codice in un’affermazione falsificabile: non basta che il punteggio salga, deve salire per la ragione attesa.

Dieci iterazioni portano il pass@1 su Terminal-Bench 2 dal 69,7% al 77,0%, sopra il riferimento Codex-CLI indicato al 71,9%. L’harness congelato viene poi applicato ad altre famiglie di modelli, con guadagni dichiarati tra +5,1 e +10,1 punti percentuali, e su SWE-bench Verified usa il 12% di token in meno rispetto alla versione iniziale. Lo studio di ablazione attribuisce gran parte dei guadagni a strumenti, componenti intermedi e memoria a lungo termine, non al solo prompt di sistema.

L’obbligo di scrivere una previsione non rende però l’agente un buon profeta. Nel paper, le previsioni di regressione ottengono appena 11,8% di precisione e 11,1% di richiamo. Sono utili per l’audit, non sostituiscono i test. Questo risultato ridimensiona una convinzione diffusa: un harness non è un prompt molto lungo. Spesso il collo di bottiglia vive nel modo in cui uno strumento restituisce lo stato, nel passaggio tra due sessioni o nella logica che decide cosa salvare.

Il codice come spazio di ricerca

L’idea di migliorare chi migliora precede gli harness moderni. Self-Taught Optimizer non ottimizza direttamente una soluzione: ottimizza la funzione incaricata di migliorarla. Un programma riceve un candidato e una funzione di utilità, produce una nuova versione e viene valutato su una distribuzione di problemi. La nuova versione può poi applicare lo stesso procedimento a sé stessa.

La ricorsione, da sola, non garantisce nulla. Negli esperimenti l’ottimizzatore basato su GPT-4 migliora in media attraverso le iterazioni; con modelli più deboli può degradare. Un modello incapace di diagnosticare una procedura produrrà variazioni, non necessariamente progressi.

Darwin Gödel Machine rinuncia a dimostrare formalmente che ogni auto-modifica sia vantaggiosa. Conserva invece un archivio di agenti, sceglie progenitori diversi, permette loro di modificare il proprio codice e valuta i discendenti. Il risultato è un albero: mantenere strade intermedie differenti impedisce che una strategia promettente, ma temporaneamente inferiore, scompaia troppo presto.

Con Claude 3.5 Sonnet come base, lo studio riporta un passaggio dal 20,0% al 50,0% su un sottoinsieme di 200 compiti di SWE-bench Verified, dopo una selezione progressiva su insiemi da 10 e 60 compiti, e dal 14,2% al 30,7% sulla valutazione Polyglot. Le modifiche scoperte includono strumenti migliori per intervenire sul codice, gestione del contesto lungo e revisione tra agenti. Gli esperimenti dichiarano sandbox e supervisione umana. L’esecuzione DGM su SWE-bench è stimata dagli autori in circa 22.000 dollari, ai prezzi API storici dello studio: il costo computazionale fa parte del risultato.

AlphaEvolve applica una logica evolutiva a programmi verificabili automaticamente. Modelli veloci esplorano molte varianti, modelli più forti propongono cambi profondi, i valutatori misurano correttezza e qualità e un database decide quali programmi genereranno i successivi. Google DeepMind riporta che, su oltre cinquanta problemi matematici, il sistema ha riscoperto lo stato dell’arte in circa il 75% dei casi e lo ha migliorato in circa il 20%, oltre a risultati usati in datacenter, progettazione di chip e addestramento dell’AI.

Il denominatore comune è molto concreto:

variazione eseguibile
+ valutazione poco costosa e ripetibile
+ archivio che conserva esperienza e diversità
+ regola esplicita di selezione

Quando queste condizioni esistono, il codice è uno spazio di ricerca eccezionale: una proposta si può eseguire invece di discuterla e una proprietà si può misurare invece di affidarla alla sicurezza retorica del modello.

La tabella non è una classifica. Numeri, modelli, benchmark e budget sono diversi. Mostra piuttosto che sotto la stessa etichetta self-improving convivono oggetti differenti: memoria, funzione di contesto, flusso di lavoro, harness completo o codice della soluzione.

E se cambiano anche i pesi?

Fin qui il modello è rimasto congelato. L’harness cambia il sistema non parametrico che gli sta intorno: è rapido da modificare, versionabile e relativamente facile da annullare. Un ciclo completo dovrebbe però capire anche quando aggiornare il modello.

È un problema di attribuzione. Se una traiettoria fallisce perché uno strumento restituisce informazioni ambigue, cambiare i pesi significa addestrare il modello a compensare un’interfaccia difettosa. Se invece l’evidenza è chiara e il modello continua a non riconoscere lo stesso schema, un’altra regola procedurale può soltanto mascherare una carenza di capacità.

SIA — Self Improving AI with Harness & Weight Updates assegna tre ruoli: un meta-agente propone l’harness, un agente esegue il compito, un terzo decide se il ciclo successivo debba modificare l’harness o aggiornare i pesi. L’idea è importante, ma l’evidenza resta preliminare. Il modello incaricato dei compiti è molto più debole di quelli che propongono e valutano le modifiche; è difficile separare il valore dell’architettura dall’intelligenza esterna che la dirige, e i confronti di riferimento non isolano con pulizia tutte le alternative.

Continual Harness esplora un’altra strada nei giochi a lungo orizzonte: aggiorna l’harness durante l’esecuzione e, sulle traiettorie a basso premio, trasferisce nel modello le etichette di un insegnante più forte.

Quando cambiano i pesi, però, il ripristino non è più un semplice git revert. Entrano in gioco stabilità dell’addestramento, dimenticanza catastrofica, contaminazione tra dati di addestramento e validazione e capacità non esercitate dal benchmark corrente. La prudenza suggerisce una gerarchia: correggere prima ambiente e strumenti, poi memoria e procedura; aggiornare i pesi soltanto davanti a una carenza persistente e rieseguire valutazioni ampie e separate. Più una modifica scende in profondità, più forte deve essere la prova richiesta per conservarla.

La verificabilità stabilisce il limite dell’autonomia

Il miglioramento automatico funziona dove la parola «migliore» può essere tradotta in una misura ripetibile. Un kernel è corretto oppure no e, se lo è, possiamo misurarne la velocità. Un test passa o fallisce. Una loss sale o scende sotto lo stesso budget. Un algoritmo usa più o meno operazioni.

Spostandosi verso manutenzione del software, ricerca aperta, strategia o design, il terreno cambia. Una modifica può far passare tutti i test e aumentare il costo delle migrazioni per i prossimi due anni. Un paper può avere citazioni corrette e un esperimento formalmente riuscito, ma partire da una domanda irrilevante. Un’interfaccia può piacere a un modello giudice e risultare sgradevole alle persone.

Più il feedback è rapido, causale e resistente alle scorciatoie, più autonomia possiamo concedere al ciclo di ottimizzazione.

The AI Scientist e sistemi successivi coordinano proposta di idee, codice, esperimenti, analisi e scrittura. È un risultato importante di automazione. Ma un manoscritto plausibile non equivale a una scoperta: citazioni corrette, implementazioni fedeli, confronti sensati e conclusioni solide richiedono catene di evidenza e giudizio di dominio.

Il rischio più insidioso è un esperimento rumoroso interpretato come successo e poi usato per modificare il processo che genererà gli esperimenti futuri. Un falso positivo può diventare infrastruttura.

Per questo un harness auto-modificabile deve avere un confine che non evolve insieme al resto. Istruzioni operative, descrizione degli strumenti, rappresentazione degli output, memoria, coordinamento, punti di ripristino e codice applicativo delimitato possono stare dentro il ciclo. Verificatori, test finali, log immutabili, modello e budget dichiarati, regole di rete e filesystem, credenziali, costi, pubblicazione e messa in produzione devono restarne fuori.

La separazione protegge da tre famiglie di fallimento. La prima è la manipolazione del criterio di ricompensa (reward hacking): il sistema impara le particolarità dei test, le preferenze superficiali di un modello giudice o gli artefatti di un benchmark. La seconda sono i confondenti: il punteggio sale, ma insieme all’harness sono cambiati modello, temperatura, tempo massimo o token disponibili. La terza è l’escalation dei permessi: il percorso più breve verso l’obiettivo attraversa dati, rete o sistemi che l’esperimento non era autorizzato a toccare.

Test separati e sandbox non eliminano questi rischi, ma rendono più difficile ottenere un falso progresso senza lasciare tracce. Ogni modifica dovrebbe dichiarare l’ipotesi che la motiva, l’effetto previsto e la regressione più probabile. Se il risultato sale per una ragione diversa da quella attesa, merita indagine, non celebrazione.

Restano limiti che nessun benchmark breve risolve. Anche un harness può adattarsi troppo ai compiti visti. I valutatori osservano output e stati strumentati, non necessariamente manutenibilità, chiarezza o costo futuro. Migliaia di tentativi possono nascondere il vero prezzo del candidato vincente. I cicli evolutivi tendono a convergere sulle strategie già premiate e a perdere diversità. Un modello può scrivere una buona procedura senza saperla seguire con costanza. Quando cambiano più componenti, servono studi di ablazione per attribuire il guadagno. E una prova di poche ore cattura male ciò che accade a un repository mantenuto per anni: compatibilità, migrazioni, debito tecnico e convenzioni sociali.

Sono obiezioni sostanziali, non note a margine. Collocano i risultati nel loro perimetro corretto: dimostrano che una parte dell’ingegneria del sistema può essere automatizzata, non che un’intelligenza possa migliorare senza confini in qualunque dominio.

Una disciplina utilizzabile oggi

Non serve costruire una Darwin Gödel Machine per adottare le idee migliori. Serve rendere il fallimento interrogabile.

Per ogni esecuzione bisogna conservare compito, configurazione, azioni, output degli strumenti, durata, costi, verifica finale e motivo dell’arresto. Un log infinito non è osservabilità: occorrono indici e report che permettano di scendere dal problema ricorrente alla traccia grezza. Nel nostro esempio, il timeout deve ricondurre alle azioni dell’agente e poi al processo in background che non è mai stato ricontrollato.

Prompt, procedure, descrizioni degli strumenti, componenti intermedi e memoria devono vivere in file revisionabili. Ogni esperimento deve indicare con quale versione dell’harness è stato eseguito. Se le istruzioni sono sparse in pannelli di controllo opachi e stringhe copiate, non possiamo attribuire il risultato né riprodurlo.

La superficie di ogni prova va limitata. Per quanto possibile, una modifica per ogni ipotesi; modello, budget, valutatore e permessi restano fissi. Prima di vedere il punteggio conviene registrare cinque cose:

evidenza: quale errore ricorrente osserviamo?
causa: quale meccanismo lo produce?
modifica: quale parte del sistema tocchiamo?
previsione: quali compiti dovrebbero migliorare?
rischio: quale comportamento sano potrebbe regredire?

Una previsione scritta dopo il risultato è una storia. Scritta prima è un test.

Servono poi insiemi di valutazione con ruoli distinti. I casi già analizzati verificano la correzione mirata; uno split nascosto al proponente protegge dalle regressioni, ma se viene consultato a ogni selezione non può essere presentato come test finale indipendente. Occorre conservare anche un terzo insieme intatto e controlli sul comportamento sano: ciò che funzionava deve continuare a funzionare.

Infine l’essere umano non deve approvare ogni grep, ma deve restare nei punti in cui il feedback automatico rappresenta male il valore: cambiare permessi, spendere budget importanti, pubblicare, contattare persone, toccare la produzione, accettare una migrazione irreversibile o ridefinire il criterio di valutazione. Il suo compito si sposta dalle singole battute di tastiera alla definizione dell’obiettivo, dei confini e delle prove che contano.

L’intelligenza che vive fuori dai pesi

Torniamo un’ultima volta all’agente che aveva dimenticato i test. Dopo avere raccolto abbastanza traiettorie, il sistema formula una causa: i processi asincroni non sopravvivono come stato. Propone una modifica limitata, prevede quali timeout dovrebbe eliminare e quali flussi potrebbe interrompere per errore. Poi la prova sui casi noti, su una regressione separata e infine su compiti mai usati durante la selezione. Se supera tutti i controlli, la nuova procedura entra nell’harness.

Il modello non ha riscritto il proprio cervello. Eppure il sistema che incontrerà il bug successivo sarà migliore di quello precedente.

È questo il risultato più importante di Meta-Harness, Self-Harness, AHE e DGM: una pratica artigianale può diventare un ciclo sperimentale.

osserva il comportamento
→ formula una causa
→ modifica una superficie delimitata
→ misura su evidenza separata
→ conserva o annulla
→ registra ciò che hai imparato

Il modello resta il centro della capacità. L’harness decide quanta di quella capacità può trasformarsi in lavoro affidabile. Il valutatore impedisce che “affidabile” significhi soltanto “convincente”. E le persone scelgono quali parti del sistema non sono autorizzate a negoziare il proprio confine.

La prima AI che migliora davvero sé stessa potrebbe non riscrivere il proprio cervello. Potrebbe imparare, esperimento dopo esperimento, a costruirsi un ambiente in cui sbagliare diventa informazione invece che destino.

Fonti e perimetro. La fonte di orientamento è “Harness Engineering for Self-Improvement” di Lilian Weng. Le fonti industriali principali sono OpenAI Harness Engineering, Unrolling the Codex agent loop, Anthropic long-running agent harnesses e autoresearch.

La ricerca accademica comprende ACE, MCE, Meta-Harness, Self-Harness, Agentic Harness Engineering, Darwin Gödel Machine, STOP e AlphaEvolve. I risultati numerici provengono dai rispettivi protocolli e non formano una classifica. Il dossier di ricerca del repository conserva il registro completo delle fonti, delle affermazioni e delle relative cautele.