Il 73% delle organizzazioni cita l’affidabilità come barriera principale al deploy di agenti in produzione. Non perché manchino i test, ma perché i test tradizionali non catturano i failure mode di sistemi che “improvvisano”.

TL;DR: Testare agenti AI richiede un cambio di paradigma. I test unitari tradizionali verificano output deterministici: dato input X, attendi output Y. Gli agenti generano output diversi a ogni esecuzione, usano tool in sequenze imprevedibili, falliscono in modi che non crashano ma producono risultati sbagliati. Servono nuove metodologie: property-based testing per definire invarianti invece di output attesi, LLM-as-judge per valutazione scalabile, red teaming automatizzato per sicurezza, fuzzing adattato per stress-testing. I framework esistono: DeepEval, Opik, LangSmith, DeepTeam, PyRIT. Chi li adotta prima del deploy evita i silent failure che emergono solo in produzione.

Un test unitario classico funziona così: chiami una funzione con input noti, verifichi che l’output corrisponda a un valore atteso. Se sum(2, 3) restituisce 5, il test passa. È deterministico, ripetibile, binario.

Ora prova a testare un agente che deve rispondere a “trova i ristoranti italiani aperti stasera vicino a me”. L’agente potrebbe chiamare un’API di geolocalizzazione, poi un servizio di ricerca locale, poi filtrare per orario. Oppure potrebbe cercare prima su Google Maps, poi verificare gli orari sui siti dei singoli ristoranti. Ogni esecuzione può produrre sequenze di azioni diverse, risultati diversi, formulazioni diverse della risposta finale.

Come scrivi un assertEquals() per questo?

Il problema non è solo la variabilità dell’output. È che i failure mode degli agenti sono fondamentalmente diversi da quelli del software tradizionale.

Un bug classico crasha o restituisce un errore. Un agente che “fallisce” potrebbe restituire una risposta perfettamente formattata, grammaticalmente corretta, apparentemente ragionevole, ma fattualmente sbagliata. Potrebbe scegliere tool inappropriati. Potrebbe allucinare informazioni. Potrebbe seguire un piano che sembra logico ma non risolve il task originale.

Il sistema non crasha. Non lancia eccezioni. Completa l’esecuzione. Solo che il risultato è sbagliato.

Questo è il cuore del problema: i test tradizionali non catturano i silent failure. E i silent failure sono la norma, non l’eccezione, nei sistemi agentici.

Tassonomia: cosa stai cercando di testare

Prima di scegliere metodologie, serve chiarire cosa significa “testare un agente”. Un paper del 2025 su arXiv propone una tassonomia bidimensionale che aiuta a orientarsi.

La prima dimensione riguarda l’oggetto della valutazione:

Behavior: L’agente si comporta come previsto? Segue le istruzioni? Rispetta i vincoli?

Capabilities: L’agente è in grado di completare determinati task? Quali classi di problemi risolve?

Reliability: L’agente produce risultati consistenti? Quanto varia la qualità tra esecuzioni?

Safety: L’agente evita azioni dannose? Resiste a tentativi di manipolazione? Protegge dati sensibili?

La seconda dimensione riguarda il processo di valutazione:

Offline evaluation: Test pre-deployment su dataset statici o ambienti simulati.

Online evaluation: Monitoraggio in produzione su traffico reale.

Component-level: Testare singoli pezzi (il retriever, il planner, il singolo tool).

End-to-end: Testare il sistema completo su task realistici.

La maggior parte delle organizzazioni si ferma alla valutazione offline delle capabilities su singoli componenti. È il minimo indispensabile, ma non basta. I bug più insidiosi emergono dalle interazioni tra componenti, dalla variabilità del comportamento su input diversi, dai casi limite che nessun dataset statico copre.

Property-based testing: invarianti invece di output

Il primo cambio di paradigma è passare da example-based testing a property-based testing.

Nell’example-based testing, definisci coppie input-output: “Se l’input è X, l’output deve essere Y”. Funziona quando l’output è deterministico e lo conosci in anticipo.

Nel property-based testing, definisci proprietà che devono valere per tutti gli input: “Per qualsiasi input valido, l’output deve soddisfare la condizione Z”. Non specifichi l’output esatto. Specifichi vincoli che l’output deve rispettare.

Per un agente, le proprietà potrebbero essere:

• La risposta deve contenere solo informazioni presenti nei documenti di contesto (no hallucination)
• Se il task richiede un calcolo numerico, il risultato deve essere matematicamente corretto
• La sequenza di tool call deve terminare entro N step
• Ogni tool call deve usare parametri nel formato corretto
• La risposta finale deve essere nella lingua richiesta

Queste proprietà possono essere verificate automaticamente, indipendentemente dalla formulazione specifica dell’output.

In pratica, il test genera input casuali o semi-casuali, esegue l’agente, verifica che le proprietà siano soddisfatte. Se trova una violazione, riduce l’input al caso minimo che causa il fallimento.

Framework come Hypothesis (Python) supportano property-based testing. Per agenti, serve estenderli con proprietà specifiche del dominio e generatori di input che producono scenari realistici.

Un limite di questo approccio: non tutte le proprietà sono formalizzabili in modo verificabile automaticamente. “La risposta è utile” o “il tono è appropriato” richiedono giudizio semantico che le asserzioni booleane non catturano.

LLM-as-Judge: valutazione scalabile

Qui entra il pattern LLM-as-judge: usare un altro modello linguistico per valutare l’output dell’agente sotto test.

Il concetto è semplice. Invece di scrivere asserzioni programmatiche, definisci criteri di valutazione in linguaggio naturale. Un LLM evaluator riceve l’input, l’output dell’agente, i criteri, e produce un giudizio strutturato: score numerici, classificazioni, spiegazioni.

Questo pattern è alla base di diversi framework di evaluation. DeepEval offre metriche predefinite come G-Eval (valutazione generale), faithfulness (aderenza ai fatti), answer relevancy, contextual precision. Opik di Comet fornisce evaluation per workflow agentici multi-step, inclusa qualità del piano, aderenza al piano, efficienza degli step.

LangSmith di LangChain e Langfuse combinano tracing, logging e evaluation, permettendo di ispezionare ogni step dell’agente e valutare sia i componenti che il risultato finale. Databricks Mosaic AI Agent Evaluation integra evaluation con la piattaforma MLOps esistente.

Il vantaggio principale: scala. Puoi valutare migliaia di output senza annotatori umani per ogni caso. Puoi definire criteri complessi in linguaggio naturale invece che in codice.

I limiti sono altrettanto concreti:

Bias dell’evaluator: Il modello valutatore ha i suoi bias. Potrebbe preferire risposte verbose, o penalizzare formulazioni corrette ma non convenzionali. Studi mostrano che gli LLM tendono a preferire le proprie risposte rispetto a quelle di altri modelli.

Costo: Ogni valutazione richiede un’inference del modello evaluator. Su dataset grandi, i costi si accumulano.

Non sostituisce validazione umana: Per decisioni critiche (lancio in produzione, confronto tra approcci), serve comunque un campione validato da umani.

La pratica migliore è usare LLM-as-judge per screening su larga scala e validazione umana su campioni stratificati. Ricerche mostrano che questa combinazione identifica il 60-70% in più di problemi rispetto al testing ad hoc.

Metriche specifiche per agenti

Le metriche generiche di NLP (BLEU, ROUGE, perplexity) non catturano ciò che conta per gli agenti. Servono metriche progettate per valutare comportamenti agentici.

Task completion rate: L’agente ha completato il task assegnato? È la metrica primaria, ma richiede una definizione chiara di “completamento”. Per task oggettivi (estrai il prezzo dal documento) è binaria. Per task aperti (scrivi una email di risposta) richiede valutazione qualitativa.

Tool correctness: Ogni tool call è valida? I parametri sono nel formato corretto? Il tool chiamato è appropriato per lo step corrente?

Tool hallucination: L’agente ha chiamato tool che non esistono? Ha inventato parametri non previsti dall’API?

Plan quality: Il piano generato dall’agente è ragionevole? Copre tutti gli step necessari? È efficiente?

Plan adherence: L’agente ha seguito il piano che ha generato? O ha deviato in modo ingiustificato?

Step efficiency: Quanti step ha richiesto per completare il task? Rispetto a un baseline o a esecuzioni precedenti?

Recovery rate: Quando un tool fallisce o restituisce un errore, l’agente riesce a recuperare? Riprova? Cerca alternative?

Consistency: Dato lo stesso input ripetuto N volte, quanto varia l’output? La varianza è accettabile o indica instabilità?

