Il rapporto ACM sull'AI open source avverte: la programmazione più veloce sta sovraccaricando la revisione umana

Il rapporto ACM sull'AI open source individua un'inversione costosa: l'AI può produrre patch rapidamente, ma sono ancora gli esseri umani a dover decidere quali modifiche meritino fiducia. Questo squilibrio aumenta il lavoro dei manutentori, che già operano con tempo, finanziamenti e capacità di revisione limitati.

Pubblicato dal Technology Policy Council dell'Association for Computing Machinery, il rapporto esamina gli effetti dell'AI sul software open source. La sua preoccupazione centrale non è se l'AI possa scrivere codice utile, bensì se i progetti guidati da persone possano assorbire in sicurezza un flusso molto più ampio di contributi assistiti dalle macchine.

La distinzione è importante perché il software open source supporta telefoni, veicoli, servizi cloud e sistemi di AI. Eppure molti progetti rilevanti dipendono da volontari o piccoli team. Godot, curl e altri progetti hanno già inasprito le regole di contribuzione dopo aver incontrato invii AI di bassa qualità. La promessa di codice abbondante si scontra con la realtà della scarsa attenzione umana.

Il rapporto ACM sull'AI open source sposta l'attenzione sulla revisione

Il rapporto sostiene che una produzione di codice più veloce non elimina il collo di bottiglia umano. Sposta quel collo di bottiglia nella revisione, nella governance e nella manutenzione.

L'ACM TechBrief è stato pubblicato nel 2026 da sei autori che lavorano attraverso il Technology Policy Council dell'ACM. Tra loro figurano Arunachalam Balasubramanian Shrinivass, Simson Garfinkel, Josiah Dykstra, Andy Oram, Nina Shamsi e Jonathan M. Smith.

Il documento affronta quattro pressioni connesse: cybersicurezza, manutenzione software, sostenibilità finanziaria e conoscenza limitata delle organizzazioni riguardo alle proprie dipendenze open source. L'AI influenza ciascuna di queste aree, ma non nello stesso modo.

I sistemi di AI possono individuare vulnerabilità, proporre patch, scrivere test e automatizzare il lavoro di sviluppo ordinario. Queste capacità possono aiutare un progetto ben gestito a risolvere più rapidamente problemi ben definiti. Possono anche aiutare un contributore a preparare documentazione o a esplorare una base di codice non familiare.

Tuttavia, una pull request è solo una proposta per modificare il progetto. Un manutentore fidato deve stabilire se risolve il problema dichiarato, preserva la compatibilità, soddisfa gli standard del progetto ed evita nuovi rischi per la sicurezza.

Questa decisione richiede spesso più della lettura delle righe modificate. I revisori potrebbero dover riprodurre il problema, ispezionare moduli correlati, valutare le conseguenze architetturali e testare il comportamento negli ambienti supportati.

L'AI riduce il costo della creazione di un invio plausibile. Non riduce allo stesso ritmo il costo della comprensione di ogni conseguenza.

Questa asimmetria cambia l'economia della partecipazione. Un contributore può generare diverse patch mentre un manutentore sta ancora esaminando la prima. Il mittente può anche andarsene dopo aver aperto la richiesta, mentre il progetto eredita ogni questione irrisolta.

Il reporting originale descrive questo fenomeno come più codice da verificare per gli esseri umani. Questa formulazione coglie il problema immediato, ma la conseguenza più ampia è più seria.

Le release open source dipendono dalla fiducia delegata. I manutentori decidono quali contributori, processi e artefatti siano sufficientemente affidabili da entrare in una build ufficiale. Un aumento dell'output non verificato crea quindi lavoro di governance, non soltanto lavoro di programmazione.

Il rapporto non afferma che ogni contributo assistito dall'AI sia scadente. Riconosce che la qualità dei modelli può migliorare. Il problema irrisolto è che ogni invio aggiuntivo richiede comunque un certo livello di giudizio umano.

