Ouroboros: l’agente che si riscrive il codice solo passando per una revisione, e i 161 giorni di Hope

In ogni officina che funziona c’è una regola non scritta: chiunque può proporre di cambiare un attrezzo, nessuno lo cambia da solo mentre gli altri lavorano. Si prova la modifica in disparte, qualcuno la guarda, e solo allora entra sul banco. E c’è sempre un interruttore generale sulla parete, che nessuno degli operai può smontare, per quanto sia bravo.

È questa, in fondo, l’idea di Ouroboros: A Self-Developing Frontier Coding Agent with Reviewed Core Evolution, depositato su arXiv l’8 agosto 2026 (2608.08311, la versione corrente è la terza, del 31 agosto). Lo firmano sei ricercatori (primo autore Anton Razzhigaev, ultimo Andrei Kuznetsov) fra l’Università statale di Mosca, lo Skoltech, la HSE, il FusionBrain Lab e il Joi Lab, l’affiliazione di Roman Yampolskiy. Con un dettaglio che non si vede spesso: l’agente stesso compare in testa come «contributore di sistema», escluso dagli autori formali per le regole di arXiv e dell’ACL. Il codice è pubblico, con licenza MIT.

Che cosa cambia rispetto agli altri agenti che si migliorano

Un agente di programmazione è un modello più un harness: il programma che costruisce il contesto, chiama gli strumenti, verifica i risultati e si riprende dagli errori. Claude Code, Codex CLI, Cursor sono harness e, a parità di modello, ricordano gli autori citando altri studi controllati, danno risultati sensibilmente diversi in accuratezza, latenza e consumo di token. Di solito l’harness si scrive una volta e poi si congela.

Da qualche anno esiste una famiglia di sistemi che modificano sé stessi, ciascuno su un pezzo diverso: Voyager accumula skill, Darwin Gödel Machine fa evolvere popolazioni di agenti, SICA modifica l’implementazione del proprio scaffold. Ouroboros si distingue su un punto preciso, che gli autori mettono in una tabella di confronto: tocca il codice del nucleo, cioè l’implementazione che eseguirà i compiti successivi, come già Darwin Gödel Machine, ma è l’unico della tabella in cui ogni modifica passa da un commit revisionato, serializzato in un repository Git versionato prima di essere adottata.

I modi in cui questo succede sono due. Nell’evoluzione libera migliorarsi è a sua volta un compito: l’agente ispeziona il proprio sistema, sceglie una modifica, la implementa, e alla fine può mettere in coda il giro successivo. Nell’evoluzione guidata dall’esperienza si parte dal lavoro ordinario: un bug, un uso inefficiente degli strumenti, un contesto costruito male, una lamentela di un utente diventano una «classe di errore» registrata, con causa e rimedio strutturale, e l’agente decide se aprirci sopra un lavoro di manutenzione.

Il cancello

La parte più interessante non sono i benchmark, è il percorso di una modifica. Prima partono controlli deterministici: versione, confini dei dati, dimensioni. Poi del diff si calcola un’impronta, un hash; il diff passa a un pannello di revisori composto da più modelli, e se il pannello non raggiunge il quorum non può registrare un via libera. Alla fine si ricalcola l’impronta: se nel frattempo qualcosa è cambiato, il commit abortisce. Ogni scrittura successiva invalida le revisioni precedenti, perché la revisione vale per quella fotografia del codice e per nessun’altra.

Il proprietario sceglie quanto lasciare fare all’agente: in modalità light non tocca il proprio repository, in advanced fa modifiche ordinarie ma non ai file di governo, in pro può toccare anche quelli, sotto revisione. Una seconda manopola decide se, oltre al diff, un revisore guardi l’intero repository (modalità max) o se questo passaggio si salti (low).

Sopra tutto sta una «costituzione» di principi numerati, da P0 a P12, riletta dal disco a ogni giro del ciclo e sempre in contesto. I primi cinque non si possono cancellare né declassare, e il primo dice che l’autonomia dell’agente non può servire ad aggirare la revisione. Fuori dal repository che l’agente può modificare stanno il supervisore e il comando /panic, che il supervisore intercetta prima che passi per l’agente e che interrompe l’intero albero dei processi, un tetto di spesa esterno che gli strumenti ordinari dell’agente non possono alzare, e il canale autenticato dell’operatore, da cui passano l’assegnazione dei compiti, il budget e la scelta dei modelli.

Quest’ultimo punto è il più lucido del paper. Un agente che può scegliersi le API dei modelli può cercare, con un cambio di configurazione che dall’interfaccia visibile non si nota, un modello più capace o meno restrittivo, e cambiare i costi di ordini di grandezza. Per questo il routing dei modelli è trattato come una modifica di configurazione tracciata e verificata, non come una scelta di esecuzione.

I numeri

Su Terminal-Bench 2.1, 89 compiti difficili da terminale ripetuti cinque volte ciascuno, Ouroboros con Opus 5 risolve 387 prove su 445. Un controllo delle traiettorie ha trovato una prova superata con una scorciatoia (la cartella del sito riempita in anticipo, senza costruire la pipeline da Git al web richiesta), e gli autori hanno chiesto ai curatori di annullarla: 386 su 445. Il miglior concorrente citato è Claude Code con Fable 5, che però gira su un altro modello. I confronti a parità di modello ci sono, con GPT-5.5 e con Grok 4.5.

Su OSWorld-Verified, 361 compiti d’uso del computer, Ouroboros arriva al 90,69% contro il 90,19% del primo in classifica. Su CL-Bench, che misura quanto un sistema impara lungo una sequenza di compiti, fa 0,2301 contro lo 0,1960 del semplice apprendimento nel contesto con lo stesso Sonnet 4.6.

