Perché il rubber duck debugging è l'uso dell'IA di cui mi fido di più
Lo strumento IA da cui ricavo di più non scrive mai il mio codice né redige i miei documenti. È un rubber duck: un agente a cui ho detto di fare domande invece di rispondere. Interroga qualsiasi cosa gli porti finché non emergono le lacune nel mio ragionamento, e nella maggior parte delle settimane questo vale più di qualsiasi risposta che potrebbe darmi.
Quasi tutti puntano l'IA sull'output: scrivi la funzione, riassumi il thread, abbozza il messaggio. È la scelta razionale di default. Una buona risposta è misurabile e fa risparmiare ore reali, e gran parte del lavoro che hai davanti ha semplicemente bisogno di questo. L'uso di cui mi fido di più punta l'IA nella direzione opposta, verso il mio stesso ragionamento. Una macchina per le risposte ti consegna quello che hai chiesto. Un buon rubber duck ti mostra la domanda che non avevi pensato di fare.
Un rubber duck mi ha smascherato prima di un incontro a Milano
Ho capito quanto può essere tagliente prima di un viaggio a Milano. Avevo un'idea di business e un incontro fissato con due possibili co-fondatori. Qualche giorno prima, ho aperto il duck per prepararmi: volevo arrivare pronto all'incontro.
È partito dalla domanda che avevo saltato: cosa volevo portarmi a casa da quell'incontro? Poi ha insistito su come mi sarei adattato: cosa avrei detto se avessero messo in dubbio l'idea, come avrei gestito la stanza se le cose fossero girate male. Dopo tre o quattro domande, non avevo più risposte.
Il duck aveva già emesso il verdetto. Sapevo cosa volevo da quell'idea, ma non avevo fatto la riflessione che una conversazione di business avrebbe richiesto. L'incontro è andato esattamente come quella premessa lasciava presagire: non abbiamo portato avanti nulla, e l'idea è morta in quella stanza. Nessuno strumento ti salva dall'essere impreparato. Ma questo ha fatto qualcosa di meglio: mi ha detto la verità prima che salissi sull'aereo, non al tavolo, davanti alle persone che volevo convincere.
La pratica è più vecchia dell'IA
Il rubber duck debugging non è arrivato con i modelli linguistici. Andy Hunt e Dave Thomas gli hanno dato questo nome in The Pragmatic Programmer nel 1999. Spiega il tuo codice, riga per riga, a un rubber duck sulla scrivania, e il bug tende a rivelarsi da solo prima che tu finisca. Il duck non aggiunge nulla. Il lavoro lo fai tu, ed è il dirlo ad alta voce che fa saltare fuori l'errore.
Ho praticato una versione di questo per tutta la carriera. Prima di fidarmi della mia stessa logica, scrivevo un commento per ogni riga, spiegando cosa avrebbe dovuto fare, e solo dopo riempivo il codice sotto. Spesso la logica crollava proprio lì, nei commenti, ed era esattamente lo scopo di scriverli. Un errore costa meno se lo scopri a parole che nel codice.
Cosa ci insegna sulla misura il duck del CS50 di Harvard
Quando ho costruito la mia versione IA, ho preso l'idea di base da Harvard. Il loro corso introduttivo, CS50, mette a disposizione un rubber duck IA chiamato CS50 Duck, che gli studenti possono interrogare a qualsiasi ora. La scelta progettuale che conta è la misura: il team gli ha messo dei paletti perché spinga lo studente verso la soluzione senza mai consegnargliela bell'e pronta. Il loro report descrive l'obiettivo come un tutor uno a uno che ti guida verso la risposta invece di svelartela.
Quella misura è l'intero prodotto. Il comportamento di default di un modello è essere utile, e utile vuol dire rispondere. Per ottenere un duck devi dirgli, con fermezza e di continuo, di fare la cosa più difficile: porre la domanda successiva e poi aspettare.
Dove rende davvero: le prove generali di un cambiamento
Prima di impegnarmi in qualcosa di difficile da annullare, come un nuovo processo o una riorganizzazione, sottopongo il lancio al rubber duck prima ancora che una sola persona ne senta parlare. Il duck fa lo scettico: cosa contesteranno gli ingegneri senior, quale frase suonerà come una minaccia quando invece intendevo presentarla come un piano. Trova il fraintendimento che avevo infilato senza accorgermene, mentre le parole costano ancora poco da cambiare. Quando il cambiamento arriva alle persone, ho già perso l'argomentazione una volta in privato e l'ho riscritta con parole più semplici.
La stessa mossa funziona prima di un grande cambiamento nel codice. Prima di un refactor o di una migrazione, ripercorro il piano ad alta voce e lascio che il duck lo metta alla prova. Chiede cosa si rompe se la mia assunzione principale è sbagliata, e cosa sto tenendo perché è giusto e cosa perché mi è familiare. Il duck prende qualsiasi decisione stia per prendere e mi costringe ad argomentarla prima ancora che sia scritta una riga di codice.
Quando il rubber duck debugging non è lo strumento giusto?
Niente di tutto questo è gratis, e non è sempre la mossa giusta. Il rubber duck debugging è lento per costruzione, quindi quando mi serve solo una risposta, un dettaglio di sintassi o del boilerplate, chiedo la risposta e vado avanti.
Inoltre, vale solo quanto la mia onestà nei suoi confronti. Posso dargli in pasto la conclusione che spero di sentire e raccogliere un cenno rassicurante. Mette alla prova la mia logica, ma le mie motivazioni le prende per buone.
Non sa nulla della mia situazione al di là di quello che gli dico e di quello su cui è stato addestrato. Lo stesso punto cieco è quello che gli permette di riscrivere codice che non può vedere. È uno specchio che fa buone domande, senza un giudizio proprio.
Quindi uso due tipi di IA. Una risponde, che è quello che la maggior parte delle persone intende con quella parola, e mi fa risparmiare tempo per davvero. L'altra fa domande ma non risponde a nulla, ed è esattamente per questo che vale di più per me. Mi fa avere ragione più spesso, o quantomeno mi ferma in tempo, prima che possano farlo le persone dall'altra parte del tavolo.