Queste metriche richiedono strumentazione. Il sistema deve loggare ogni step, ogni tool call, ogni decisione del planner. Senza trace dettagliato, non puoi calcolarle.

Framework come Opik e LangSmith forniscono tracing automatico. Se usi framework custom, devi costruire il logging.

Red teaming: testare la sicurezza prima che lo facciano altri

Il red teaming è la pratica di attaccare deliberatamente il sistema per scoprire vulnerabilità prima che lo facciano attori malevoli. Per gli agenti AI, è particolarmente critico.

OWASP ha pubblicato a dicembre 2025 il Top 10 per applicazioni agentic. Le categorie principali includono:

Prompt injection: Input malevoli che inducono l’agente a ignorare le istruzioni originali o eseguire azioni non autorizzate. Può essere diretto (nell’input utente) o indiretto (nascosto nei dati che l’agente recupera).

Tool misuse: L’agente viene indotto a usare tool in modi non previsti: leggere file sensibili, inviare dati a endpoint esterni, eseguire codice arbitrario.

Memory leakage: Informazioni da sessioni o utenti precedenti che trapelano nelle risposte.

Privilege escalation: L’agente acquisisce permessi superiori a quelli previsti, spesso attraverso catene di tool call.

Il red teaming tradizionale è manuale: esperti di sicurezza tentano di violare il sistema usando creatività e conoscenza del dominio. È efficace ma non scala.

Il red teaming automatizzato usa LLM per generare attacchi. DeepTeam, sviluppato da Confident AI, genera automaticamente prompt di attacco per diverse categorie di vulnerabilità e valuta la robustezza del sistema. PyRIT di Microsoft è un framework open-source per red teaming di sistemi AI, con focus su generazione automatica di attacchi e reporting.

Enkrypt AI offre red teaming as a service con prompt dinamici che evolvono in base alle difese del sistema. Giskard combina red teaming con vulnerability scanning specifico per LLM.

Le best practice per enterprise raccomandano:

• Red teaming prima di ogni release in produzione
• Cadenza trimestrale per sistemi ad alto rischio
• Test aggiuntivi dopo ogni cambio materiale: nuovo modello, nuovo tool, nuova fonte dati
• Mappatura degli attacchi al framework MITRE ATLAS
• Metriche tracciate: vulnerabilità scoperte per test, tempo di remediation, tasso di successo ai re-test

L’EU AI Act richiede red teaming documentato per sistemi ad alto rischio. Non è più opzionale per chi opera in Europa.

Fuzzing: stress-testing ai confini

Il fuzzing è una tecnica classica di security testing: bombardare il sistema con input invalidi, inattesi, casuali, per scoprire bug e vulnerabilità che il testing normale non trova.

Per software tradizionale, il fuzzing cerca crash, memory corruption, behavior indefinito. Per agenti AI, cerca comportamenti indesiderati: risposte dannose, leak di informazioni, violazioni di policy, loop infiniti.

Un survey del 2024 cataloga le tecniche di fuzzing applicate a LLM. I principali approcci:

Black-box fuzzing: Tratti il modello come scatola nera. Generi input, osservi output, iteri. Non richiede accesso ai pesi o all’architettura. Funziona con qualsiasi API.

Grey-box fuzzing: Combini generazione casuale con feedback sulla copertura. Se un input esplora un comportamento nuovo (misurato tramite output o trace), lo tieni come seed per ulteriori mutazioni.

LLM-enhanced fuzzing: Usi un LLM per generare input più intelligenti. Invece di mutazioni casuali, chiedi al modello di generare varianti che potrebbero causare problemi.

ChatFuzz combina fuzzing grey-box con generazione via ChatGPT. Un “chat mutator” prende seed dal pool e chiede a ChatGPT di generare input simili ma diversi. I nuovi input vengono valutati e quelli interessanti diventano nuovi seed.

Fuzz4All usa GPT-4 e StarCoder come motori di generazione e mutazione, permettendo fuzzing su progetti in linguaggi diversi. È stato usato per trovare bug in compilatori e interpreti.

Per agenti, il fuzzing si applica a diversi livelli:

• Input utente: Genera query malformate, ambigue, con caratteri speciali, lunghe, multilingue
• Risposte dei tool: Simula tool che restituiscono errori, timeout, dati malformati, dati malevoli
• Contesto RAG: Inietta documenti con contenuto contraddittorio, injection attempt, formattazione insolita

Il fuzzing è computazionalmente costoso. Ogni run richiede inference del modello. Ma trova classi di bug che altri metodi non scoprono.

Ambienti di test: benchmark e simulazioni

Testare agenti in produzione è rischioso: ogni bug è visibile agli utenti. Testare su dataset statici è insufficiente: non cattura le interazioni dinamiche con tool e ambienti.

La soluzione intermedia sono gli ambienti di simulazione che replicano condizioni realistiche senza conseguenze reali.

AgentBench fornisce 8 ambienti distinti (web browsing, coding, database query) per valutare agenti su task realistici. WebArena simula siti web reali dove gli agenti possono navigare e completare task. SWE-bench valuta agenti su issue GitHub reali, misurando la capacità di risolvere bug in codebase esistenti.

Questi benchmark hanno un problema: sono statici. Una volta che un agente è stato ottimizzato per un benchmark, i risultati non predicono più le performance su casi nuovi.

Il trend è verso benchmark dinamici e continuamente aggiornati. AppWorld e WorkArena++ propongono task che cambiano nel tempo. Il concetto è simile ai dataset di evaluation per code generation che usano problemi di competitive programming: nuovi problemi ogni mese, impossibili da memorizzare.

Per testing interno, la pratica migliore è costruire ambienti che replicano il deployment target:

• Mock dei tool esterni con risposte realistiche (successi, errori, latenza)
• Dataset di input che riflettono la distribuzione di produzione
• Scenari edge case identificati da incident post-mortem
• Versioning degli ambienti di test per reproducibilità

Un ambiente di test ben costruito è un asset che si accumula nel tempo. Ogni bug trovato in produzione diventa un nuovo test case.

Pipeline di evaluation: pre-deploy e post-deploy

L’evaluation non è un evento singolo. È un processo continuo che attraversa tutto il lifecycle.

Pre-deploy (offline):

1. Unit test sui componenti: Il retriever restituisce documenti rilevanti? Il planner genera piani validi? I tool wrapper gestiscono errori?

2. Integration test end-to-end: L’agente completo risolve task rappresentativi? Su un dataset di almeno 500-1000 casi diversi?

3. Property-based testing: Le proprietà invarianti sono rispettate su input generati casualmente?

4. Red teaming: Il sistema resiste agli attacchi noti? Le nuove vulnerabilità sono state testate?

5. Regression testing: Le performance sono uguali o migliori della versione precedente? Nessun degradamento su casi critici?

La soglia per il deploy dovrebbe essere esplicita: task completion rate > X%, zero vulnerabilità critiche, regression test 100% passed.

Post-deploy (online):

1. Sampling: Valuta un campione (1-5%) degli output di produzione. Prioritizza casi flaggati da guardrail o con feedback negativo.

2. Monitoring metriche: Traccia task completion, latenza, error rate, costo per query in tempo reale. Alert su deviazioni.

3. Drift detection: Le performance stanno degradando? La distribuzione degli input sta cambiando?

4. Human review: Revisione periodica di campioni stratificati da annotatori qualificati.

5. Incident analysis: Ogni failure diventa un caso di test. Root cause analysis alimenta il dataset di regression.

L’integrazione con CI/CD è critica. Ogni PR che modifica l’agente dovrebbe triggerare la suite di test offline. Il deploy in produzione dovrebbe essere bloccato se i test non passano.

Il costo del non testare

I numeri parlano chiaro. Il 73% delle organizzazioni cita l’affidabilità come barriera al deploy di agenti. Non la tecnologia, non i costi di inference: l’affidabilità.

La conseguenza è che molti progetti restano in POC indefinitamente. Il team non ha fiducia sufficiente per andare in produzione. Senza metodologie di testing adeguate, quella fiducia è impossibile da costruire.

Chi investe in evaluation rigorosa pre-deploy scopre i problemi prima che li scoprano gli utenti. Chi non lo fa scopre i problemi tramite incident, ticket di supporto, perdita di fiducia.

Il testing di sistemi non-deterministici è più complesso del testing tradizionale. Richiede nuove competenze, nuovi tool, nuovi processi. Ma l’alternativa, deployare senza confidence e scoprire i bug in produzione, è più costosa.

I framework esistono. Le metodologie sono documentate. Il gap è nell’adozione.

