Chiunque può programmare… ma solo i ricchi possono essere grandi!

Ricordate la scena finale di Ratatouille? Anton Ego, il critico gastronomico più temuto di Parigi, siede davanti a un piatto preparato da Remy e ha un’epifania. Per anni aveva deriso il motto dello chef Auguste Gusteau: “Chiunque può cucinare”. Lo considerava un insulto alla nobiltà dell’arte. Eppure, davanti a quel piatto preparato da un topo, capisce il vero significato di quelle parole: “non tutti possono diventare dei grandi artisti, ma un grande artista può celarsi in chiunque!”.

Mentre leggevo articoli che celebravano l’ennesimo modello “rivoluzionario”, pensavo esattamente a questo. Prendendo spunto dalla frase di Gusteau, sembra che nel software il mantra del momento sia diventato “Chiunque può programmare”, grazie all’IA generativa e al Vibe Coding. E come con Gusteau, contiene una verità reale. L’Intelligenza Artificiale (IA) ha abbassato le barriere. I prototipi si costruiscono in ore. Il codice si genera, si testa, si riscrive.

La promessa non è falsa.

È incompleta.

La favola di avere uno sviluppatore a 20 dollari al mese sta finendo. E il risveglio è costoso.

Parafrasando Gusteau: “Chiunque può programmare”. Ma, visto l’andamento dei costi degli strumenti IA nel 2026, “solo i ricchi possono essere grandi”.

La narrativa “l’IA sostituisce il lavoro” sta cambiando tono

#

Il 2026 verrà ricordato come l’anno in cui la narrativa della “Sostituzione Silenziosa” ha cambiato tono. Non più solo promesse di team più piccoli, sviluppatori “10x” e agenti autonomi capaci di fare il lavoro di interi reparti, ma ristrutturazioni reali raccontate con una parola ricorrente: efficienza da IA.

Una parte di questa promessa è reale. L’automazione sta comprimendo alcune attività knowledge-based, e molte aziende stanno riorganizzando organici e processi con l’IA al centro.

Ma dire “l’IA ruba il lavoro” è una scorciatoia. La realtà è più scomoda e più interessante: l’IA diventa una leva per ridisegnare ruoli, aspettative, budget e responsabilità. A volte sostituisce attività. A volte aumenta la pressione sulle persone rimaste. A volte diventa il linguaggio con cui il management racconta una riduzione dei costi che aveva anche altre cause.

Gli esempi raccontano sfumature diverse dello stesso movimento. Nel caso Cisco, l’IA sembra soprattutto una riallocazione di capitale: quasi 4.000 tagli, meno del 5% della forza lavoro, mentre l’azienda sposta investimenti verso infrastruttura IA e aree di crescita correlate¹.

Altri casi usano un linguaggio più diretto. Cloudflare ha collegato circa 1.100 tagli all’uso interno dell’IA, cresciuto di oltre il 600% in tre mesi, pur in un trimestre da record.² PayPal parla di modernizzazione della piattaforma e adozione aggressiva dell’IA nello sviluppo, dentro una riorganizzazione più ampia con risparmi attesi importanti.³ DeepL, infine, è forse l’esempio più esplicito: circa 250 tagli, un quarto della forza lavoro, e una “massive structural shift” su quale lavoro esiste, chi lo fa e quante persone servono.⁴

Il pattern è chiaro: non stiamo guardando una semplice sostituzione uomo-macchina.

Fonti: Reuters, TechCrunch, Heise/tech.eu — marzo/maggio 2026

Il vero problema: non l’IA, ma il conto

#

La parte più sottovalutata della storia è economica.

Negli ultimi tempi abbiamo venduto l’IA come se fosse software tradizionale: un prezzo mensile, una licenza, qualche limite di utilizzo. Ma i modelli generativi non sono un SaaS classico. Ogni richiesta consuma calcolo. Ogni output ha un costo. Ogni finestra di contesto più grande trascina con sé più token. Ogni agente che legge file, chiama strumenti, fa retry e aspetta test consuma risorse anche quando noi lo percepiamo come “sta lavorando da solo”.

GitHub lo ha detto annunciando il passaggio di Copilot a un modello usage-based dal 1 giugno 2026. I prezzi base non cambiano, ma le premium request unit vengono sostituite da GitHub AI Credits consumati in base a input, output e token cached. La motivazione ufficiale è chiara: Copilot è diventato una piattaforma agentica capace di sessioni lunghe e multi-step, con richieste di compute e inference molto più elevate.⁵