Quel giudizio è particolarmente costoso quando il codice generato appare convincente. Una patch può compilare e superare i test visibili pur fraintendendo un'assunzione non documentata. Può anche aggiungere complessità apparentemente innocua, finché modifiche successive non la mettono in evidenza.

Il rapporto ACM sull'AI open source modifica quindi la domanda centrale. Il problema non è più semplicemente se l'AI renda più veloci i singoli sviluppatori. È se la capacità di revisione a livello di progetto cresca insieme al loro output.

Questa riformulazione crea il conflitto principale dell'articolo: abbondanza generata dalle macchine contro fiducia controllata dagli esseri umani.

I manutentori open source affrontano un divario nella capacità di revisione

I progetti sottoposti alla maggiore pressione non sono necessariamente quelli con il codice peggiore. Sono quelli con un'adozione elevata e troppo pochi revisori qualificati.

Un revisore qualificato necessita di più di una generica capacità di programmazione. Deve comprendere l'architettura del progetto, le promesse di compatibilità, il processo di rilascio e le aspettative della comunità.

Questa conoscenza si sviluppa lentamente. Un progetto maturo può avere migliaia di utenti ma solo un piccolo gruppo capace di approvare modifiche rilevanti. Aggiungere un altro generatore di codice non crea automaticamente un altro revisore fidato.

Il problema si acuisce quando l'AI attrae contributori alla prima esperienza. Una nuova partecipazione può rafforzare una comunità open source quando i contributori apprendono le sue norme e alla fine assumono responsabilità di manutenzione.

La revisione tradizionale ha in parte svolto questa funzione di mentoring. Un manutentore spiega perché una modifica necessita di revisione e il contributore porta quella conoscenza nel lavoro futuro.

La partecipazione mediata dalle macchine può interrompere questo scambio. Il manutentore continua a spendere tempo per spiegare i requisiti del progetto, ma chi invia il codice potrebbe non comprendere né trattenere la lezione.

Godot ha reso esplicita questa preoccupazione quando ha annunciato regole di contribuzione più rigide il 30 giugno 2026. Il motore di gioco open source ha dichiarato che il suo bacino di revisori qualificati era ristretto e che l'arretrato di pull request era già difficile da gestire.

Godot ha affermato che l'AI aveva ridotto lo sforzo necessario per creare una pull request senza diminuire il lavoro necessario per esaminarla. La fondazione ha inoltre messo in dubbio il valore di un feedback che non forma né il contributore né un futuro manutentore.

Le regole previste vietano agenti AI autonomi e codice sostanzialmente scritto dall'AI. Richiedono inoltre responsabilità umana e divulgazione quando i contributori utilizzano un'assistenza AI limitata.

La politica non rappresenta semplicemente un rifiuto ideologico dell'AI. È un tentativo di proteggere una risorsa scarsa: il tempo informato dei revisori.

Il rischio va oltre gli invii di codice. I progetti possono ricevere segnalazioni di bug generate, proposte di funzionalità, rilevamenti di sicurezza e commenti nelle discussioni. Ogni elemento compete per l'attenzione degli stessi manutentori.

Una segnalazione di vulnerabilità apparentemente dettagliata può essere particolarmente costosa. I revisori devono stabilire se la falla dichiarata esista prima di poterla scartare in sicurezza. Una segnalazione inventata può consumare ore anche quando non produce alcuna correzione.

Un preprint del luglio 2026 ha descritto questo modello come un'ondata di contributi AI. I ricercatori hanno analizzato 294 repository contenenti oltre due milioni di pull request e issue.

Hanno riferito che il volume delle pull request è aumentato nel 2025 mentre i tassi di merge sono diminuiti. I contributori occasionali hanno registrato un calo del 18,18 percento nei tassi di merge rispetto al controfattuale modellato dallo studio.

