Microsoft frena l'AI nel codice dei suoi ingegneri: il paradosso, e cosa dice alle PMI

In breve. Circola un articolo su Medium (Level Up Coding, firmato Noah Byteforge) secondo cui Microsoft avrebbe invitato i propri ingegneri a usare meno gli strumenti AI per scrivere codice. La fonte è una sola e il tono è da titolo a effetto, quindi va presa per quello che è: un claim non confermato. Ma sotto al titolo c'è una domanda seria, e quella vale per tutti. Se anche chi vende gli strumenti inizia a mettere dei paletti su come si usano, forse il problema non è l'AI. È il modo in cui la stiamo infilando nei processi.

Cosa dice la notizia (e perché va maneggiata con cura)

Il pezzo racconta che internamente Microsoft avrebbe chiesto ai team di sviluppo di ridurre la dipendenza da Copilot e simili, per tre motivi: qualità del codice generato, rischi di sicurezza, e il fatto che gli ingegneri più giovani non imparano davvero a programmare.

Primo punto di onestà: non c'è una comunicazione ufficiale di Microsoft a sostegno. È un articolo singolo, su una piattaforma dove chiunque pubblica, con un titolo costruito per il clic. Quindi non lo prendo come un fatto. Lo prendo come un sintomo.

Perché il paradosso che evoca, quello sì, è reale. Microsoft ha investito miliardi in OpenAI, ha costruito GitHub Copilot, ha messo l'AI dentro ogni suo prodotto. Se anche solo una parte dei suoi team sta rallentando, la cosa interessante non è il gossip aziendale. È il segnale.

Il problema vero numero uno: la qualità

Un assistente che genera codice è bravissimo a produrre qualcosa che funziona alla prima prova. Il guaio arriva dopo. Codice che gira ma che nessuno ha capito fino in fondo, scritto in fretta, con dipendenze infilate senza pensarci. Funziona oggi, diventa un problema fra otto mesi quando qualcuno deve metterci mano.

Chi sviluppa software da un po' conosce la differenza tra "compila" e "tiene". L'AI è eccezionale per il primo, indifferente al secondo. Se la velocità di scrittura aumenta ma nessuno alza il livello della revisione, il debito tecnico non sparisce. Si accumula più in fretta, semplicemente.

Il problema numero due: la sicurezza

Il codice generato eredita i pattern su cui il modello è stato addestrato, inclusi quelli sbagliati. Librerie obsolete, gestione approssimativa dei dati sensibili, controlli che mancano. Sono cose che un occhio esperto intercetta in revisione, ma solo se la revisione c'è ancora.

Qui il rischio è subdolo. Più il codice "sembra" giusto, meno viene guardato. E un errore di sicurezza che passa la revisione perché aveva un bell'aspetto è peggio di un errore evidente.

Il problema numero tre, il più scomodo: il deskilling

Questo è il punto che mi interessa di più, perché non riguarda solo gli sviluppatori.

Un ingegnere junior che impara a programmare con l'assistente sempre acceso rischia di non costruire mai i muscoli di base. Sa chiedere, non sa fare. Sa correggere quando il modello sbaglia in modo evidente, non quando sbaglia in modo sottile. E il giorno che lo strumento non basta, gli manca il fondo per accorgersene.

Non è un discorso nostalgico sul "ai miei tempi si scriveva tutto a mano". È una questione di sistema. Stai formando persone che dipendono da uno strumento prima di aver capito il problema che lo strumento risolve. Quando l'amplificatore arriva prima della competenza, amplifica il vuoto.

Cosa c'entra tutto questo con una PMI italiana

Quasi nessuna PMI italiana scrive software come Microsoft. Ma quasi tutte stanno mettendo l'AI dentro qualcosa: il commerciale che genera le offerte, l'ufficio acquisti che fa riassumere i contratti, il marketing che produce contenuti a raffica. La dinamica è identica, cambia solo il mestiere.

La domanda da farsi non è "quanta AI usiamo". È un'altra. Le persone che usano l'AI nei nostri processi, sanno ancora fare il lavoro senza? Sanno accorgersi quando il risultato è plausibile ma sbagliato?

Perché il valore di una persona, in un mondo pieno di strumenti che producono output decente in automatico, si sposta proprio lì. Non nel produrre. Nel giudicare. E il giudizio non te lo regala nessun modello.

La lettura giusta, secondo me

Se la storia di Microsoft fosse vera, non sarebbe un passo indietro sull'AI. Sarebbe un passo avanti sul metodo. Significherebbe che hanno smesso di chiedersi "come usiamo più AI" e hanno iniziato a chiedersi "dove l'AI ci serve davvero, e dove invece ci sta indebolendo".

Standardizzare prima di automatizzare. Capire il processo prima di metterci dentro lo strumento. Tenere viva la competenza umana proprio dove l'AI sembra renderla superflua. Non sono regole contro l'intelligenza artificiale. Sono le condizioni perché funzioni senza farti male.

L'AI è un moltiplicatore. Moltiplica quello che già c'è, nel bene e nel male. Su una competenza solida, la fa volare. Su un vuoto, lo rende solo più grande, e più difficile da vedere.

Domande frequenti

Microsoft ha vietato davvero l'AI ai suoi ingegneri? Non risulta una comunicazione ufficiale. La notizia arriva da un singolo articolo su Medium, da trattare come claim non verificato. Il dibattito di fondo, però, è reale e documentato in molti team di sviluppo.

Allora l'AI per scrivere codice è da evitare? No. Il problema non è lo strumento, è l'uso senza criterio. AI più revisione seria e competenza solida è un vantaggio enorme. AI al posto della competenza è un debito.

Cosa può fare concretamente una PMI? Mappare dove l'AI è già entrata nei processi, verificare che le persone sappiano ancora valutare gli output, e tenere la competenza umana sui punti critici. L'automazione viene dopo la standardizzazione, non prima.

Vuoi capire dove l'AI conviene davvero nei tuoi processi, e dove invece ti sta indebolendo senza che te ne accorga? È il tipo di diagnosi che facciamo in Unicorn Consulting.