Questa è una svolta culturale. Finché il prezzo era percepito come flat, una chat veloce e una sessione agentica di due ore sembravano appartenere allo stesso abbonamento. Nel momento in cui il billing segue token, modelli e consumo reale, la differenza diventa visibile.

Anthropic rende il fenomeno ancora più concreto nella documentazione ufficiale di Claude. I prezzi API sono espressi per milione di token, con differenze importanti tra modelli, input, output e cache. Claude Opus 4.7, rilasciato il 16 aprile 2026, è listato a 5 dollari per milione di token input e 25 dollari per milione di token output; Claude Sonnet 4.6 a 3 e 15 dollari; Haiku 4.5 a 1 e 5 dollari.⁶ Fin qui nulla di sorprendente.

La parte interessante arriva nei dettagli: Opus 4.7 introduce un nuovo tokenizer (che può usare fino al 35% di token in più), endpoint regionali e data residency a costi maggiorati, fast mode (6x), tool, web search e managed agents possono modificare sensibilmente il costo reale di una sessione.⁶ Il prezzo pubblicato per milione di token è solo l’inizio del conto.

Fonti: Anthropic API Pricing, GitHub Blog — aprile/maggio 2026

Presi singolarmente, questi numeri sembrano piccoli. Moltiplicati per sviluppatori, workflow CI/CD, documentazione interna, customer support, agenti di security, analisi log e retry automatici, diventano una voce di budget seria.

Il Financial Times ha titolato che la spesa IA da 725 miliardi di dollari delle Big Tech sta portando il free cash flow ai minimi da un decennio.⁷ Anche senza entrare nei dettagli dell’articolo, il messaggio è evidente: l’IA “economica” per l’utente finale si regge su un’infrastruttura molto costosa per chi la eroga.

Ed è qui che la metafora del libro di cucina torna utile. All’inizio il ricettario ti fa credere di poter cucinare; poi scopri che servono ingredienti, attrezzature sempre più costose, energia e tempo. Ma per un piatto davvero stellato serve lo chef: chi sa distinguere un codice che “funziona” da uno davvero solido, sicuro e pronto per essere servito.

Vibe coding: utile, veloce, ma non magico

#

Uso strumenti di IA generativa, incluso il coding, ogni giorno. E sì, funzionano.

Nel dettaglio, il vibe coding funziona molto bene per prototipi, boilerplate, refactoring controllati, documentazione, script temporanei, parsing di log, UI iniziali e traduzione di concetti in codice verificabile. Se devo preparare una demo CIAM, una proof of concept o un laboratorio, oggi parto molto più veloce di qualche anno fa. Un esempio concreto è il progetto Opaflix: non è nato in poche ore, ma grazie al vibe coding sono riuscito a realizzarlo in pochi giorni o settimane, invece che in mesi, pur non essendo uno sviluppatore full-time.

Ma “più veloce” non significa “senza supervisione”.

In pratica, spesso non sto delegando all’IA. Sto facendo da product manager, architect, security reviewer e QA allo stesso tempo. Devo spiegare il contesto, limitare lo scope, impedire riscritture inutili, verificare che non inventi API e fermarla quando decide di “migliorare” parti che nessuno le aveva chiesto di toccare.

L’IA perde contesto, somiglia a uno stagista molto veloce ma senza memoria stabile: ogni volta deve rileggere codice, README, AGENTS.md o CLAUDE.md. E ogni ricarica di contesto consuma token.

Un potenziale disastro di sicurezza

#

La parte più pericolosa è che spesso il codice generato sembra plausibile. Non è rotto in modo evidente. Compila. La demo gira. La UI risponde. E proprio per questo può passare sotto il radar.

Mi è successo in modo molto concreto. Stavo realizzando una demo di un sito web per un progetto CIAM di un cliente. Mi serviva un esempio di integrazione di reset password in modalità full code, senza usare il widget preconfezionato di Okta. Ho chiesto all’IA di generarmi un esempio, e mi ha restituito codice funzionante.

Funzionante, sì, ma completamente vulnerabile.

Bastava passare uno username via query string per cambiare la password di qualunque utente, senza alcuna verifica. Il backend prendeva quello username e usava l’SDK e l’API di Okta per impostare la nuova password. Nessun token di recupero, nessuna verifica out-of-band, nessun controllo sull’identità del richiedente, nessuna protezione seria contro abuso o enumerazione.

