Quando un agente AI ha chiesto di contribuire a matplotlib, una delle librerie Python più usate al mondo, Scott Shambaugh ha rifiutato senza esitare. Non per ostilità verso l’intelligenza artificiale, ma perché matplotlib, come molti altri progetti open source, è ormai sommersa da contributi generati automaticamente. La politica è diventata semplice: tutto il codice scritto dall’AI deve essere revisionato da un essere umano prima di essere accettato. Il problema è che i volontari che gestiscono questi progetti non hanno il tempo per farlo.
Lo racconta MIT Technology Review in un’inchiesta che mette in luce un effetto collaterale poco discusso della diffusione degli strumenti di coding AI: il collasso della collaborazione nei progetti open source. Gli agenti AI, sempre più capaci di scrivere codice autonomamente, vengono usati da sviluppatori e aziende per inviare contributi in massa a librerie pubbliche. Il risultato è un’ondata di pull request che i maintainer, spesso volontari non retribuiti, non riescono a gestire.
Il fenomeno ha conseguenze concrete per chiunque usi software open source nel proprio lavoro, e in Italia sono molte le PMI che si appoggiano a librerie e strumenti gratuiti per le proprie applicazioni gestionali, i siti web o i sistemi di analisi dati. Se i maintainer di queste librerie si esauriscono o abbandonano i progetti, la qualità e la sicurezza del software che molte aziende danno per scontato inizia a degradarsi.
C’è anche una dimensione più sottile che l’articolo esplora: alcuni maintainer riferiscono di ricevere messaggi aggressivi o insistenti da parte di utenti che usano l’AI per automatizzare anche le comunicazioni di follow-up sui loro contributi rifiutati. Non si tratta ancora di un fenomeno sistematico, ma il confine tra automazione legittima e molestia digitale automatizzata sta diventando più labile.
Per uno studio di sviluppo software o un’azienda che mantiene componenti open source, questo significa dover ripensare le proprie politiche sui contributi esterni. Accettare tutto indiscriminatamente espone a rischi di qualità e sicurezza. Rifiutare tutto rallenta l’innovazione. La soluzione che molti progetti stanno adottando, richiedere una firma umana e una responsabilità esplicita su ogni contributo, è ragionevole ma richiede risorse che spesso non ci sono.
Il pezzo completo è disponibile su MIT Technology Review.
Perche conta. Se la vostra azienda usa librerie open source nei propri sistemi, lunedi mattina vale la pena fare un inventario di quelle critiche e verificare chi le mantiene e con quale frequenza vengono aggiornate. Un progetto abbandonato o in difficolta è un rischio di sicurezza reale. Chiedete al vostro team tecnico o al vostro fornitore software quali dipendenze open source usate e se esistono alternative commerciali supportate per le piu critiche.