Chiedete a un assistente AI di sommare i numeri di una colonna. Funziona. Poi scoprite che un foglio di calcolo lo avrebbe fatto in un istante, con una frazione minuscola di risorse.
Viene spontaneo pensare: ma che spreco! In parte è vero. Ma è una domanda che l'informatica si è già posta quasi settant'anni fa e la risposta di allora ci aiuta a capire cosa sta succedendo oggi. E cosa succederà senz’altro domani.
Quanto “costa” davvero chiedere qualcosa all'AI
Cominciamo da un termine. Un LLM (large language model) è il motore dietro ChatGPT e simili. Pensatelo come un lettore velocissimo che ha letto quasi tutto e che, parola dopo parola, indovina la risposta più sensata, senza davvero capire cosa sta dicendo.
Un programma classico, invece, è deterministico: come una calcolatrice, con lo stesso input dà sempre lo stesso risultato. L'AI no: la stessa domanda può produrre ogni volta risposte leggermente diverse.
Sui consumi dell’AI rispetto al codice deterministico i numeri sono ancora molto incerti. Google dichiara che una richiesta testuale mediana a Gemini usa circa 0,24 Wh e che questo valore è sceso di 33 volte in un anno. Sam Altman parla di 0,34 Wh per ChatGPT, ma senza spiegare come si è arrivati a questo calcolo. Sono cifre dichiarate dalle aziende, non verificate da terzi, e non includono l'addestramento dei modelli. Che è di sicuro la parte più onerosa dell’intero processo.
Attenzione però ai luoghi comuni, come quello secondo cui ChatGPT consumerebbe 10 volte una ricerca su Google. Un'analisi sui media ha rilevato che il 75% degli articoli riporta queste stime senza fonti né incertezze e che la cifra nasce da un confronto con un dato Google del 2009.
E il confronto con un programma classico? Non ho trovato misure pubblicate. Una stima mia, che condivido a puro scopo illustrativo: un programma semplice che gira per pochi millisecondi su un computer consuma frazioni di milliwattora. Tra questo e 0,24 Wh ballano ordini di grandezza, nell'ordine delle migliaia di volte. Non è una misura precisa, lo so, ma può essere un modo per dare un’idea della scala di valori in gioco.
Nel 1957 “sprecare” era un'eresia, chi poteva immaginarlo?
Per capire meglio il punto focale della questione, torniamo per un attimo alle origini, quando tutto è cominciato.
I primi computer si programmavano in linguaggio macchina: ogni istruzione descriveva un singolo “gesto” del processore.
Era come scrivere una ricetta indicando ogni minimo movimento delle mani del cuoco.
Nell'aprile 1957 IBM consegnò al mondo il Fortran, primo linguaggio di alto livello nella storia ad essere in seguito largamente adottato: si scrivevano formule quasi come sui libri di matematica e un compilatore, cioè un traduttore automatico, le convertiva in istruzioni per la macchina.
I programmatori dell'epoca erano scettici. I traduttori precedenti producevano programmi da cinque a dieci volte più lenti di quelli scritti a mano. E, come racconta I Programmer, molti vedevano in quel passaggio una perdita di controllo: il linguaggio di alto livello si metteva tra il programmatore e la macchina.
Poi andò diversamente. Il compilatore Fortran si avvicinò all'efficienza del codice a mano e, come ricorda Vivek Haldar, i linguaggi di alto livello non eliminarono affatto i programmatori: al contrario, ne fecero esplodere la domanda, perché molte più persone potevano finalmente scrivere software. Vi ricorda qualcosa? 😏
Dal Basic al PHP: lo spreco che vince ancora
Quel copione si è ripetuto con Basic, Perl, PHP, Python. Ognuno più comodo del precedente, e ognuno sempre più “sprecone”.
Un dato concreto: nello studio del 2017 Energy Efficiency across Programming Languages, Python consumava circa 75 volte più energia di C. Rifatto su Python 3.12, il divario scende a circa 48 volte su un calcolo puro, e gran parte del lavoro pesante viene comunque delegato a librerie scritte in C.
Perché allora nessuno è tornato indietro? ve lo dico io:
Perché vale la legge di Wirth:
il tempo delle persone costa più dell'energia delle macchine, quindi i team scambiano razionalmente efficienza della macchina con velocità di sviluppo.
Pensate a un sito di prenotazioni per un piccolo studio professionale: in PHP si mette in piedi in pochi giorni, scritto in linguaggio macchina sarebbe un progetto da anni. Il server consuma di più, ma nessuno lo rimpiange.
Oggi tocca all'AI
Andrej Karpathy, tra i fondatori di OpenAI, descrive questo passaggio come “Software 3.0”: le istruzioni al computer si scrivono in linguaggio naturale, e per lui l'inglese è diventato il linguaggio di programmazione più diffuso. Un'altra tappa, quindi, nella salita verso linguaggi sempre più vicini a noi.
Il costo, intanto, scende in fretta: secondo a16z, a parità di prestazioni il prezzo per far rispondere un modello cala di circa 10 volte l'anno (dato del 2024, destinato a cambiare).
Un mini-caso. Avete 200 fatture con nomi di file confusi da riordinare. Se non sapete programmare, scrivere il programma da soli richiede ore o giorni; con l'AI lo fate in pochi minuti. In termini assoluti, l'energia in più è irrisoria rispetto al tempo risparmiato.
E la produttività? I dati sono ancora in movimento. Uno studio del 2025 su 16 sviluppatori esperti trovò che con l'AI impiegavano il 19% di tempo in più, pur credendo di essere più veloci. Nel 2026 lo stesso gruppo, METR, ha dichiarato inaffidabile il nuovo esperimento perché molti sviluppatori rifiutavano di lavorare senza AI, ritenendo probabile che oggi i vantaggi siano maggiori. Onestamente: la discussione è aperta.
A proposito di nomi: c'è chi vuole ribattezzare l'intelligenza artificiale. Trump ha proposto all'ONU di chiamarla “Super Intelligence” (SI) nei documenti ufficiali. Comunque la vogliate chiamare, la mia impressione è una sola: più “super” la definiamo, più è facile dimenticarci quanto sia fondamentale mantenerla sotto il nostro controllo.
Attenzione: ogni livello “perde”
C'è però un limite e bisogna conoscerlo bene. Nel 2002 Joel Spolsky formulò una legge delle astrazioni che perdono in cui spiegava come ogni strumento che nasconde la complessità sotto un livello comodo, prima o poi la lascia filtrare. Le astrazioni, in sintesi, ci fanno risparmiare tempo di lavoro ma non tempo di studio.
Un esempio: leggere una grande tabella riga per riga o colonna per colonna sembra lo stesso lavoro, ma per il computer non lo è. I dati sono salvati in un certo ordine e seguirlo è molto più veloce che saltare avanti e indietro, come leggere un libro pagina dopo pagina invece di aprirlo a caso.
Ecco, ignorare che il concetto di tabella è una semplificazione di un certo modo di procedere nella lettura dei dati, proprio non si può, perché semplicemente la verità emerge presto in termini di problemi prestazionali.
Altro esempio usando una metafora. La CPU è il cuoco, la RAM è il piano di lavoro (poco spazio, accesso immediato), il disco è il magazzino in cantina (molto spazio, ma si deve scendere a prendere le cose). L'allocazione della memoria è come prenotare spazio sul piano; lo stack è una pila di comande in cui l'ultima arrivata è la prima a uscire e se la pila diventa troppo alta, cade tutto.
Un programmatore che ignori queste cose scrive programmi che funzionano finché i dati sono pochi. Lo stesso vale per chi usa l'AI senza capire come funzionano sistemi e linguaggi: alla prima anomalia non sa dove guardare.
E qui l'analogia con il passato presenta però una differenza molto importante: un compilatore è deterministico, l'AI no. Come ci ricorda bene Martin Fowler, chiedere a un LLM di modificare un programma può introdurre errori anche in parti che non avevamo minimamente intenzione di cambiare. Il cosiddetto vibe coding (coniato da Karpathy nel febbraio 2025, cioè programmare chiedendo all'AI senza guardare il codice) era nato, ricorda Scrimba, per progetti da fine settimana, non come metodo di lavoro per tutto.
AI, codice deterministico o entrambi?
Come credo a questo punto sia abbastanza intuibile, la strada sensata non è mai sposare uno soltanto dei tre approcci come metodo fisso.
Non ha senso, in altre parole, scegliere in maniera drastica tra AI, codice deterministico o una combinazione di entrambi sempre e in ogni condizione, un approccio del genere è semplicemente insensato.
Bisogna piuttosto imparare ad adottarli di volta in volta in maniera molto pragmatica in base allo scenario che ci si presenta:
- Compito ripetitivo, che deve dare sempre lo stesso risultato (fatture, report, calcoli): usate l'AI per farvi scrivere un piccolo programma, poi leggetelo e capitelo. Da quel momento gira in modo prevedibile e quasi gratis.
- Compito ambiguo o linguistico (riassumere, riformulare, classificare messaggi): l'AI direttamente.
- Mix dei due: alcuni sviluppatori usano modelli deterministici per le parti fisse e l'AI solo per quelle variabili, spendendo meno e ottenendo risultati più affidabili.
E nella scelta ci si deve sempre porre una domanda fondamentale: quante risorse sono disposto a “sprecare” per ottenere il mio obiettivo nei modi e nei tempi più consoni al problema che sto risolvendo?