I ricercatori hanno inoltre intervistato professionisti e condotto un sondaggio tra 229 partecipanti all'open source. Hanno identificato strategie difensive che andavano da modelli di contribuzione più rigorosi a restrizioni più ampie sugli invii esterni.

Questi risultati non stabiliscono che l'AI abbia causato ogni richiesta respinta. Gli studi sui repository affrontano anche limiti di classificazione e confronto. Mostrano però perché i manutentori percepiscono il nuovo volume come un problema di capacità.

Un altro studio del 2026 ha esaminato 11.097 repository GitHub tra gennaio 2023 e maggio 2026. Ha riportato un aumento del 5,3 percento nella profondità della revisione dopo che i progetti hanno adottato agenti di programmazione AI.

La profondità della revisione misura l'intensità dell'interazione di revisione, non la qualità del software finale. Tuttavia, l'aumento supporta un meccanismo coerente: una generazione più rapida trasferisce il lavoro verso la convalida.

Il risultato è un divario nella capacità di revisione. Il volume dei contributi può espandersi attraverso un'automazione a basso costo, mentre la revisione affidabile resta legata a una competenza umana scarsa.

La programmazione AI più veloce crea un compromesso tra fiducia e sicurezza

L'AI può aiutare a riparare il software open source, ma la stessa velocità può aumentare le opportunità di attacco e sopraffare le persone responsabili di release sicure.

Il rapporto ACM sull'AI open source presenta l'AI come una capacità a duplice uso. I modelli possono individuare vulnerabilità e proporre correzioni. Tecniche simili possono aiutare gli aggressori a cercare debolezze o a generare invii malevoli persuasivi.

CodeMender di Google illustra la promessa difensiva. Secondo Google, l'agente ha contribuito a 72 correzioni di sicurezza per progetti open source tra aprile e ottobre 2025.

Alcuni progetti presi di mira contenevano fino a 4,5 milioni di righe di codice. L'automazione può essere preziosa su questa scala perché i team umani non possono ispezionare manualmente ogni percorso.

Tuttavia, una correzione automatizzata entra comunque nel processo di fiducia di un progetto. I manutentori devono verificare la diagnosi, esaminare la patch, valutare i test e coordinare i tempi della release.

Questo processo diventa più difficile quando un'applicazione dipende da molti pacchetti distinti. Ogni componente ha i propri manutentori, il proprio calendario di release e i propri utenti downstream.

Un sistema di AI potrebbe individuare rapidamente debolezze correlate in diverse librerie. L'ecosistema non può necessariamente correggere, rilasciare e distribuire ogni componente interessato alla stessa velocità.

Gli aggressori non affrontano le stesse responsabilità. Possono generare molte ipotesi, abbandonare i fallimenti e sfruttare il primo risultato utile. I difensori devono indagare su rilevamenti credibili senza compromettere i sistemi esistenti.

I repository aperti creano anche un rischio per la supply chain. Un attore malevolo può inviare un pacchetto, una patch o un aggiornamento di dipendenza che sembra utile mentre nasconde comportamenti indesiderati.

L'AI può rendere tali invii più rifiniti. Può generare test, documentazione e spiegazioni dettagliate che creano un'apparenza di cura. La qualità della presentazione non stabilisce la provenienza né la sicurezza.

Ecco perché una suite di test superata non può fungere da unico controllo. I test rappresentano aspettative note. Raramente coprono ogni confine di sicurezza, ambiente insolito o costo di manutenzione a lungo termine.

I revisori devono chiedersi chi comprenda la modifica e chi la riparerà in seguito. Devono anche stabilire se dipendenze aggiunte, file generati o schemi non familiari amplino la superficie di attacco del progetto.

Questa questione di responsabilità distingue l'assistenza dalla delega. Uno sviluppatore può utilizzare l'AI rimanendo in grado di difendere ogni scelta progettuale. Un contributore che non sa spiegare la patch trasferisce tale responsabilità al progetto.

