Sedici istanze di Claude Opus 4.6 che lavorano in parallelo, di notte, senza supervisione umana. Il risultato? Un compilatore C scritto in Rust, 100.000 righe di codice, capace di compilare il kernel Linux. E sì, fa girare Doom.
Nicholas Carlini, ricercatore del team Safeguards di Anthropic, ha pubblicato questo esperimento il 5 febbraio 2026. Non è un comunicato stampa patinato. È un report tecnico che solleva domande scomode sul futuro dello sviluppo software autonomo.
Cosa sono gli agent teams e perché dovresti preoccupartene
Gli agent teams rappresentano un’evoluzione della tecnica Ralph-loop – quel trucco dove metti Claude in un ciclo infinito che riesegue il task finché non è completato. La versione di Carlini espande il concetto: invece di un singolo agente, sedici Claude lavorano contemporaneamente su una codebase condivisa.
Il meccanismo di coordinamento è brutalmente semplice. Ogni agente vive in un container Docker separato. Quando vuole lavorare su un task, crea un file di lock nella cartella current_tasks/. Git si occupa della sincronizzazione. Se due agenti provano a prendere lo stesso task, il secondo deve scegliere qualcos’altro.
Merge conflicts? Frequenti. Ma Claude li risolve da solo. Nessun orchestratore centrale, nessun sistema elaborato di comunicazione tra agenti. Ogni Claude decide autonomamente cosa fare dopo guardando lo stato del progetto.
I numeri che fanno riflettere
Due settimane di lavoro autonomo. Quasi 2.000 sessioni di Claude Code. 2 miliardi di token in input, 140 milioni in output. Costo totale: circa 20.000 dollari in chiamate API.
Il risultato è un compilatore clean-room – scritto senza accesso a internet, dipendente solo dalla libreria standard di Rust. Compila Linux 6.9 su x86, ARM e RISC-V. Passa il 99% della GCC torture test suite. Compila PostgreSQL, SQLite, Redis, QEMU, FFmpeg.
E fa girare Doom. Perché apparentemente è l’unico benchmark che conta davvero.
Dove il modello ha fallito
Carlini non nasconde le limitazioni. Il compilatore manca del generatore di codice x86 a 16 bit necessario per il boot di Linux da real mode – quella fase viene delegata a GCC. L’assembler e il linker sono ancora buggy. Il video demo usa quelli di GCC.
Il codice generato è inefficiente. Con tutte le ottimizzazioni attive, produce codice peggiore di GCC con le ottimizzazioni disattivate. La qualità del Rust è ragionevole, ma lontana da quella di un programmatore esperto.
Carlini ha provato – dice lui stesso “hard!” – a far risolvere queste limitazioni al modello. Nuove feature e bugfix continuavano a rompere funzionalità esistenti. Il compilatore ha raggiunto i limiti delle capacità di Opus 4.6.
Le lezioni pratiche per chi lavora con agenti AI
La parte interessante del paper non è il compilatore in sé. Sono le tecniche che Carlini ha sviluppato per far funzionare il sistema.
Test di qualità altissima o niente
Claude risolverà qualsiasi problema gli dai. Il problema è definire correttamente cosa vuoi. Se il verificatore di task non è quasi perfetto, Claude risolverà il problema sbagliato. Carlini ha dovuto trovare test suite di compilatori di alta qualità, scrivere verificatori per pacchetti open source, e creare nuovi test ogni volta che identificava failure mode.
Verso la fine del progetto, Claude iniziava a rompere funzionalità esistenti ogni volta che implementava feature nuove. La soluzione: una pipeline di continuous integration con enforcement più stretto.
Pensa come penserebbe Claude
Il test harness deve essere scritto per Claude, non per te. Ogni agente parte in un container fresco senza contesto. Prima ancora di arrivare ai test, Carlini ha incluso istruzioni per mantenere README estesi e file di progresso aggiornati frequentemente.
I modelli linguistici hanno limitazioni specifiche da aggirare. Context window pollution: il test harness non deve stampare migliaia di byte inutili. Al massimo qualche riga, con log dettagliati in file separati. Formato dei log processabile automaticamente – se c’è un errore, scrivi ERROR e la ragione sulla stessa riga così grep lo trova.
Time blindness: Claude non sa che ore sono. Lasciato solo, passerà ore a eseguire test invece di fare progressi. Il harness stampa progresso incrementale raramente e include un’opzione –fast che esegue l’1% o il 10% dei test in modo deterministico per agente ma random tra VM.
Parallelizzazione intelligente
Quando ci sono molti test falliti, è banale: ogni agente lavora su un test diverso. Quando la test suite raggiunge il 99% di pass rate, ogni agente compila un progetto open source diverso.
Ma quando gli agenti hanno iniziato a compilare il kernel Linux, si sono bloccati. Compilare il kernel è un task monolitico. Ogni agente colpiva lo stesso bug, lo fixava, e sovrascriveva i cambiamenti degli altri. Sedici agenti non servivano a niente perché tutti risolvevano lo stesso problema.
La soluzione: usare GCC come oracolo. Un nuovo test harness compilava la maggior parte del kernel con GCC, solo i file rimanenti con il compilatore di Claude. Se il kernel funzionava, il problema non era nei file di Claude. Se si rompeva, si raffinava ulteriormente. Questo permetteva a ogni agente di lavorare in parallelo su bug diversi in file diversi.
Specializzazione degli agenti
Non tutti gli agenti devono fare la stessa cosa. Carlini ne ha assegnato uno a coalescere codice duplicato. Un altro ottimizzava le performance del compilatore stesso. Un terzo migliorava l’efficienza del codice compilato. Uno criticava il design dal punto di vista di uno sviluppatore Rust. Un altro si occupava della documentazione.
Le implicazioni che tengono Carlini sveglio di notte
Carlini viene dal penetration testing. Ha passato anni a sfruttare vulnerabilità in prodotti di grandi aziende. L’idea di programmatori che deployano software che non hanno mai verificato personalmente lo preoccupa.
Quando un umano siede con Claude durante lo sviluppo, può assicurare qualità consistente e catturare errori in tempo reale. Per sistemi autonomi, è facile vedere i test passare e assumere che il lavoro sia fatto. Raramente è così.
“Costruire questo compilatore è stato tra le cose più divertenti che ho fatto di recente,” scrive Carlini. “Ma non mi aspettavo che qualcosa del genere fosse neanche lontanamente possibile così presto nel 2026.”
Il rapido progresso nei modelli linguistici e negli scaffold per interagirci apre la porta alla scrittura di quantità enormi di nuovo codice. Carlini si aspetta che le applicazioni positive superino quelle negative. Ma riconosce che stiamo entrando in un mondo nuovo che richiederà strategie nuove per navigarlo in sicurezza.
Dove va a finire tutto questo
Ogni generazione di modelli linguistici apre modi nuovi di lavorarci. I primi modelli servivano per il tab-completion negli IDE. Poi potevano completare il corpo di una funzione dalla docstring. Claude Code ha portato gli agenti al mainstream, permettendo ai developer di fare pair programming con Claude.
Ma tutti questi prodotti operano con l’assunzione che un utente definisce un task, un LLM gira per secondi o minuti e ritorna una risposta, poi l’utente fornisce un follow-up.
Gli agent teams mostrano la possibilità di implementare interi progetti complessi in modo autonomo. Questo permette a chi usa questi strumenti di diventare più ambizioso con i propri obiettivi.
Il codice sorgente del compilatore è disponibile su GitHub. Carlini continuerà a far pushare nuovi cambiamenti a Claude per chi vuole seguire i tentativi continuati di affrontare le limitazioni.
Siamo ancora agli inizi. Lo sviluppo completamente autonomo comporta rischi reali. Ma il genio è uscito dalla lampada. La domanda non è più se sia possibile, ma come gestirlo.