Era il tipo di codice che in una demo superficiale può sembrare perfetto. In produzione sarebbe stato un disastro.

Questo è il punto che chi lavora in IAM e CIAM vede subito: l’autenticazione non è solo “una form che funziona”. Il reset password è uno dei flussi più sensibili di un sistema di identità. Va progettato con proof of possession, rate limiting, audit, policy, token temporanei e separazione netta tra richiesta e azione. L’IA può aiutare a scrivere codice, ma non può sostituire il giudizio di sicurezza se non le dai vincoli, contesto e review.

Per questo non mi preoccupa l’idea che piattaforme come Okta possano essere rimpiazzate da qualche prompt di IA generativa. Generare codice è una cosa; progettare, testare, proteggere e mantenere in produzione un servizio di gestione delle identità è un’altra. Sicurezza, affidabilità, auditabilità e responsabilità operativa non si improvvisano con un prompt ben formattato.

Il costo dell’usare davvero l’IA

#

Nel mio caso ho visto anche l’altro lato economico. Tra febbraio/marzo e aprile/maggio, i costi personali e professionali legati all’IA sono aumentati di circa 25-30 volte. Non perché stessi facendo cose assurde, e nemmeno perché avessi cambiato radicalmente modo di lavorare: sono cambiati il modo in cui vengono conteggiati i token, il prezzo dei token e il peso economico delle sessioni agentiche. E ovviamente non sono l’unico ad avere avuto questa esperienza, in molti hanno riscontrato aumenti vertiginosi dei costi ⁸.

Questo è il problema della gestione dei costi IA: il consumo cresce non quando “giochi” con l’IA, ma quando inizi a usarla davvero. Ed è qui che la battuta diventa meno battuta: con queste dinamiche, il vibe coding rischia davvero di diventare sostenibile solo per chi può permetterselo.

Il lavoro umano non è solo output

#

La sostituzione completa dei team umani viene spesso raccontata come un problema di produttività: se un agente produce lo stesso output di cinque persone, allora posso ridurre il team. Ma nelle organizzazioni reali il lavoro non è solo output.

Il lavoro è memoria storica. È sapere perché un sistema è stato costruito in un certo modo. È ricordare quel cliente che ha una configurazione diversa perché anni fa c’era una migrazione incompleta. È sapere che una policy apparentemente ridondante esiste per un audit passato. È conoscere i “trucchi del mestiere” che nessuno ha scritto perché sembravano ovvi a chi era lì.

Questa conoscenza implicita è difficilissima da trasferire a un modello. Non perché l’IA sia stupida, ma perché spesso non esiste in forma documentata. È distribuita tra persone, chat, ticket, call ed eccezioni temporanee diventate permanenti.

E c’è un altro punto umano, spesso ignorato: non è scontato che le persone vogliano addestrare serenamente il sistema che domani potrebbe ridurre il loro ruolo. La collaborazione con l’IA richiede fiducia. Se l’IA viene introdotta solo come leva di taglio costi, quella fiducia si rompe.

Molte aziende sottovalutano anche il costo della supervisione. Alcune analisi sul vibe coding parlano ormai di Quality Tax: ore senior spese a mantenere test, verificare codice generato e correggere output che sembravano pronti.⁹ Un agente che produce dieci pull request al giorno non elimina necessariamente lavoro: può spostarlo su review, sicurezza, architettura e governance.

L’IA è un moltiplicatore: se moltiplichi per zero, ottieni zero; se moltiplichi per un team esperto, ottieni risultati. Ma questo potere ha un prezzo, e le aziende che controllano questi strumenti detengono anche le chiavi dei costi.

Il ricettario può aiutarti a iniziare.

Ma qualcuno deve ancora assaggiare il piatto prima di servirlo.

Gli errori recenti non sono fantascienza

#

Quando parliamo di rischi IA, non serve immaginare scenari apocalittici. Bastano gli incidenti operativi e di sicurezza già visibili.

GitHub, nel report di disponibilità di aprile 2026, ha documentato incidenti che hanno impattato anche Copilot. Il 9 aprile, Copilot coding agent ha avuto ritardi nell’avvio di nuove sessioni: circa l’84% delle nuove richieste era ritardato, con picchi di attesa di 54 minuti rispetto a una baseline di 15-40 secondi, e circa 22.700 workflow creation ritardati o falliti. La causa era un bug nel rate limiting, aggravato da traffico API aumentato 3-4x dopo un aggiornamento client.¹⁰

