Tre ingegneri entrano in ufficio a Londra alle 8 di mattinaee trovano già pronto il lavoro della notte: quasi cento agenti AI hanno scritto codice, eseguito test, generato pull request, documentato tutto. Lo sprint review non è più ogni due settimane, è ogni giorno. Il rapporto di McKinsey appena pubblicato, firmato da Charlotte Relyea e Martin Harrysson come estratto del libro “Rewired” (Wiley, 2026), racconta questo scenario come qualcosa che sta già accadendo in una grande banca globale.
I risultati dichiarati sono dieci volte la velocità a metà del costo, ed è il tipo di affermazione che costringe a fermarsi e ragionare su cosa significhi davvero per chi costruisce prodotti digitali, per chi dirige team di sviluppo, per chi decide dove investire e soprattutto per chi domani dovrà gestire la selezione di fornitori di applicativi.
La tesi centrale è piuttosto forte, e condivisibile: se l’intelligenza artificiale generativa ha un’applicazione killer, è lo sviluppo software. E la curva di produttività che il rapporto disegna non è incrementale, è esponenziale.
Indice degli argomenti:
Quattro livelli di produttività, un solo punto di svolta
McKinsey articola la progressione in quattro livelli che vale la pena attraversare con attenzione, perché dentro quella scala c’è la mappa delle decisioni strategiche che ogni azienda dovrà prendere nei prossimi mesi.
- Al primo livello lo sviluppatore scrive tutto da solo,
- al secondo l‘AI suggerisce blocchi di codice mentre lavori (il classico copilot),
- al terzo un agente prende in carico interi passaggi del workflow partendo da una descrizione in linguaggio naturale, genera codice, test e documentazione;
- al quarto livello, quello che il rapporto chiama “la prossima frontiera“, un piccolo team umano supervisiona un’organizzazione virtuale di agenti che consegna un’applicazione intera, dall’architettura al deployment, sollevando solo le decisioni che richiedono giudizio umano.
Il salto nei numeri è brutale e mette in discussione modelli di business: dal livello uno al due si passa da 1x a 1,2x di produttività, dal due al tre si arriva a 2x, ma dal tre al quattro si salta a 20x! La maggior parte delle aziende oggi è al livello due, il livello tre è in adozione crescente, il quattro è ancora sperimentale. Però i primi casi concreti ci sono già.
La fabbrica a due turni: umani di giorno, agenti di notte
Il concetto più potente del rapporto è quello della “agent factory“, la fabbrica di agenti, e vale la pena di descriverlo perché cambia radicalmente il modo in cui pensiamo al ciclo di sviluppo. Di giorno il team umano lavora sulla direzione: raffina le user story, traduce le feature in specifiche, scompone il lavoro in task ben definiti con criteri di accettazione chiari, fornisce contesto architetturale (quali moduli toccare, quali no, perché). Gli umani non scrivono codice, guidano, decidono, controllano qualità.
Di notte gli agenti prendono il turno. Una flotta coordinata esegue workflow complessi: agenti di coding implementano modifiche, agenti di test generano ed eseguono suite di test, agenti QA cercano regressioni, agenti di sicurezza scansionano vulnerabilità, agenti di performance fanno benchmark, agenti di documentazione aggiornano i riferimenti API. Un agente orchestratore gestisce i passaggi: se i test falliscono, il lavoro torna a un agente di fix; se le performance calano, interviene un agente dedicato; se una policy viene violata, il workflow si ferma.
Al mattino il team umano trova un set di pull request pronte per la review, ciascuna con codice, test, log, risultati di analisi e una spiegazione in linguaggio naturale.
Lo sviluppo software diventa un loop continuo ad alta velocità, non più un ciclo a sprint bisettimanali. Ed è qui che il moltiplicatore 20x smette di essere un numero su una slide e inizia a diventare un modello operativo.
Non basta dare strumenti AI agli sviluppatori
Il dato più interessante dell’analisi McKinsey, condotta su quasi 300 aziende quotate, è che distribuire tool AI ai developer non sposta l’ago della bilancia in modo significativo. Il quintile superiore delle aziende analizzate ottiene miglioramenti del 16-30% in produttività, time to market e customer experience, con guadagni del 31-45% sulla qualità del software. Ma queste aziende non si sono limitate ad aggiungere un copilot: hanno ridisegnato il modo in cui costruiscono software, integrando l’AI lungo l’intero ciclo di sviluppo, dall’ideazione ai requisiti, dal design al testing, dal deployment alle operation.
Il punto è organizzativo prima che tecnologico. Queste organizzazioni hanno reso il loro modello di sviluppo AI-native, trasformando i ruoli e i flussi di lavoro perché gli umani agiscano come orchestratori degli agenti, non come esecutori assistiti.
Gli sviluppatori passano dalla scrittura del codice alla supervisione della generazione, alla validazione dell’architettura, alla gestione della qualità; i product manager e i designer si muovono verso un pensiero più sistemico.
Tre abilitatori che separano chi ci riesce da chi no
Il rapporto identifica tre fattori che distinguono chi ottiene risultati reali.
Il primo è l’investimento serio in upskilling, con workshop pratici, simulazioni di sprint reali e coaching dedicato, non formazione passiva. IBM ha portato oltre 8MILA sviluppatori attraverso un programma di questo tipo in circa sei mesi, assegnando coach a ogni team per almeno due sprint, organizzando “bring your code in” office hours e costruendo una community Slack attiva dove i campioni interni rispondevano alle domande in tempo reale. L’adozione iniziale era stata frammentaria, molti avevano provato gli strumenti AI e poi erano tornati ai metodi precedenti; il programma strutturato ha cambiato la traiettoria.
Il secondo fattore è la misurazione degli outcome reali, non delle metriche di adozione. Frequenza di rilascio, tasso di difetti, esperienza cliente: sono questi i numeri che contano, non quante volte qualcuno ha usato il copilot.
Il terzo fattore è l’allineamento degli incentivi: circa l’80% delle aziende top performer lega gli obiettivi di AI generativa alle valutazioni di product manager e sviluppatori. Senza questi tre elementi, le organizzazioni ricadono nelle vecchie abitudini e il potenziale dell’AI si dissolve.
Cosa serve per far funzionare una agent factory
Il rapporto è molto concreto sui prerequisiti. Gli agenti hanno bisogno di requisiti strutturati, user story chiare e criteri di accettazione non ambigui, perché non possono inferire l’intento di business. Serve contesto ricco: knowledge graph che unifichino repository di codice, documenti, diagrammi di architettura, contratti API, modelli dati, confini dei servizi, aspettative non funzionali.
La capacità umana cruciale diventa la decomposizione del lavoro in task “agent-ready”, piccoli e ben definiti con input, output e criteri di accettazione espliciti. Senza questa scomposizione, gli agenti si bloccano o divergono.
C’è poi la questione del “context engineering“, che il rapporto distingue nettamente dal prompt engineering. Non si tratta di formulare domande più intelligenti, ma di fornire agli agenti il contesto giusto, architettura, vincoli, regole di business, in modo strutturato e completo.
L’output di qualità viene dal contesto, non dalla formulazione furba della richiesta. Ed è un’osservazione che risuona con chiunque abbia lavorato seriamente con agenti AI: la differenza tra un risultato mediocre e uno utilizzabile sta quasi sempre nella qualità delle istruzioni e del contesto fornito, non nel modello scelto.
Le implicazioni strategiche del moltiplicatore 20x
Se il costo marginale dello sviluppo software si avvicina a zero, le conseguenze strategiche si propagano ovunque. Le aziende che raggiungono questo livello di produttività diventano “continuous real-time business improvers“, con customer journey che evolvono settimanalmente, non annualmente. L’innovazione smette di essere limitata dalla capacità e diventa limitata solo dall’immaginazione. La modernizzazione dei sistemi legacy non è più un programma mastodontico ma un’attività ordinaria. E il gap competitivo si allarga: rilasci più frequenti, costi inferiori, esperienze migliori, controlli più stretti creano un vantaggio strutturale che si compone nel tempo.
McKinsey pone tre domande ai C-suite che meritano di essere rilanciate: la vostra azienda deve guidare questa rivoluzione o può permettersi di seguire? Come misurerete l’impatto dell’AI sulla produttività e qualità dei vostri prodotti? Come cambierebbe la vostra strategia se il costo dello sviluppo tendesse a zero?
Il nodo del token consumption e il nuovo ruolo del FinOps
Un elemento che il rapporto affronta con pragmatismo e che spesso viene sottovalutato è il consumo di token. In un mondo dove i team possono istanziare agenti che a loro volta generano prompt e sub-agenti, il consumo può crescere esponenzialmente e portare a sforamenti di costo significativi.
La risposta è costruire capacità di FinOps dedicate al tracciamento e alla governance dell’attività degli agenti, un tema che chi ha esperienza di cloud management riconoscerà immediatamente, declinato in un contesto nuovo.
La sfida vera è umana, non tecnologica
Il rapporto di McKinsey conferma quello che chi lavora con l’AI in contesti reali percepisce da tempo: la trasformazione non è un problema di strumenti, è un problema di modello operativo, di cultura, di competenze umane ridefinite.
LATAM Airlines, citata come caso di riferimento, ha raggiunto incrementi di produttività del 50% con team più piccoli, ma sottolinea che i prerequisiti sono stati una piattaforma ingegneristica robusta e un modello operativo già orientato al prodotto. Non si improvvisa.
La provocazione finale è forse la più interessante: gli umani in questo modello diventano “editors-in-chief” della fabbrica. Devono saper revisionare codice generato, intercettare derive architetturali, valutare se il lavoro degli agenti corrisponde all’intento originale, decidere quando stringere i guardrail o modificare i test. La combinazione di giudizio di prodotto, comprensione architetturale e capacità di review rimane interamente umana. Ed è una competenza che oggi quasi nessuno sta sviluppando in modo sistematico.
