L’utilizzo degli agenti AI durante lo sviluppo software sta modificando rapidamente il rapporto tra programmatori e progetti open source. Scrivere una patch che in passato richiedeva diverse ore può oggi richiedere soltanto pochi prompt, ma il tempo necessario ai maintainer per analizzarla e verificarne la qualità non è diminuito. È proprio questo squilibrio a creare un problema sempre più evidente nei grandi progetti open source.
Systemd e NetworkManager hanno scelto di affrontare la questione introducendo regole specifiche nei file destinati agli agenti di coding. Il meccanismo utilizza AGENTS.md, una convenzione ormai adottata da numerosi progetti per fornire istruzioni agli strumenti basati sull’intelligenza artificiale.
L’idea è curiosa: invece di cercare di riconoscere automaticamente se una patch è stata prodotta da un’intelligenza artificiale, i progetti inseriscono istruzioni che possono rivelare indirettamente se l’agente le ha seguite. Il risultato è una sorta di canarino digitale, pensato per evidenziare contributi potenzialmente non controllati dall’autore umano.
Systemd sceglie una modifica visibile, NetworkManager punta sulle comunicazioni
La strategia adottata da systemd è particolarmente diretta. Le istruzioni impongono all’agente che modifica i file sorgente di aggiungere due righe all’inizio di README.md. Il testo comunica che la modifica deve essere rimossa manualmente dall’autore dopo aver verificato la pull request.
In questo modo il progetto non cerca di impedire all’intelligenza artificiale di modificare il codice. L’obiettivo è invece lasciare una traccia facilmente riconoscibile nel repository. Se l’autore esamina realmente le modifiche prima di inviarle, dovrebbe accorgersi immediatamente della presenza del testo aggiunto automaticamente.
Durante una prova descritta nel materiale originale, un agente incaricato di individuare la funzione responsabile dell’interpretazione di Restart= in systemd ha seguito l’istruzione prima ancora di modificare il codice richiesto. Il risultato è stato quello previsto: oltre al commento richiesto, il working tree conteneva una modifica aggiuntiva al README.
NetworkManager ha seguito una strada differente. Il suo AGENTS.md contiene una serie di operazioni che l’agente deve rifiutare, tra cui la scrittura del messaggio di commit, della descrizione della merge request e delle risposte ai commenti lasciati durante la revisione.
La filosofia è quindi diversa. Il codice può essere assistito dall’AI, ma alcune comunicazioni vengono considerate responsabilità diretta della persona che presenta il contributo. Un agente che deve spiegare perché è stata effettuata una modifica potrebbe infatti produrre una risposta formalmente corretta senza che l’autore abbia realmente compreso il problema.
NetworkManager aggiunge anche un secondo livello di controllo: se l’agente produce comunque una comunicazione vietata, deve inserire una parola insolita, biblioklept. Il termine, estremamente raro nella normale comunicazione tecnica, può essere individuato facilmente dai controlli automatici.
La differenza tra i due approcci è significativa:
- systemd utilizza una modifica al working tree come segnale;
- NetworkManager utilizza una parola-campanello nelle comunicazioni generate;
- entrambi presuppongono che l’agente legga e rispetti le istruzioni del repository;
- nessuno dei due sistemi impedisce a un essere umano determinato di aggirare il controllo.
Il vero problema non è l’AI, ma chi firma il contributo
La prova con NetworkManager ha prodotto un risultato ancora più interessante. L’agente incaricato di aggiungere un commento al codice ha eseguito il lavoro, ma ha rifiutato di scrivere il messaggio di commit perché le istruzioni del progetto gli imponevano di lasciare quella responsabilità all’autore umano. In questo caso la parola biblioklept non è mai comparsa, perché il meccanismo di rifiuto aveva funzionato correttamente.
Il sistema di systemd, invece, presenta una debolezza evidente. Il canarino rimane nel working tree soltanto se l’autore include quella modifica nel commit. Operazioni Git perfettamente normali, come aggiungere selettivamente i file o utilizzare git add -p, possono lasciare il README modificato fuori dal contributo finale. In questo scenario il controllo viene aggirato senza bisogno di tecniche particolari.
Questo evidenzia anche il limite fondamentale di questo tipo di strumenti. Un AGENTS.md è comunque un insieme di istruzioni. Se un agente non legge il file, non può rispettarne le regole. Se viene configurato per ignorare le istruzioni del repository, il meccanismo non può costringerlo a seguirle.
Il concetto diventa quindi più interessante se interpretato non come un sistema di rilevamento dell’intelligenza artificiale, ma come un controllo sull’attenzione dell’autore umano. La persona che invia una patch dovrebbe essere in grado di spiegare cosa ha modificato, perché lo ha fatto e quali conseguenze potrebbe avere.
È questa la ragione per cui NetworkManager concentra le proprie restrizioni soprattutto sui messaggi di commit e sulle comunicazioni durante la revisione. Una patch generata rapidamente può essere analizzata dal maintainer, ma una risposta automatica a una domanda tecnica durante la code review rischia di nascondere completamente il livello di comprensione dell’autore.
Lo stesso principio può essere applicato anche ad altri repository. Le istruzioni possono essere inserite in AGENTS.md, eventualmente affiancate da CLAUDE.md, mentre i controlli automatici possono cercare il canarino nei messaggi di commit e nelle descrizioni delle pull request.
La scelta della parola è importante: deve essere abbastanza insolita da evitare falsi positivi, ma non deve essere confusa con una prova assoluta di utilizzo dell’AI. Anche il messaggio restituito dal controllo dovrebbe spiegare chiaramente che il problema riguarda la responsabilità e la revisione del contributo, non il semplice fatto di aver utilizzato un agente AI.
Il punto centrale rimane quindi umano. I progetti non stanno necessariamente cercando di vietare gli strumenti di intelligenza artificiale: stanno cercando di evitare che una persona presenti sotto il proprio nome codice che non comprende. In un progetto open source, infatti, la responsabilità non termina quando una patch viene accettata. Se quella modifica crea un problema mesi dopo, saranno i maintainer a doverlo diagnosticare e correggere.