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.
Prima di andare nel dettaglio dei risultati, faccio un po’ di framing dell’esperimento, tre team (io ne gestivo uno come fractional manager) con una pianificazione di lavoro simile, diciamo tre mesi, e tre approcci al lavoro differenti. Un team non ha usato nessuno strumento di AI; un team ha usato l’AI come e quanto voleva; e il terzo team (guidato da me) ha usato l’AI con senso critico, limitandone l’uso quando non era utile.
Sul fronte ambientale, applicando meramente il calcolo dello SCI for AI (quindi attribuendo all’azienda solo le emissioni derivanti dall’inferenza), è emerso che, aumentando di un giorno a testa lo smart working, si sarebbero riassorbite sul fronte della responsabilità aziendale le emissioni dell’uso dell’AI (lo so, non bisogna avere la tunnel vision sulla CO2 in quanto gli impatti dei datacenter sono trasversali alle sole emissioni, ma ai fini dell’esperimento e del report dell’azienda questo era sufficiente).
Sul fronte della governance, quello che è emerso, osservando i team che usavano prodotti AI diversi, è che l’azienda non era ancora pronta ad abbracciare l’AI Act (che sarebbe arrivato qualche mese dopo). Quindi il lavoro fatto è stato quello di ridurre al minimo la shadow AI. È stato pertanto vietato l’utilizzo dei piani privati dei dipendenti (ie. niente più Canva o ChatGPT in un’azienda dedicata a Claude e Gemini), riducendo di fatto lo spazio operativo, a vantaggio però di un maggior controllo dei dati e dei processi ed è stato studiato come gestire il RAG aziendale per risolvere problemi di accesso a dati riservati a chi non dovrebbe leggerli. Ovviamente questo è un tema mastodontico e, da quel che so, è un problema ancora lontano dall’essere interamente risolto (forse integrando uno strumento come JEV…) ma di cui, almeno c’è una forte consapevolezza.
E fin qui nulla di nuovo, almeno dal mio punto di vista.
Sul fronte sociale (inteso come qualità del lavoro e benessere del team) è dove c’è stato il momento Eureka! O forse una consapevolezza che, in fondo, quello che c’è scritto in Pragmatic Programmer è ancora attuale. Nel team da me gestito abbiamo infatti assunto un atteggiamento molto opinionato: tutto quello che non era in backlog non andava fatto, a meno che non fosse indispensabile alla riuscita del progetto, o meglio, abbiamo piantato i piedi per evitare di introdurre Scope Creep nel progetto e AI Slop negli artifact prodotti.
Quindi il mio team, una volta raggiunti gli obiettivi del progetto, ha deciso di farmarsi e fare due cose, mentre l’altro ha continuato a produrre codice e features non pianificate perché l’AI le suggeriva.
La prima è stata quella di fare una retrospettiva su cosa ha funzionato e cosa no per aggiornare il processo stesso, la seconda è stata analizzare in questo tempo morto per il management dell’azienda (ma guadagnato per me) cosa normalmente non poteva fare perché affogato di attività o in ritardo con le consegne.
Ne è uscito un mare di informazioni utili seguito da un piano operativo:
- fare la formazione saltata fino a quel momento, compresa quella su CRA e AI-ACT obbligatorie, che sarebbero state relegate a qualche video invece che qualcosa di più approfondito,
- ridurre il debito tecnico aumentando sia i test funzionali che quelli di mutazione. Ovviamente con AI, ma senza più la scusa del “adesso non c’è tempo“,
- provare a fare dei POC per valutare un diverso approccio alla risoluzione di un problema per scegliere quello più elegante e pragmatico.
- far partire una serie di A/B test con un periodo di raccolta dati più lungo per meglio capire su cosa fare refactoring (codice, interfaccia o copy),
- analizzare i ticket (sempre con l’uso di AI) per identificare pattern tra richieste e lamentele in modo da pianificare la prossima release usando dati reali e non “sensazioni di pancia“.
In sostanza, abbiamo deciso consapevolmente di produrre di meno per produrre meglio, che, incidentalmente, era uno degli OKR del team.
Il risultato si è visto nello sprint successivo dove il team senza AI è arrivato in fondo facendo quanto stimato, ma fermandosi li. Il team AI-unlimited nell’iterazione successiva ha pianificato il deploy di quanto fatto ma solo dopo la rimozione di parte del codice e del riadattamento della ux secondo lo standard di progetto (si, hanno fatto molto slop) mentre noi avevamo un piano operativo per due iterazioni con tanto di dati alla mano relativi agli A/B svolti per oltre un mese.
Perché questo è successo? Come team avevamo chiari gli obiettivi di progetto e di team, quindi la nostra DoD è stata un po’ la stella polare che ci ha permesso di fermarci quando c’era il rischio di uscire dallo scope. Non è un tema nuovo su questo blog e lo abbiamo solo messo a terra.
Una delle domande fatte post-esperimento è stata “Ma non potevate far scrivere tutto all’AI?” e la comprendo benissimo. Abbiamo lavorato su diversi fronti per approcciarci al coding. L’AI ha prodotto pezzi di codice in autonomia; altri sono stati realizzati da sviluppatori in pair con un agente; altri (critici) hanno ricevuto una code review da parte dei senior, che ne devono garantire il corretto funzionamento. Ci ha aiutato il definire chi-fa-cosa, in una sorta di patto di lavoro che abbiamo seguito con il buon senso di chi sa rimettersi in discussione quando emergono nuove informazioni.
Un’altra domanda emersa è stata: “Quindi possiamo ridurre di un terzo il team?“. Farlo dimostra solo miopia, riducendo il team si ritornerebbe nella situazione di partenza in cui le persone sono sovraccariche di attività, prossime al burnout e con una qualità che tende al basso. Probabilmente, invece di un team di 15-20 persone, si può ragionare per avere un maggior numero di team più piccoli ed interdisciplinari che portano avanti più spike in parallelo, aumentando di fatto la velocità di delivery, lasciando però tempo per fare le attività di analisi necessarie. Inoltre, questo funziona solo con team che hanno almeno i 2/3 di senior a bordo, e siccome sul fronte sociale è necessario (su una scala medio-lungo termine) formare dei junior, smettere di assumere junior di punto in bianco lo vedo, di nuovo, come miopia operativa.
Riassumendo.
Questo approccio ci ha permesso di capire che una buona competenza nei pattern di sviluppo, nella pianificazione e nel design del codice e del prodotto rende un team che usa l’AI non solo 3 volte più veloce nel produrre, ma anche 3 volte più bravo a capire cosa produrre.
Ma ha reso anche evidente che, insieme al team, è necessario avere capacità discrezionale, una Definition of Done delle attività e, soprattutto, obiettivi chiari e metriche esplicitamente dichiarate, altrimenti il rischio di fare AI Slop è sempre molto presente.