Microsoft si è costruita la sua AI per rimpiazzare OpenAI. Ora il modello è una commodity. (Giugno 2026)

Il 2 giugno 2026, al Build, Microsoft ha rilasciato sette modelli MAI sviluppati in casa, addestrati apposta per dipendere meno da OpenAI e tagliare i costi per gli sviluppatori. Uno di questi, MAI-Code-1-Flash, è un modello di coding da 5 miliardi di parametri che secondo Microsoft risolve i task di coding più difficili con fino al 60% di token in meno, ed è già in distribuzione su GitHub Copilot e VS Code. Un altro, MAI-Thinking-1, è un modello di reasoning da 35B addestrato da zero senza distillazione dai modelli di OpenAI [1][2].

I titoli parlano di Microsoft contro OpenAI. La cosa che conta davvero per chi costruisce su questi modelli è più sottile, ed è questa: il modello sotto la tua applicazione è ormai una commodity intercambiabile, e la frequenza con cui lo cambi sta accelerando. L'asset durevole non è il modello. Sono i tuoi prompt.

Voglio renderlo concreto, perché suona come uno slogan ma è in realtà un'affermazione operativa, con conseguenze su come lavori questo mese.

Conta i rilasci di modelli da metà aprile

Se mantieni qualcosa sopra un LLM, le tue ultime sei settimane sono andate così: Claude Opus 4.8 (28 maggio), Google Gemini 3.5 Flash in GA (19 maggio) con Gemini 3.5 Pro atteso da un giorno all'altro, la famiglia GPT-5.5 di OpenAI con GPT-5.6 già annunciato per giugno, DeepSeek V4, e ora sette modelli MAI di Microsoft in un solo keynote. Non è una frontiera che si muove una volta all'anno. È una frontiera che si riprezza e si riordina ogni paio di settimane.

Quando i rilasci erano annuali, "quale modello" era una decisione strategica che prendevi una volta sola. Quando arrivano ogni due settimane, "quale modello" è una decisione di routing che prendi di continuo, per task, per fascia di prezzo, per benchmark. MAI-Code-1-Flash esiste proprio perché Microsoft possa instradare il traffico di Copilot su un modello più economico quando è abbastanza buono. Tu farai la stessa cosa con i tuoi carichi di lavoro, che lo pianifichi o no, perché l'economia lo impone.

Commodity è la parola giusta, e non è un insulto ai modelli. Significa che sono sempre più intercambiabili a livello di interfaccia, differenziati soprattutto su prezzo, velocità e qualche punto di benchmark, e sostituiti spesso. È un mercato sano. Ed è anche un problema per lo strato che ci sta sopra.

Cosa fa la commoditizzazione a un prompt

Ecco la parte che si sottovaluta. Un prompt non è portabile gratis. È messo a punto, in modo esplicito o implicito, sulla disposizione di un modello specifico, e quella messa a punto non si trasferisce in modo pulito quando cambi il backend.

Ho scritto lo stesso avvertimento tre volte negli ultimi due mesi, perché continua a succedere la stessa cosa a ogni rilascio:

• Opus 4.8 ha iniziato a segnalare l'incertezza e a rifiutare di approvare per riflesso, quindi i prompt scritti per estrarre una sola risposta sicura si sono comportati all'improvviso diversamente.
• Gemini 3.5 Flash ha spostato in silenzio il suo livello di reasoning di default, quindi i prompt che non lo impostavano esplicitamente giravano più deboli della settimana prima.
• GPT-5.5 ha calibrato diversamente verbosità e aderenza alle istruzioni, quindi lo scaffolding passo-passo che aiutava il vecchio default ha cominciato a fare danni.

Ora moltiplica tutto questo per un mondo in cui potresti far girare MAI-Code-1-Flash per il coding di massa a basso costo, Opus per il reasoning difficile e Gemini per il long-context, tutti nello stesso prodotto. Ognuno di quei backend vuole il suo prompt modellato in modo leggermente diverso. Un prompt eccellente su uno è soltanto adeguato su un altro e ogni tanto rotto su un terzo. Cambiare il modello costa poco. Ri-validare ogni prompt sul nuovo modello è il costo vero, ed è il costo che nessuno mette a budget.

In concreto: un prompt di estrazione JSON solidissimo su un modello può iniziare ad avvolgere l'output in una frase di prosa su un modello che calibra diversamente la verbosità, e il tuo parser si rompe in produzione prima che qualcuno si accorga che il modello è perfino cambiato. Il cambio era una modifica di config da una riga. Il danno è stato un incidente a valle. Questa asimmetria, banale da cambiare e costosa da verificare, è tutto il problema in una riga.

Così la domanda smette di essere "qual è il modello migliore" e diventa "come sposto i miei prompt tra i modelli senza degradarli in silenzio". È una domanda di prompt-management, non di modello.

Il moat è lo strato dei prompt, e va costruito di proposito

Se il modello è la commodity, il tuo asset difendibile è lo strato sopra: i prompt, le versioni, la conoscenza di quale prompt funziona con quale modello e perché. Quell'asset esiste solo se lo costruisci di proposito. La maggior parte dei team non lo fa. Tiene i prompt in una dozzina di posti, li incolla tra gli strumenti, li ritocca per ogni modello e perde traccia di quale versione era tarata per cosa. Quando esce il modello successivo, riscopre da zero gli stessi fix.