Fonti

Confident AI. (2025). LLM Testing in 2025: Top Methods and Strategies.

Databricks. (2025). Announcing Agent Evaluation.

Galileo AI. (2025). Top 12 AI Evaluation Tools for GenAI Systems in 2025.

GitHub. (2025). DeepTeam: Framework to red team LLMs.

Hu, J., Zhang, Q., & Yin, H. (2023). ChatFuzz: Large Language Model Enhanced Fuzzing. arXiv:2305.06498.

OWASP. (2025). Top 10 for Large Language Model Applications v2025.

Skywork AI. (2025). Agentic AI Safety & Guardrails: 2025 Best Practices for Enterprise.

Wang, L., et al. (2024). Large Language Models Based Fuzzing Techniques: A Survey. arXiv:2402.00350.

Zhang, Y., et al. (2025). A Survey on the Evaluation of LLM-based Agents. arXiv:2503.16416.

Il 60% dei manager ammette di aver bisogno di KPI migliori per l’AI. Solo il 34% sta facendo qualcosa. Nel frattempo, i dati che davvero contano esistono già, ma nessuno li sta guardando.

TL;DR: Le aziende misurano attività (ore risparmiate, task automatizzati) invece di impatto. Un paper Stanford su 25 milioni di lavoratori mostra come fare: segmentare per ruolo e seniority, distinguere uso sostitutivo da augmentativo, usare gruppi di controllo, monitorare in tempo reale. Chi adotta questi principi avrà un vantaggio informativo su chi continua a tracciare metriche di vanità.

I report sull’adozione dell’AI nel 2025 raccontano una storia strana. Da un lato, le aziende dichiarano di misurare tutto: deployment completati, ore risparmiate, ticket gestiti, costi ridotti. Dall’altro, il 42% sta abbandonando la maggior parte dei propri progetti AI, più del doppio rispetto all’anno precedente. Il 95% dei progetti pilota, secondo MIT NANDA, non genera alcun impatto misurabile sul conto economico.

Se misuriamo così tanto, perché falliamo così spesso?

Il problema è che stiamo misurando le cose sbagliate. Le metriche tipiche dell’AI enterprise (tempo risparmiato per task, volume di interazioni automatizzate, costo per query) catturano l’attività, non l’impatto. Dicono se il sistema funziona tecnicamente, non se sta creando o distruggendo valore.

Un paper pubblicato ad agosto 2025 dal Digital Economy Lab di Stanford offre un approccio diverso a cosa significhi misurare davvero l’AI. E le implicazioni per chi gestisce investimenti tecnologici sono concrete.

Il problema delle metriche di vanità

La maggior parte delle dashboard AI aziendali traccia varianti delle stesse metriche: quante richieste processate, quanto tempo risparmiato per interazione, quale percentuale di task automatizzati. Sono numeri che crescono facilmente e si presentano bene nelle slide. Il loro difetto è fondamentale: non dicono nulla sull’impatto reale sul business.

Un chatbot che gestisce 10.000 ticket al mese sembra un successo. Ma se quei ticket richiedono comunque escalation umana nel 40% dei casi, se la customer satisfaction è calata, se i clienti più profittevoli stanno migrando ai competitor, il numero di ticket gestiti non cattura nulla di tutto questo.

Il report di S&P Global sul 2025 documenta esattamente questo pattern: aziende che hanno accumulato “deployment” e “sperimentazioni completate” solo per scoprire, mesi dopo, che il ROI non si materializzava. I costi erano reali e immediati; i benefici vaghi e sempre rimandati al prossimo trimestre.

Secondo un’analisi MIT Sloan, il 60% dei manager riconosce di aver bisogno di KPI migliori per l’AI. Ma solo il 34% sta effettivamente usando l’AI per creare nuovi indicatori di performance. La maggioranza continua a usare le stesse metriche che usava per i progetti IT tradizionali, metriche progettate per software deterministico, non per sistemi probabilistici che interagiscono con processi umani complessi.

Cosa significa misurare sul serio

“Canaries in the Coal Mine”, il paper di Erik Brynjolfsson, Bharat Chandar e Ruyu Chen pubblicato dallo Stanford Digital Economy Lab, non parla di come le aziende dovrebbero misurare l’AI. Parla di come l’AI sta cambiando il mercato del lavoro. Ma il metodo che usa è esattamente quello che manca alla maggior parte delle valutazioni enterprise.

Gli autori hanno ottenuto accesso ai dati di payroll di ADP, il più grande processore di buste paga negli Stati Uniti, con record mensili di oltre 25 milioni di lavoratori. Non sondaggi, non self-report, non stime: dati amministrativi granulari su chi viene assunto, chi lascia, quanto guadagna, in quale ruolo, in quale azienda.

Hanno poi incrociato questi dati con due metriche di esposizione all’AI: una basata su analisi teorica dei task (quali mansioni sono tecnicamente automatizzabili) e una basata su dati reali di utilizzo (come le persone usano effettivamente Claude, il modello di Anthropic, nel lavoro quotidiano).

Il risultato è una radiografia dell’impatto dell’AI con una granularità senza precedenti. Non il generico ‘l’AI sta cambiando il lavoro’, ma numeri precisi: l’occupazione per sviluppatori software tra 22 e 25 anni è calata del 20% dal picco di fine 2022, mentre per gli over-35 nelle stesse mansioni è cresciuta dell’8%. Nelle professioni dove l’uso dell’AI è prevalentemente sostitutivo, i giovani perdono occupazione; dove è prevalentemente augmentativo, non c’è declino.

Questo tipo di misurazione dovrebbe informare le decisioni aziendali sull’AI. Non perché le aziende debbano replicare esattamente questo studio, ma perché illustra tre principi che la maggior parte delle metriche enterprise ignora completamente.

Misurare gli effetti differenziali, non le medie

Il dato aggregato nasconde più di quanto riveli. Se misuri solo “ore risparmiate dall’AI”, non vedi chi sta risparmiando quelle ore e chi sta perdendo il lavoro. Se misuri solo “ticket automatizzati”, non vedi quali clienti ricevono servizio peggiore.

Il paper Stanford mostra che l’impatto dell’AI è radicalmente diverso per fasce d’età. I lavoratori tra 22 e 25 anni nelle professioni esposte hanno visto un declino occupazionale del 13% rispetto ai colleghi in ruoli meno esposti. I lavoratori over 30 nelle stesse professioni hanno visto crescita. L’effetto medio è quasi nullo, ma l’effetto reale è una redistribuzione massiva.

Per un CFO, le metriche aggregate di produttività possono mascherare costi nascosti. Se l’AI sta aumentando l’output del team senior mentre rende impossibile assumere e formare junior, il gain di breve periodo potrebbe trasformarsi in un problema di pipeline di talenti nel medio. Il paper lo chiama “paradosso dell’apprendistato”: le aziende smettono di assumere entry-level perché l’AI fa quei task meglio, ma senza entry-level oggi non avranno senior domani.

La conseguenza operativa è che ogni dashboard AI dovrebbe segmentare l’impatto per ruolo, seniority, team, tipologia di cliente. Un singolo numero di “produttività” è quasi sempre fuorviante.

Distinguere uso sostitutivo da uso augmentativo

Una delle scoperte più rilevanti del paper riguarda la differenza tra uso sostitutivo e uso augmentativo dell’AI. Gli autori hanno usato i dati di Anthropic per classificare come le persone usano effettivamente i modelli linguistici: per generare output finali (sostituzione) o per iterare, apprendere, validare (augmentazione).

Nelle professioni dove l’uso è prevalentemente sostitutivo, l’occupazione giovanile è crollata. Dove l’uso è prevalentemente augmentativo, non si osserva alcun declino; anzi, alcune di queste categorie mostrano crescita sopra la media.

Non tutti i “deployment” sono uguali. Un sistema che genera automaticamente report finanziari sostituisce lavoro umano in modo diverso da uno che aiuta gli analisti a esplorare scenari. Le metriche dovrebbero catturare questa distinzione: classificare ogni applicazione AI come prevalentemente sostitutiva o augmentativa, tracciare separatamente l’impatto su headcount, skill mix, capacità di formazione interna. I sistemi augmentativi potrebbero avere ROI meno immediato ma effetti più sostenibili.

Controllare per gli shock esterni

Uno degli aspetti metodologici più sofisticati del paper Stanford è l’uso di effetti fissi impresa-tempo. In pratica, gli autori confrontano lavoratori all’interno della stessa azienda nello stesso mese, isolando così l’effetto dell’esposizione AI da qualsiasi altro fattore che colpisce l’azienda: tagli di budget, rallentamento settoriale, cambi di strategia.