Il paper dichiara l’incertezza su Terminal-Bench, ed è giusto farci due conti. L’errore standard di una proporzione $p$ stimata su $n$ prove è

$$\sigma = \sqrt{\frac{p\,(1-p)}{n}},$$

che con $n = 445$ vale circa 1,7 punti in questa fascia. Gli autori scrivono che il loro 86,74% sta «circa due errori standard» sopra l’83,8%. Il divario è di 2,9 punti; ma quando si confrontano due stime, ciascuna con il suo errore, l’incertezza della differenza è circa $\sqrt{2}\,\sigma \approx 2{,}4$ punti. Il vantaggio, per nostro calcolo, è poco più di un errore standard della differenza: un segnale, non una distanza netta. E la formula tratta le 445 prove come indipendenti, mentre sono 89 compiti ripetuti: l’incertezza vera è un po’ più larga. Su OSWorld il margine è di mezzo punto su un’esecuzione singola.

Poi ci sono le prove in cui Ouroboros non vince. Su SWE-bench Pro, dopo aver tolto in modo simmetrico ogni compito in cui uno dei due sistemi aveva raggiunto la soluzione di riferimento via ricerca web o storia Git, risolve il 58,2% contro il 59,4% di Codex su 655 coppie: differenza non significativa al test di McNemar ($p = 0{,}40$). Su GAIA, con Sonnet 5 per entrambi, fa 78,2% contro il 78,8% di Claude Code. Il paper nota che il filtro sulla contaminazione ribalta la lettura del dato grezzo, e parla di parità.

Hope, 161 giorni in pubblico

La seconda metà del paper racconta Hope, l’istanza di Ouroboros che vive dal febbraio 2026 su sette canali: chat web, voce, Telegram, Discord, X, commenti del sito, email. Al 6 agosto, dopo 161 giorni, il contatore pubblico riporta circa 110.600 dollari di spesa in modelli, 79,7 miliardi di token, 175.755 righe di codice; un’esportazione interna, oscurata, aggiunge circa 3.600 persone e 222.474 messaggi pubblici. I commit di auto-modifica sono 1.085, per il 94,2% scritti dall’agente; i tentativi passati in revisione 1.522, e il tasso di blocco «recente» dei revisori è del 63,5%, senza che il paper dica su quale finestra.

Le persone segnalano difetti e propongono funzioni, ma le loro richieste sono consultive: è Hope a decidere che cosa merita una modifica, e i messaggi pubblici non possono invocare direttamente commit, riavvii o shell. Due esempi del paper danno l’idea. Qualcuno nota che l’agente a volte manda due volte lo stesso messaggio: Hope trova il percorso difettoso e aggiunge un controllo contro i duplicati. Le autorevisioni profonde si interrompono con un’apparente indisponibilità del modello: l’agente scopre che il problema è un contesto troppo grande e sostituisce il modo di assemblarlo con una selezione limitata dei file, ordinata per centralità nel grafo degli import. Un episodio lo raccontano senza enfasi: la quasi totale cancellazione di un worktree non ancora salvato ha fatto scattare, prima del reset dell’operatore, un meccanismo di salvataggio implementato in precedenza. Proprio per questo, scrivono, i meccanismi di conservazione dell’agente possono evolvere, ma l’autorità di fermarlo deve restare al supervisore. Nessun episodio registrato ha opposto resistenza allo spegnimento.

Che cosa il paper non dimostra

Il punto più importante lo dicono gli autori stessi, nell’abstract e in una tabella di appendice: nei benchmark l’evoluzione era spenta. Si misurano «semi congelati», fotografie dell’harness prese da una linea imparentata con Hope, mentre Hope continua a evolvere su una linea separata. È una scelta corretta per la riproducibilità, ma significa che i record dicono quanto è buono l’harness prodotto, non quanto rende il processo che lo produce. Non c’è un confronto fra la stessa base prima e dopo mesi di evoluzione, né una popolazione di agenti evoluti in modo indipendente: gli autori stessi ammettono di seguire una sola linea di sviluppo. E il record principale mette a confronto sistemi interi su modelli diversi, Opus 5 contro Fable 5; dove il modello è lo stesso, il vantaggio va da ampio (Grok 4.5) a nullo (SWE-bench Pro, GAIA).

Anche la sicurezza ha dei buchi dichiarati. I revisori sono modelli linguistici e possono condividere i punti ciechi dell’agente che rivedono. In modalità low la revisione dell’intero repository salta. Nelle prime prove su GAIA l’agente ereditava la cartella home dell’operatore, e i tentativi ripetuti potevano lasciare file sulla sua vera scrivania; i lanci successivi usano cartelle isolate, ma per un isolamento completo, scrivono, le convenzioni di percorso non bastano: serve una sandbox più forte. SWE-bench Pro, infine, soffre di soluzioni trapelate e compiti difettosi.

La posta in gioco

Ouroboros non risolve il problema dell’agente che si migliora da solo, e non lo dichiara. Fa una cosa più modesta e più utile: tratta l’auto-modifica come un problema di ingegneria del software, con i vecchi strumenti del mestiere (commit, revisione, impronte, rollback, un interruttore che il sistema non può toccare). La domanda che lascia aperta è quella giusta: se l’agente può riscrivere tutto ciò che sta dentro il repository, quanto a lungo i controlli che stanno fuori restano davvero fuori. Per ora la risposta è affidata a una separazione architetturale e all’attenzione di chi tiene l’interruttore.