Le organizzazioni che utilizzano l'open source ne ereditano le conseguenze. Molti team mantengono una base di conoscenza tecnica, ma continuano a non avere una mappa aggiornata delle proprie dipendenze software.

Una distinta base del software, o SBOM, fornisce un inventario leggibile dalle macchine dei componenti di un'applicazione. Può aiutare un team di sicurezza a individuare una libreria interessata dopo la divulgazione di una vulnerabilità.

Un SBOM non può mostrare se il componente disponga di un numero sufficiente di manutentori. Non può rivelare se le pull request irrisolte si stiano accumulando o se la governance di un progetto si sia indebolita.

Non può nemmeno determinare se una correzione generata dall'AI abbia ricevuto una revisione adeguata. L'inventario è necessario, ma la consapevolezza organizzativa deve includere anche la salute del progetto e le pratiche di manutenzione.

Il compromesso, quindi, non è tra IA e sicurezza. È tra velocità senza responsabilità e velocità supportata da revisione, tracciabilità e titolarità responsabile.

L’IA può accorciare il percorso dalla scoperta a una patch candidata. Non può eliminare la necessità di stabilire che la patch appartenga a una release affidabile.

Il modello di finanziamento non rispecchia il valore dell’open source

L’IA sta aumentando le richieste rivolte ai maintainer in un ecosistema il cui valore economico supera di gran lunga i finanziamenti che raggiungono molti singoli progetti.

Il documento ACM cita una ricerca secondo cui le aziende spenderebbero 3,5 volte di più per il software se l’open source non esistesse. Lo stesso studio sul valore economico ha stimato il suo valore mondiale, dal lato della domanda per le imprese, in 8,8 trilioni di dollari.

Queste cifre descrivono i costi che le organizzazioni evitano utilizzando software condiviso. Non rappresentano entrate percepite dai maintainer.

Questo divario conta perché la manutenzione dell’open source comprende molto più della scrittura di codice. I progetti necessitano di gestione delle release, documentazione, supporto agli utenti, packaging, test, raccolta fondi e moderazione della community.

L’IA può assistere in alcune parti di questo lavoro. Non può decidere le priorità di un progetto né riconciliare i disaccordi tra utenti, contributori e sponsor.

Il rapporto ACM sull’IA open source evidenzia un significativo confronto istituzionale. La Linux Foundation ha dichiarato ricavi per 292.217.236 dollari nel 2024. L’Apache Software Foundation ha dichiarato 2.379.402 dollari.

Queste organizzazioni differiscono per ambito e modello operativo, quindi i loro ricavi non dovrebbero essere considerati un confronto diretto delle prestazioni. Il contrasto dimostra comunque quanto disomogeneamente le risorse possano fluire nell’open source.

La disuguaglianza più rilevante esiste a livello di progetto. Un componente ampiamente utilizzato può non avere un’organizzazione dedicata, un contratto di supporto o un maintainer a tempo pieno.

Le aziende possono costruire servizi redditizi su quel componente senza sapere chi approva le release. Potrebbero indagarne la governance solo dopo la comparsa di una vulnerabilità, di un abbandono o di una modifica incompatibile.

Questo è il problema del free rider: gli utenti ricevono valore da una risorsa condivisa senza contribuire in modo proporzionato alla sua manutenzione. L’IA non crea questo problema, ma può intensificarlo.

Un’azienda può utilizzare strumenti di coding basati sull’IA per produrre modifiche a una dipendenza esterna. Se i suoi ingegneri inviano tali modifiche upstream, il progetto ricevente si assume il costo della revisione.

L’azienda ottiene una generazione di codice meno costosa. Il maintainer volontario riceve un’altra proposta da convalidare.

Anche una patch utile comporta lavoro di coordinamento. I maintainer devono assicurarsi che supporti la comunità di utenti più ampia, non solo i requisiti privati del contributore.