Il 22 aprile, Copilot Chat su github.com e Copilot Cloud Agent sono stati indisponibili per un problema di configurazione infrastrutturale che ha causato problemi di connettività con i database.¹⁰ Ancora una volta: non è la fine del mondo. Ma se un’azienda decide di basare il proprio delivery su agenti IA, questi incidenti diventano parte del rischio operativo.

Dal punto di vista della sicurezza, gli esempi concreti iniziano ad accumularsi. A marzo 2026, Meta ha dovuto gestire agenti interni che avrebbero esposto dati sensibili a dipendenti non autorizzati.¹¹

OWASP, con il GenAI Security Project, include esplicitamente LLM, sistemi agentici e applicazioni guidate dall’IA nel perimetro delle pratiche di secure development e governance.¹² Non è un dettaglio: quando gli agenti possono chiamare tool, leggere dati, scrivere codice, aprire ticket, modificare configurazioni o eseguire workflow, non sono più “chatbot”. Sono attori operativi.

Soluzioni come Okta for AI Agents possono aiutare alcuni di questi rischi, sopratutto quelli legati a identità, accesso, policy, privilege e audit. Ma la responsabilità di progettare, testare, monitorare e governare questi sistemi resta in capo alle aziende che li adottano.

Come ha appreso PocketOS, i rischi non sono solo di sicurezza ma anche operativi. A maggio 2026 un coding agent basato su Claude avrebbe cancellato database di produzione e backup in pochi secondi, ammettendo poi la colpa e scusandosi subito dopo.¹³

Chi controlla i fornelli?

#

La conclusione, per me, non è anti-IA.

L’IA non è un bluff. I progressi sono reali, l’aumento di produttività è reale, e ignorarla sarebbe irresponsabile. Ma sarebbe altrettanto irresponsabile accettare senza spirito critico l’idea che sostituire team umani con agenti sia sempre conveniente, sicuro o efficiente.

Oggi la sostituzione completa spesso sposta i costi invece di eliminarli: token, inference, piattaforme, governance, review, incident response e supervisione. Non aumenta automaticamente la qualità, perché la qualità richiede contesto, test, sicurezza e conoscenza del dominio. E introduce nuovi rischi, perché ogni agente che agisce per conto nostro ha identità, privilegi e responsabilità.

Per chi, come me, si occupa di IAM, la direzione è chiara: gli agenti IA sono identità. Devono essere governati come identità — ho approfondito il blueprint per l’agentic enterprise sicura e i pattern di accesso per agenti IA con Okta. Serve sapere chi li ha creati, quale umano li sponsorizza, quali dati possono leggere, quali azioni possono eseguire, quando vanno disattivati e come vengono auditati.

Least privilege, policy, logging, lifecycle, approvazioni, segregation of duties e compliance non diventano meno importanti con l’IA. Diventano più importanti. Anche l’EU AI Act va in questa direzione: approccio basato sul rischio, logging, trasparenza, supervisione umana, cybersecurity e obblighi specifici per sistemi ad alto rischio e modelli general-purpose.¹⁴

La parte di sicurezza possiamo affrontarla con governance, identità, policy, audit e strumenti adeguati. L’incognita più difficile resta quella dei costi crescenti: token, compute, modelli premium e pricing sempre più legati al consumo reale.

Questo è forse il punto più importante. Le aziende che controllano modelli, pricing, infrastruttura e accesso al compute avranno un potere enorme sul modo in cui lavoriamo. Non solo perché venderanno strumenti, ma perché diventeranno parte della catena di produzione del software, del supporto, della compliance e della conoscenza aziendale. Di conseguenza, ogni aumento di costo che imporranno potrà avere effetti molto concreti sui bilanci delle aziende.

Forse la frase “chiunque può programmare, ma solo i ricchi possono essere grandi” è troppo cinica, ma coglie un punto reale.

L’IA può abbassare la barriera d’ingresso. Può aiutare più persone a creare. Può rendere più accessibile la sperimentazione. Tornando a Ratatouille: “non tutti possono diventare grandi artisti, ma un grande artista può celarsi in chiunque”.

Ma diventare davvero bravi richiederà ancora competenza, giudizio, contesto, responsabilità e soprattutto risorse economiche per sostenere token, strumenti e supervisione..

Qual è la tua esperienza con costi IA, produttività IA e sviluppo con agenti IA? Stai vedendo più produttività reale o più complessità da governare? Scrivimi nei commenti o su LinkedIn.