Go down

Un progetto open source vieta ogni utilizzo dell’AI, persino per correggere un testo o cercare bug. Ma vietare uno strumento significa davvero garantire qualità e responsabilità?

Una regola che vieta anche di parlarne

Dal 28 ottobre 2026 il codice di condotta di MicroZig, progetto open source dello Zig Embedded Group, contiene una sezione intitolata "Strict No LLM / No AI Policy". Non chiede di dichiarare l'uso dell'AI: lo vieta, in ogni forma.

L'elenco è preciso. Niente codice o prosa generati da un LLM. Niente parafrasi di quei contenuti. Niente LLM per correggere ortografia e grammatica. Niente LLM per tradurre, con una precisazione: "English is encouraged, but not required". Niente brainstorming con un LLM, nemmeno se poi il testo lo scrivi tu. Niente LLM per trovare bug. E infine: "No talking about use of chatbot/LLM services".

C'è poi un secondo divieto, da tenere distinto dal primo. Tra i comportamenti inaccettabili il codice elenca anche "Discussing this Code of Conduct or publicly accusing someone of violating it", e precisa che questa discussione non deve avvenire su GitHub o su Discord. Il primo divieto riguarda gli strumenti: non si parla dell'uso di chatbot. Il secondo riguarda le regole stesse: negli spazi del progetto non si discute il codice di condotta, e le segnalazioni vanno ai maintainer.

Secondo AI Weekly la regola vale per l'organizzazione GitHub e per il server Discord del gruppo, e la applicano i maintainer Matthew Knight e Felix Queißner: "We will swiftly remove anyone who is antagonizing others or being generally destructive".

Quello che il testo non dice è il perché. Non c'è una motivazione, solo un rimando a "Profession", un racconto di Isaac Asimov. Dichiara però da dove viene: è "largely taken from Zig's Code of Conduct", il codice di condotta del linguaggio su cui MicroZig è costruito. Per capire la regola bisogna partire da lì.

Il problema vero: chi rivede, e chi risponde

Zig, il linguaggio, ha messo al bando i contributi scritti con l'AI già da mesi: il 30 aprile 2026 Simon Willison ne discuteva le motivazioni. Andrew Kelley, presidente della Zig Software Foundation, ha poi spiegato la scelta in un podcast di JetBrains, ripreso da Business Insider e Slashdot: i contributi generati con l'AI hanno "negative value, because they take review time away from the team". Li ha definiti "invariably garbage". All'epoca Zig aveva circa 200 pull request aperte e più pull request che revisori.

Il secondo argomento, più interessante del primo, lo ha formulato Loris Cro, vicepresidente per la comunità della Zig Software Foundation, con l'espressione "contributor poker": "In contributor poker, you bet on the contributor, not on the contents of their first PR". Zig aiuta i nuovi arrivati a far entrare anche lavori imperfetti, perché l'obiettivo è far crescere persone di cui fidarsi nel tempo. Kelley lo dice così: "We're all trying to get better at programming". Una patch generata e inviata senza comprenderla non fa crescere il contributore: anche quando è buona, rivederla rende poco.

Una conseguenza concreta riguarda Bun, il runtime JavaScript scritto in Zig e acquisito da Anthropic, l'azienda che sviluppa Claude, a dicembre 2025. Bun mantiene un proprio fork di Zig, in cui ha ottenuto una compilazione circa quattro volte più veloce, e ha detto di non voler proporre quelle modifiche al progetto principale perché "Zig has a strict ban on LLM-authored contributions". Il divieto non è però l'unico ostacolo: secondo Willison, un contributore di Zig ha sollevato anche questioni di design, perché l'analisi semantica in parallelo tocca "the Zig language itself".

Qui Zig ha ragione. Scrivere una patch plausibile oggi costa quasi zero; rivederla costa quanto prima. Quando il costo di produzione crolla e quello di verifica resta uguale, chi verifica viene sommerso. Il collo di bottiglia non è mai stato scrivere codice, è sempre stato fidarsi del codice.