Le proposte di bassa qualità impongono un costo esterno maggiore. L’organizzazione che le invia può abbandonare la richiesta, mentre il progetto deve chiuderla, spiegare la decisione o gestire il conflitto risultante.

I finanziamenti possono aumentare la capacità di revisione, ma il denaro da solo non crea immediatamente competenza. Un nuovo maintainer ha comunque bisogno di tempo per imparare il progetto e guadagnare la fiducia della community.

Ciò significa che il supporto dovrebbe estendersi oltre le ricompense a breve termine per i bug. I progetti necessitano di finanziamenti continuativi per documentazione, onboarding, infrastruttura di test, packaging e pianificazione della successione.

Le raccomandazioni del documento ACM riflettono questa esigenza più ampia. Chiede maggiore attenzione alla sostenibilità finanziaria e al lavoro organizzativo che mantiene i progetti utilizzabili.

Gli acquirenti aziendali dovrebbero trattare questo tema come gestione della supply chain. Se una dipendenza critica è mantenuta da un solo volontario esausto, questa condizione rappresenta un rischio operativo.

I team di procurement valutano abitualmente la stabilità dei fornitori commerciali. Raramente applicano un controllo equivalente ai pacchetti open source perché nessuna fattura attiva la revisione.

La pressione delle contribuzioni generate dall’IA rende questa omissione più difficile da giustificare. Più output automatizzato può arrivare a un progetto, mentre la sua capacità umana resta invisibile agli utenti downstream.

La questione dei finanziamenti è quindi inseparabile dalla questione della revisione. Un sistema che genera più proposte senza finanziare il giudizio approfondirà il collo di bottiglia.

I divieti generalizzati sull’IA proteggono l’attenzione ma possono restringere la partecipazione

Barriere più rigorose possono preservare la capacità di revisione nel breve periodo, ma restrizioni mal progettate possono anche bloccare contributori legittimi e indebolire le future pipeline di maintainer.

Un progetto che affronta un’ondata di proposte a basso valore ha diverse opzioni. Può richiedere la divulgazione dell’uso dell’IA, limitare la dimensione dei contributi, pretendere test riproducibili, restringere le nuove funzionalità o vietare certe forme di utilizzo dell’IA.

Ogni regola cambia chi sostiene il costo. Un modello dettagliato per le proposte obbliga i contributori a spiegare il proprio lavoro prima che un maintainer inizi a revisionarlo.

I requisiti di autorizzazione riducono le richieste speculative di funzionalità. I controlli automatizzati possono respingere errori di formattazione o test mancanti prima della revisione umana.

Un divieto generalizzato offre un confine più chiaro, ma è difficile da applicare. Il codice generato dall’IA non porta un marcatore tecnico affidabile, e anche il lavoro scritto da esseri umani può essere di bassa qualità.

Gli strumenti di rilevamento possono produrre falsi positivi. I contributori che scrivono in una seconda lingua o utilizzano strumenti di accessibilità possono essere messi ingiustamente in discussione se un testo rifinito diventa prova dell’uso dell’IA.

Regole rigide possono anche rendere più difficile l’ingresso per i nuovi arrivati genuini. L’open source dipende dalla trasformazione di alcuni contributori alla prima esperienza in partecipanti di lungo periodo.

Se i progetti chiudono ogni percorso accessibile, possono proteggere i revisori di oggi riducendo al contempo il bacino di maintainer di domani. Questa è la trappola della sostenibilità identificata da ricerche recenti.

Il rapporto ACM sull’IA open source non fornisce una politica universale per i contributi. La governance open source resta decentralizzata e i progetti differiscono notevolmente per rischio, scala e capacità di revisione.

Una piccola utility da riga di comando non può copiare il processo di una grande fondazione. Una libreria crittografica dovrebbe applicare requisiti di garanzia diversi rispetto a uno strumento sperimentale di design.

Le evidenze raccolte dai maintainer mostrano comunque un ampio scetticismo. Il sondaggio tra i maintainer di Tidelift ha chiesto in che modo un uso noto dell’IA avrebbe influenzato la disponibilità a revisionare i contributi.

