Microsoft: scrivere codice software è il passato, Debian avverte sul vero rischio

“Scrivere codice a mano è ormai roba del passato“. È una frase volutamente provocatoria, ma pronunciata da qualcuno che il software lo costruisce davvero: David Fowler, Distinguished Engineer di Microsoft e figura centrale nello sviluppo di Aspire. Fowler non sta annunciando la scomparsa dei programmatori; descrive piuttosto uno spostamento del lavoro umano verso ciò che viene prima e dopo la produzione delle singole righe di codice.

Quasi contemporaneamente, dall’altro estremo della corsa all’intelligenza artificiale, il CEO di NVIDIA, Jensen Huang, è tornato a parlare dell’arrivo dell’AGI, l’intelligenza artificiale generale, collegando le capacità dei nuovi modelli alla disponibilità di infrastrutture computazionali sempre più imponenti.

E poi c’è Debian. Il progetto che sviluppa una delle distribuzioni Linux più importanti al mondo ha appena concluso una votazione interna sull’uso dei modelli generativi. La posizione scelta la dice lunga sul futuro dello sviluppo software: l’AI può essere utilizzata, nell’ambito dello sviluppo della distro, ma chi presenta una modifica resta pienamente responsabile di ciò che consegna. Ed è una posizione perfettamente sovrapponibile con quella di Linus Torvalds.

Microsoft: non è finita la programmazione, sta finendo una parte del lavoro

La frase di Fowler rischia di essere interpretata male se estratta dal contesto. Microsoft non sostiene che gli sviluppatori non servano più. Sta osservando qualcosa di molto più concreto: strumenti come GitHub Copilot non si limitano ormai a suggerire qualche riga mentre si scrive una funzione.

Gli agenti di coding possono preparare ambienti, modificare repository, eseguire build e test, utilizzare linter (strumento che analizza automaticamente il codice sorgente per individuare errori, problemi di stile, costrutti sospetti o violazioni delle regole definite dal progetto), correggere errori e infine aprire una pull request che un essere umano potrà esaminare. Il supporto si sta estendendo anche agli ambienti Windows e a WSL (Windows Subsystem for Linux), rendendo possibile delegare porzioni sempre più ampie del ciclo di sviluppo.

La prima generazione di assistenti AI lavorava principalmente dentro l’editor: completava una funzione, proponeva una regular expression, scriveva un test o spiegava un errore.

I nuovi agenti AI cominciano invece a lavorare molto più in profondità orchestrando simultaneamente vari strumenti: possono ricevere un’attività, esplorare il progetto, cambiare più file, eseguire comandi, leggere gli errori generati dall’applicazione e iterare autonomamente fino a ottenere un risultato apparentemente funzionante.

Scrivere un costrutto for(...) o chiedere a un modello AI di generare l’intero blocco di codice diventa quasi un dettaglio dell’interazione. L’attività interessante si sposta verso un livello superiore: definire cosa deve fare il sistema, stabilire i vincoli, decidere l’architettura e infine verificare che il risultato corrisponda davvero alle aspettative.

Il codice diventa economico, la verifica diventa costosa

Se un agente AI riesce a produrre in pochi minuti una modifica che avrebbe richiesto ore di lavoro manuale, la quantità di software che può essere generata cresce enormemente. Non cresce automaticamente, però, la capacità degli esseri umani di valutarlo. È un po’ la critica che avevamo sollevato nei confronti della recente presa di posizione di Bill Gates in tema di AI e mercato del lavoro.

Un modello generativo può produrre dieci possibili implementazioni di codice durante il tempo necessario a un senior developer per analizzarne attentamente una. Ancora, può creare creare centinaia di test, può proporre decine di patch, può aprire pull request in continuazione.

Qualcuno deve però stabilire se quelle modifiche siano corrette non soltanto dal punto di vista sintattico, ma rispetto al comportamento complessivo del sistema. Indubbiamente, quindi, la generazione del codice di programmazione diventa più economica ma, allo stesso tempo, cresce in parallelo il valore della revisione.

Debian ha scelto una regola semplice

Per settimane Debian è stata raccontata da diverse testate e da molti addetti ai lavori come uno dei progetti open source più intransigenti nei confronti dell’intelligenza artificiale generativa. All’interno della comunità era stata effettivamente presentata una proposta per vietare i contributi scritti con l’uso o l’assistenza di LLM (Large Language Models) e altri strumenti di AI generativa, arrivando persino a ipotizzare un’integrazione esplicita del divieto nel Social Contract del progetto.

La recente General Resolution ha però messo ai voti diverse alternative, da quelle nettamente contrarie ai LLM fino a formulazioni molto più permissive.

Alla fine ha prevalso la proposta Responsible Use of Generative AI, che abbandona l’idea di un divieto generalizzato e adotta un principio molto più interessante: l’AI può essere utilizzata, ma non diventa mai una giustificazione per abbassare gli standard del progetto o per scaricare sulla macchina la responsabilità del lavoro prodotto.

Qualità, correttezza, manutenibilità e conformità legale devono quindi rimanere le stesse indipendentemente dagli strumenti impiegati. Soprattutto, chi presenta un contributo deve essere in grado di comprenderlo, valutarlo e sostenerne le scelte tecniche. La domanda diventa qui: “sei in grado di garantire questo codice?”