Ecco la disciplina model-agnostic che applico ora, ed è la differenza tra un cambio di modello che dura un pomeriggio e uno che diventa una caccia alle regressioni:

1. Tieni i prompt indipendenti dal modello per default. Scrivi l'intento e i vincoli, non lo scaffolding specifico del modello. Gli espedienti come "ragiona passo passo" e "rispondi sempre in JSON, senza preamboli" sono compensazioni per le stranezze di un modello specifico; tienili in uno strato chiaramente segnato che puoi togliere o sostituire, non incastonati nel prompt centrale.

2. Versiona ogni prompt annotando il modello di destinazione. Quando metti a punto un prompt per Opus 4.8 o MAI-Code-1-Flash, registralo. La versione non vale niente sei settimane dopo se non sai per quale modello era stata modellata.

3. Dai un punteggio e fai regression-test a ogni cambio. Prima di instradare un carico su un modello più economico perché è "abbastanza buono", misuralo sui tuoi input rappresentativi, non su un benchmark. Abbastanza buono su SWE-bench non è abbastanza buono sulla tua codebase.

4. Tieni un'unica fonte di verità, non una dozzina di fork incollati. Nel momento in cui lo stesso prompt vive in tre repo e due strumenti di chat, hai perso la capacità di aggiornarlo una volta e fidarti ovunque. È anche una superficie di sicurezza, come sa chi ha letto il pezzo sulla prompt injection agentica.

5. Tratta il modello come un backend che sostituirai. Progetta in modo che mettere MAI-Code-1-Flash al posto di un modello più caro sia un cambio di config più un giro di test, non una riscrittura. Se cambiare il modello significa riscrivere i prompt ovunque, i tuoi prompt erano troppo accoppiati fin dall'inizio.

Niente di tutto questo è esotico. È la stessa disciplina che i team software hanno imparato sulle dipendenze dieci anni fa: blocca ciò da cui dipendi, astrai le parti sostituibili, testa prima di aggiornare. Il modello è ora una dipendenza che rilascia una nuova major version ogni due settimane.

Perché proprio questo rilascio lo dimostra

Microsoft è il vendor AI più integrato che esista, e perfino Microsoft ha deciso di non voler restare legata a un singolo fornitore di modelli. Si è costruita i suoi per avere optionality e abbassare il conto [1]. È questo il segnale. Se l'azienda con la partnership OpenAI più profonda del settore si sta ingegnerizzando la libertà di cambiare modello, la libertà di cambiare modello è la posizione strategica, non la fedeltà a un modello qualsiasi.

Non hai il budget di Microsoft, ma puoi avere la stessa postura alla tua scala, e il costo è soprattutto disciplina. Tieni i prompt portabili, versionati e testati, e ogni nuovo modello, MAI, GPT-5.6, Gemini 3.5 Pro, diventa un'occasione per tagliare i costi o guadagnare qualità invece che un'emergenza. Salta quella disciplina e ogni rilascio è una tassa.

È il problema attorno a cui è costruito Keep My Prompts. Ogni prompt è versionato con una nota sul modello di destinazione, il Prompt Score lo valuta su sei criteri così da confrontare lo stesso prompt tra i modelli prima di cambiare, e tieni un'unica copia autorevole invece di fork sparsi tra gli strumenti. Quando arriva MAI-Code-1-Flash o GPT-5.6 e vuoi sapere se instradarci sopra, testi i tuoi prompt reali e vedi muoversi il punteggio, invece di tirare a indovinare. Gratis per iniziare, senza carta di credito.

Si lega al discorso più ampio di scegliere il modello come decisione continua invece che come scommessa una tantum: il mondo multi-model è qui, e premia i team che trattano la propria libreria di prompt come lo strato stabile.

Il segnale

Sette modelli in un keynote non è la notizia. La notizia è che "sette modelli in un keynote" è ormai una settimana normale, e continuerà a esserlo. Lo strato dei modelli si sta consolidando in una commodity che si riprezza di continuo, e il valore sta migrando più in alto nello stack, verso chi possiede un insieme di prompt pulito, portabile e testato.

Scegli il modello per il task di oggi sul prezzo e sul benchmark di oggi. Ma costruisci come se lo sostituissi il mese prossimo, perché lo farai. Versiona i prompt, annota il modello di destinazione, testa prima di cambiare e tieni un'unica fonte di verità. Il modello è in affitto. La libreria di prompt è di proprietà. Regolati di conseguenza.

Keep My Prompts ti aiuta a versionare i prompt per modello, a valutarli su 6 criteri di qualità e a spostarli tra i modelli senza regressioni silenziose. Gratis per iniziare, senza carta di credito.

Riferimenti

[1] Microsoft unveils new AI models to lessen reliance on OpenAI and lower costs for developers, CNBC, 2 giugno 2026. https://www.cnbc.com/2026/06/02/microsoft-unveils-new-ai-models-lessen-reliance-on-openai-lower-costs.html

[2] Biggest Microsoft Build 2026 announcements: MAI models (MAI-Code-1-Flash 5B, MAI-Thinking-1 35B), Tom's Guide, 2 giugno 2026. https://www.tomsguide.com/news/live/microsoft-build-2026