Ho finito il credito di Claude Max per preparare una serie di artefatti per un corso sull’AI e ho deciso di approfittarne per riscrivere un articolo, 100% a mano, su come (non) usare l’AI per essere più performanti.
La scorsa primavera ho partecipato ad un esperimento all’interno di un’azienda che voleva valutare l’impatto dell’AI da diversi aspetti della sostenibilità: ambientale, sociale (benessere del team) e di governance.
Diciamocelo: nella maggior parte delle aziende il “proof of concept” era una parola usata per indicare qualcos’altro… cioè qualcosa che nasceva per validare un’idea e finiva per diventare un software in produzione interna se andava bene, a tutti i clienti altrimenti. Questo avveniva e tuttora avviene perché realizzare un POC ha un costo. Tre giorni-uomo, cinque, dieci, e una cosa che costa dieci giorni-uomo non la butta via nessuno, nemmeno quando dovrebbe.
Il risultato è un vizio che ho visto ovunque e che ho avuto anch’io: si parte già preoccupati per la qualità. Si sceglie l’architettura giusta prima di sapere se il problema è quello che si crede. Si discute della libreria di validazione prima di capire se la feature ha senso. È un’ottimizzazione prematura applicata a una fase di discovery, in cui ha poco senso ottimizzare un percorso di cui non si sa ancora dove finirà.