L’esperimento

Gestisco spesso più progetti contemporaneamente, e in ciascuno tengo insieme fronti diversi: architettura e servizi, interfaccia e infrastruttura, il codice da scrivere e i rilasci da preparare, ciò che gira in produzione e le decisioni di prodotto. La difficoltà che accomuna questi fronti è rientrare nel progetto: ritrovare, ogni volta, non solo dove mi trovavo ma perché avevo deciso così.

Da lì nasce l’impostazione operativa di questo libro. Rientrare in un progetto non è un lavoro di lettura: è una conversazione con qualcuno che quel progetto lo conosce già. Per questo motivo gestisco l’agente non come un completatore al quale impartire ordini sempre più lunghi, né come un collega immaginario al quale delegare responsabilità, ma come un pair: una controparte con cui esplorare, contestare, verificare e decidere.

Perché questa relazione funzioni, gli esiti che il Senior sceglie di rendere persistenti devono lasciare tracce strutturate, coerenti e consultabili nel tempo. Da qui l’obiettivo che mi sono prefissato:

Costruire attorno all’agente un System Harness che dia forma agli esiti del giudizio scelti per la persistenza, così che ogni decisione conservi le ragioni che l’hanno prodotta. Poi verificarne l’effetto: capire se, dopo molte sessioni, le decisioni e le loro ragioni si ritrovano, anziché dover essere ricostruite a partire dal codice o dalle conversazioni passate.

Il percorso dell’esperimento si articola in tre passaggi:

1. Osservazione: analizzo i modelli linguistici dentro i framework agentici, per capire dove accelerano, dove inventano continuità, quando seguono una regola e quando la perdono.

2. Interazione: studio il modo in cui un Senior guida il modello: formulare un mandato, concedere decisioni operative, trattenere quelle direzionali, progettare verifiche e arresti.

3. Progettazione: traduco queste lezioni nella costruzione di un System Harness personalizzato.

Non sto cercando di dimostrare che sia stata «salvata la cognizione» in senso forte, né che una memoria collegata renda sicuro un agente o più produttivo un team. L’obiettivo è più circoscritto. Dopo molte sessioni, il progetto riesce a dire perché un simbolo nel codice dipende ancora da una decisione ormai superata? Una correzione già fatta modifica davvero il lavoro successivo? Una lezione resta corrente finché resta corrente la causa che l’ha prodotta?

Fisso adesso due regole, prima di sapere come andrà.

La prima riguarda ciò che affermo: ogni proprietà che attribuisco al System Harness deve avere un controllo che si può eseguire. Se non so indicare come si verifica, non ho descritto il sistema: ho descritto quello che speravo.

La seconda riguarda quando smettere di difenderlo, ed è la condizione di smentita: se una decisione che il Senior aveva scelto di rendere persistente deve essere ricostruita a partire dal codice, invece di essere ritrovata, il disegno ha fallito nel punto in cui prometteva di più.

Ti propongo di portare questo esperimento nei tuoi progetti, attraverso cinque domande:

• quale contesto rendere disponibile;
• che cosa delegare;
• quale evidenza pretendere;
• quando fermare l’agente;
• quali esiti del giudizio rendere persistenti.

Queste domande funzionano soltanto se le rendi esplicite, se le metti alla prova durante le iterazioni che sostieni con l’agente e se le correggi là dove la collaborazione tra voi degrada. Ognuna, però, si può porre a tre livelli diversi: ciò che deve restare vero, il modo in cui si valuta il caso presente, la forma tecnica scelta. Confondere questi livelli è il modo più rapido di rispondere correttamente alla domanda sbagliata — ed è la confusione che il capitolo seguente prova a togliere di mezzo.