Catalini: l'IA abbassa il costo di creare, non di verificare

Un messaggio generato in pochi secondi. Un’immagine scelta in un colpo d’occhio. Un test che passa e sblocca il deploy. Qui l’IA vola perché il controllo costa poco. Altrove si inceppa. Christian Catalini lo riassume così: l’IA rende economica la produzione, non la verifica.

Il confine dell’automazione si sposta. Non più tra compiti di routine e non di routine, ma tra ciò che si misura bene e ciò che resiste alla misurazione affidabile. Da qui la traiettoria delle adozioni: chat, immagini, assistenza al codice. Non i problemi più difficili. Quelli con un feedback rapido e chiaro sull’output.

L’utente legge una risposta e valuta tono e utilità. Guarda una variante grafica e decide se va bene. Avvia i test e vede se il codice supera le prove. Il ciclo è breve, il costo di verifica è basso, l’errore si corregge subito. In questi contesti l’IA guadagna spazio senza frizioni.

Martin Fowler lega il punto alla misurazione nel software. Ricorda che contare righe di codice non dice nulla sul valore consegnato. E che confondere un indicatore comodo con una metrica valida porta fuori strada. Molto lavoro efficace richiede feedback lenti o giudizi sottili che non entrano in un numero unico.

Qui nasce il rischio operativo. Team e manager adottano automazioni perché migliorano ciò che vedono sul cruscotto. Ma il cruscotto mostra solo una parte. Nel breve gli indicatori salgono. Nel lungo si accumulano effetti che le metriche non catturano. Se valuti l’IA con proxy parziali, ottimizzi ciò che misuri, non ciò che conta.

L’implicazione è netta. Il vecchio filtro “routine/non routine” non basta più. Conta la qualità della verifica. Dove verificare è rapido, economico e condiviso, l’IA entra prima. Dove il controllo è oneroso o dipende da competenze esperte, l’adozione resta incerta e i rischi crescono.

Per chi guida team, la priorità è proteggere la qualità dalla tirannia dei numeri semplici. Evitare obiettivi misurati solo su quantità. Legare le metriche a esiti che contano per utenti e sistemi, soprattutto quando il feedback arriva tardi. Fowler avverte: gli errori di misurazione emergono nel tempo lungo. I guadagni apparenti possono nascondere debito futuro.

Anche la scelta dei casi d’uso cambia. Conviene partire dove il controllo è facile: chat, immagini, test automatici sul codice. Il ciclo di feedback breve limita l’errore e guida il miglioramento. Altrove, prima di scalare, serve investire nella misurazione: definire esiti valutabili, tempi di feedback, responsabilità della verifica.

Cosa fare domani, da manager? Tre mosse: mappa i flussi distinguendo verifiche rapide da lente; elimina o declassa le metriche fuorvianti (righe di codice, volumi grezzi); per ogni progetto con IA, scrivi a monte come si verifica il valore e quando arriva il feedback. Se non sai come misurare, non scalare.