Codice scritto con l'AI: la lezione di Linux per chi sviluppa

Introduzione

Uso assistenti AI ogni giorno: per generare migrazioni Laravel, scrivere test, rifattorizzare componenti React. E ogni tanto un cliente mi chiede, un po' preoccupato: "Ma il codice lo scrivi tu o l'AI?". Questa settimana la stessa domanda se la sono posta gli sviluppatori del kernel Linux, discutendo se eliminare l'obbligo di dichiarare i contributi assistiti dall'AI. La risposta di Linus Torvalds è stata netta: nessun divieto sugli strumenti, conta che chi firma il codice lo capisca davvero. È un principio che condivido, e in questo articolo ti racconto come lo applico nei progetti che consegno.

Partiamo da cosa è successo, perché il progetto open source più importante al mondo è un ottimo banco di prova per capire dove sta andando il nostro mestiere.

Cosa sta succedendo nel kernel Linux

All'inizio del 2026 il kernel Linux ha introdotto un tag, Assisted-by, da aggiungere ai contributi realizzati con l'aiuto di un assistente AI. L'idea era semplice: dare ai maintainer, le persone che revisionano e accettano le modifiche, un modo per sapere quali patch erano state scritte con un modello linguistico.

A ottobre Sasha Levin, uno degli sviluppatori del kernel, ha proposto di eliminare quell'obbligo dalla documentazione per i contributori e dallo script checkpatch.pl, che controlla automaticamente le patch. Le regole esistenti sui contenuti generati resterebbero, così come la piena responsabilità di chi invia il codice, inclusa la firma del Developer Certificate of Origin.

La proposta ha raccolto il sostegno di Greg Kroah-Hartman, che in passato aveva difeso il tag. Non tutti sono d'accordo: Laurent Pinchart sostiene che servano comunque aspettative chiare sull'uso dell'AI, anche se qualcuno non le rispetterà. Al momento la modifica non è ancora stata accettata.

Il dato che fa riflettere: 1 commit su 10

Il motivo della proposta è pratico: il tag non funziona. Su 18.533 commit (esclusi i merge) di Linux 7.3 fino alla release candidate 7, solo circa il 10% riporta Assisted-by. Eppure tutti sanno che l'uso reale dell'AI è molto più diffuso.

Le ragioni sono due: molti contributori non conoscono la regola, altri scelgono di non applicarla. Il risultato è un'etichetta che dà un'impressione falsa: chi la legge pensa di sapere quanto codice è assistito dall'AI, ma in realtà vede solo chi ha deciso di dichiararlo.

Qui c'è una lezione che vale anche fuori dal kernel. Una regola che nessuno può verificare finisce per premiare chi non la rispetta e penalizzare chi è trasparente. Vale per un progetto open source con migliaia di sviluppatori, e vale per il rapporto tra un'azienda e il suo fornitore di software.

La posizione di Torvalds: lo strumento non conta, la responsabilità sì

Torvalds è intervenuto con il suo stile diretto. In sintesi (traduzione mia): non capisce questa idea "idiota" del "non usare l'AI per X", e il kernel non farà "regole stupide" che vietano di usare strumenti per qualcosa. Con un po' di sarcasmo ha aggiunto che, se il punto è dimostrare di aver capito il codice, allora bisognerebbe vietare anche i compilatori e scrivere tutto in assembly.

Il concetto di fondo è questo: chi invia una modifica deve fare del suo meglio e capire quello che consegna, qualunque strumento abbia usato. L'AI è un attrezzo come l'IDE, il linter o lo Stack Overflow di qualche anno fa.

Sono d'accordo, con una precisazione. "Capire quello che consegni" è facile da dire e meno facile da dimostrare. Nel kernel lo garantiscono anni di review severissime. In un progetto per una PMI, spesso l'unico revisore è lo sviluppatore stesso. Per questo mi sono dato delle regole precise.

Come lo gestisco nei progetti per i clienti

Non ho un tag da aggiungere ai commit, ma ho un metodo. Eccolo, così com'è.

Nessuna riga entra senza review

Il codice proposto dall'AI lo tratto come quello di un collaboratore junior molto veloce: utile, ma da rileggere riga per riga. Se non riesco a spiegare cosa fa un blocco, non entra nel progetto. Vale soprattutto per le parti delicate: pagamenti, autenticazione, calcolo di prezzi e IVA, sincronizzazione degli ordini con il gestionale.

Test automatici prima della fiducia

L'AI è bravissima a scrivere codice plausibile, cioè codice che sembra giusto. Per questo su Laravel ogni funzionalità importante ha i suoi test (feature test con Pest o PHPUnit), e su React i componenti critici hanno test sul comportamento. Il test è la prova che ho capito cosa deve succedere, non solo che il codice gira.

Niente dati dei clienti nei prompt

Credenziali, chiavi API, dati personali di clienti finali ed export di database non finiscono mai in un assistente AI. Uso dati fittizi e configurazioni di esempio. È una questione di GDPR prima ancora che di buon senso.

Trasparenza nell'offerta e nel contratto

Nelle mie offerte scrivo in modo esplicito che uso strumenti di sviluppo assistiti dall'AI e che la responsabilità del codice consegnato resta interamente mia. Non serve un'etichetta su ogni file: serve che il cliente sappia come lavoro e chi risponde se qualcosa non va.

Il guadagno di tempo va dove serve

L'AI mi fa risparmiare ore sul codice ripetitivo: CRUD, validazioni, migrazioni, componenti di interfaccia. Quel tempo lo reinvesto in analisi dei processi, test e ottimizzazione delle prestazioni, cioè nelle parti che fanno davvero la differenza per un e-commerce o un gestionale.

Cosa chiedere al tuo sviluppatore

Se hai una PMI o un e-commerce e lavori con uno sviluppatore o un'agenzia, chiedere "usi l'AI?" serve a poco: la risposta, oggi, è quasi sempre sì. Le domande utili sono altre:

Chi rilegge il codice prima che vada online? Deve esserci almeno una revisione umana, soprattutto su pagamenti e dati dei clienti.
Ci sono test automatici sulle funzioni critiche? Checkout, calcolo spedizioni, sincronizzazione del magazzino: se si rompono, devi saperlo prima dei tuoi clienti.
Quali dati finiscono negli strumenti AI? La risposta giusta è: nessun dato personale dei tuoi clienti e nessuna credenziale.
Chi è responsabile se qualcosa non funziona? Deve essere scritto nel contratto, a prescindere dagli strumenti usati.
Mi sai spiegare questa parte del codice? Un buon professionista sa sempre spiegare cosa ha consegnato, anche se l'ha scritto con l'aiuto di un assistente.

Conclusione

Il dibattito nel kernel Linux sposta la domanda dallo strumento alla responsabilità. Non importa se una riga l'ha scritta una persona, un'AI o un generatore di codice: importa che chi la firma la capisca, la verifichi e ne risponda. Per chi sviluppa è un invito a usare l'AI con metodo. Per chi commissiona un progetto è un invito a fare le domande giuste.

Se vuoi capire come l'AI può velocizzare lo sviluppo del tuo e-commerce o del tuo gestionale senza sacrificare qualità e sicurezza, scrivimi: ne parliamo partendo dai tuoi processi reali.