MicroZig, quindi, non ha inventato la regola. La sezione sugli LLM del codice di condotta di Zig contiene gli stessi divieti, compresi quello di usare gli LLM per trovare bug e quello di parlare di chatbot, e lo stesso divieto di discutere il codice di condotta. La novità del 28 ottobre è che quel testo si estende a un altro progetto. Le critiche che seguono valgono per entrambi.

Tre punti deboli

Il problema è reale. Lo strumento scelto, però, ha almeno tre difetti.

Non si può verificare. Una patch scritta male si vede. Una correzione grammaticale fatta da un LLM no, e nemmeno un'idea nata da una conversazione con un chatbot. Una regola che non si può controllare finisce per colpire chi la ammette, non chi la viola. In pratica premia chi tace.

Vietare di parlarne è l'opposto della trasparenza. I divieti totali sono ancora un'eccezione: secondo la rassegna pubblicata da Phil Eaton su The Consensus il 2 marzo 2026, su 112 progetti source-available solo quattro vietavano del tutto i contributi con l'AI (Zig, NetBSD, GIMP e QEMU), mentre in 71 c'erano commit che dichiaravano esplicitamente l'uso di un assistente AI. L'alternativa più ovvia al divieto è la dichiarazione: dimmi cosa hai usato, così so come rivedere il tuo lavoro. Questo codice va nella direzione opposta: tratta l'uso di un LLM come una violazione di condotta, non come qualcosa da dichiarare. Il risultato prevedibile è che l'uso continui, ma in silenzio, e che i revisori ne sappiano meno di prima. E poiché negli spazi del progetto non si può nemmeno discutere il codice di condotta, la regola non si può contestare là dove si applica.

Il divieto di traduzione sposta il costo, non lo elimina. La regola non obbliga a scrivere in inglese: "English is encouraged, but not required". Il testo di Zig, da cui deriva, è ancora più esplicito: si può scrivere nella propria lingua e lasciare agli altri "their own translation tools of choice". È una soluzione più inclusiva di quanto sembri. Ma la traduzione non sparisce: passa da chi scrive a chi legge, e il testo non chiarisce se chi legge possa usare un LLM per tradurre. In una discussione tecnica tra persone di lingue diverse, ogni lettore si traduce il testo per conto suo, con strumenti diversi, aumentando il rischio di interpretazioni differenti.

Il nodo sicurezza: escludere o mettere alla prova?

C'è una voce dell'elenco che merita un discorso a parte: "No LLMs for finding bugs".

Il 27 ottobre, il giorno prima che la regola entrasse in vigore, Causal Security ha pubblicato la ricerca del suo agente AI Cipher su EPICS Base, il software open source che controlla acceleratori di particelle, telescopi ed esperimenti sulla fusione, ed è alla base dell'architettura di controllo di ITER. In 3 ore e 49 minuti Cipher ha trovato quattro vulnerabilità di sicurezza della memoria. La più grave, CVE-2026-114595, ha un punteggio CVSS di 9.8: è un overflow che porta a una scrittura fuori dai limiti della memoria. L'esecuzione di codice da remoto è una conseguenza possibile, ma, precisa Causal Security, "Cipher did not demonstrate it". L'agente ha lavorato da solo su un codice che non conosceva; l'unico intervento umano è stata un'istruzione che autorizzava test più approfonditi in un ambiente isolato. Le correzioni sono nella versione 7.0.11. Il caso è stato raccontato anche da The Register.

MicroZig serve a programmare sistemi embedded, cioè proprio il tipo di software in cui un bug di memoria può avere conseguenze fisiche. Qui però serve una distinzione. Il divieto vale per la comunità del progetto, la sua organizzazione GitHub e il suo server Discord: riguarda il modo in cui lavorano i contributori. Il testo non parla di audit esterni né di segnalazioni di vulnerabilità che arrivano da fuori, e non è detto che le impedisca. Sostenere che il divieto avvantaggi gli attaccanti è quindi un'ipotesi ragionevole, non una conseguenza dimostrata.

