reportSylvain Kalache apre il suo post con una scena precisa: un sistema di produzione va in crisi alle tre di notte, l'AI di gestione degli incidenti interviene, identifica il problema, applica la correzione, chiude il ticket. L'ingegnere di turno dorme. La mattina dopo trova un report. Tutto sembra funzionare.
Il punto è quello che succede sei mesi dopo, quando lo stesso sistema va di nuovo in crisi e nessuno nell'organizzazione sa più come funziona davvero.
Kalache, ingegnere con esperienza in ambienti di produzione complessi, sostiene che delegare la gestione degli incidenti all'AI produce un effetto che le aziende tendono a ignorare: gli ingegneri perdono il contatto operativo con i sistemi che nominalmente gestiscono. "La comprensione profonda di un sistema si costruisce attraverso il debug, l'analisi post-mortem, la diagnosi manuale degli errori," scrive. "Quando queste esperienze spariscono, sparisce anche la capacità di intervenire quando l'automazione fallisce."
Quella capacità sparisce in silenzio, senza che nessun indicatore la misuri.
Lo studio pubblicato da Alexander Bick della Federal Reserve di St. Louis, Adam Blandin e David Deming di Vanderbilt e Harvard, e Tyler Schumacher, offre una mappa quantitativa di come gli strumenti di AI generativa entrano nel lavoro reale. I ricercatori hanno costruito i primi indici di adozione dell'AI a livello di singolo task, su un campione rappresentativo della popolazione adulta americana. I dati mostrano che l'adozione avanza per compiti specifici, dentro occupazioni specifiche - non per settori interi. La granularità cambia il modo in cui si può leggere il fenomeno.
Ma la granularità non cattura quello che Kalache descrive: la perdita di competenza che avviene proprio dove l'adozione sembra più efficiente.
Da Cambridge, Paul Osterman, professore emerito di Human Resources and Management al MIT Sloan, descrive una struttura più ampia in cui questo processo si inserisce. Il suo libro "Disposable Workers: The Transformation of Employment" traccia come le aziende abbiano progressivamente esternalizzato il rischio verso i lavoratori, guadagnando flessibilità e cedendo responsabilità. "Le aziende ottengono flessibilità e tagliano i costi mentre si liberano della responsabilità verso i loro lavoratori," scrive Osterman in un'analisi pubblicata su Fast Company.
L'ingegnere che non capisce più il sistema che gestisce è una variante di questa logica: il rischio del de-skilling è del lavoratore, il risparmio operativo è dell'azienda.
Nella Silicon Valley, il movimento è visibile anche dall'interno. Un articolo pubblicato su Jacobin riporta la testimonianza di un ingegnere software il cui team ha adottato un approccio "AI-first". "Ora temo una domanda più di qualsiasi altra, che è diventata un ritornello in ufficio: 'Perché non lo dai a Claude?'" racconta. La domanda arriva davanti a problemi difficili, quelli che richiedono comprensione profonda del sistema. Quelli, cioè, dove la competenza conta di più.
La MIT Sloan Management Review descrive un'ulteriore pressione che si sovrappone a questa: i modelli AI cambiano continuamente, spesso nel giro di settimane. Una vicepresidente di prodotto apre il laptop un lunedì mattina e scopre che il modello su cui il suo team ha lavorato per sei settimane è già stato superato da un'alternativa più economica e veloce. Ancora. L'organizzazione si trova a dover ricostruire le sue pratiche in modo permanente, senza mai stabilizzarsi.
Questa instabilità strutturale rende ancora più costosa la perdita di competenza profonda: in un ambiente che cambia continuamente, la capacità di capire cosa succede sotto la superficie è l'unica risorsa che non si aggiorna da sola.
Sylvain Kalache chiude con una domanda che le organizzazioni tendono a rinviare: chi interviene quando l'automazione fallisce in un modo che l'automazione stessa non riesce a diagnosticare? L'ingegnere che quella notte dormiva non ha la risposta. E il report che ha trovato al mattino non lo aiuta a trovarla.