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à.
Un’ora e passa di chiamata per decidere cosa portare avanti sui firmware dei sensori, distribuiti in due repository. Il tipo di riunione che chiunque abbia gestito progetti tecnici riconosce: qualcuno propone uno scenario, qualcun altro lo smonta, si esplora una terza via e, a un certo punto, verso la fine, si torna alla prima ipotesi con un vincolo nuovo che nessuno aveva in mente all’inizio. Alla fine le decisioni ci sono, e sono buone. Il problema è che sono sparse in un materiale che le contraddice.
Quello che resta in mano è una trascrizione. Materiale grezzo, prezioso e sporco allo stesso tempo, in cui la stessa questione compare tre volte, con tre esiti diversi, e solo l’ultimo conta.
Con l’arrivo degli agenti e della loro autonomia operativa, dare a un LLM un compito complesso è diventato molto più semplice: glielo descrivi e si mette al lavoro da solo, aprendo i file e lanciando i comandi necessari, iterando senza che io debba intervenire a ogni passaggio. Il rovescio della medaglia è che un agente lasciato a briglia sciolta parte volentieri per la tangente. Per questo Claude Code ha aggiunto /goal, un comando pensato per favorire la convergenza: gli dai una condizione di completamento e l’agente continua a lavorare turno dopo turno finché quella condizione non risulta soddisfatta, senza che tu lo solleciti ogni volta.
È uno strumento utilissimo, con un dettaglio che però cambia tutto: converge verso la condizione che gli scrivi tu e, quando la condizione è buona, l’autonomia lavora per te; quando è vaga, lavora comunque, solo che a vuoto, e te ne accorgi dal conto dei token.