Akka mette alla prova il porting AI su 65 progetti open source con 9,41 miliardi di token

L'esperimento è durato 99,3 ore. Ha consumato 9,41 miliardi di token. Akka ha usato questa potenza di calcolo per verificare quanto bene gli agenti AI riuscissero a fare il porting di software open source quando li guidano specifiche strutturate.

Porting guidato da specifiche su larga scala

Secondo InfoQ, Akka ha analizzato tutti e 65 i progetti in una prima tranche. Ha generato le specifiche e implementato fino al 10% della superficie di ciascun progetto. Poi ha scelto 10 progetti da implementare per intero in base alle caratteristiche del sistema. Il ciclo di consegna alternava scoperta, specifica, porting, benchmark e miglioramento. Claude, affiancato da Akka Specify, si è occupato di implementazione, test e revisione. Questa struttura ha permesso al team di isolare i punti di fallimento nella pipeline di migrazione. Ha chiarito dove l'automazione funzionava e dove serviva l'intervento umano. Il processo non è stato un semplice trova e sostituisci. È stata una trattativa complessa tra la logica del codice originale e i nuovi vincoli architetturali dell'ambiente di destinazione.

I risultati sono stati misti ma significativi.

Akka ha riportato un miglioramento delle righe di codice o delle prestazioni in 57 dei 65 porting. L'azienda ha però segnalato che nei file di contesto restavano lacune sulle decisioni che coinvolgono più componenti. Questo suggerisce che l'AI sa gestire componenti isolati. Fatica a capire il sistema nel suo insieme senza definizioni comportamentali precise e tipizzate. La qualità delle specifiche conta più della potenza grezza del modello. I team che valutano una modernizzazione assistita dall'AI dovrebbero tenerne conto. L'impegno speso a definire vincoli comportamentali chiari produce implementazioni migliori al primo passaggio rispetto a fidarsi solo delle capacità del modello. È un dato che conta per i responsabili tecnici che devono bilanciare velocità e affidabilità nelle roadmap di migrazione.

«Specifiche strutturate con asserzioni, evidenze e comportamenti tipizzati hanno migliorato le implementazioni al primo passaggio», si legge nel rapporto.

Efficienza e costo dei modelli

La scelta del modello ha inciso sia sulla velocità sia sul costo. Secondo il rapporto di InfoQ, Sonnet ha impiegato in media 61 minuti per porting contro i 120 di Opus. Opus però ha usato circa il 40% di token in meno. Impostazioni di impegno più alte aumentavano i consumi senza migliorare in modo costante l'efficienza. Questo compromesso mette in luce la realtà economica dell'uso di modelli di frontiera per la migrazione di codice in massa.

Nei commenti su LinkedIn qualcuno ha osservato che i modelli più piccoli seguivano la specifica più da vicino. I modelli più grandi tendevano a improvvisare. Aaditya, un commentatore citato da InfoQ, ha scritto: «Il comportamento del modello più piccolo corrispondeva al lavoro di modernizzazione che aveva osservato, dove il modello piccolo segue la specifica mentre uno più grande può improvvisare». L'osservazione è coerente con i dati sul consumo di token. I vincoli possono dare risultati migliori della capacità grezza. Per i team aziendali, scegliere sempre il modello più grande disponibile non è la strategia ottimale per progetti di migrazione economicamente sostenibili.

Per chi gestisce budget, questi dati offrono un punto di riferimento.

Se state facendo il porting di codice legacy, la qualità delle specifiche può decidere se risparmiate tempo o bruciate potenza di calcolo. La cifra di 9,41 miliardi di token è un numero concreto su cui pianificare. Non è un costo banale, nemmeno per una grande impresa. Per dare la misura, i 9,4 miliardi di token non sono un tetto: sono quanto è stato effettivamente speso.

La governance dell'open source nell'era dell'AI

L'esperimento si colloca in un contesto di norme che cambiano nella sicurezza e nella manutenzione dell'open source. Il 1° ottobre Google ha sospeso l'invio di segnalazioni di vulnerabilità di prodotto al suo Open Source Software Vulnerability Reward Program. Lo ha fatto per l'ondata di segnalazioni non valide generate dall'AI, secondo Tom's Hardware. Il programma non riprenderà prima del primo trimestre del 2.027. La mossa mette in evidenza la pressione che i contenuti generati dall'AI esercitano sui sistemi moderati da persone.

Sul fronte opposto, Anil Madhavapeddy, professore a Cambridge, ha sostenuto in un articolo discusso da InfoQ che gli agenti AI stanno sconvolgendo la divulgazione tradizionale delle vulnerabilità. Ha raccontato che nei log del suo webserver sono comparse sonde pochi minuti dopo l'apertura di una PR per correggere una vulnerabilità. «Mi sembra che i nostri processi di sicurezza debbano in qualche modo invertirsi», ha scritto. Il tempo tra divulgazione e sfruttamento si accorcia perché gli agenti AI riescono a generare exploit da indizi limitati.

Queste questioni di governance non sono astratte. Riguardano gli stessi progetti open source a cui oggi si chiede di fare porting e manutenzione con gli agenti AI. Se l'AI sa scrivere il codice, sa anche trovare i bug. La difficoltà è distinguere l'automazione utile da quella malevola o sciatta. L'esperimento di Akka prova a risolvere il primo caso. I rapporti di Google e Cambridge illustrano il secondo.

Infrastruttura e strumenti

L'ascesa dello sviluppo assistito dall'AI sta cambiando anche l'infrastruttura che circonda l'open source. Il 5 ottobre GitHub ha rilasciato ReviewBench, un benchmark aperto per la revisione del codice fatta dall'AI. Secondo il blog di GitHub, il benchmark usa 219 pull request pubbliche in 19 linguaggi. È modellato su oltre 100.000.000 di pull request reali. Punta a offrire una metodologia di valutazione rigorosa e riproducibile per gli agenti che revisionano il codice.

Nello stesso giorno Reflection AI ha rilasciato Beam, un modello a pesi aperti con 501.000.000.000 di parametri totali. Secondo Semafor, Beam è presentato come un «cavallo da tiro» per il coding e i compiti agentici. Richiede da tre a quattro volte meno potenza di calcolo rispetto a modelli aperti comparabili. Il rilascio riflette una tendenza verso modelli a pesi aperti ed efficienti, che si possono distribuire in locale o in sistemi di AI sovrana.

Questi strumenti formano il nuovo stack per lo sviluppo open source.

Ci sono i modelli (Beam, Sonnet, Opus), i benchmark (ReviewBench), i flussi di lavoro (Akka Specify) e le sfide di sicurezza (la sospensione del VRP di Google). L'ecosistema sta maturando, ma lo fa sotto pressione. I 9,41 miliardi di token usati da Akka ricordano che non è un pranzo gratis. È un processo intensivo in risorse e richiede una gestione attenta.

Per gli ingegneri il messaggio è chiaro. L'AI sa fare il porting del codice, ma ha bisogno di struttura. Sa revisionare il codice, ma ha bisogno di benchmark. Sa trovare vulnerabilità, ma sa anche inondarne i sistemi. La direzione dell'open source non riguarda solo chi scrive il codice. Riguarda come lo verifichiamo, lo mettiamo in sicurezza e lo manteniamo in un'epoca di generazione sintetica.