Il risultato: anche controllando per tutti questi fattori, i giovani nelle mansioni esposte all’AI mostrano un declino relativo del 16% rispetto ai colleghi in mansioni non esposte nella stessa azienda.

Questo tipo di rigore è raro nelle valutazioni aziendali. Quando un progetto AI viene lanciato e i costi calano, è facile attribuire il merito all’AI. Ma forse i costi sarebbero calati comunque per fattori stagionali. Forse il team stava già ottimizzando prima del lancio. Forse il confronto è con un periodo anomalo.

La soluzione è definire baseline e gruppi di controllo prima del lancio. Non confrontare “prima vs dopo” ma “trattati vs non trattati” nello stesso periodo. Usare A/B test dove possibile, o almeno confronti con team, regioni o segmenti che non hanno adottato l’AI.

Verso dashboard economici ad alta frequenza

Nelle sue previsioni per il 2026, Brynjolfsson ha proposto l’idea di “AI economic dashboards”, strumenti che tracciano in tempo quasi reale l’impatto dell’AI sull’economia, aggiornati mensilmente invece che con i ritardi tipici delle statistiche ufficiali.

È una proposta ambiziosa a livello macro. Ma la logica sottostante è applicabile a livello aziendale: smettere di aspettare report trimestrali per capire se l’AI sta funzionando e costruire invece sistemi di monitoraggio continuo che catturano gli effetti man mano che si manifestano.

La maggior parte dei progetti AI viene valutata come un investimento tradizionale: business case ex-ante, review periodiche, post-mortem finale. Ma l’AI non si comporta come un asset tradizionale. I suoi effetti sono distribuiti, emergenti, spesso inattesi. Un sistema di monitoraggio continuo può catturare derive prima che diventino problemi.

In pratica, questo significa lavorare con dati in tempo reale invece che retrospettivi. Se il sistema di payroll può dirvi oggi quante persone sono state assunte ieri in ogni ruolo, potete tracciare l’effetto dell’AI sull’organico con lag di giorni, non mesi. Lo stesso vale per ticket gestiti, vendite chiuse, errori rilevati.

Un altro principio chiave: privilegiare metriche leading rispetto a quelle lagging. Il tasso di utilizzo effettivo (quanti dipendenti usano davvero lo strumento AI ogni giorno) è un indicatore anticipatore. Se cala, ci sono problemi prima che si vedano nei numeri di produttività.

Come il paper Stanford segmenta per età, le dashboard aziendali dovrebbero segmentare per ruolo, tenure, performance pregressa. L’AI potrebbe aiutare i top performer mentre danneggia gli altri, o viceversa.

Servono anche confronti interni: team che hanno adottato l’AI vs team che non l’hanno fatto, periodi con feature attiva vs periodi con feature disattivata. Questi confronti sono più informativi dei trend temporali puri.

Il costo del non misurare

C’è un argomento economico diretto per investire in misurazione migliore. Il 42% delle aziende che ha abbandonato progetti AI nel 2025 ha speso budget, tempo, attenzione manageriale per poi non ottenere nulla. Con metriche migliori, alcuni di quei progetti sarebbero stati fermati prima. Altri sarebbero stati corretti in corsa. Altri ancora non sarebbero mai partiti.

Il report MIT NANDA stima che le aziende stiano spendendo 30-40 miliardi di dollari all’anno in AI generativa. Se il 95% non genera ROI misurabile, stiamo parlando di decine di miliardi bruciati. Non perché la tecnologia non funzioni, ma perché viene applicata male, misurata peggio, e quindi non corretta.

Il paper Brynjolfsson offre un modello di cosa potrebbe essere la misurazione dell’AI. Dati amministrativi invece di sondaggi. Granularità demografica invece di medie aggregate. Controlli rigorosi invece di confronti ingenui. Monitoraggio continuo invece di valutazioni puntuali.

Nessuna azienda ha le risorse di Stanford o l’accesso ai dati di ADP. Ma i principi sono trasferibili: segmentare, distinguere uso sostitutivo da uso augmentativo, controllare per fattori confondenti, monitorare in tempo reale. Chi adotta questi principi avrà un vantaggio informativo su chi continua a tracciare deployment e ore risparmiate.

Fonti

Brynjolfsson, E., Chandar, B., & Chen, R. (2025). Canaries in the Coal Mine: Six Facts about the Recent Employment Effects of AI. Stanford Digital Economy Lab.

Deloitte AI Institute. (2025). State of Generative AI in the Enterprise. Deloitte.

MIT Project NANDA. (2025). The GenAI Divide 2025. Massachusetts Institute of Technology.

MIT Sloan Management Review. (2024). The Future of Strategic Measurement: Enhancing KPIs With AI. MIT Sloan.

S&P Global Market Intelligence. (2025, October). Generative AI Shows Rapid Growth but Yields Mixed Results. S&P Global.

Tre mesi dopo, Marco se n’è andato. È arrivato Luca. Il team non funziona ancora.

La scena si ripete perché la diagnosi è sbagliata. Non sbagliata in modo ovvio — sbagliata in modo plausibile, che è peggio. “Marco non è motivato” suona ragionevole. Tutti annuiscono. Peccato che il problema non sia Marco.

La psicologia sociale ha un nome per questo: fundamental attribution error. Ross lo ha descritto nel 1977: quando osserviamo un comportamento, tendiamo ad attribuirlo a tratti della persona (pigrizia, scarsa collaboratività) sottovalutando il peso della situazione in cui quella persona si trova.

J. Richard Hackman ha studiato team per quarant’anni: equipaggi di volo, orchestre, squadre di intelligence. Il punto fermo della sua ricerca: le condizioni strutturali in cui un team opera spiegano fino all’80% della varianza nella sua efficacia (Wageman, Hackman & Lehman, 2005). Quando un team non funziona, il problema più probabile non è chi ci lavora dentro. È come è stato progettato.

Prima di cambiare le persone, conviene verificare le condizioni.

Le cinque condizioni: una checklist, non una teoria

Hackman non ha prodotto un modello astratto. Ha prodotto una checklist. Cinque condizioni che, se presenti, rendono probabile che un team funzioni. Se assenti, rendono probabile il contrario. Le ha validate empiricamente su centinaia di team in contesti diversi, e funzionano come strumento diagnostico molto prima che come teoria.

Le riassumo con una traduzione rapida nel contesto software. Chi vuole il quadro completo può partire dal pezzo precedente su Hackman e la distinzione team/gruppo di lavoro.

1. Essere un team reale. Confini chiari, composizione stabile, interdipendenza reale. Se manca anche solo una di queste tre, non hai un team. Hai un gruppo di persone con un manager in comune.

2. Una direzione convincente. Un obiettivo chiaro, sfidante e significativo. Non “chiudere le story dello sprint”, che è un’unità di misura, non una direzione. Una direzione convincente risponde alla domanda: perché questo lavoro conta?

3. Una struttura abilitante. Ruoli, norme, competenze. Il minimo di infrastruttura perché le persone non debbano rinegoziare tutto da zero ogni settimana.

4. Un contesto organizzativo che supporta. Il team ha le informazioni che gli servono? Le risorse? Il sistema di reward incentiva il risultato di gruppo o la performance individuale? Questa è la condizione che il team non può darsi da solo. Dipende dall’organizzazione intorno.

5. Un coaching competente sul processo. Non mentoring tecnico: qualcuno che aiuta il team a lavorare meglio insieme. Come prendono decisioni, come gestiscono i disaccordi, come distribuiscono il lavoro. È la condizione che conta meno delle altre quattro (il 10% del 60/30/10 di Hackman), ma è quella su cui tutti si concentrano.

L’istinto di chi gestisce team è partire dal fondo: coaching, facilitazione, dinamiche interpersonali. Hackman dice: parti dall’alto.

La tabella che ribalta la diagnosi

Ecco il nucleo del discorso. Sei frasi che sento ripetere in continuazione, e per ciascuna la diagnosi abituale, la causa strutturale più probabile, e dove conviene guardare.

Alcune di queste mappature sono ancorabili direttamente alla ricerca di Hackman. Altre sono la mia traduzione nel contesto software, e le segnalo.

“Marco non è motivato”

È un problema di Marco, si dice. Manca di drive, di ownership, forse non è la persona giusta per il ruolo.

