Una volta era facile capire quando un testo era generato automaticamente: la sua struttura aveva un non so che di artefatto. Ora a quanto pare gli LLM sono arrivati a fregarci sempre meglio. MomScience riporta il risultato di due studi, nemmeno troppo recenti (si parla del 2023) dove il tasso di errore nel definire se un testo era umano o artificiale era intorno al 50%: essenzialmente come tirare a indovinare. Peggio ancora, nel caso di editor di riviste tecniche il tasso di riconoscimento corretto è stato molto inferiore al 50%: in pratica un reverse benchmark.

Come mai? Innanzitutto, le IA ormai non fanno più errori grammaticali e refusi, a differenza di chi scrive spesso di fretta e non rilegge il suo testo (quorum ego). In pratica, al momento è meglio fidarsi di un testo più ruspante. Credo però che ci sia anche un altro punto: il fare una verifica superficiale, senza entrare nel merito del significato del testo. Un altro studio, stavolta del 2026, elenca gli indizi cercati dai professori quando controllano gli elaborati ricevuti. I primi quattro sono la presenza di allucinazioni nei fatti presentati; allucinazioni nelle fonti citate; mancanza (appunto!) di errori grammaticali e ripetizioni del testo. Peccato che se il compito è quello di riassumere un testo è molto improbabile che le IA facciano di questi “errori”, o più correttamente lascino tracce visibili!

Quello a cui forse dovremo rassegnarci è che non è più importante sapere chi (o cosa…) ha scritto un testo, ma dobbiamo concentrarci sul suo contenuto. Ho come il sospetto che per molta gente ciò sarà ancora più difficile :-)

Nella sua newsletter, Simon Willison racconta di un caso interessante he riguarda le reimplementazioni di codice. L’esempio tipico, raccontato anche nel suo post, è stato quando Compaq ha preso un gruppo di sviluppatori per disassemblare il BIOS dei PC IBM e scrivere un documento di specifiche relative; il documento è stato dato a un altro gruppo di sviluppatori che hanno creato un BIOS compatibile ma senza problemi di copyright, perché a essere copiate sono state le funzionalità e non il codice. Questa metodologia si chiama in gergo “clean room”, come le camere pulite dove si costruiscono (costruivano? io me le ricordo a fine anni ’80…) i chip, perché non c’è nessuna contaminazione. Il problema è che un metodo del genere è molto costoso, in termini di risorse e soprattutto di tempo. Ma ora ci sono le IA che scrivono codice: non si può far fare il lavoro a loro?

È proprio quello che è stato fatto con la libreria Python chardet, che cerca di determinare qual è il codifica dei caratteri usata in un documento. Il programma è stato creato nel 2006 da Mark Pilgrim e rilasciato sotto la licenza LGPL, e portato avanti da vari sviluppatori, soprattutto da Dan Blanchard che ha praticamente preso le redini del progetto dal 2012 e la versione 1.1. Ora Blanchard ha rilasciato una nuova versione, la 7.0.0 (al momento siamo alla 7.0.2) definita come “riscrittura da zero” con l’aiuto di Claude Code e rilasciata con la MIT license, il che significa che può essere usata anche senza far automaticamente far diventare open source tutto il progetto che la usa. Pilgrim però ha obiettato, dicendo che non era possibile cambiare licenza al software, e da qui è partita una diatriba. Blanchard ha spiegato che è partito dalla generazione di un insieme di specifiche usando superpowers, per poi partire ex novo con un progetto e istruire Claude Code a non usare codice GPL oppure LGPL. Il risultato, usando il tool JPlag che verifica la somiglianza del codice con un altro dato, è che la similarità massima è dell’1,29%.

Willison elenca poi una serie di punti che rendono il caso complicato: Blanchard sicuramente conosce fin troppo bene il codice originale, avendoci lavorato su per tre lustri; Claude Code ha sicuramente referenziato parti del codice originale, come il file che elenca le proprietà delle varie codifiche, ma d’altra parte Pilgrim aveva scritto il codice partendo da un’implementazione in C con la licenza Mozilla; Claude è stato quasi sicuramente addestrato anche con il materiale di chardet, e la sua “memoria” è sicuramente molto più affidabile di quella degli sviluppatori che compilano in una clean room. Ma naturalmente il vero problema non è tanto chardet, che rimarrebbbe con una licenza libera. Il software libero nasce proprio in contrapposizione a quello proprietario: cosa succede se il pendolo si sposta dall’altra parte e le aziende sfruttano il software libero per averne dell’altro bloccato?