Tra 344 intervistati, il 64 per cento ha dichiarato che sarebbe stato meno disposto a revisionare o accettare contributi prodotti dall’IA. Il nove per cento ha affermato che sarebbe stato più disposto, mentre il 27 per cento non era sicuro.

Il sondaggio precede i più recenti agenti di coding e gli atteggiamenti potrebbero cambiare con il miglioramento degli strumenti. Mostra comunque che la fiducia nei contributori non può essere presunta dalla capacità tecnica.

L’obiettivo politico più equo è la responsabilità, non lo stile di scrittura. I contributori dovrebbero comprendere le proprie modifiche, divulgare l’automazione rilevante, fornire prove e restare disponibili per le revisioni.

I progetti possono inoltre separare l’assistenza a basso rischio dalla delega sostanziale. Il completamento del codice, la sostituzione meccanica e la traduzione possono creare oneri diversi rispetto allo sviluppo autonomo di funzionalità.

Anche la dimensione del contributo conta. Una patch mirata con un bug riprodotto e test specifici è più facile da valutare rispetto a un ampio refactoring generato senza una discussione preventiva.

I maintainer necessitano dell’autorità per chiudere proposte che creano un lavoro di revisione sproporzionato. Hanno inoltre bisogno di politiche che spieghino questo confine prima che i contributori investano tempo.

Piattaforme come GitHub possono aiutare offrendo ai progetti controlli più solidi sull’ingresso dei contributi. Funzionalità utili potrebbero includere autorizzazioni per i contributi, dichiarazioni strutturate, limiti di frequenza e controlli specifici del repository.

Il supporto della piattaforma non può sostituire la governance locale. Può ridurre lo sforzo amministrativo necessario per applicare le scelte di ciascuna community.

Il punto scettico resta importante: le evidenze attuali non possono misurare tutto il lavoro assistito dall’IA. I contributori non dichiarano sempre l’uso degli strumenti e i ricercatori devono dedurre l’adozione da segnali incompleti.

Un aumento dell’attività di revisione potrebbe riflettere progetti più grandi o popolazioni di contributori in cambiamento. Non dimostra che ogni commento di revisione aggiuntivo rappresenti output dannoso prodotto da macchine.

Le evidenze disponibili supportano una conclusione più circoscritta. La capacità di generazione sta aumentando più rapidamente della capacità di molti progetti di convalidare i contributi, e i maintainer stanno rispondendo con barriere più rigorose.

Tre segnali mostreranno se la pressione si sta attenuando

Il prossimo test sarà capire se i progetti acquisiranno capacità di revisione, se le piattaforme miglioreranno i controlli sui contributi e se i principali utilizzatori finanzieranno le dipendenze su cui fanno affidamento.

Il primo segnale è un cambiamento misurabile nelle code dei repository. Ricercatori e responsabili dei progetti dovrebbero monitorare tempi di revisione, motivi di chiusura, tassi di merge e contributi ripetuti.

Un intervento sano dovrebbe ridurre l’ingresso di contributi a basso valore senza eliminare i nuovi arrivati che hanno successo. Code più brevi da sole non bastano se i progetti le ottengono chiudendo la partecipazione esterna.

Le evidenze più solide combinerebbero volume e qualità. I progetti dovrebbero riferire se le modifiche accettate richiedono meno revisioni, causano meno regressioni e attirano contributori che rimangono coinvolti.

Il secondo segnale è il supporto a livello di piattaforma per la responsabilità. Gli host dei repository possono rendere più semplici la divulgazione e la verifica senza cercare di identificare la paternità dell’IA attraverso rilevamenti inaffidabili.

Campi strutturati per le proposte potrebbero richiedere ai contributori di descrivere i test, spiegare le scelte progettuali e confermare la loro capacità di mantenere la modifica.