Più probabilmente manca una direzione convincente (condizione 2). Se l’obiettivo del team è vago, puramente gestionale o cambia ogni due settimane, la motivazione non è un tratto di Marco. È una risposta razionale a un contesto che non dà ragioni per investire energia. Ho visto sviluppatori brillanti sembrare svogliati perché il mandato del loro team era “supportare il prodotto”, che in pratica significava rispondere a ticket senza fine e senza una visione di dove si stava andando.

Non guardare a Marco. Guarda al mandato del team. Se non riesci a spiegare in una frase perché quel lavoro conta, il problema è lì.

“Sara non comunica”

Dove guardare, in questo caso, è al design del lavoro. Se ogni persona lavora su una feature separata e le interazioni si limitano a qualche commento su una pull request, non c’è motivo strutturale per comunicare di più. Sara non è poco collaborativa. È razionale: perché dovrebbe aggiornare gli altri su un lavoro che non li riguarda?

La causa è la mancanza di interdipendenza reale (condizione 1). Puoi organizzare tutti i workshop di comunicazione che vuoi: se la struttura del lavoro non genera dipendenze reciproche, la comunicazione resterà un rituale vuoto.

“Il team non si fida”

La reazione classica: team building, esercizi di vulnerabilità, un offsite per conoscersi meglio.

La fiducia in un team non nasce da un workshop di un pomeriggio. Nasce dal lavorare insieme abbastanza a lungo da poter prevedere come si comporterà l’altro. Hackman lo ha visto con gli equipaggi di volo: quelli che volavano insieme da tempo commettevano meno errori di quelli appena formati, anche con piloti meno esperti. Il problema più probabile è la composizione instabile (condizione 1). Se ogni trimestre ruoti le persone tra team, riparti da zero ogni volta.

Quante volte è cambiata la composizione nell’ultimo anno? Se la risposta è “spesso”, il deficit di fiducia non è un problema relazionale. È turnover strutturale.

“Le retro non producono nulla”

Qui la domanda viene prima della risposta: c’è un processo condiviso da migliorare? Le retrospettive presuppongono un team che collabora su un risultato comune e vuole migliorare il modo in cui lo fa. Se ognuno ha il suo flusso, le sue priorità e i suoi blocchi, la retro non ha un oggetto. Il formato non c’entra. La causa è che il gruppo non è un team reale (condizione 1).

“Il lead non riesce a guidare il team”

La diagnosi abituale: mancano le soft skill. Mandiamolo a un corso di leadership.

Il lead può essere bravissimo, ma se il team non ha accesso alle informazioni che gli servono, se le risorse vengono tagliate senza preavviso, se il sistema di valutazione premia la performance individuale e ignora quella di gruppo, il lead è in una posizione impossibile. È come chiedere a un pilota di atterrare bene con un aereo progettato male — puoi mandarlo a tutti i corsi di volo che vuoi, ma se i flap non funzionano, il problema non è la sua tecnica.

La causa è il contesto organizzativo (condizione 4). Il lead ha l’autorità per prendere decisioni? Le priorità sono stabili abbastanza da permettere un piano? Se no, la leva è nell’organizzazione, non nella persona.

“Troppi conflitti”

Qui la risposta è meno lineare. Il conflitto in un team può essere un buon segno: se il team è reale e sta negoziando le norme su come lavorare insieme (condizione 3), un certo grado di attrito è fisiologico. Hackman lo dice chiaramente: i team migliori non sono quelli senza conflitti, sono quelli che hanno imparato a gestirli.

Ma il conflitto può anche essere il sintomo di confini poco chiari (condizione 1): chi decide cosa? Chi ha autorità su quale parte del sistema? Se due persone pensano entrambe di essere responsabili della stessa area, il conflitto non è relazionale. È strutturale.

La distinzione utile: se il conflitto è su come fare le cose, probabilmente è sano. Se è su chi dovrebbe fare cosa, è un problema di confini. E se è cronico nonostante le buone intenzioni di tutti, quasi certamente non è un problema di persone.

Perché continuiamo a sbagliare diagnosi

Se le condizioni strutturali contano così tanto, perché il default è sempre “colpa di qualcuno”?

La prima ragione è che la struttura è invisibile. Le persone le vedi. I comportamenti li vedi. Le condizioni in cui quei comportamenti emergono, no. Hackman ha insistito su questo punto nell’ultimo paper della sua carriera, “From causes to conditions” (Hackman, 2012): la ricerca sui team si è concentrata troppo sulle cause interne (chi fa cosa, come si comportano) e troppo poco sulle condizioni esterne (come il team è progettato, in che contesto opera). Lo stesso vale per chi gestisce team nella pratica.

La seconda è che cambiare le persone sembra più facile. Dare un feedback a Marco, mandare Sara a un workshop, sostituire il lead: sono tutte azioni che un manager può fare domani mattina. Ridisegnare il mandato del team, stabilizzare la composizione, cambiare il sistema di incentivi richiedono tempo, autorità e spesso negoziazione con chi sta sopra. La diagnosi interpersonale è attraente perché ha soluzioni a portata di mano. Peccato che siano le soluzioni sbagliate.

La terza è più insidiosa, e l’ho vista da vicino: l’organizzazione incentiva la diagnosi individuale. Le performance review valutano le persone, non le condizioni. I PIP si applicano alle persone. Il “fit culturale” è un attributo delle persone. L’intero apparato di gestione è costruito attorno all’idea che la performance sia un tratto individuale. Ammettere che il problema è strutturale significa ammettere che il sistema è progettato male, e chi ha progettato il sistema è spesso chi sta facendo la diagnosi.

La prossima volta che qualcuno dice “il problema è Marco”, fermati un momento. Non perché Marco sia necessariamente innocente: a volte il problema è davvero la persona. Ma è meno frequente di quanto pensiamo, e la diagnosi interpersonale è così intuitiva che ci arriviamo sempre per prima.

Prova a riformulare. Non “chi non funziona?” ma “cosa nella struttura non funziona?”. Passa dalla persona alla condizione. Poi chiediti: questa condizione è sotto il mio controllo? Se sì, è lì che va l’energia. Se no, almeno sai che nessun workshop di team building la risolverà.

Non è una differenza da poco. È la differenza tra debuggare il codice e debuggare il compilatore.

Fonti

• Hackman, J.R. (2002). Leading Teams: Setting the Stage for Great Performances. Harvard Business School Press.
• Hackman, J.R. (2011). Collaborative Intelligence: Using Teams to Solve Hard Problems. Berrett-Koehler.
• Hackman, J.R. (2012). From causes to conditions in group research. Journal of Organizational Behavior, 33, 428-444.
• Wageman, R., Hackman, J.R. & Lehman, E.V. (2005). Team Diagnostic Survey: Development of an Instrument. Journal of Applied Behavioral Science, 41(4), 373-398.
• Ross, L. (1977). The intuitive psychologist and his shortcomings: Distortions in the attribution process. In L. Berkowitz (Ed.), Advances in Experimental Social Psychology (Vol. 10, pp. 173-220). Academic Press.

Se ti riconosci, non sei solo. Il 17th State of Agile Report di Digital.ai (2024) riporta che solo l’11% dei praticanti si dichiara “molto soddisfatto” delle pratiche Agile nella propria organizzazione. La frustrazione è così diffusa che due firmatari del Manifesto Agile originale hanno preso posizioni pubbliche contro ciò che Agile è diventato: Ron Jeffries, co-creatore di Extreme Programming, ha scritto che gli sviluppatori dovrebbero abbandonare Agile, o almeno la versione che le organizzazioni ne hanno fatto. Dave Thomas, un altro firmatario, ha dichiarato che Agile è morto, svuotato di significato dal marketing e dalla certificazione di massa.

La diagnosi più comune è che Agile sia diventato burocrazia: troppi rituali, troppo processo, troppo poco codice. Ha senso. Chi non l’ha pensato almeno una volta, uscendo dall’ennesimo planning infinito?

Ma c’è un’altra possibilità. Una che non ha a che fare con Agile in sé, ma con qualcosa di più basilare: la struttura su cui lo stai applicando.

J. Richard Hackman ha passato 40 anni a studiare team reali: equipaggi di volo, orchestre, team di intelligence, squadre chirurgiche. La sua ricerca, condensata in Leading Teams (2002) e Collaborative Intelligence (2011), arriva a una distinzione che nel mondo software quasi nessuno fa: quella tra un team e un gruppo di lavoro. Sono cose diverse. Funzionano in modi diversi. E richiedono strumenti diversi.

Le pratiche Agile sono progettate per team. Se le applichi a un gruppo di lavoro, il risultato è esattamente la frustrazione che stai provando. Il problema non è il metodo. È un mismatch strutturale.

