Note for non-native Italian speakers: this is a (still unlisted) video that I recorded a few days ago to capture a couple of thoughts that were mumbling in my mind lately. Unfortunately, the recording is in Italian.

https://www.youtube.com/watch?v=6jzOqtNnQT4

Video notes

Ho registrato in modo estemporaneo questo video per catturare una riflessione che avevo in testa mentre allenavo le mie skills di prompt engineering con il Goose Game kata, in pair con GitHub Copilot 😄... Sono pensieri sparsi, ma provo a riassumerne anche qui i punti essenziali:

• gli strumenti di AI come Copilot hanno la capacità di individuare le astrazioni come facciamo noi quando facciamo ad esempio refactoring? Sono incerto nel rispondere, ma sono molto curioso e vorrei sperimentare di più su questo aspetto.
• è comunque così importante che questi strumenti producano codice "rifattorizzato"? Ha senso che questo codice sia intellegibile da noi essere umani? Ho bisogno di poter leggere il bytecode prodotto dal compilatore quando scrivo codice Kotlin? Decenni fa, per modificare un server in produzione, si faceva tutto a mano; ora si termina semplicemente l'istanza e se ne ricrea una nuova riapplicando una serie di script scritti in un linguaggio di alto livello come Terraform. Non potremmo fare lo stesso per il codice sorgente?
• detto in altre parole, se (ipotesi) il costo per andare dall'idea al risultato si abbassasse notevolmente, avrebbe ancora senso "manutenere" il codice? Non potremmo semplicemente buttarlo via e ricrearlo da zero?
• e soprattutto, questo è possibile con strumenti (come gli LLMs) che non sono intrinsecamente deterministici ma macchine statistiche e quindi essenzialmente non deterministiche? Se questo fosse possibile, potrei versionare la sequenza di prompt che ha portato al mio codice e semplicemente di fronte ad un change modificare il prompt, buttare via la codebase generata e "riapplicare" la sequenza di prompt dall'inizio... ma questo è veramente possibile?

Feedback ricevuto

Risposta di Marco

Risposta di Marco Fracassi.mp3

Ciao Pietro, ho sentito oggi il tuo video. Bello innanzitutto, interessante. Ti faccio qualche spunto che magari ti può essere utile, più che altro sulle tue due osservazioni finali.

Sulla prima: mi viene in mente come le astrazioni sono pattern, ok, ma a volte quei pattern non sono solo pattern nel codice… noi cerchiamo di descrivere poi nel codice qualcosa che viene fuori dal codice, nel mondo reale; e quindi potrebbe essere più difficile per questi linguaggi… anche solo noi osserviamo, chiediamo, parliamo, quindi riportare tutto poi a un prompt è molto difficile. Bisognerebbe quasi registrare un discorso e dare quel discorso come prompt, forse, per descrivere il mondo reale, e quindi dato il mondo reale poi trovare quali sono anche le migliori astrazioni nel codice. Quindi lo vedo un po come un limite di questi strumenti.

L'altro, come dici tu, è sul fatto che ok, non c'è il determinismo: quando tu fai una sequenza di prompt, probabilmente la stessa sequenza di prompt il giorno dopo darebbe un risultato diverso, anche perché poi apprendono questi modelli, non rimangono fermi. Però ti pongo questa riflessione: facciamo finta che ci sia il determinismo perfetto, quindi io riesco a dargli sempre lo stesso prompt e ottengo sempre lo stesso risultato. Il mio dubbio è che per domini complessi il dettaglio di prompt che tu devi dare è molto simile al dettaglio di codice che tu devi scrivere. Cioè temo che tu debba arrivare a dirgli le singole if dicendogli magari in linguaggio naturale, ma sempre a quel livello di dettaglio le vai a descrivere, e man mano che complichi le condizioni, alla fine, è come scrivere condizioni più complicate nel tuo codice, quindi anche il livello di dettaglio a cui potrebbe arrivare un prompt in una situazione reale che magari va fuori dal gioco e così, temo che dovresti avere una sequenza di prompt molto simile alla sequenza di istzioni del codice.

E l'altra cosa è sempre in un discorso di determinismo perfetto, ma se tu hai la tua sequenza di prompt e devi ritornare indietro su una scelta che hai fatto a un certo punto del tuo dettato di prompt, devi cambiare la tua sequenza di prompt e quindi andare, non so, a metà della tua sequenza di prompt, ordinarne una, cambiarne una, ma a quel punto invaliderebbe tutte quelle successive. Perché in una macchina a stati finiti se tu stai cambiando uno stato non hai nessuna garanzia che gli altri si comportino allo stesso modo. L'alternativa sarebbe aggiungere la n+1 prompt e andare indietro per cercare di cambiare un comportamento che vuoi cambiare, che è stato fatto n mila prompt più indietro. Mi chiedo se questo sia sempre possibile e, se sì, probabilmente dovresti dare una quantità di prompt anche lì per tornare indietro nello stato che potrebbe essere molto complesso.

Mi immagino che a un certo punto, se tu metti sotto versione la tua lista di prompt, passi dal dover riuscire a manutenere il tuo codice, a dover riuscire a mantenere la tua lista di prompt. Se nel codice siamo bravi a fare refactoring e così non so se saremo altrettanto bravi, se sia possibile farlo su una lista di prompt: alla fine non hai più da capire il codice ma hai da capire la lista di prompt quindi stai temo solo spostando il problema e quindi boh non so, è uno spunto fammi sapere…

Risposta di Nicola

Ciao Piero, ho visto il video ed ho un paio opinioni/feedback

In generale mi è piaciuto tantissimo, ci sono dei punti molto molto interessanti che vorrei mettere in luce:

1. all'inizio hai spiegato come mettere in chiaro le modalità di collaborazione con Copilot, questo è bellissimo, è come si fa durante il pairing con un essere umano, metti in chiaro le modalità di co-creazione durante lo sviluppo di codice insieme. Questo fa emergere un pensiero che è: le stesse skills comunicative che si mettono in atto durante il pairing sono da mettere in atto con copilot; non avere queste skills porta a delle risposte da parte di copilot che vanno in una direzione sconveniente.