I progetti hanno inoltre bisogno di strumenti per limitare tipi di contributo ad alto costo. Un maintainer dovrebbe poter richiedere una discussione preventiva per grandi refactoring o proposte inviate da agenti autonomi.

Se le piattaforme introdurranno questi controlli, la diagnosi del rapporto ACM sull’IA open source otterrà una risposta operativa. Se si concentreranno solo sull’aumento dell’output degli agenti, lo squilibrio crescerà.

Il terzo segnale è il finanziamento continuativo da parte delle organizzazioni che dipendono dall’open source. I finanziamenti una tantum aiutano, ma la manutenzione richiede supporto ricorrente e tempo retribuito per i revisori.

Le aziende dovrebbero identificare quali dipendenze incidono su produzione, sicurezza e conformità. Dovrebbero poi esaminare concentrazione dei maintainer, attività di release, qualità della documentazione e capacità di risposta.

Un SBOM può avviare questo processo identificando i componenti. Il passo più difficile è collegare l’inventario alle decisioni su titolarità, governance e investimenti.

I team di sicurezza dovrebbero inoltre distinguere tra disponibilità di una patch e distribuzione della patch. L’IA può individuare rapidamente una falla, ma i prodotti downstream possono restare esposti finché ogni dipendenza non si aggiorna.

Questo ritardo è in parte tecnico e in parte organizzativo. Un progetto con personale insufficiente può diventare l’anello più lento in molti sistemi commerciali.

Anche gli sviluppatori hanno responsabilità. Chiunque utilizzi uno strumento di coding basato sull’IA per il lavoro open source dovrebbe verificare l’output e comprendere il codice circostante.

Una proposta dovrebbe includere una chiara descrizione del problema, un ambito mirato, test pertinenti e una spiegazione che il contributore possa difendere senza consultare il modello.

Le organizzazioni possono ridurre i costi di revisione esterni assegnando ingegneri esperti a supporto delle loro modifiche upstream. Non dovrebbero trattare i maintainer della community come controllo qualità non retribuito.

I maintainer, nel frattempo, hanno bisogno dell’autorizzazione a progettare processi di contribuzione attorno alla loro reale capacità. L’apertura non richiede di accettare output illimitato e non verificato.

L’opportunità a più lungo termine non è eliminare l’IA dall’open source. È utilizzare l’automazione dove riduce il lavoro ripetitivo senza separare il codice dalla responsabilità umana.

La revisione assistita dall’IA potrebbe infine contribuire a questo equilibrio. Una ricerca che ha coinvolto 587 revisioni di patch ha rilevato che solo una minoranza dei commenti generati veniva accettata direttamente, sebbene ulteriori commenti fossero valutati utili come guida.

Quel risultato contrastante suggerisce che gli strumenti di revisione possono supportare il giudizio umano senza sostituirlo. I progetti avranno bisogno di prove tratte dai propri flussi di lavoro prima di fare affidamento su sistemi di questo tipo.

L'inversione centrale resterà finché tali sistemi non matureranno. La generazione di codice sta diventando abbondante, mentre il giudizio contestuale rimane scarso.

I lettori che sviluppano prodotti basati sull'open source dovrebbero porsi tre domande pratiche. Quali dipendenze smetterebbero di ricevere aggiornamenti sicuri se un manutentore se ne andasse? Chi finanzia il loro lavoro di revisione? Come risponderebbe il vostro team se gli invii automatizzati consumassero la capacità rimanente?

Il rapporto ACM sull'IA open source rende queste domande urgenti perché la pressione è già visibile. Nei prossimi mesi, osservate gli arretrati dei repository, i controlli delle piattaforme e i finanziamenti ricorrenti per la manutenzione.

Se tutti e tre miglioreranno, l'IA potrà diventare un apporto netto alla capacità dell'open source. Se il volume degli invii aumenterà senza di essi, una programmazione più veloce continuerà a produrre fiducia più lenta.