La parola più abusata nel software

Nel mondo del software “team” è la parola predefinita per qualsiasi gruppo di persone che lavora nello stesso progetto. Cinque sviluppatori che condividono una board Jira? Team. Due backend, un frontend e un designer che riportano allo stesso manager? Team. Otto persone sparse su tre fusi orari che si vedono allo standup delle 9? Team.

Hackman non sarebbe d’accordo. In Leading Teams definisce un “real team” attraverso tre proprietà minime, tutte necessarie.

La prima è avere confini chiari: tutti sanno chi fa parte del team e chi no. Sembra banale, ma nella pratica software non lo è. Il designer “condiviso” tra tre team è dentro o fuori? Lo sviluppatore “in prestito” per due sprint, è un membro? Se non riesci a fare una lista senza esitare, i confini non sono chiari.

La seconda è una composizione stabile. Le persone restano le stesse abbastanza a lungo da sviluppare modi di lavorare condivisi. Hackman studiava equipaggi di volo: i dati della NASA, che lui riporta in Leading Teams, mostravano che gli equipaggi appena formati commettevano più errori di quelli che volavano insieme da tempo, anche con piloti meno esperti. Nel software, la rotazione trimestrale delle persone tra team distrugge questo effetto. Ogni volta si ricomincia da zero.

La terza, e la più sottovalutata, è l’interdipendenza reale. Il risultato del team dipende dalla collaborazione tra i membri, non è la somma di contributi individuali. Questo è il punto dove la maggior parte dei “team” software crolla. Cinque sviluppatori che lavorano su cinque feature indipendenti, con cinque code review incrociate per formalità, non sono interdipendenti. Il lavoro di uno non cambia il lavoro dell’altro. Se togliessi tutte le riunioni e li mettessi in stanze separate, il risultato sarebbe lo stesso.

Il test è brutale nella sua semplicità: se domani eliminassi standup, retro e planning, e ognuno lavorasse per conto suo, il prodotto finale peggiorerebbe? Se la risposta è no, se il risultato sarebbe identico, magari persino più veloce senza le interruzioni, allora quello che hai non è un team. È un gruppo di individui con un manager in comune.

Non è un insulto. È una diagnosi. E la diagnosi è il primo passo per smettere di applicare gli strumenti sbagliati.

Le condizioni strutturali: il 60/30/10

Hackman non si è fermato alla definizione. Ha studiato cosa rende un team efficace, e la risposta è meno intuitiva di quanto sembri.

La ricerca di Hackman e della sua collaboratrice Ruth Wageman identifica cinque condizioni che abilitano la performance di un team: essere un team reale, avere una direzione convincente, una struttura abilitante, un contesto organizzativo di supporto e un coaching competente. Non le approfondisco tutte qui, ognuna meriterebbe un articolo a sé. Il punto rilevante è un altro: quanto contano queste condizioni rispetto a quello che un leader fa giorno per giorno?

La risposta di Hackman, formulata in Collaborative Intelligence (2011), è il 60/30/10: il 60% dell’efficacia di un team dipende dal design, le condizioni strutturali messe in piedi prima che il team cominci a lavorare. Il 30% dipende dal lancio: come il team viene avviato, i primi giorni, le norme iniziali. Il restante 10% dal coaching in corso d’opera.

Una precisazione: Hackman presenta questa ripartizione come una “best estimate”, non come il risultato di un singolo studio con quelle percentuali esatte. È un’euristica che sintetizza decenni di ricerca. Non un dato puntuale.

Ma l’ordine di grandezza ha un ancoraggio empirico solido. Il Team Diagnostic Survey (TDS), sviluppato da Wageman, Hackman e Lehman e pubblicato nel 2005, è stato somministrato a 2.474 persone in 321 team. Il risultato: le condizioni strutturali spiegano fino all’80% della varianza nell’efficacia dei team (Wageman, Hackman & Lehman, 2005). Non il 20%, non il 50%. L’80%.

Uno studio precedente di Wageman (2001) su 43 team autogestiti a Xerox aveva già mostrato lo stesso pattern: le attività di design del leader influenzavano la performance del team. Le attività di coaching quotidiano, no.

L’implicazione per chi lavora nel software è diretta. Quando un team non funziona, la reazione istintiva è lavorare sulle dinamiche: facilitare meglio le retro, migliorare la comunicazione, fare team building. Il framework di Hackman suggerisce che la leva più potente è a monte. Chi fa parte del team? Qual è il mandato? Come è disegnato il lavoro? Il contesto organizzativo lo supporta? Se queste condizioni non ci sono, nessuna quantità di facilitazione compenserà.

Ma la prima di quelle cinque condizioni, “essere un team reale”, apre una domanda che nel software quasi nessuno si pone.

Team o gruppo di lavoro: la distinzione che cambia tutto

Va chiarito un punto che Hackman ripete spesso e che viene frainteso altrettanto spesso: la distinzione tra team e gruppo di lavoro non è un giudizio di valore. Non è “team = bene, gruppo di lavoro = male”. Sono due modalità organizzative diverse, ognuna con i suoi vantaggi.

Un gruppo di lavoro è un insieme di persone che riportano allo stesso manager e possono coordinarsi, ma il cui output è principalmente individuale. Ognuno ha i suoi obiettivi, le sue responsabilità, i suoi deliverable. Il manager coordina, assegna, rimuove ostacoli. Non c’è bisogno di interdipendenza profonda.

Un team produce un output collettivo. Il risultato non è scomponibile nella somma dei contributi individuali: richiede collaborazione continua, decisioni condivise, aggiustamento reciproco. Il costo è più alto, servono confini stabili, norme condivise, tempo per sviluppare modi di lavorare insieme. Ma per certi tipi di problemi, è l’unica configurazione che funziona.

Il danno nasce quando confondi le due cose.

Un gruppo di lavoro gestito come team genera overhead senza beneficio. Le riunioni di coordinamento esistono, ma non c’è nulla di sostanziale da coordinare. Le retrospettive non producono azioni perché non c’è un processo condiviso da migliorare: ognuno ha il suo flusso, le sue priorità, i suoi blocchi. Il cerimoniale Agile diventa un costo fisso su un’attività che non lo richiede.

Il danno, però, è bidirezionale. Un team reale gestito come un gruppo di lavoro è altrettanto disfunzionale. Se hai persone che devono collaborare su un problema complesso e le tratti come contributori individuali, assegnando task separati, valutandoli singolarmente, senza proteggere il tempo per il lavoro congiunto, stai sabotando l’unica cosa che rende quel team efficace: l’interdipendenza.

Ho visto entrambi gli scenari. Il primo è più comune nel software, perché l’organizzazione predefinita tende ad essere il gruppo di lavoro (sviluppatori assegnati a feature individuali), ma l’infrastruttura di processo è quasi sempre quella del team (Scrum, Kanban con standup, retro, planning).

La domanda operativa non è “come migliorare il mio team?”. È più basilare: quello che guido, è un team o un gruppo di lavoro? La risposta cambia tutto ciò che viene dopo.

Il mismatch Agile: strumenti giusti, struttura sbagliata

Torniamo alla frustrazione di partenza. Le pratiche Agile, Scrum in particolare, non sono nate nel vuoto. Sono progettate attorno a un’assunzione precisa: che un piccolo gruppo di persone lavori in modo interdipendente su un obiettivo condiviso, iterando insieme. Lo sprint presuppone un goal comune. Lo standup presuppone che sapere cosa fanno gli altri cambi il tuo lavoro. La retro presuppone un processo condiviso da ispezionare. Il planning presuppone decisioni collettive sulla priorità.

Sono tutti strumenti che presuppongono interdipendenza. Senza, perdono senso.

Ora guarda la configurazione tipica di un “team” di sviluppo in molte organizzazioni. Le persone vengono assegnate, spesso ruotate, a un “team” che è in realtà un contenitore organizzativo. Ognuno lavora sulla propria user story, con interazioni limitate al code review e a qualche domanda su Slack. Il “goal dello sprint” è la somma delle story individuali. L’interdipendenza è minima o assente.

Se applichi strumenti da team a questa struttura, il risultato è prevedibile. Lo standup diventa un giro di aggiornamenti che nessuno ascolta. La retro produce lamenti generici. Il planning diventa burocrazia. Non perché Scrum sia burocrazia, ma perché lo stai usando su una struttura per cui non è progettato.

