C’è un equivoco diffuso quando si parla di “agenti AI” applicati allo sviluppo software. Molti immaginano un assistente evoluto che scrive funzioni, corregge bug e magari propone refactoring, sempre sotto la supervisione di un programmatore, in una visione ancora legata al paradigma classico del pair programming. Il recente esperimento di Anthropic con Claude Opus 4.6 sposta invece l’asticella in un territorio diverso, con più istanze dello stesso modello che lavorano in parallelo su un’unica codebase e senza un operatore umano costantemente presente, con l’obiettivo di portare avanti un progetto complesso per settimane.

Il banco di prova scelto da Anthropic è volutamente estremo. Sedici agenti di Claude Code sono stati infatti incaricati di scrivere da zero un compilatore C in Rust senza dipendenze esterne capace di compilare il kernel Linux. Non un toy compiler per dimostrazione accademica, ma un artefatto concreto in grado di costruire Linux 6.9 su x86, ARM e RISC-V. Il risultato finale, dopo quasi 2.000 sessioni e circa 20.000 dollari di API, è un compilatore da circa 100.000 linee, con un tasso di successo vicino al 99% sui test più severi del settore inclusi i GCC torture tests.

Il compilatore, di per sé, è già una prova di forza non comune, ma il punto più interessante dell’esperimento è ciò che emerge sul design dell’infrastruttura che permette a un modello di lavorare in autonomia per lungo tempo e senza la supervisione umana.

Un agente LLM, se lasciato solo, tende a fermarsi e anche strumenti evoluti come Claude Code, per come sono concepiti oggi, danno per scontato che l’utente rimanga in loop, pronto a rispondere, chiarire, approvare. Se il compito è lungo e complesso, il modello arriva a un punto in cui chiede input o attende un segnale.

Per forzare una progressione sostenuta, l’autore costruisce un loop estremamente semplice, con un wrapper che lancia sessioni consecutive del modello in container isolati. Finito un task, l’agente riparte subito con il successivo. Un dettaglio tecnico che introduce un cambio concettuale per cui il modello diventa un processo continuo. E quando un processo è continuo, i difetti non vengono “coperti” dall’intervento umano, ma si accumulano come debito tecnico.

Il secondo aspetto interessante dell’esperimento riguarda il parallelismo. Un singolo agente può fare una cosa alla volta e questo limita drasticamente la scalabilità, ma 16 agenti permettono di distribuire debugging, implementazioni e pulizia del codice su più flussi di lavoro. Il parallelismo introduce anche un vantaggio spesso trascurato come la specializzazione, visto che alcuni agenti possono concentrarsi sulle feature, altri sulla performance, altri ancora su code quality e documentazione. È una replica artificiale di ciò che fa un team reale, con un costo marginale che dipende più dall’API che dal recruiting.

L’implementazione, inoltre, è volutamente “povera” di orchestrazione. Non esiste un agente manager centrale, non esiste una chat interna tra agenti, non esiste una roadmap imposta dall’alto. Ogni istanza lavora in un container, clona la repository, prende in carico un task e fa commit e push su un upstream comune. Il coordinamento avviene con un sistema di lock file che impedisce a due agenti di lavorare sullo stesso task.

Claude compilatore

Il risultato finale, per quanto impressionante, è volutamente descritto con onestà dalla stessa Anthropic. Il compilare infatti non è ancora un drop-in replacement, manca un backend 16-bit x86 realmente funzionale e la qualità del codice generato è inferiore a GCC, uno dei compilatori più usati al mondo per trasformare codice sorgente in programma eseguibile o in codice oggetto.

Il punto più interessante, però, è che il progetto sembra arrivare a un plateau in cui ogni nuova feature o bugfix tende a rompere qualcosa che prima funzionava. È il comportamento tipico di un sistema complesso sviluppato senza una visione architetturale forte e continua e mostra che senza supervisione umana, la coerenza globale diventa fragile.

In ogni caso, questo esperimento suggerisce che la traiettoria degli strumenti di sviluppo AI sta entrando in una fase nuova. Prima c’erano completamenti, poi funzioni, poi pair programming, mentre ora si intravede la possibilità di progetti interi portati avanti da agenti persistenti. Ed è qui che emerge la doppia faccia del progresso. La produttività potenziale cresce in modo enorme, ma al tempo stesso cresce anche il rischio di software scritto, assemblato e “validato” da test, ma mai veramente compreso da chi lo distribuisce, in un contesto dove basta un errore sistemico per trasformare un acceleratore di sviluppo in un moltiplicatore di vulnerabilità.