Tecnologia Codice AI rompe i backup: scoppia la lite in rsync
2' 51''
11/06/2026

Scoperti commit AI nel codice di rsync: la comunità open source si divide sull'uso dell'intelligenza artificiale in un tool critico usato da milioni di sistemi.

Codice AI rompe i backup: scoppia la lite in rsync

La scoperta di commit attribuiti a un assistente di intelligenza artificiale nel repository di rsync, uno degli strumenti di sincronizzazione file più diffusi nell'ecosistema Unix/Linux, ha scatenato un acceso dibattito nella comunità open source nelle ultime settimane. Al centro della polemica c'è Andrew Tridgell, creatore del software, accusato di aver integrato codice generato dall'AI in un'infrastruttura critica su cui si appoggiano milioni di sistemi di backup aziendali e NAS in tutto il mondo.

La questione non riguarda un progetto marginale. Rsync, nato negli anni Novanta, è componente fondamentale di innumerevoli pipeline di backup aziendale, appliance NAS e script di amministrazione di sistema. La posta in gioco è la fiducia in un software che, per sua natura, esiste proprio perché gli utenti non si fidano che i dati sopravvivano senza ridondanza. Qualsiasi regressione in questo contesto ha un costo operativo immediato e misurabile.

Il caso è emerso quando alcuni utenti hanno segnalato malfunzionamenti nei backup incrementali dopo l'aggiornamento alla versione 3.4.3, rilasciata per correggere multiple vulnerabilità di sicurezza. Scavando nella cronologia dei commit del progetto a partire dalla versione 3.4.1, gli utenti hanno trovato decine di contributi attribuiti a "tridge and claude", riferimento esplicito a Tridgell e all'assistente AI di Anthropic, Claude. La scoperta ha generato una risposta su GitHub dal titolo emblematico "Please Do Not Vibe Fuck Up This Software", diffondendosi poi su Reddit e Hacker News.

"I did not just vibe-code 'convert test suite to python'. I'm a software engineer with 40 years experience."

Tridgell ha risposto alle critiche con un post su Medium intitolato "Rsync and Outrage", ammettendo le regressioni introdotte con la 3.4.3 e definendole "casi d'uso validi ma insoliti" non coperti dalla suite di test esistente. Ha però contestato l'interpretazione che il progetto fosse stato affidato integralmente all'AI: secondo la sua ricostruzione, Claude è stato utilizzato insieme a OpenAI Codex e Google Gemini per il cosiddetto "grunt work", ossia la conversione della suite di test da shell script a Python, un'attività tecnica ma ripetitiva. Il framework architetturale, sostiene, è stato progettato da lui e il codice risultante è stato revisionato manualmente.

Sul piano tecnico, la migrazione dei test in Python era funzionale a rafforzare la sicurezza del progetto, obiettivo dichiarato delle ultime release. Tridgell ha anche sollevato un tema più ampio: la crescente pressione sui maintainer di software open source, costretti a gestire un volume sempre maggiore di segnalazioni di sicurezza, molte delle quali generate a loro volta da strumenti AI. Un effetto sistemico che aumenta i costi di manutenzione senza un corrispondente incremento delle risorse disponibili.

"The world of IT security and maintaining software in the face of the flood of reports has completely and utterly changed just in the last few weeks."

Tridgell ha anche risposto alle minacce di migrazione verso openrsync, il progetto alternativo di OpenBSD, rilevando che la nuova suite di test di rsync evidenzia decine di fallimenti quando eseguita contro tale implementazione. Un dato che, pur provenendo da una fonte chiaramente di parte, introduce elementi di valutazione tecnica nel dibattito.

Tridgell ha dichiarato di voler continuare a usare gli strumenti AI mentre rsync si avvicina a una release 3.5 focalizzata sui miglioramenti di sicurezza.

Il caso rsync apre interrogativi strutturali sul governo dell'open source nell'era dell'AI generativa. Chi garantisce la qualità del codice quando i maintainer, spesso volontari o con risorse limitate, ricorrono all'AI per sostenere carichi di lavoro crescenti? E soprattutto: esistono standard trasparenti di disclosure per l'uso di AI nel software critico, o la questione viene lasciata alla discrezione dei singoli sviluppatori?

Condividi questo contenuto