I firmatari del Manifesto lo dicono, anche se con parole diverse. Jeffries parla di “Dark Scrum”, organizzazioni che usano i rituali Agile come strumenti di controllo, svuotandoli di collaborazione. Thomas dice che “Agile” è stato trasformato in un sostantivo commerciale, quando era pensato come un aggettivo che descrive un modo di lavorare. La loro critica è legittima. Ma la diagnosi che propongono, “le organizzazioni hanno corrotto Agile”, è incompleta. Il framework di Hackman ne offre una più strutturale: molte organizzazioni non hanno corrotto Agile. Lo hanno applicato a strutture che non sono team.

Ne parlo perché l’ho visto accadere più volte di quante vorrei ammettere, anche in contesti con persone competenti e buone intenzioni. La risposta standard al malessere era sempre la stessa: cambiamo facilitatore, proviamo un altro formato di retro, aggiungiamo una cerimonia. Il framework di Hackman mi ha dato un vocabolario per dire quello che sentivo ma non riuscivo a formulare: il problema non era l’esecuzione. Era la premessa.

Questo cambia la diagnosi e le soluzioni. Se il problema è “Agile è diventato burocrazia”, la risposta è meno processo, meno rituali, più autonomia. A volte è giusto. Ma se il problema è un mismatch strutturale, la risposta è diversa: o trasformi la struttura in un team reale, con i costi che questo comporta, o accetti che hai un gruppo di lavoro e adotti strumenti coerenti con quella realtà. Entrambe le opzioni sono legittime. Quello che non funziona è restare nel mezzo.

Riprendiamo lo standup di dodici minuti da cui siamo partiti. Cinque persone, cinque aggiornamenti, nessuna interazione. La diagnosi ovvia è che lo standup sia mal facilitato, o che Scrum non funzioni, o che il team abbia bisogno di “lavorare sulla comunicazione”. Sono tutte risposte che agiscono sul sintomo.

La domanda di Hackman è diversa, e viene prima: quelle cinque persone hanno bisogno di parlarsi ogni mattina per fare il loro lavoro? Se il lavoro di ciascuno non dipende dagli altri, lo standup non è mal facilitato. È inutile per design. E la retro non produce azioni perché non c’è un processo condiviso da migliorare. E il planning è burocrazia perché non ci sono decisioni collettive da prendere.

Non è una questione di esecuzione. È una questione di struttura.

La prossima volta che pensi “Agile non funziona”, prova a riformulare. Non chiederti come migliorare il processo. Chiediti se quello che guidi è un team o un gruppo di lavoro. La risposta non è un giudizio. È una diagnosi. E dalla diagnosi dipende tutto il resto.

Fonti

• Hackman, J.R. (2002). Leading Teams: Setting the Stage for Great Performances. Harvard Business School Press.
• Hackman, J.R. (2011). Collaborative Intelligence: Using Teams to Solve Hard Problems. Berrett-Koehler.
• Wageman, R. (2001). How Leaders Foster Self-Managing Team Effectiveness: Design Choices Versus Hands-on Coaching. Organization Science, 12(5), 559-577.
• Wageman, R., Hackman, J.R. & Lehman, E.V. (2005). Team Diagnostic Survey: Development of an Instrument. Journal of Applied Behavioral Science, 41(4), 373-398.
• Digital.ai (2024). 17th State of Agile Report.
• Jeffries, R. (2018). Developers Should Abandon Agile.
• Thomas, D. (2014). Agile is Dead (Long Live Agility).

Le aziende non assumono junior perché l’AI svolge i loro task meglio. E tra dieci anni, chi guiderà i team?

Nei report trimestrali non trovi mai questa domanda. La butto lì: se smettiamo di assumere chi sta imparando, chi diavolo saprà fare questo lavoro tra un decennio?

I numeri raccontano qualcosa che dovrebbe far venire i brividi a chiunque gestisca team tecnici. L’occupazione per sviluppatori software tra i 22 e i 25 anni è calata del 20% dal picco di fine 2022. Il dato viene da un paper del Digital Economy Lab di Stanford, basato su payroll di 25 milioni di lavoratori. E non è un calo uniforme, anzi: nello stesso periodo gli over-35 nelle stesse mansioni sono cresciuti dell’8%.

Potremmo chiamarlo paradosso dell’apprendistato, questo meccanismo. Le aziende smettono di assumere entry-level perché l’AI svolge quei task meglio. Peccato che senza entry-level oggi, senior domani non ne avrai.

Numeri, non impressioni

La contrazione è documentata da fonti multiple e indipendenti, non è una sensazione.

Le assunzioni entry-level nelle 15 maggiori aziende tech sono calate del 25% tra il 2023 e il 2024, secondo SignalFire. L’età media delle assunzioni tecniche dal 2021 è aumentata di tre anni. Le aziende non stanno solo assumendo meno, stanno assumendo diversamente. Vogliono gente produttiva dal giorno uno.

I tirocini tech crollati del 30% dal 2023, secondo Handshake. Le candidature aumentate del 7%. Più gente che si sbatte per meno posti, e quei posti che restano chiedono sempre più esperienza.

Uno studio Harvard su 285.000 aziende americane ha trovato che quando le imprese adottano AI generativa, l’occupazione junior cala del 9-10% entro sei trimestri. I senior restano stabili. Non sono licenziamenti di massa, è un congelamento silenzioso: le aziende semplicemente smettono di aprire posizioni entry-level.

In Europa stesso schema. Posizioni junior nel tech giù del 35% nei principali paesi EU durante il 2024, dati aggregati da LinkedIn, Indeed, Eures. In UK le Big Four della consulenza hanno tagliato le assunzioni di neolaureati tra il 6% e il 29% in due anni. India: le aziende IT hanno ridotto i ruoli entry-level del 20-25%, report EY.

Il World Economic Forum nel Future of Jobs Report 2025 avverte che il 40% dei datori di lavoro prevede di ridurre personale dove l’AI può automatizzare i task. E i task automatizzabili sono, quasi per definizione, quelli che facevano i junior.

Il ragionamento ha senso. Nel breve periodo.

Devo ammetterlo, la logica dietro queste scelte è comprensibile.

Un senior engineer con strumenti AI può fare quello che prima richiedeva due o tre junior, almeno per certi task. GitHub Copilot, Cursor e simili promettono aumenti di produttività del 20-50% secondo i vendor (certo, c’è il marketing, ma anche scontandolo qualcosa resta). Per un CFO che guarda al prossimo trimestre, assumere un junior che richiederà sei mesi di formazione prima di essere produttivo sembra difficile da giustificare.

James O’Brien, professore di computer science a Berkeley che lavora con startup, descrive il cambio: “Prima, le startup assumevano una persona senior e due o tre coder early-career per assisterla. Ora chiedono: perché assumere un neolaureato quando l’AI è più economica e veloce?”

Domanda ragionevole, nel breve.

Il codice generato dall’AI non è di prima qualità, ma neanche quello scritto da un neolaureato, diciamocelo. La differenza, nota O’Brien, è che il processo iterativo per migliorare il codice AI richiede minuti. Un junior potrebbe impiegare giorni per lo stesso task.

Heather Doshay, head of talent di SignalFire, la mette così: “Nessuno ha pazienza o tempo per il hand-holding in questo nuovo ambiente, dove molto del lavoro può essere fatto autonomamente dall’AI.”

Quello che non appare in nessun bilancio

C’è un difetto in questa logica, e si chiama pipeline di talenti.

Matt Garman, CEO di AWS, lo ha detto chiaro: “Se non hai una pipeline di talenti che stai costruendo, se non hai persone junior che stai mentorando e facendo crescere nell’azienda, spesso scopriamo che è da lì che vengono le idee migliori. Se un’azienda smette di assumere junior e di farli crescere, tutto il sistema alla fine esplode.”

Non è retorica, è matematica demografica applicata alle organizzazioni.

Ogni senior engineer, ogni tech lead, ogni CTO è stato un junior. Il percorso da neolaureato a leader tecnico richiede anni su progetti reali, errori fatti e corretti, feedback ricevuti, pattern che entrano sotto pelle. Non ci sono scorciatoie, su questo.

Faccio un conto brutale: se l’industria smette di assumere junior nel 2023, nel 2033 avrà una carenza strutturale di mid-level. Cinque anni dopo mancheranno i senior. Altri cinque e non ci sarà nessuno da promuovere a ruoli di leadership tecnica.

Questo costo non appare in nessun bilancio trimestrale, ecco il punto. È un debito che si accumula silenziosamente, e quando diventerà evidente sarà troppo tardi per rimediare in fretta.

L’AI che insegna e quella che atrofizza

