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.
Alla fine della chiamata ho scritto un prompt. Non un prompt elegante, ma uno di quelli che escono di getto mentre hai ancora la riunione in testa. Poi l’ho ripulito, e la versione leggibile è questa:
Contesto: riunione sulle attività da portare avanti sui firmware dei sensori,
repository A e repository B. Ti do il transcript integrale.
Leggi il transcript tenendo presente che è materiale grezzo: gli scenari
discussi all'inizio sono corretti da quelli discussi alla fine. In caso di
contraddizione vale l'ultima posizione emersa, non la prima.
Estrai gli scenari emersi e per ciascuno indica punti di forza e punti di
debolezza. Usa due valutatori separati, uno per i primi e uno per i secondi,
senza farli dialogare. Ogni costo di realizzazione dichiarato va ancorato allo
storico di sviluppo dei due repository o alle decisioni già registrate nella
knowledge base del progetto, non a una stima libera.
Costruisci un piano d'azione e fallo verificare da un agente che non ha
partecipato alla stesura. La verifica ha due criteri: ogni affermazione del
piano deve riportare il punto del transcript da cui proviene, e deve risultare
coerente con le milestone pubblicate su GitHub.
Consegna il piano come tabella. Non procedere oltre: aspetta la mia conferma
prima di qualsiasi operazione.Sembra lungo. Sono cinque mosse, e nessuna è decorativa: ognuna chiude una porta da cui l’output sarebbe uscito storto.
Le cinque mosse, una per volta
La prima riguarda il tempo. Un modello che legge un transcript non ha nessun motivo per sapere che le posizioni hanno una cronologia interna, e nel dubbio tratta tutto come materiale di pari dignità, con una tendenza a dare peso a ciò che incontra per primo. Il risultato è un piano che mescola l’ipotesi scartata alle otto e mezza con la decisione presa alle nove e quaranta, presentandole con la stessa faccia. Dichiarare che vale l’ultima posizione emersa costa una riga e vale per tutto il resto, perché senza quella riga ogni verifica successiva opera su materiale già inquinato.
La seconda riguarda la provenienza. Ogni affermazione del piano deve riportare il punto del transcript da cui proviene. Non è pignoleria da revisore: è l’unico modo per distinguere ciò che è stato detto da ciò che è plausibile che sia stato detto, e la seconda categoria è esattamente quella in cui i modelli sono più bravi e più pericolosi. Con la provenienza in chiaro, una riga senza riferimento diventa visibile a colpo d’occhio, e nella mia esperienza è lì che si nascondono le sintesi troppo ordinate per essere vere.
La terza riguarda la separazione. Se chiedi a un solo agente le forze e le debolezze di uno scenario, ottieni una simmetria fittizia: tre punti di qua, tre punti di là, un equilibrio che rassicura e non informa. Due valutatori che non dialogano producono invece due liste asimmetriche, e l’asimmetria è il dato. Uno scenario con due forze deboli e sei debolezze robuste ti dice qualcosa che il bilancino non ti direbbe mai. È lo stesso principio su cui avevo costruito adversarial-verify, nato dopo aver scoperto che cinque agenti in ruoli espliciti si dichiaravano a vicenda soddisfatti mentre il lavoro non era stato fatto.
La quarta riguarda i costi. Ogni stima di sforzo va ancorata allo storico di sviluppo dei repository o alle decisioni già registrate, mai lasciata alla stima libera. Un modello a cui chiedi quanto costa una modifica produce un numero, sempre, e quel numero ha la stessa consistenza di un sondaggio fatto a una persona sola. Ancorarlo allo storico significa chiedergli di guardare quanto è costato fare cose simili in quel codebase, con quei vincoli. Vale qui la regola che avevo già messo nero su bianco parlando di definition of done: un delta senza baseline è un auspicio.
La quinta riguarda l’uscita. Il piano arriva sotto forma di tabella e l’agente si ferma lì. Il formato tabellare non è una preferenza estetica, è ciò che rende il risultato ispezionabile riga per riga: ogni scenario, la sua provenienza, le sue forze, le sue debolezze, il suo costo ancorato. E il cancello finale, “aspetta la mia conferma”, blocca la mia decisione proprio in un momento in cui sarebbe comodissimo lasciarla andare.
PENSARE
CON GLI LLM, THE RIGHT WAY
È su leanpub
Ma il prompt dà qualcosa per scontato…
Quel prompt funziona per un motivo non esplicito: quando l’agente cerca le decisioni già prese, le trova.
Nel progetto, la knowledge base è una cartella di file, uno per decisione, con una numerazione progressiva che non si riusa né si riordina. Ogni file ha lo stesso scheletro: il contesto verificato sul codice, i vincoli che non possiamo cambiare, le opzioni considerate con il loro costo, la decisione scritta al presente in una frase chiara, le conseguenze operative che diventano issue collegate.
Il criterio per finire lì dentro è uno solo: se cambio idea su questo, devo toccare più di un repository? Se sì, la decisione va registrata; se no, resta nel firmware che la riguarda. Questo mantiene la cartella piccola e leggibile, condizione affinché serva a qualcosa.
Ci sono due dettagli che valgono più di tutto il resto.
Il primo è che una decisione superata non si cancella. Passa allo stato “superata da”, seguito dal numero di chi l’ha sostituita, e resta dov’è. Il valore sta nel sapere che ci avevamo già pensato, e nel non rifare la stessa discussione tra sei mesi arrivando per caso a una conclusione diversa senza accorgersene.
Il secondo è un campo che si chiama “cosa la farebbe cambiare”: il fatto nuovo che ci farebbe riaprire la questione. Se non riesci a scriverlo, la decisione probabilmente non è ancora matura. Chi ha letto l’articolo sulle quattro decisioni prima di integrare l’AI riconosce il segnale di riconsiderazione dei canvas, sceso dalla scala della strategia a quella della singola scelta tecnica. Senza quel campo la decisione non invecchia, marcisce.
Qui si vede chiaramente la differenza tra le due metà del sistema. La regola di precedenza temporale, nel transcript, devo dichiararla a mano nel prompt, ogni volta, perché il materiale grezzo è grezzo per definizione. Nella knowledge base quella stessa regola è incorporata nella struttura: lo stato “superata da” fa il lavoro senza che nessuno debba ricordarselo. Il tempo speso una volta per dare forma alla fonte è tempo che smetti di spendere a ogni interrogazione.
E la knowledge base non è composta solo da documenti tecnici. Ci finiscono i transcript, le discussioni sulle issue, il tempo effettivamente impiegato a chiudere un problema. È la parte che di solito evapora, e che invece è esattamente quella che serve quando devi stimare un costo o ricostruire perché una scelta fu presa. Sono anche materiali che vivono in contesti diversi e che raramente un solo contesto di lavoro riesce a tenere insieme, un problema su cui sono già tornato parlando di project traversing.
A questo punto va detta la precondizione, perché è la domanda che si fa chi legge. Un prompt come quello sopra chiede alla fonte di esistere. Se nel vostro progetto non c’è un tracker delle issue con discussioni leggibili, un archivio delle email che conti qualcosa, una traccia di dove sono finite le ore, allora la quarta mossa gira a vuoto e l’agente vi restituisce numeri inventati con una faccia molto seria. Ogni tanto, sui progetti che valuto piccoli, ci casco ancora anch’io: tengo tutte le decisioni nella mia testa, e me ne pento sempre. Quel materiale serve comunque, LLM o non LLM, ed è semplicemente il mestiere. La buona notizia è che quasi tutti ce l’hanno già, sparso in tre posti diversi e mai interrogato.
Dove va il tempo, davvero
Vale la pena essere precisi sul beneficio, perché la promessa facile sarebbe che l’AI accorcia la decisione. Non la accorcia. Semmai la allunga, visto che questo metodo aggiunge una verifica di provenienza, due valutazioni separate e un cancello di conferma.
Il tempo si guadagna ai due estremi. Prima, perché le informazioni utili sono già raccolte e visibili invece che sparse tra la memoria personale, le chat e gli allegati, e la fase di ricostruzione del contesto, quella che divora le ore, si riduce a un’interrogazione. Dopo, perché da un piano approvato posso far generare le issue, assegnarle, collegare la documentazione di corredo: tutta la manovalanza che sta tra la decisione presa e la decisione eseguita.
In mezzo resta il giudizio, che costa quanto prima e va bene così. Automatizzare la ripetizione e tenersi il giudizio è il crinale su cui si gioca questo mestiere.
Resta l’obiezione seria, quella che mi farei se leggessi questo articolo scritto da un altro: mantenere la knowledge base costa, e costa a ogni decisione, cioè proprio alla persona che dovrebbe risparmiare tempo. Vero. Solo che il confronto giusto non è tra scriverla e non scriverla: è tra scriverla e pagare il conto di non averla. E quel conto l’ho visto arrivare più volte. Un team con rotazione alta, dove chi aveva preso una scelta tecnica ha cambiato ruolo o è uscito, ricomincia da capo ogni anno: rimette in discussione decisioni già istruite, riapre analisi già fatte, e a volte reinventa la stessa ruota con un raggio leggermente diverso, che è il modo più elegante di accumulare debito tecnico. È un dato aneddotico, mio, non uno studio, e va preso per quello che è. Ma l’ordine di grandezza non è dubbio: mezz’ora per registrare una decisione che attraversa due repository pesa più di una settimana di discussioni per ricostruire perché fu presa.
La morale: chi lo costruisce se lo tiene
Da questa pratica è nato un nuovo corso per project e product manager (che estende quello già fatto) , che accompagna “Pensare con gli LLM, the Right Way“. Due edizioni già erogate in business school, due in programma per l’autunno, e un collaudo quotidiano nelle startup che seguo, che è poi il posto dove il metodo si rompe o regge.
La cosa che ho visto accadere in aula è ciò che mi interessa di più. I partecipanti non ricevono il sistema già fatto: lo costruiscono uno strato alla volta, dal prompt usa e getta fino all’orchestrazione, e all’ultimo esercizio provano a smontare l’output di cui vanno più fieri. Chi arriva a una scelta progettuale partendo dal basso ne capisce il meccanismo e, a quel punto, se la porta via.
Il che porta a una domanda che in aula arriva puntuale: un prompt del genere, se lo uso spesso, tanto vale impacchettarlo come skill. A volte sì, ed è la strada già tracciata con adversarial-verify, che viveva nei prompt di un progetto prima di diventare uno strumento a sé stante. A volte no, e la risposta onesta è che dipende da dove proviene la vostra informazione. Io lavoro molto sulle trascrizioni delle chiamate, quindi un filtro per le trascrizioni mi serve ogni giorno. Un team che decide tutto nei commenti delle issue di GitHub, con la discussione già scritta e ordinata, di quel filtro non sa che farsene: gli servirà qualcos’altro, magari nulla. La parte che si insegna, e che nessuna skill vi regala, è riconoscere quale dei due team siete.
È esattamente il motivo per cui il libro parla di pensare bene e non di tecnicismi. I comandi cambiano a ogni versione, i modelli si rinominano, le funzioni di ieri diventano deprecate con due settimane di preavviso. Le cinque mosse di quel prompt, invece, sono domande su come si decide, e quelle invecchiano molto più lentamente.
Se dovessi ridurre tutto a una riga: l’AI non vi restituisce il tempo della decisione, vi restituisce il tempo intorno. Ma solo se il progetto si è preso la briga di ricordare cosa ha già deciso, e perché.
E voi, dove finiscono oggi le decisioni prese nelle vostre riunioni?
Vuoi parlarne o seguire un corso in azienda su questi temi?
Contattami