La domanda da fare è un'altra: perché escludere a priori uno strumento potenzialmente utile alla ricerca di vulnerabilità, anziché stabilire criteri rigorosi per accettarne i risultati? Molte segnalazioni generate dall'AI sono false o inutili, e filtrarle costa: è lo stesso problema di revisione visto prima. Ma lo si può affrontare chiedendo prove, cioè un test che fallisce o un caso riproducibile, verificato da una persona che se ne assume la responsabilità. Un criterio così vale per qualunque segnalazione, comunque sia stata trovata.

Una regola di responsabilità, non di strumento

Se dovessi scrivere io la regola per un progetto come questo, partirei dal problema che Kelley descrive bene, il costo della revisione, e non dallo strumento. Cinque punti:

  1. Chi contribuisce risponde di ogni riga. Deve saperla spiegare e difendere in revisione. Se non sa farlo, il contributo viene respinto, comunque sia stato scritto.
  2. Dichiarare, non nascondere. Una riga nella pull request: ho usato questo strumento per questa parte. Serve al revisore per sapere dove guardare.
  3. Prove obbligatorie. Ogni modifica arriva con i suoi test; ogni segnalazione di bug con un test che fallisce o un caso riproducibile.
  4. Limiti di volume, per tutti. Un numero massimo di pull request aperte alla volta, più stretto per chi non ha ancora una storia nel progetto ma valido anche per i contributori storici: anche chi è nel progetto da anni può produrre grandi quantità di codice non verificato. È il filtro che la fatica di scrivere codice faceva da sola, e che l'AI ha tolto.
  5. L'onere della prova spetta a chi propone. Il maintainer può rifiutare un contributo senza doverne sostenere il costo della correzione. Chi propone una modifica ha l'onere di dimostrarne qualità, utilità e correttezza.

Nessuno di questi punti richiede di indovinare se un testo è stato scritto da una macchina. Tutti spostano il peso su chi contribuisce, che è dove deve stare.

Qualità o identità?

Una comunità open source ha tutto il diritto di darsi le regole che vuole. Chi tiene in piedi un progetto nel tempo libero non deve niente a nessuno, e capisco la stanchezza di chi passa le serate a scartare patch che chi le ha mandate non ha nemmeno letto.

Ma una regola si giudica da quello che produce. Una regola sulla responsabilità può favorire codice migliore e contributori che crescono. Una regola che vieta di correggere la grammatica con uno strumento, di tradurre, di parlare di chatbot e perfino di discutere le proprie regole produce soprattutto silenzio, e un confine netto tra chi è dentro e chi è fuori.

Il rimando ad Asimov è pertinente, forse più di quanto sembri. In "Profession" il protagonista, George Platen, non rifiuta semplicemente il sistema che trasferisce le competenze direttamente nella mente. Ne viene escluso: resta fuori dal normale percorso di istruzione professionale. E scopre poco a poco che la capacità di imparare da sé, sviluppare idee originali e produrre conoscenza nuova è una qualità rara e preziosa.

Questa lettura rafforza la conclusione invece di indebolirla. Nel racconto il valore umano non sta nel rifiutare uno strumento, ma nel conservare la capacità di comprendere, imparare e creare autonomamente. È questo che una regola sull'AI dovrebbe proteggere. E lo si protegge chiedendo a chi contribuisce di capire ciò che propone e di risponderne, non vietando gli strumenti.

La domanda da fare a ogni divieto sull'AI è semplice: protegge la qualità del software, o protegge un'identità? Nel caso di MicroZig, il rischio è che la difesa della qualità finisca per trasformarsi nella difesa di un'identità.

Nella preparazione di questo articolo mi sono avvalso del supporto di Claude (Anthropic), in particolare per la ricerca delle fonti e la revisione delle bozze. La selezione finale delle fonti, le valutazioni, le conclusioni e, più in generale, il risultato editoriale restano sotto la mia responsabilità.

Fonti

Pubblicato il 29 ottobre 2026

Gianluca Garofalo

Gianluca Garofalo / AI Responsabile & Governance | Automazione Strategica | Associate Manager @Accenture | Comitato Tecnico Scientifico @ENIA

https://ggarofalo-dev.github.io/
Pensieri e parole al tempo dell’IA
What we get wrong about politics today