Non mi piace parlare con i robot

Ho un telefono Android, ma ho disattivato i comandi vocali. Non ho mai posseduto un Alexa. Non sono sicuro di cosa faccia esattamente Siri, perché sono riuscito a cavarmela nella vita senza che mi trovasse una playlist. Quindi, quando gli strumenti di codifica AI sono diventati difficili da ignorare, mi sono avvicinato lentamente. Per un po', ho fatto ciò che alcuni chiamano “approccio a colpo singolo”: lavorare come ho sempre fatto, delegando occasionalmente una parte del lavoro all'AI, e poi aspettando per vedere cosa tornava. È un approccio davvero interessante per chi ama il gioco d'azzardo.

Per me, parte dell'attrito era l'interfaccia di chat stessa. L'idea di avere una conversazione con il modello mi sembrava sciocca. Costruisco cose. Non negozio con le caselle di testo.

Ma lo sviluppo guidato da specifiche non funziona così. Definisci il problema in modo preciso, indichi al modello quali file considerare, descrivi il risultato desiderato, vai avanti e indietro discutendo il piano prima che l'intelligenza artificiale generi una riga di codice. I modelli di intelligenza artificiale di oggi sono veloci nella codifica, ma sono ancora pericolosamente inconsistenti nelle decisioni di alto livello. Quando lavori con l'intelligenza artificiale, il tuo compito è trasformare il tuo giudizio di progettazione in una specifica scritta, così puoi dare all'IA una lista di passaggi a bassa decisione che corrispondono a ciò che faresti, se stessi per scrivere il codice tu stesso. Per ottenere quella specifica correttamente, devi negoziare.

L'ho imparato negli ultimi sei mesi. E sono diventato abbastanza bravo in ciò. Quasi mai scrivo codice a mano, eppure sto consegnando più funzionalità di quanto abbia mai fatto prima. E poiché non sto affidando la progettazione software al modello, sto applicando gli stessi standard di qualità che ho imparato a mantenere nella mia carriera di 25 anni nello sviluppo di prodotti digitali.

Ciò che non mi aspettavo era quanto sarebbe stato difficile insegnarlo.

Sono già Picasso?

C'è l'idea (tra i dirigenti?) che gli strumenti LLM aumenteranno la produttività di tutti gli ingegneri. In pratica, non l'ho visto. Ciò che vedo sono ingegneri esperti e adattabili che raggiungono molte volte quello che producevano prima, mentre altri producono lo stesso o meno.

Questa non è una buona situazione per i neofiti. Gli strumenti di codifica basati sull'IA sembrano semplici perché le loro interfacce sono solo caselle di testo. Ma non si diventa Picasso spalmando arbitrariamente vernice su una tela bianca.

Sindrome dell'implementazione parallela

Ci tengo agli ingegneri junior per molte ragioni, non ultima quella che sono le mie persone preferite con cui lavorare! La loro apertura mentale non si è ancora atrofizzata, e mi aiutano a vedere le cose in modo diverso. Recentemente, ho intrapreso un percorso di apprendimento dell'IA con un giovane ingegnere che è intelligente, entusiasta degli strumenti di IA, impaziente di mettersi all'opera, e per niente esitante a parlare con il robot.

Eppure, in qualche modo non funzionava.

Il primo segno fu il sistema di autenticazione. Lei aveva bisogno di aggiungere OAuth a un servizio esistente, e ha chiesto al modello di costruire l'intero flusso di autenticazione in una specifica gigantesca. Accesso, rinnovo del token, gestione delle sessioni, accesso basato sui ruoli e il flusso di disconnessione. Tutto. Il modello ha accondisceso volentieri. Ha prodotto diverse centinaia di righe di codice che sembravano complete con il 100% di copertura del codice e test superati.

Ma quando l'ho rivisto, i problemi erano strutturali. Il modello aveva creato una nuova memorizzazione delle sessioni invece di usare quella che già avevamo. Ha introdotto un pattern di rinnovo dei token che era in conflitto con il nostro gateway API. La logica di accesso basata sui ruoli duplicava le regole di business che già esistevano in un middleware condiviso. Tecnicamente, niente di tutto ciò era sbagliato—funzionava. Architetturalmente, era tutto sbagliato.

Mi sono seduto con lei e ho fatto una semplice domanda: “Prima di chiedere questo, sapevi come gestiamo le sessioni oggi?” Ha esitato. “Non esattamente.” Quella era la lacuna. Non aveva mappato il territorio prima di chiedere al modello di costruirci sopra.

Il tentativo successivo andò diversamente, ma non abbastanza. Lei chiese al modello di modificare il flusso di accesso per supportare un nuovo fornitore. Questa volta, stava riducendo l'ambito, il che era positivo. Ma descrisse il cambiamento in termini di ciò che voleva che l'interfaccia utente facesse, non in termini di ciò che il codice esistente già gestiva. Il modello, non avendo motivo di conoscere la nostra astrazione del fornitore, scrisse un'implementazione parallela da zero. Stesso risultato: codice funzionante, architettura errata.

Abbiamo parlato di ciò che era successo. Le ho detto di pensare al modello come penserebbe a un nuovo collaboratore esterno nel team. Talentuoso, veloce, zero esperienza con la nostra codebase. Non consegneresti questo progetto a un collaboratore esterno e te ne andresti. Diresti: ecco la nostra memorizzazione delle sessioni, ecco il middleware, ecco lo schema per aggiungere un nuovo fornitore. Adatta il tuo lavoro a questo.