Il programmatore passa da autore a garante?

Per decenni la produttività di uno sviluppatore è stata associata, almeno superficialmente, alla capacità di produrre codice.

È sempre stata una semplificazione: un bravo programmatore poteva risolvere un problema eliminando codice anziché aggiungerlo oppure evitare mesi di lavoro scegliendo l’architettura corretta all’inizio. D’altra parte, anche (e soprattutto!) ai tempi dell’AI generativa, Leslie Lamport ci ricorda che coding e programmazione sono cose molto diverse.

Se produrre migliaia di righe richiede pochi minuti, il numero di righe perde definitivamente qualsiasi valore come misura del lavoro.

Contano invece altre capacità: capire un sistema complesso; definire requisiti precisi; individuare casi limite; riconoscere assunzioni errate; valutare implicazioni di sicurezza; comprendere dipendenze e licenze; accorgersi di quando una soluzione apparentemente elegante potrebbe divenire ingestibile nel giro di breve tempo.

L’AI potrebbe quindi, di fatto, ridurre la quantità di codice prodotto ma paradossalmente rendere gli aspetti ingegneristici ancora più importanti e cruciali.

Più l’automazione funziona bene, più l’essere umano tende a fidarsene; quando serve realmente il suo intervento, potrebbe essere meno preparato a riconoscere le anomalie. Nel software il fenomeno è particolarmente delicato perché alcune conseguenze non emergono immediatamente. Un errore di gestione della memoria, una race condition, una validazione incompleta dell’input o una modifica apparentemente innocua al sistema delle autorizzazioni possono rimanere invisibili a lungo.

Il tema AGI e gli annunci commerciali contano meno

Il dibattito sull’arrivo o meno dell’AGI appare quasi distante da questi problemi quotidiani. Jensen Huang ha celebrato OpenAI GPT-6 Astra sostenendo che l’AGI sia ormai arrivata e ha contemporaneamente sottolineato l’enorme quantità di GPU NVIDIA usate per realizzare il modello. Anzi, proprio dopo l’acquisizione di Hugging Face, il numero uno di NVIDIA ha rimarcato la necessità, a suo dire, di estendere ulteriormente l’infrastruttura per ottenere progressi successivi.

La discussione sull’etichetta AGI rimane però problematica perché non esiste una definizione universalmente condivisa che permetta di stabilire con precisione il momento in cui la soglia viene superata.

Un programmatore, d’altra parte, non ha bisogno di sapere se lo strumento davanti a lui possieda una qualche forma filosoficamente soddisfacente di intelligenza generale.

Ha bisogno di sapere se il modello generativo:

• comprende correttamente il repository;
• modifica le parti giuste;
• esegue test significativi;
• non introduce vulnerabilità;
• rispetta le API;
• non rompe la compatibilità;
• produce modifiche che qualcun altro potrà comprendere tra due anni.

È significativo che persino gli strumenti di coding AI più avanzati non chiudano davvero il cerchio in completa autonomia. Possono modificare file, eseguire test, correggere errori e preparare una pull request, cioè una proposta strutturata di modifica al progetto che viene poi sottoposta all’esame di uno sviluppatore. L’agente AI può arrivare molto vicino alla fine del lavoro operativo, ma il passaggio decisivo rimane ancora umano.

Huang guida NVIDIA, l’azienda che più di ogni altra beneficia della corsa globale alla costruzione di infrastrutture per l’AI: difficile ignorare la componente commerciale di una dichiarazione del genere.

Il vero problema sarà formare i programmatori di domani

Gli sviluppatori senior oggi riescono a valutare il codice prodotto dall’AI perché hanno trascorso anni a scriverlo, leggerlo, romperlo, correggerlo e a confrontarsi con sistemi complessi. La loro capacità di riconoscere una soluzione fragile o un errore nascosto nasce dall’esperienza accumulata sul campo.

Ma cosa succede se i programmatori junior iniziano direttamente da agenti AI capaci di produrre intere funzionalità, correggere bug e preparare modifiche complete? Il rischio è che queste figure possano saltare proprio quella fase di apprendimento che permette di capire davvero cosa il codice sta facendo.

Proprio mentre cresce la necessità di persone capaci di verificare il lavoro delle macchine, potrebbe ridursi il numero di occasioni attraverso le quali si impara a farlo.

Per questo il futuro dello sviluppo software non dovrebbe essere costruito sulla contrapposizione tra programmatori e AI. La distinzione più utile sarà probabilmente un’altra: tra chi usa l’AI come strumento per amplificare competenze che possiede e chi la utilizza per sostituire conoscenze che non ha acquisito.

Nel primo caso l’agente AI può trasformare uno sviluppatore competente in uno sviluppatore enormemente più produttivo. Nel secondo può produrre l’illusione di una competenza che emerge soltanto finché tutto procede come previsto.

La posizione scelta da Debian sembra quasi anticipare il problema meglio delle dichiarazioni sull’arrivo dell’AGI: non importa tanto chi abbia materialmente prodotto il codice, quanto chi sia in grado di comprenderlo, difenderlo e assumersene la responsabilità.