La settimana scorsa ho chiesto a Claude di scrivermi una proposta tecnica per un cliente.
Ha prodotto un documento impeccabile in quaranta secondi. Architettura pulita, stima dei costi su tre ambienti, timeline con milestone, analisi dei rischi. Formattazione perfetta. Linguaggio professionale.
Ho buttato via tutto.
Non perché fosse sbagliato. Era tecnicamente corretto, anzi, probabilmente migliore di quello che avrei scritto io di getto. L’ho buttato via perché quel cliente, tre mesi prima, ci aveva detto in una call che il suo cto era stato licenziato dopo un progetto fallito con un approccio simile a quello proposto.
Non lo trovi in nessun dataset. Non c’è in nessun prompt. È una cicatrice organizzativa che vive nella memoria di chi c’era a quella call, e che cambia tutto: il tono della proposta, la scelta della soluzione, persino le parole da usare e quelle da evitare.
L’AI aveva prodotto la risposta giusta alla domanda sbagliata. È una cosa che fa benissimo.
Il lavoro invisibile #
Faccio i lead in una società volutamente di piccole dimensioni. Il mio lavoro, sulla carta, è prendere decisioni: quale prodotto costruire, per chi, con quali priorità, entro quando. Se guardassi la mia job description, un modello linguistico potrebbe fare il novanta percento di quello che faccio. Forse di più.
Ma la job description è una bugia. Come tutte le job description.
Il mio lavoro vero è fatto di cose che non stanno in nessun backlog e in nessun documento di progetto. È fatto di silenzi durante le call, quel momento in cui un cliente dice “sì, va bene” con un tono che significa “no, non va bene per niente, ma non ho voglia di discutere adesso”.
È fatto di pranzi con un collega che non rende da due settimane e che, al secondo caffè, ti dice che sta attraversando un momento difficile a casa.
È fatto della decisione, presa alle undici di sera, di non rispondere a un’email provocatoria di uno stakeholder e aspettare il mattino dopo, quando le parole pesano meno.
Niente di tutto questo è computabile. E non credo sia solo un problema di contesto mancante che si risolve con un prompt più lungo o con un rag più sofisticato.
È un tipo di conoscenza diverso. È situato, relazionale, quasi corporeo.
Sai che un meeting sta andando male perché senti la tensione nella stanza. Sai che una stima è gonfiata perché conosci chi l’ha fatta. Sai che un requisito va rifiutato non per ragioni tecniche, ma perché accettarlo sposterà il prodotto in una direzione dalla quale non si torna indietro. E lo sai perché sei già stato in quella direzione tre progetti fa, con un altro cliente, e hai le cicatrici per dimostrarlo.
L’AI lavora su quello che è esplicito. Il mio mestiere vive in quello che è implicito.
Quattro cose che non riesco a delegare #
Ho provato a fare un esercizio, un po’ per curiosità e un po’ per paura: identificare le parti del mio lavoro che un modello linguistico, per quanto avanzato, non riesce a fare.
Non le parti che non fa ancora. Quelle che, per come è fatto, probabilmente non può fare. O almeno non nello stesso modo.
Ne ho trovate quattro.
La prima è leggere le persone #
Non intendo assegnare task o fare performance review. Quello lo può fare un foglio Excel, e spesso lo fa pure meglio.
Intendo la parte vera. Capire che un collega che improvvisamente produce lavoro sciatto non ha un problema di competenza, ma un problema di motivazione. E che quel problema di motivazione nasce dal fatto che negli ultimi tre sprint lo hai messo su attività che considerava sotto il suo livello.
E che non te l’ha detto perché ha paura di sembrare arrogante.
E che tu lo sai perché lo conosci da quattro anni e sai come reagisce quando si sente sottovalutato.
Questa catena causale non è scritta da nessuna parte. Metà degli anelli non sono mai stati verbalizzati. Esistono nello spazio tra due persone che lavorano insieme abbastanza a lungo da capirsi senza parlare.
Gestire un team non è ottimizzare risorse. È navigare le complessità emotive di un gruppo di esseri umani che passano insieme più tempo di quanto ne passino con le loro famiglie.
E farlo senza manuali, senza metriche, spesso senza nemmeno rendertene conto.
La seconda è capire cosa vuole davvero un cliente #
Non quello che dice di volere. Quello che vuole davvero. Sono due cose quasi sempre diverse.
Un cliente che ti chiede un gestionale documentale spesso non vuole un gestionale documentale. Vuole che il suo capo smetta di chiedergli dove sono i file.
Un cliente che ti chiede un’app mobile vuole dimostrare al board che la sua divisione innova.
Un cliente della pubblica amministrazione che mette a bando una piattaforma digitale spesso ha bisogno di qualcosa di molto più semplice, ma il bando è stato scritto copiando quello di un altro comune che aveva esigenze completamente diverse.
Il mio lavoro è scavare sotto la richiesta fino a trovare il bisogno. E il bisogno è quasi sempre politico, organizzativo, emotivo. Raramente tecnico.
Ci arrivi facendo domande che non c’entrano niente con la tecnologia. Chi userà questo sistema? Chi ha deciso che serviva? Cosa succede se non lo facciamo? Chi ci guadagna e chi ci perde?
Sono domande che un’AI non sa fare perché non sa se e quando vanno fatte.
Forse è questa la parte che mi inquieta di più. Non è che la macchina risponda male. È che risponde bene a una domanda che magari nessuno avrebbe dovuto porre in quel modo.
La terza è dare peso al contesto che non c’è scritto da nessuna parte #
Ogni prodotto ha una storia. Non quella scritta nella documentazione, che è la versione ufficiale. La storia vera è fatta di compromessi accettati perché il budget era finito, di feature aggiunte per accontentare uno stakeholder che poi ha cambiato ruolo, di scelte che erano sbagliate ma che ormai sono così intrecciate con i processi del cliente che rimuoverle costerebbe più che conviverci.
Quando devo decidere se la prossima release deve riscrivere un modulo o aggiungere una funzionalità, non posso chiedere a un modello.
Perché la risposta giusta dipende da chi usa quel modulo, come lo usa, cosa stava succedendo nel progetto quando è stato costruito, qual è la relazione attuale con il cliente, e se quel cliente tra tre mesi avrà ancora il budget per la fase due.
Un’AI può dirti qual è la roadmap ideale in assoluto.
Un product leader sa qual è la roadmap giusta per quel prodotto, con quel team, per quel cliente, in questo momento.
La differenza tra le due cose è la differenza tra un libro di ricette e un cuoco.
La quarta è dire no #
È la più importante e la meno tecnica di tutte.
Dire no a una feature che sembra ragionevole ma che porterà il prodotto in un vicolo cieco.
Dire no a un cliente che vuole una timeline impossibile, sapendo che perderai la gara.
Dire no a uno stakeholder che spinge per un pivot affascinante ma che distruggerebbe il valore costruito in due anni.
Dire no a te stesso quando l’entusiasmo per un’idea nuova ti sta facendo perdere di vista che i tuoi utenti hanno bisogno di qualcosa che funzioni, non di qualcosa di innovativo.
Il no è un atto di giudizio che richiede coraggio, contesto e responsabilità.
L’AI non dice mai no. Non può permetterselo. Il suo design è ottimizzato per essere utile, per dare risposte, per risolvere.
Ma a volte la cosa più utile è fermarsi. A volte la risposta migliore è “non lo facciamo”.
E nessun prompt al mondo può insegnare a un modello quando quel momento è arrivato, perché riconoscerlo richiede qualcosa che nessun training set contiene: il peso delle conseguenze sulle proprie spalle.
Il paradosso dell’amplificazione #
Sia chiaro, non sto dicendo che l’AI è inutile. Sarebbe disonesto, oltre che stupido. La uso ogni giorno. Il mio team la usa per produrre, documentare, analizzare. Risparmiamo ore, giorni, settimane, mesi. La qualità dei deliverable è salita. Non tornerei indietro.
Però c’è un paradosso che vedo emergere e che mi preoccupa.
Più l’AI si occupa delle parti “producibili” del mestiere, quindi documenti, analisi, specifiche, codice, più il valore si concentra nelle parti “imponderabili”: le decisioni, le relazioni, i no.
E queste sono esattamente le parti che non si imparano leggendo documentazione o facendo corsi. Si imparano sbagliando, osservando, stando in una stanza con altre persone per anni.
Il rischio, mi chiedo, è che una generazione di professionisti cresca delegando le parti eseguibili senza mai attraversare la fase in cui quelle parti ti insegnano il mestiere.
Scrivere una proposta sbagliata, gestire una demo che va in pezzi davanti al cliente, perdere un contratto perché hai sottovalutato un requisito non è solo sofferenza formativa. È il processo attraverso cui sviluppi l’intuizione che poi ti permette di prendere le decisioni che l’AI non può prendere.
Se salti quel passaggio, arrivi al tavolo della negoziazione senza aver mai sentito il peso di una scelta sbagliata. E, a quel tavolo, l’AI non ti può aiutare.
Il mestiere che resta #
Il mio mestiere sta cambiando. Non sta scomparendo, sta cambiando forma.
Il tempo che passavo a produrre deliverable lo passo a ragionare su cosa quei deliverable dovrebbero dire.
Il tempo che passavo a cercare informazioni lo passo a decidere cosa farne.
Il tempo che spendevo sulle parti ripetitive lo passo a parlare con le persone, colleghi, clienti, utenti.
È uno spostamento verso l’alto nella catena del valore, e per certi versi è una liberazione.
Ma porta con sé una responsabilità nuova, che forse è anche una responsabilità vecchia vista con occhi diversi: non confondere la velocità con la competenza.
Il fatto che uno strumento mi aiuti a produrre di più non significa che sappia di più. Significa che ho più tempo per applicare quello che so, o per scoprire quello che non so, se sono onesto con me stesso.
L’AI sa quello che è stato scritto.
Il mio mestiere è sapere quello che non è stato scritto, e spesso quello che non può essere scritto.
Finché sarà così, e sospetto che sarà così per molto tempo, il mestiere resta. Cambia forma, cambia ritmo, cambia gli strumenti.
Ma resta.
Quello che l’AI non sa del mio mestiere è, in fondo, quello che lo rende un mestiere e non un algoritmo.