La riga era già nel commit history, e tu non l’avevi messa. L’attribuzione AI nei commit di VS Code era opt-out, non opt-in: dall’aggiornamento 1.117 di aprile, l’estensione Git aggiungeva automaticamente “Co-authored-by: Copilot” a ogni commit. Secondo il report di Thomas Claburn su The Register, compariva anche quando Copilot era disabilitato, anche dopo che il messaggio era stato riscritto a mano. Microsoft ha poi cambiato rotta, ma solo sotto la pressione di 372 pollici giù su un’issue pubblica e praticamente nessun pollice su.

La vicenda si è chiusa in pochi giorni. Ma il fatto che sia potuta cominciare così dice qualcosa di preciso su dove si trova, oggi, il confine tra il lavoro di uno sviluppatore e il prodotto del vendor che produce il suo editor.

L’attribuzione AI nei commit: cosa è cambiato e perché non si vedeva

Il cambiamento tecnico era contenuto in una singola PR: il parametro git.addAICoAuthor era passato dal default "off" a "all". Nessun opt-in esplicito. Nessun banner durante l’aggiornamento. Nessuna voce nel changelog formulata in modo da spiegare l’effetto pratico: ogni commit di ogni progetto aperto in VS Code avrebbe ricevuto un trailer di attribuzione a Copilot, indipendentemente da qualsiasi utilizzo reale dell’assistente AI.

Il caso più documentato era anche il più problematico. Uno sviluppatore aveva revisionato il messaggio di commit, lo aveva modificato manualmente eliminando il testo generato da Copilot, poi aveva eseguito il commit. Il trailer era comparso lo stesso nel log finale: “This means the message I reviewed before committing was not the final content that ended up in Git history.”

Non è una questione di formato. In un sistema di version control, il commit che lo sviluppatore ha esplicitamente approvato e quello che ha raggiunto il repository erano oggetti diversi. Per quel commit, tutta la catena di revisione era compromessa. Il GitHub issue #314311, aperto per tracciare la situazione, ha raccolto centinaia di segnalazioni simili prima che Microsoft revertisse il default.

Git log non è un credits reel

git blame e git log non tracciano meriti: tracciano responsabilità tecniche. “Chi ha scritto questa riga?”, “quando è stata introdotta questa logica?”, “qual era il contesto di quella modifica?”. Nei team con code review strutturata, sono parte del processo di audit interno quotidiano.

In settori con compliance obbligatoria, il peso è ancora più concreto. Per chi sviluppa sistemi finanziari o in ambito sanitario, la storia dei commit può avere valenza legale durante audit esterni o in fase di post-incident review. Aggiungere a quella storia un’entità non-persona, che non può firmare contratti, non può essere citata in giudizio, e non risponde di nulla, non è un’operazione neutra. Altera la semantica di quella traccia.

Il problema del copyright sul codice generato dall’AI è già aperto da tempo. Chi conosce la questione delle licenze GPL e del codice prodotto da assistenti come Copilot sa che la giurisprudenza non è definita. Aggiungere un’attribuzione automatica in git non chiarisce niente: aggiunge un attore in più in un quadro già ambiguo, senza che quell’attore abbia alcuna capacità di rispondere legalmente di quello che ha “co-firmato”.

Il default come dichiarazione di intenzione

Microsoft ha inquadrato la funzionalità come “AI provenance”: trasparenza su dove ha contribuito l’intelligenza artificiale nel processo di sviluppo. L’obiettivo dichiarato ha una logica. Il metodo no.

Opt-out significa che chi aggiorna VS Code senza leggere le note di rilascio, cioè la maggioranza degli utenti durante un aggiornamento automatico, partecipa al meccanismo senza averlo scelto. Questo non è un dettaglio implementativo: è la struttura del consenso. Si normalizza un comportamento che, presentato in forma esplicita, troverebbe resistenza. La forza del default sta nel fatto che la maggioranza non lo cambia, e chi costruisce prodotti software lo sa.

Microsoft produce sia l’IDE sia Copilot. L’attribuzione automatica su ogni commit posiziona Copilot come collaboratore integrato nel flusso di sviluppo. Ogni progetto con quella riga nel log è, implicitamente, una dimostrazione del prodotto. Non è necessario attribuire intenzioni malevole per riconoscere che il meccanismo serve un interesse commerciale preciso.

Il rollback è arrivato in pochi giorni. Non è la prova che il sistema funziona: è la prova che la reazione è stata abbastanza rumorosa da rendere il costo politico superiore al beneficio. La logica che ha prodotto il default originale non è cambiata.

Il take di TechMonk

Un IDE è uno strumento che esegue le intenzioni di chi sviluppa. Non dovrebbe mai aggiungere le proprie dichiarazioni all’output di quel lavoro. Un commit è una dichiarazione: “questo codice è quello che ho letto, modificato e approvato.” Alterarla senza consenso esplicito è attraversare un confine che in qualsiasi altro strumento professionale non sarebbe accettabile.

Il problema dell’audit trail non è filosofia: è pratica. In qualsiasi team che usa git log per ricostruire le decisioni prese sul codice, un commit il cui contenuto dipende da un parametro di configurazione dell’editor, che può cambiare tra una versione e la successiva senza notifica, non è più un documento affidabile. Non per un bug del codice: per un comportamento deliberato dello strumento.

L’aspetto più rilevante di tutta la vicenda non è il commit authorship in sé. È che questo cambiamento è stato notato perché era visibile: una riga in più in ogni messaggio di commit appare nel primo git log successivo. I cambiamenti di default meno visibili, quelli che riguardano telemetria, comportamenti di rete, o integrazione con servizi esterni, producono lo stesso problema strutturale con molte meno probabilità di scatenare centinaia di segnalazioni in ventiquattro ore.

Il modello dell’IDE-come-piattaforma, dove l’editor diventa il punto di controllo di un’intera suite di servizi connessi, spinge in questa direzione. Più funzionalità sono integrate nell’editor, più i suoi default diventano decisioni rilevanti per il flusso di lavoro, la compliance e la tracciabilità di chi lo usa. Ogni nuova funzionalità aggiunta come opt-out è un’altra area in cui stai, consapevolmente o meno, delegando una scelta a qualcun altro.

Microsoft ha corretto il tiro sull’attribuzione. La struttura che ha reso possibile quel cambiamento, però, quella per cui una singola PR può modificare silenziosamente cosa finisce nel tuo git history, è ancora lì. E si applica a qualsiasi default futuro.

Conclusione

Le vittorie per pressione pubblica funzionano così: cambiano i tempi, non le intenzioni. Il prossimo default problematico arriverà con un framing migliore, in un momento con meno attenzione, in un’area dove le conseguenze sono meno immediate di una riga in più nel messaggio di commit. Scegliere i propri strumenti sapendo che i loro default appartengono a qualcun altro è il punto di partenza per usarli con qualche grado di controllo reale.