C’è un’ironia in tutto questo. Gli stessi strumenti AI che stanno eliminando i ruoli junior potrebbero, in teoria, accelerare l’apprendimento. Un tutor AI disponibile 24/7, paziente, che risponde a ogni domanda: il sogno di ogni studente, no?

La realtà è più complicata. E qui i dati sono interessanti, secondo me.

Un esperimento di ricercatori Wharton e Penn su quasi mille studenti di liceo in matematica ha testato due versioni di un tutor basato su GPT-4. Il gruppo con accesso a un’interfaccia tipo ChatGPT standard (GPT Base) ha ottenuto risultati del 48% migliori durante le sessioni di pratica assistita. Il gruppo con un tutor progettato per guidare senza dare risposte dirette (GPT Tutor) ha fatto il 127% meglio.

Ma ecco il punto: quando l’AI è stata tolta e gli studenti hanno fatto l’esame da soli, il gruppo GPT Base ha ottenuto risultati del 17% peggiori rispetto al gruppo di controllo che non aveva mai usato AI. Il gruppo GPT Tutor invece era in linea col controllo.

Gli studenti usavano l’AI come stampella. Performavano meglio con l’assistenza, imparavano meno. Quando l’assistenza spariva, si ritrovavano più indietro di chi non l’aveva mai avuta.

Uno studio del MIT Media Lab ha documentato quello che i ricercatori chiamano “debito cognitivo”: l’uso di LLM per la scrittura sembra ridurre lo sforzo mentale durante il task, ma a costo di un apprendimento più superficiale. La ricercatrice Nataliya Kosmyna lo dice chiaramente: “I cervelli che si stanno sviluppando sono quelli a rischio più alto.”

Non significa che l’AI non possa aiutare l’apprendimento. Lo studio Wharton dimostra che può farlo, se progettata con le giuste salvaguardie. Ma l’AI “selvaggia”, quella che dà risposte invece di guidare verso le risposte, può fare danni.

Chi saranno i junior che passeranno il filtro?

Se le posizioni junior si riducono, chi viene assunto?

I segnali dal mercato sono chiari. Saper programmare non basta più. I datori di lavoro si aspettano che i neolaureati sappiano gestire progetti, comunicare con i clienti, capire il ciclo di vita dello sviluppo software. Il lavoro “grunt” che una volta serviva da palestra viene automatizzato. Chi entra deve essere operativo a un livello più alto quasi dal primo giorno.

Jamie Grant, che gestisce i career services per ingegneria alla University of Pennsylvania, descrive il cambio: “Non stanno necessariamente solo programmando. C’è molto più pensiero di alto livello e conoscenza del ciclo di vita dello sviluppo software.”

David Malan di Harvard, che insegna il corso di introduzione alla programmazione più seguito al mondo, nota che l’impatto maggiore dell’AI è stato sui programmatori, non sui ruoli che ci si aspettava (tipo i call center). La ragione: il lavoro di programmazione è relativamente solitario e altamente strutturato. Perfetto per l’automazione, insomma.

Ma Malan nota anche qualcosa di interessante. Negli Stati Uniti l’occupazione per “programmatori” è calata del 27,5% tra il 2023 e il 2025, ma quella per “software developers”, posizione più orientata al design, è calata solo dello 0,3%. La differenza è nel livello di astrazione. Chi scrive codice è vulnerabile. Chi progetta sistemi lo è meno.

Tre scenari, nessuno inevitabile

Il collasso della pipeline. Le aziende continuano a non assumere junior. Tra cinque, dieci anni la carenza di mid-level diventa acuta. I senior rimasti vengono pagati cifre astronomiche. Le aziende che non possono permetterseli perdono competitività. L’industria si polarizza tra pochi giganti che attraggono talento e tutti gli altri che arrancano.

L’apprendistato reinventato. Alcune aziende capiscono che il problema sta arrivando e investono controcorrente. Creano programmi di formazione intensivi, magari assistiti da AI progettata per insegnare invece che sostituire. Diventano i datori di lavoro preferiti per i talenti migliori, che sanno che lì potranno crescere. Nel lungo periodo hanno un vantaggio competitivo.

La democratizzazione irregolare. L’AI abbassa la barriera d’ingresso per alcune competenze (scrivere codice funzionante) ma la alza per altre (progettare sistemi, debuggare problemi complessi, gestire l’AI stessa). Chi ha accesso a formazione di qualità e mentorship può saltare alcuni gradini. Chi non ce l’ha resta bloccato. La disuguaglianza di opportunità aumenta.

Nessuno di questi scenari è scritto nella pietra. Dipende da scelte che aziende, istituzioni educative e policy maker faranno nei prossimi anni.

Se assumi, qualche domanda da farti

Stai ottimizzando per il prossimo trimestre o per i prossimi dieci anni? Un junior costa di più nel breve periodo, certo. Ma l’alternativa è dipendere interamente dal mercato esterno per il talento, competendo con tutti gli altri che hanno fatto la stessa scelta.

Il tuo team sta ancora insegnando? Se i senior passano tutto il tempo a produrre e nessuno a trasferire conoscenza, stai consumando capitale umano senza rigenerarlo.

Come usi l’AI nella formazione? Se i tuoi junior usano Copilot per avere risposte invece che per imparare a trovarle, stai accelerando la loro produttività a breve termine e compromettendo la loro crescita a lungo termine.

Stai assumendo per le skill di oggi o per l’adattabilità di domani? Le competenze tecniche specifiche hanno una half-life sempre più breve. La capacità di imparare, di ragionare su problemi nuovi, di lavorare con le persone: quelle durano.

Se stai iniziando, qualche considerazione

Il mercato sembra chiuderti le porte, lo so. Ma non tutto il lavoro junior sta sparendo. Sta sparendo quello ripetitivo e isolato. I ruoli che sopravvivono richiedono interazione umana, giudizio su problemi ambigui, creatività applicata a contesti specifici. Quelli sono i ruoli da cercare.

L’AI come strumento, non come stampella. La differenza conta davvero. Chi usa ChatGPT per avere risposte e chi lo usa per esplorare problemi sono due persone diverse: una atrofizza, l’altra cresce.

Il networking conta, probabilmente più di prima. Se le posizioni junior sono poche, la competizione è feroce, e spesso vince chi ha una connessione, non chi ha il CV migliore. Non è giusto, ma è quello che succede.

Le competenze trasversali non sono optional. Comunicare, gestire progetti, capire il business: sono cose che l’AI non sa fare e che i datori di lavoro cercano anche nei profili tecnici.

La domanda resta aperta

Torno alla domanda iniziale: chi saranno i senior di domani?

Non ho una risposta sicura, e a mio avviso nessuno ce l’ha. Stiamo conducendo un esperimento in tempo reale, senza gruppo di controllo, su scala globale.

Quello che so è che ogni senior che conosco è stato un junior che qualcuno ha deciso di assumere e formare. Ogni tech lead ha fatto errori da principiante che qualcuno ha avuto la pazienza di correggere. Ogni architetto di sistema ha scritto codice imbarazzante prima di scrivere codice elegante.

Se eliminiamo quella fase, se la consideriamo un costo da tagliare invece che un investimento da proteggere, non stiamo ottimizzando. Stiamo consumando un capitale che non sappiamo come rigenerare.

La domanda non è se l’AI può sostituire i junior. Può farlo, per molti task. La domanda è se vogliamo un’industria che sa solo consumare competenze o una che sa anche produrle.

Per ora i numeri suggeriscono che abbiamo scelto la prima opzione.

Il conto arriverà. Non nel prossimo trimestre, ma arriverà.

Fonti

Brynjolfsson, E., Chandar, B., & Chen, R. (2025). Canaries in the Coal Mine: Six Facts about the Recent Employment Effects of AI. Stanford Digital Economy Lab.

Bastani, H., Bastani, O., Sungu, A., Ge, H., Kabakcı, Ö., & Mariman, R. (2024). Generative AI Can Harm Learning. The Wharton School Research Paper.

Stack Overflow. (2025, December). AI vs Gen Z: How AI has changed the career pathway for junior developers. Stack Overflow Blog.

IEEE Spectrum. (2025, December). AI Shifts Expectations for Entry Level Jobs.

Rest of World. (2025, December). AI is wiping out entry-level tech jobs, leaving graduates stranded.

Kosmyna, N., et al. (2025). Your Brain on ChatGPT: Accumulation of Cognitive Debt when Using an AI Assistant for Essay Writing Task. arXiv.

World Economic Forum. (2025). Future of Jobs Report 2025.

FinalRound AI. (2025). AWS CEO Shares 3 Solid Reasons Why Companies Shouldn’t Replace Juniors with AI Agents.