Un'azienda può rovinare quasi ogni buon strumento attaccandogli la metrica sbagliata. Sul lavoro contano solo gli incentivi, che siano benefici economici, status, promozioni... I lavoratori lavorano per gli incentivi. Anche tu e io. Praticamente tutti fanno le cose perché conviene a loro o ai loro cari. Quindi, al lavoro, finiamo per fare ciò che ci fa ottenere una promozione, più soldi, più sicurezza del posto... Non siamo i proprietari dell'azienda, siamo dipendenti. Pensiamo a noi stessi. E v
"Era un problema che avevamo già risolto": vero, l'abbiamo vissuto premiando chi scriveva più codice. Le codebase crescevano gonfie e fragili, piene di righe scritte per il KPI. Le linee di codice e i token sono lo stesso errore con vestiti diversi. Misur
"Era un problema che avevamo già risolto": vero, l'abbiamo vissuto premiando chi scriveva più codice. Le codebase crescevano gonfie e fragili, piene di righe scritte per il KPI.
Le linee di codice e i token sono lo stesso errore con vestiti diversi. Misuri l'attività perché è visibile, e la gente ti dà attività, non valore.
Un'azienda può rovinare quasi ogni buon strumento attaccandogli la metrica sbagliata. Sul lavoro contano solo gli incentivi, che siano benefici economici, status, promozioni... I lavoratori lavorano per gli incentivi. Anche tu e io. Praticamente tutti fanno le cose perché conviene a loro o ai loro cari. Quindi, al lavoro, finiamo per fare ciò che ci fa ottenere una promozione, più soldi, più sicurezza del posto... Non siamo i proprietari dell'azienda, siamo dipendenti. Pensiamo a noi stessi. E va bene così.
Quando il management comincia a celebrare il consumo di token, il volume di prompt, il numero di agent o l'uso quotidiano dell'IA, le persone ottimizzeranno per l'attività della macchina invece che per i risultati utili. Se il tuo posto è a rischio perché vieni segnalato come uno che si rifiuta di usare l'IA, allora... usi l'IA. Tantissimo, soprattutto quando gli ingegneri vengono premiati per usarla sempre di più. Questo non vuol dire che siano irrazionali. Vuol dire che sono dipendenti. I dipendenti rincorrono ciò che i vertici possono vedere, soprattutto quando ciò che è visibile porta delle ricompense. In questo momento l'attività con l'IA porta tante ricompense
Non è altro che la corruzione dei KPI travestita da nuovo. Le organizzazioni sanno in teoria che, una volta che una metrica diventa un obiettivo, smette di essere una misura pulita, poi dimenticano la regola nel momento in cui la metrica sembra tecnica e proiettata al futuro. L'IA peggiora l'amnesia perché l'attività della macchina è facile da mettere in un grafico e facile di cui vantarsi. L'adozione dell'IA è una di queste.
Il punteggio migliore è più difficile e meno lusinghiero. Immagina un team di supporto che con orgoglio raddoppia il volume di risposte assistite dall'IA. Sembra fantastico, finché non noti che sono aumentate anche le escalation, perché le risposte di primo livello erano superficiali e i supervisori hanno passato più tempo a sistemarle. Una metrica migliore non è "quante risposte IA abbiamo generato?" È "il tempo di prima risposta è migliorato senza che peggiorassero escalation, rilavorazioni o frustrazione del cliente?" Lo stesso vale nell'ingegneria. Bruciare più token non significa nulla se il tempo di review, il tasso di difetti e il rischio di rollback peggiorano tutti. E poi, quanto impatto ha avuto davvero il team di ingegneria?
C'è un'obiezione che vale la pena prendere sul serio. All'inizio di un rollout, le metriche di utilizzo possono contare. Se nessuno tocca lo strumento, non c'è proprio nessuna storia di adozione. D'accordo. Ma le metriche temporanee di sperimentazione hanno la brutta abitudine di diventare metriche di vanità permanenti. Una volta che status e valutazione si agganciano all'attività IA visibile, l'organizzazione comincia a fabbricare attività per alimentare il punteggio.
È così che gli strumenti utili diventano burocrazia. I dipendenti si mettono a fare prompt quando dovrebbero semplicemente decidere da soli. I capi cominciano a chiedere agent plan perché gli agent plan sembrano moderni. I team ottimizzano per la superficie IA misurabile invece che per costo, qualità e consegna reali. L'istituzione ha semplicemente trovato un nuovo modo di sprecare soldi mentre si fa i complimenti da sola.
Era un problema che avevamo già risolto. Una volta il management premiava gli ingegneri perché scrivessero più codice. Così le codebase finivano per crescere a dismisura e diventare fragili e gonfie. Quella metrica semplificata aveva già mostrato come non si possano mettere in piedi metriche semplici per la performance e aspettarsi buoni risultati. Appena le metti, le persone ottimizzano per quelle. E va bene così, lo faccio anch'io.
Aggiungo la parte scomoda: ottimizzare per la superficie IA misurabile spinge fuori il lavoro che conta ma non si conta. Decidere da soli invece di fare prompt, rivedere bene invece di generare in fretta. Tutto questo diventa invisibile, quindi penalizzato, mentre l'attività IA visibile viene premiata. È la solita inversione: il visibile mangia l'utile.
"Era un problema che avevamo già risolto": vero, l'abbiamo vissuto premiando chi scriveva più codice. Le codebase crescevano gonfie e fragili, piene di righe scritte per il KPI.
Le linee di codice e i token sono lo stesso errore con vestiti diversi. Misuri l'attività perché è visibile, e la gente ti dà attività, non valore.
È legge di Goodhart pura: quando una metrica diventa obiettivo, smette di essere una misura pulita. Lo sappiamo in teoria e lo dimentichiamo appena la metrica sembra tecnica e proiettata al futuro.
Il consumo di token è facile da mettere in grafico e da vantare, quindi diventa l'obiettivo, e la gente ottimizza per l'attività della macchina invece che per i risultati utili. L'IA non ha creato il problema, ha solo dato un nuovo nome lucido a un errore vecchio.
C'è un'obiezione vera che il pezzo concede: all'inizio di un rollout l'utilizzo conta, perché se nessuno tocca lo strumento non c'è storia di adozione.
Il punto giusto è che le metriche temporanee di sperimentazione diventano metriche di vanità permanenti. La difesa non è "mai misurare l'uso", è mettere una data di scadenza alla metrica di utilizzo prima ancora di lanciarla.
La metrica giusta non è mai quella facile. L'esempio del supporto è perfetto:
vanity: "quante risposte assistite dall'IA abbiamo generato?"
reale: "il tempo di prima risposta è migliorato senza far crescere escalation, rilavorazioni e frustrazione?"
Nell'ingegneria stesso schema: bruciare token non vale niente se peggiorano tempo di review, tasso di difetti e rischio di rollback. Il punteggio onesto è più difficile e meno lusinghiero, per questo viene evitato.