Questo articolo è stato pubblicato su LinkedIn, clicca per leggere...

Durante un corso di ingegneria del software all'università, uno dei docenti più in gamba che abbia conosciuto ci suggerì una lettura che nessuno si aspettava: Lo Zen e l'arte della manutenzione della motocicletta di Robert Pirsig. Un libro sulla qualità in un corso dove contava far funzionare il codice. La tesi di Pirsig suona semplice, quasi banale: la cura e l'attenzione che metti in qualsiasi cosa sono di per sé una forma di valore. La qualità non abita nel prodotto finale. Abita nel processo, nell'atteggiamento con cui ti avvicini al lavoro.

All'epoca mi sembrò una divagazione. Quasi trent'anni dopo, ci penso più spesso di quanto mi aspettassi.

Immagina un'azienda che taglia alberi. Per decenni, la scelta del bosco e degli alberi ha richiesto una conoscenza precisa: la domanda di legno, le capacità di rigenerazione del territorio, l'equilibrio tra bisogno immediato e rischio di disboscamento. Gli alberi venivano tagliati con seghe particolari, da persone che sapevano orientare la caduta di tronchi che pesavano tonnellate. Il processo era lento. Ma ogni taglio incorporava un giudizio.

Poi arriva la motosega (o, insomma, qualcosa di simile). E l'azienda decide che, siccome tagliare è diventato facile, può assumere chiunque. Lo strumento diventa il processo. Si costruisce un'organizzazione attorno alla motosega e si perde di vista la scelta che veniva prima: quale bosco, quali alberi, quanti, in che ordine. Ti chiedo: avrebbe un senso?

Questo è quello che sta succedendo con l'intelligenza artificiale nello sviluppo software. L'AI è la motosega. Taglia codice a una velocità che fino a due anni fa era impensabile. E la risposta dell'industria è stata costruire sistemi di sicurezza attorno alla motosega: pipeline automatiche, review gate, self-healing loop, deploy continuo. La chiamiamo harness engineering. Non è sbagliato, è necessaria. Ma resta un sistema di sicurezza per chi impugna lo strumento. Non dice nulla su quale bosco stiamo tagliando.

Vedo circolare un equivoco che mi preoccupa. Si confonde il metodo nell'uso efficace dell'AI con la metodologia di software engineering. Sono due cose diverse.

Il metodo è tattico: come strutturi il contesto per il tuo agente, come configuri la review automatica, come organizzi il ciclo di deploy. È il come uso la motosega. La metodologia è strategica: come comprendi il bisogno, come decomponi il problema, come gestisci la complessità nel tempo, come garantisci che quello che costruisci abbia senso tra sei mesi. È il perché taglio questo albero e non quello.

Un famoso adagio: qualcuno proclama di aver rivoluzionato la logistica. In realtà ha comprato camion più veloci. I camion corrono, ma chi decide dove vanno?

L'AI eccelle nelle fasi a valle del ciclo di sviluppo: scrivere codice, testarlo, deployarlo, monitorarlo. È forte lì, e negarlo sarebbe disonesto. Ma il focus deve essere sulle fasi a monte: capire il bisogno, progettare l'architettura, prendere decisioni di prodotto. E lì il giudizio umano. È dove si concentra e si concentrerà sempre più il lavoro vero.

Un test automatico che valida una feature in pochi minuti ti dice se il codice fa quello che hai chiesto. Non ti dice se hai chiesto la cosa giusta.

Il punto non è solo pragmatico. I numeri lo rendono concreto. Ci sono team che oggi rilasciano in produzione tre, cinque, otto volte al giorno. Cicli che andavano da sei settimane a pochi mesi si chiudono in ore: idea al mattino, prototipo a pranzo, test nel pomeriggio, decisione entro sera. Il 99% del codice di produzione generato da agenti AI.

Funziona. Non è un esperimento. La motosega taglia davvero.

Ed è proprio qui che la questione diventa seria. Un incompetente con una sega a mano fa poco danno: un taglio storto, un albero in meno, una giornata persa (sempre che l'albero, cadendo nella direzione sbagliata, non l'accoppi). Un incompetente con una motosega rade al suolo un ettaro prima di pranzo. L'accelerazione dello strumento non elimina la necessità di competenza. La amplifica. Lo confermano i dati: gli ingegneri senior che usano AI producono 4.3 volte l'output del novantesimo percentile. Lo strumento moltiplica quello che c'è. Se c'è giudizio, moltiplica giudizio. Se c'è superficialità, moltiplica superficialità.

Il rischio non è che l'AI produca codice scadente. Il codice lo sa scrivere, spesso meglio di chi lo commissiona. Il rischio è che diventi così facile produrre che smettiamo di chiederci se quello che produciamo serve a qualcuno. Ogni difetto nel processo che prima impiegava mesi a manifestarsi ora si materializza in ore.

A mio avviso, il segnale più interessante viene da chi sta già ripensando i ruoli. Accanto all'ingegnere del software tradizionale stanno emergendo figure come il context engineer, che progetta l'ecosistema informativo in cui un agente opera, o il decision engineer, che si occupa della qualità delle scelte a monte del codice. Sono nomi nuovi per un'idea antica: l'ingegneria non è mai stata solo tecnica. È sempre stata anche comprensione del contesto, del bisogno, delle conseguenze. La parte che non si automatizza.

Ma qui Pirsig torna.

L’AI non è il nemico della qualità. Al contrario, può esserne un alleato serio, se accettiamo che la misura del valore non sia più la quantità prodotta, una metrica ormai facilmente superata dall'AI stessa, ma la profondità con cui comprendiamo i problemi reali.

La cura di cui parlava Pirsig non è nostalgia. Chi la mantiene nel processo produrrà cose che funzionano per le ragioni giuste. Chi la perde taglierà più alberi di chiunque altro, e un giorno si guarderà attorno e scoprirà che del bosco non è rimasto granché.

La motosega è uno strumento straordinario. Resta da capire se sappiamo ancora scegliere dove usarla.