I guadagni di produttività che arrivano dagli strumenti di coding AI sono reali. Ciò che quei guadagni non dimostrano ancora è un miglioramento proporzionale nella qualità del software, nel giudizio di prodotto o nell'apprendimento organizzativo. È un divario che vale la pena capire prima che arrivi il conto.
Punti chiave:
- Il CEO di Anthropic colloca l'impatto degli strumenti di coding AI sulla produttività intorno al 15–20%: una stima prudente da parte di chi avrebbe ogni ragione per dichiarare cifre più alte. Gli stessi ingegneri di Anthropic hanno dichiarato un incremento del 50%. I 30 punti di differenza tra le due cifre sono il punto di partenza per una conversazione più onesta su cosa stiano davvero facendo questi strumenti.
- Uno studio randomizzato controllato ha rilevato che sviluppatori esperti, al lavoro su codebase complesse a cui contribuivano da anni, erano misurabilmente più lenti con gli strumenti AI, pur continuando a credere di essere più veloci.
- Goldman Sachs non rileva alcuna relazione significativa tra adozione dell'AI e produttività su scala dell'intera economia, nonostante guadagni concreti in casi d'uso specifici e mirati.
- Il rischio non sono gli strumenti. È la pressione competitiva che fa sembrare un'adozione ponderata una zavorra, e un'adozione superficiale un atto di coraggio.
- L'attrito del costruire insieme — sessioni di grooming, code review, lo sviluppatore che dice "questi requisiti si contraddicono a vicenda" — produceva qualcosa che andava oltre il software. Gli agenti AI non replicano quel sottoprodotto.
Cosa significa "vibe coding" e perché la definizione conta?
La confusione comincia dalla parola. Nel febbraio 2025, Andrej Karpathy ha coniato il termine "vibe coding" in un tweet: la descrizione informale di un workflow da weekend in cui ci si affida completamente all'AI, si accettano tutti i diff senza leggerli e si smette di preoccuparsi di capire il codice. Lo aveva limitato esplicitamente ai progetti usa-e-getta.
Quello che è successo dopo è istruttivo. Karpathy stesso ha poi dichiarato di preferire "agentic engineering" per il lavoro serio: non perché abbia fatto marcia indietro sul coding assistito dall'AI, ma perché ritiene che la pratica meriti supervisione, rigore e cura artigianale. In un'intervista del marzo 2026 al podcast No Priors, ha raccontato di non aver scritto una riga di codice da dicembre.
Nel frattempo, Gene Kim e Steve Yegge hanno pubblicato Vibe Coding: Building Production-Grade Software (2025), definendo con lo stesso nome una pratica professionale rigorosa, con prefazione di Dario Amodei. Altrove, il termine circola come dispregiativo, come motivo di vanto, come descrizione della democratizzazione e come quasi-sinonimo di sviluppo assistito dall'AI in generale.
Il caos definitorio conta perché permette a pratiche molto diverse di circolare sotto la stessa etichetta. Un team che usa l'AI con review disciplinate, ownership chiara e verifica accurata può sembrare a parole molto simile a un team che accetta l'output generato con un controllo minimo. Il termine è scivoloso; le scelte di governance no.
Questo articolo non è un atto d'accusa contro lo sviluppo assistito dall'AI. È una domanda su cosa accade quando la pressione culturale ad adottare in fretta, su larga scala, e ad annunciare la trasformazione spinge le organizzazioni a credere di muoversi con cura mentre in realtà si muovono con leggerezza.
Cosa dicono i dati sulla produttività del coding AI?
Le stime più credibili sono più modeste di quanto suggeriscano i titoli, e il divario tra percezione e realtà è notevole.
Dario Amodei, intervenuto al Dwarkesh Podcast nel febbraio 2026, ha dato probabilmente la stima più onesta disponibile da parte di chi ha interessi diretti in gioco. Ha collocato l'impatto degli strumenti di coding AI sulla produttività intorno al 15–20%: una stima approssimativa, deliberatamente prudente, da parte di chi avrebbe avuto ogni motivo per dichiarare di più.
Uno studio interno di Anthropic a sé stante, pubblicato a fine 2025 e basato su sondaggi a 132 ingegneri dell'azienda, ha rilevato guadagni di produttività auto-dichiarati intorno al 50%. Sono misurazioni diverse — una stima ampia di produttività e i guadagni auto-dichiarati dagli ingegneri di un'azienda di AI con accesso privilegiato e anticipato agli strumenti — ma vale la pena soffermarsi sul divario tra le due. Misurano cose diverse, e nessuno dei due numeri è preciso. Una differenza di 30 punti tra due stime approssimative che puntano in direzioni opposte dice comunque qualcosa, soprattutto quando la maggior parte delle decisioni sull'organico legate all'AI si fonda sulla produttività percepita più che su qualcosa valutato in modo indipendente.
Lo studio randomizzato controllato di METR — tra i più rigorosi studi indipendenti sugli strumenti di coding AI condotti finora — si è concentrato proprio sul contesto più rilevante per chi guida l'engineering: sviluppatori esperti al lavoro su codebase ampie, complesse e mature a cui contribuivano da anni. In quel contesto, gli sviluppatori che usavano strumenti AI sono risultati più lenti del 19% rispetto a quando non li usavano, pur avendo previsto un'accelerazione del 24%. Ancora più rivelatore: una volta concluso lo studio, hanno stimato che l'AI li avesse resi più veloci del 20%, mentre i dati oggettivi mostravano l'opposto.
METR precisa con attenzione che questo risultato potrebbe non essere generalizzabile oltre il proprio contesto. Gli strumenti AI possono comportarsi diversamente con sviluppatori meno esperti, codebase non familiari o lavori greenfield. Ma il divario di percezione — la sistematica disconnessione tra quanto gli sviluppatori credono di andare veloci e quanto lo sono davvero — si applica in modo molto più ampio. È questo divario, più ancora del rallentamento in sé, a spiegare gran parte di ciò che alimenta l'attuale dibattito sulla produttività dell'AI.
Gli economisti di Goldman Sachs, in un'analisi del Q4 2025, non hanno rilevato "alcuna relazione significativa tra produttività e adozione dell'AI a livello dell'intera economia". La stessa analisi ha individuato guadagni di produttività intorno al 30% in casi d'uso specifici e localizzati: coding del software e customer service. La storia della produttività dell'AI è reale a macchie di leopardo. Non è ancora la trasformazione ad ampio raggio che si proclama.
Ciò che le evidenze attuali sostengono è più ristretto sia dell'hype sia del backlash. Gli strumenti di coding AI possono produrre guadagni significativi in contesti specifici. Producono anche un ricorrente divario di percezione, in cui l'accelerazione soggettiva supera il miglioramento misurato. Ciò che le evidenze non hanno ancora stabilito è che una produzione di codice più rapida si traduca in modo affidabile in guadagni proporzionali nella qualità del software, nel giudizio di prodotto o nell'apprendimento del team.
Quanto regge la narrativa dei licenziamenti di fronte ai dati?
Alcune delle aziende più rumorose nel tagliare l'organico in nome della produttività AI sono anche quelle in cui le evidenze sono più sottili.
Klarna è il caso più istruttivo, raccontato per intero da Fortune. L'azienda ha dichiarato che il proprio assistente AI svolgeva il lavoro di 700 agenti del customer service. Nel giro di pochi mesi, i clienti si lamentavano di risposte generiche e dell'assenza di supporto umano, e l'azienda ha ripreso ad assumere personale umano. Il CEO Sebastian Siemiatkowski è stato diretto su ciò che era accaduto: "Dato che il costo è purtroppo sembrato un fattore di valutazione troppo predominante… ciò che si finisce per ottenere è una qualità inferiore." Klarna non dimostra che le strategie di sostituzione tramite AI falliscano sempre. È un esempio nitido di cosa si perde quando si scambia il volume gestito per la qualità erogata.
Klarna è il caso più documentato, ma non è isolato. Tra il 2025 e il 2026, diverse aziende hanno annunciato riduzioni di organico legate all'AI, mentre analisti e insider indicavano l'over-hiring da pandemia come spiegazione più semplice. Il mercato ha premiato la narrazione AI in quasi tutti i casi, a prescindere.
Uno studio IBM su 2.000 CEO ha rilevato che soltanto un progetto AI su quattro produce il ritorno sull'investimento promesso. Eppure quasi due terzi dichiarano che il rischio di restare indietro li spinge a investire prima ancora di avere una chiara comprensione del valore.
Vale la pena soffermarsi su quest'ultima statistica. Il principale motore degli investimenti in AI non è l'evidenza dei ritorni: è l'ansia per quello che accadrà se i concorrenti si muoveranno più velocemente. Quell'ansia è comprensibile e, in certi contesti, razionale. Ma crea le condizioni per un particolare tipo di auto-inganno collettivo: organizzazioni che annunciano trasformazioni guidate dall'AI non perché la trasformazione sia avvenuta, ma perché annunciarla è competitivamente necessario. La narrazione viaggia più veloce dei risultati.
E quando i risultati diventano chiari, la narrazione ha già plasmato decisioni di assunzione, aspettative degli investitori e impegni strategici difficili da disfare.
Gli strumenti sono reali. La narrazione sta facendo un lavoro che gli strumenti non stanno facendo.
Perché produrre codice più in fretta non equivale a produrre software migliore?
È la domanda più importante, e ha rilevanza ben oltre il dibattito sulla produttività.
Apra l'app Claude sul suo iPad. Funziona. Ed è anche, se la usa con regolarità, chiaramente un prodotto su cui non si è riflettuto a fondo dal punto di vista di chi tiene un iPad in mano e vuole che qualcosa gli sembri giusto.
Questo non è in primo luogo un problema di generazione di codice. È un problema di giudizio: qualcuno doveva decidere cosa l'app dovesse essere, che sensazione dovesse dare nell'uso e cosa avrebbe spinto a sceglierla rispetto al browser. Una migliore generazione di codice può accelerare l'implementazione, ma da sola non risolve quel livello di decisione. Risolverlo richiede un'attenzione costante a ciò che gli altri esseri umani sperimentano davvero, e quel tipo di attenzione è lenta, incerta e non si fa apparire dal nulla a colpi di vibe.
Quando produrre diventa rapido ed economico, la pressione economica a riflettere con cura prima di costruire si riduce. Si può rilasciare qualcosa di plausibile in pochi giorni e iterare. L'effetto cumulativo è che questa logica scoraggia attivamente l'investimento in una reale comprensione dell'utente, ciò che rende un software degno di essere usato. Perché spendere settimane in una ricerca utente accurata quando si può lanciare e vedere cosa succede? Il problema è che "vedere cosa succede" produce apprendimento utile solo se si è già definito cosa si sta cercando e perché. Senza questo, ciò che si lancia rivela meno di quanto ci si aspetti, e correggere ciò che si trova costa più del previsto. Quando la cosa diventa chiara, le decisioni sono già state prese. È lo stesso istinto in una forma diversa: ottimizzare per ciò che è visibile e veloce, rinviare ciò che è lento e difficile da misurare.
Questa tendenza — ottimizzare per la metrica entusiasmante trascurando il meccanismo che la abilita — non è nuova. Quando un cliente si lamentò dei freni della sua Type 35 da corsa negli anni Venti, Ettore Bugatti rispose: "Costruisco le mie auto per andare, non per fermarsi." La frase ha circa cento anni. Il pensiero che esprime è evidentemente eterno. Le auto di Bugatti erano belle, potenti e notoriamente sotto-frenate. Andavano fortissimo, finché non smettevano di farlo.
Nel 2023, Gene Kim e Steven Spear hanno pubblicato Wiring the Winning Organization, uno studio sulle organizzazioni ad alte prestazioni che ha dato un nome all'antidoto: slowification. Prendersi il tempo di pianificare, prepararsi e costruire una comprensione condivisa prima di eseguire non è l'opposto della velocità: è ciò che la rende sostenibile. Le organizzazioni che hanno investito in una preparazione deliberata hanno superato in modo costante quelle che trattavano ogni momento di riflessione come un costo da eliminare. Kim ha poi co-scritto Vibe Coding: Building Production-Grade Software, sostenendo proprio questo tipo di pratica rigorosa e deliberata. Il principio individuato nel 2023 si applica direttamente al modo in cui quello sviluppo dovrebbe essere affrontato.
Il soffitto della produzione si è alzato. Quello della comprensione no.
Non è uno schema nuovo. Ogni generazione di tooling migliore — linguaggi più espressivi, framework più ricchi, infrastruttura cloud — ha reso più rapido ed economico costruire cose senza capirle. Il movimento low-code prometteva di democratizzare la creazione di software e ha consegnato in larga parte software rapido da creare e frustrante da usare. Gli strumenti di coding AI sono finora l'incarnazione più potente di questo schema, non la sua invenzione.
Il divario tra ciò che le organizzazioni sanno costruire e ciò che davvero comprendono si è riprodotto a ogni livello di astrazione. Adesso si sta riproducendo più rapidamente che mai.
Cosa si perde quando gli agenti AI sostituiscono gli sviluppatori umani?
Il giudizio che rende buono un software non è mai stato appannaggio dei soli product manager. Era distribuito: nel team, attraverso l'attrito del costruire insieme.
Non tutto l'attrito ha valore. Una parte è burocrazia, latenza e zavorra evitabile. Ma una parte è il luogo in cui si produce la comprensione collettiva, e l'attuale ondata di automazione rende facile rimuovere entrambe insieme.
Non è un discorso puramente teorico. Nelle community di engineering, in questo momento, qualcosa emerge in modo coerente nel modo in cui gli sviluppatori raccontano la propria esperienza: rilasciare più in fretta, sentirsi più produttivi e perdere silenziosamente la presa su cosa il sistema stia davvero facendo e perché. La ricerca di cui sopra lo conferma a livello macro. Anche la conversazione lo conferma.
Quando uno sviluppatore opponeva resistenza in una sessione di grooming — "Non posso costruire questa cosa perché due di questi requisiti si contraddicono direttamente" — l'organizzazione era costretta a fare i conti con qualcosa che era riuscita ad aggirare. Quel disagio non era un fallimento del processo di pianificazione. Era il processo di pianificazione che funzionava. Il requisito era stato scritto in modo apparentemente coerente, finché qualcuno non aveva provato davvero a implementarlo. La confusione dello sviluppatore era lo specchio dell'organizzazione.
Quando una code review avveniva tra un ingegnere senior e uno junior, entrambi ne uscivano con qualcosa che prima non avevano. Il junior imparava come pensare a una classe di problemi. Il senior doveva mettere in parole qualcosa che prima conosceva solo tacitamente, e l'atto stesso di metterlo in parole lo affinava. La conversazione era l'apprendimento. Il codice ne era il residuo.
Questa distinzione conta più di quanto possa sembrare. Michael Polanyi ha dedicato una carriera a renderla precisa. "Sappiamo più di quanto possiamo dire", ha scritto in The Tacit Dimension, e il corollario è che ciò che possiamo dire è sempre meno di ciò che davvero sappiamo.
La comprensione costruita attraverso la pratica è qualitativamente diversa dall'informazione acquisita tramite lettura o istruzione. Non si arriva con la lettura a sapere come un sistema complesso si rompe sotto carico, o come un certo tipo di utente incappa in un certo tipo di confusione. Bisogna esserci stati: aver tenuto in mano il modello, averlo visto cedere e aver costruito la comprensione rivista a partire dai resti di quella precedente.
È ciò che la sessione di grooming e la code review producevano, come sottoprodotto dell'attrito, che qualcuno gli desse o meno un nome.
Un agente AI non produce questi sottoprodotti. Procede senza obiezioni. La conformità dell'agente non è la prova che i suoi requisiti fossero chiari. È la prova che l'agente non si lamenta.
Si può rivedere il codice di un agente AI. Non si può avere quella conversazione con lui. L'agente non porterà avanti la review come comprensione. Lo sviluppatore junior che si sarebbe formato attraverso anni di scambi del genere viene assunto sempre meno. E l'organizzazione che ha sostituito quegli scambi con codice generato ha rimosso un meccanismo da cui forse non sapeva di dipendere, un meccanismo che faceva qualcosa di molto diverso dal produrre software.
La domanda da porsi
La metrica rilevante non è solo di quanto si stia rilasciando più in fretta. È se i guadagni nella produzione siano accompagnati da guadagni in chiarezza, giudizio e apprendimento.
Non è un atto d'accusa contro gli strumenti AI. Usati bene — con la supervisione, la cura artigianale e il giudizio su cui Karpathy, Kim e Yegge insistono tutti — questi strumenti sono davvero preziosi. La questione è se il momento attuale stia creando le condizioni per quel tipo di uso. L'ansia competitiva, la pressione a rilasciare prima di pensare, la sensazione crescente che rallentare per capire qualcosa sia una forma di sotto-rendimento: nulla di tutto questo è prodotto dagli strumenti in sé. È l'aria culturale che oggi li circonda.
I piloti da corsa sanno che i freni non servono a rallentare. Servono a permettere l'impegno: a rendere possibile spingere più forte in curva perché ci si fida della propria capacità di fermarsi se qualcosa va storto. L'attrito che i team stanno oggi rimuovendo in nome della velocità era spesso esattamente questo: non overhead, non inefficienza, ma il meccanismo che rendeva possibile andare veloci, in primo luogo. Il praticante rigoroso dello sviluppo assistito dall'AI lo sa. L'organizzazione travolta dall'ansia competitiva spesso no.
Rilasciare più codice non è la stessa cosa che costruire software migliore, e non lo è mai stato. Il codice è sempre stato un artefatto: il residuo visibile della comprensione che lo ha prodotto, non la comprensione stessa. Ciò che è cambiato non è la confusione tra artefatto e comprensione. È quanto sia diventato veloce ed economico tenere in piedi quella confusione su larga scala.
La domanda da porsi — onestamente, in modo specifico, sul proprio team — è quale tipo di adozione si stia effettivamente praticando. Quella domanda di solito guadagna molto da uno sguardo esterno: qualcuno che ha visto entrambi i tipi e sa cosa cercare.
Queste domande non hanno risposte pulite, e chi sostiene il contrario probabilmente non se le sta ponendo abbastanza sul serio. In DoiT abbiamo lavorato a fianco di centinaia di leader dell'engineering e della tecnologia che si muovevano esattamente in questa tensione, capendo cosa mantenere, cosa cambiare e cosa stavano per perdere senza accorgersene. Abbiamo scoperto che le domande giuste, poste con le persone giuste, tendono a produrre risposte migliori di qualunque framework. Se vede qualcosa che noi non vediamo, o sta affrontando questo tema in modi che funzionano, ci farebbe piacere saperne di più.
Domande frequenti
Quali sono i diversi significati di "vibe coding"? Il termine ha almeno tre significati distinti nell'uso attuale. Nel suo senso originale — coniato da Andrej Karpathy nel febbraio 2025 — descriveva un workflow informale, basato sull'abbandono fiducioso, adatto a progetti usa-e-getta. Gene Kim e Steve Yegge hanno poi definito una pratica professionale seria con lo stesso nome nel loro libro del 2025 Vibe Coding: Building Production-Grade Software, ponendo l'accento su rigore, supervisione e cura artigianale. Nell'uso comune funge anche da sinonimo generico di sviluppo assistito dall'AI e, in alternativa, da dispregiativo per un'adozione AI superficiale. Il caos definitorio conta: quando lo stesso termine descrive sia l'accettazione passiva dell'output AI sia un'agentic engineering disciplinata, una conversazione significativa su cosa stia facendo davvero un certo team diventa molto difficile.
Gli strumenti di coding AI possono migliorare la produttività senza migliorare la qualità del software? Sì. Le evidenze suggeriscono che lo stiano già facendo su larga scala. Gli strumenti AI possono aumentare in modo misurabile l'output di codice e accorciare i cicli di consegna senza migliorare il giudizio che determina cosa costruire, la chiarezza dei requisiti o la profondità della comprensione dell'utente alla base del prodotto. Goldman Sachs rileva guadagni di produttività reali nel coding del software come caso d'uso specifico. Ciò che non rileva — e ciò che le evidenze più ampie non mostrano ancora — è che quei guadagni si traducano in miglioramenti proporzionali nella qualità del software o nei risultati di prodotto.
Cosa ha effettivamente rilevato lo studio METR sul coding AI? Lo studio randomizzato controllato di METR del 2025 ha messo alla prova 16 sviluppatori esperti su 246 task reali, in codebase open-source ampie e mature che conoscevano bene. Gli sviluppatori che usavano strumenti AI hanno impiegato il 19% in più per completare i task rispetto a chi non li usava, pur avendo previsto un'accelerazione del 24% e continuando a credere, anche dopo, di essere stati più veloci. METR osserva che il risultato è specifico di questo contesto e potrebbe non generalizzarsi a sviluppatori meno esperti o codebase non familiari. Il divario di percezione — credere sistematicamente che l'AI stia aiutando quando i dati dicono il contrario — è il risultato più ampiamente applicabile.
Perché c'è un divario così grande tra produttività AI auto-dichiarata e misurata? Due dati illustrano il divario da angolazioni diverse. Nella sua apparizione al podcast del febbraio 2026, Dario Amodei ha stimato l'impatto sulla produttività degli strumenti di coding AI intorno al 15–20%. Uno studio interno di Anthropic di fine 2025 ha rilevato che gli stessi ingegneri di Anthropic hanno auto-dichiarato un incremento di produttività del 50%: una misurazione diversa, ma il divario tra le due è istruttivo. Lo studio di METR ha osservato uno schema percettivo simile: gli sviluppatori credevano che l'AI li avesse accelerati del 20% mentre la misurazione oggettiva mostrava un rallentamento del 19%. La stessa analisi di METR sul divario indica diversi fattori: il coding assistito dall'AI richiede meno sforzo cognitivo e dà la sensazione di essere più veloce anche quando non lo è; gli sviluppatori potrebbero confondere la facilità con la velocità; e il tempo speso a rivedere, correggere e ripulire il codice generato dall'AI di solito non viene conteggiato nelle auto-dichiarazioni.
Cosa è successo quando Klarna ha sostituito gli agenti del customer service con l'AI? Klarna ha sostituito circa 700 ruoli del customer service con un assistente AI sviluppato con OpenAI, sostenendo che l'AI svolgesse un lavoro equivalente. Nel giro di pochi mesi, i clienti si lamentavano di risposte generiche e dell'assenza di supporto umano, mentre gli agenti AI faticavano con interazioni complesse, sfumate ed emotivamente cariche. Il CEO Sebastian Siemiatkowski ha riconosciuto l'errore in modo diretto: "Dato che il costo è purtroppo sembrato un fattore di valutazione troppo predominante… ciò che si finisce per ottenere è una qualità inferiore." L'azienda ha ripreso ad assumere personale umano nel customer service nel 2025. Il caso è istruttivo non solo come storia di fallimento, ma come esempio di cosa si perde quando la metrica è il volume gestito anziché la comprensione dimostrata.
Cos'è la slowification e perché conta per i team di sviluppo software? La slowification è un concetto del libro del 2023 di Gene Kim e Steven Spear Wiring the Winning Organization. Descrive l'investimento deliberato in pianificazione, preparazione e comprensione condivisa prima dell'esecuzione: rallentare per muoversi più velocemente e in modo più affidabile a valle. La loro ricerca su organizzazioni ad alte prestazioni ha rilevato che si trattava di un fattore di differenziazione costante: i team che praticavano la slowification superavano in modo costante quelli che trattavano ogni momento di riflessione come un costo. Il principio si applica direttamente allo sviluppo software: la sessione di grooming, la ricerca utente accurata, la code review che sembrava lenta facevano spesso esattamente questo, producendo la conoscenza condivisa da cui dipende un'esecuzione sicura.
Gli strumenti AI possono aumentare l'output riducendo la comprensione? Sì, ed è verosimilmente la domanda più importante, più ancora di quella sull'aumento di produttività. Output e comprensione sono prodotti da meccanismi diversi. Il codice è prodotto dall'esecuzione; la comprensione è prodotta dall'attrito di affrontare i problemi insieme: lo sviluppatore che obietta di fronte a requisiti contraddittori, la code review in cui un ingegnere senior deve mettere in parole qualcosa che prima conosceva solo tacitamente, la sessione di grooming in cui un team scopre che ciò che sembrava una specifica chiara non lo è. Gli agenti AI procedono senza generare questi sottoprodotti. Non si lamentano, non chiedono chiarimenti, non portano avanti la conversazione come apprendimento. Un'organizzazione può rilasciare più software perdendo allo stesso tempo la presa su cosa stiano facendo i suoi sistemi, perché siano stati costruiti in quel modo e cosa serva davvero ai suoi utenti. L'output cresce. La comprensione che dovrebbe accompagnarlo non tiene il passo.
Goldman Sachs sostiene che l'AI non abbia alcun impatto sulla produttività? Non esattamente. Gli economisti di Goldman Sachs, nella stessa analisi del Q4 2025, non rilevano alcuna relazione significativa tra adozione dell'AI e produttività su scala dell'intera economia. La stessa analisi ha rilevato guadagni di produttività intorno al 30% in casi d'uso specifici e localizzati: coding del software e customer service, i due più citati. Il quadro è quello di guadagni reali in contesti specifici che non si sono ancora tradotti in un miglioramento ampio della produttività economica. Quella distinzione conta nel modo in cui le organizzazioni dovrebbero ragionare sui propri investimenti in AI: un'adozione mirata in contesti dove i guadagni sono ben documentati è cosa diversa dal trattare l'AI come un moltiplicatore di produttività di uso generale.