Aveva afferrato il concetto. Ma le successive iterazioni mi hanno dimostrato che il concetto era la parte facile. Otteneva un singolo piano dal modello e lo approvava senza cercare alternative. Lei vedeva la disponibilità del modello a fare modifiche di codice estese come accuratezza; io la vedevo come un rischio inutile. Non aveva ancora l'istinto di dire 'no, è troppa area di superficie per questo cambiamento.'

Un ingegnere esperto avrebbe gestito quello stesso compito OAuth in sei o sette sessioni focalizzate, ognuna delimitata a una parte del sistema che già comprendeva.

Le competenze trasversali sono le nuove competenze tecniche.

Ciò potrebbe sembrare un sovraccarico che cancellerebbe i guadagni di produttività della codifica con IA. Ma queste non sono nuove abilità. Gli ingegneri esperti lo hanno sempre fatto nella loro testa. La differenza è che lo sviluppo guidato dalle specifiche esternalizza la pianificazione del design software di tutti i compiti. La negoziazione del design che avveniva internamente, tra te e il tuo stesso giudizio, ora avviene in una finestra di chat.

Prima di aprire la chat, devi sapere cosa vuoi. Non l'implementazione, ma il comportamento, i vincoli, la forma della cosa. Devi conoscere abbastanza bene la tua codebase per dire al modello dove il suo lavoro deve inserirsi. Quando il modello torna con una risposta, probabilmente funzionerà. Non è sufficiente. Devi sapere se effettivamente si adatta al sistema che già possiedi.

A volte riconosci che il modello ha ragione e tu hai torto, e hai bisogno di umiltà per valutarlo equamente.

In tutto il processo, ciò che separa le persone che usano bene questi strumenti da quelle che li usano velocemente è la pazienza: la volontà di andare avanti e indietro cinque o sei volte invece di accettare qualcosa di mediocre già al secondo giro. C'è anche l'abilità di scrivere con precisione del codice senza scrivere codice, descrivendo flussi di dati, casi limite e modalità di guasto in linguaggio semplice. E c'è il gusto, che è più difficile da definire ma facile da riconoscere: un senso di come si percepisce il buon software dalla prospettiva della manutenzione a lungo termine, non solo se funziona.

E poi c'è la parte scomoda. La maggior parte di queste competenze è riconoscimento di pattern che si costruisce dopo anni di errori. Riconosci una cattiva decisione architetturale perché ne hai vissuto le conseguenze. Respingi la prima risposta del modello perché hai già implementato la tua prima idea e te ne sei pentito.

Gli ingegneri junior si trovano in situazioni in cui devono effettuare negoziazione del design ad alto livello, ma non sembra esserci un programma formativo per questo. È tempo di spostarsi da “LeetCode” alla negoziazione del design, e questo sarà l'argomento dei futuri post in questa serie.

Addendum

Competenze trasversali per la negoziazione delle specifiche con l'IA

Durante la negoziazione

• Fluenza nella lettura del codice: Analizza ciò che il modello produce per la solidità strutturale, non solo per la sintassi. Stai leggendo per valutare l'adattamento, non per i bug. Perché è importante: Il modello può generare codice valido che non appartiene al tuo sistema. Devi identificarlo rapidamente.

• Senso architetturale: Riconoscere quando una soluzione è tecnicamente valida ma sbagliata per questo sistema. Perché è importante: Il modello non sa cosa significhi "sbagliato per noi". Tu sì.

• Guida creativa: Trova cornici alternative quando il modello è bloccato. Riformula il problema, offri un'analogia, applica vincoli diversi. Perché è importante: Il modello risponde a come si inquadrano le cose, e una cornice migliore produce un risultato migliore.

• Sapere quando assumere una posizione: Il modello presenta le opzioni in modo neutrale. Tu decidi, e spieghi perché un approccio è migliore per il tuo contesto. Perché è importante: Questo è giudizio ingegneristico, e ci vogliono anni per svilupparlo.

• Scetticismo produttivo: Supponi che la prima risposta del modello sia una bozza, non una soluzione. Non è cinismo, ma l'abitudine di fare un test di resistenza prima di accettare. Perché è importante: Gli output di prima passata sono seducenti perché sono fluenti. La fluenza non è correttezza.

• Sapere ciò che non si sa: Riconoscere quando il modello potrebbe avere ragione e tu potresti avere torto. Perché è importante: La negoziazione è bidirezionale. A volte emerge un approccio che non avevi considerato, e hai bisogno di umiltà per valutarlo equamente.

Attraverso tutto il processo

• Pazienza: Vai avanti e indietro cinque o sei volte invece di accettare qualcosa di mediocre al secondo giro. Perché è importante: Questo separa le persone che usano bene lo strumento da quelle che lo usano velocemente.

• Comunicazione tecnica: Scrivi in modo preciso sul codice senza scrivere codice. Descrivi flussi di dati, cambiamenti di stato, casi limite e modalità di guasto in linguaggio semplice. Perché è importante: Questo è più difficile di quanto pensino la maggior parte degli ingegneri, ed è l'interfaccia primaria tra te e il modello.

• Gestire la complessità mentalmente: Tieni traccia di come la decisione attuale interagisce con tre altre parti del sistema che il modello non conosce. Perché è importante: Il modello non ha un contesto architetturale persistente. Tu sei la memoria di lavoro.

• Gusto: Un senso di come si sente un buon software dalla prospettiva dell'utente. Non solo "funziona" ma "è questa l'esperienza giusta, il comportamento giusto, il giusto livello di complessità." Perché è importante: Senza questo, accetterai soluzioni che sono funzionali ma sbagliate.

• Sapere quando fermarsi: Riconoscere quando la specifica è abbastanza buona da passare all'esecuzione e quando si sta facendo un iper-raffinamento. Perché è importante: I rendimenti decrescenti sono reali. A un certo punto, ulteriore negoziazione costa più di quanto migliora.