Claude Code e FORTRAN sono più simili di quanto immagini

TLDR

Negli anni Cinquanta c’era chi considerava scrivere codice efficiente un’arte che una macchina non avrebbe saputo replicare. Oggi rileggiamo, correggiamo e personalizziamo il codice generato da Claude Code e Codex. Le differenze ci sono, ma una domanda può suonare familiare: se uno strumento comincia a fare ciò in cui sono diventato bravo, che cosa cambia nel mio mestiere?

Cominciamo

Cos’hanno in comune i primi compilatori FORTRAN e gli assistenti AI di oggi, come Claude Code e Codex?

Per cominciare, una piccola verifica.

Quando hai controllato per l’ultima volta l’assembly prodotto dal tuo compilatore?

Se la risposta è «mai», tranquillo: nessuno verrà a ritirarti il tesserino da sviluppatore. Se invece lo hai fatto stamattina, anche se un po’ stento a crederti, avrai avuto un motivo preciso per andare a guardare laggiù.

Puoi passare una giornata a scrivere C senza leggere una sola delle istruzioni in cui verrà tradotto. Affidi a un programma una parte del lavoro e continui a considerarti, con una certa naturalezza, la persona che ha scritto quel software.

La nascita dei primi compilatori

Riavvolgiamo il nastro.

Negli anni Cinquanta, prima del C, John Backus e il suo gruppo lavoravano a FORTRAN. L’idea di affidare a una macchina la produzione di codice efficiente incontrò scetticismo e resistenze. Nel racconto di Backus, alcuni programmatori consideravano quella capacità un’arte troppo complessa per essere automatizzata.

Con il senno di poi è facile sorridere. Proviamo però a cambiare sedia.

Immagina di conoscere benissimo la tua macchina. Sai dove risparmiare memoria, riconosci una soluzione mediocre a colpo d’occhio, riesci a fare in poche istruzioni quello che ad altri ne richiede molte di più. Ci hai messo anni. Le persone vengono da te quando il problema è difficile.

Poi arriva uno strumento che promette di occuparsi proprio di quella parte.

Le sue prime prove le guarderesti con curiosità. Probabilmente troveresti anche parecchio da correggere. Ma se cominciasse a migliorare, ogni suo progresso potrebbe farti un effetto curioso: una bella notizia per il progetto, una notizia un po’ più complicata per la tua autostima.

Avevi appena finito di diventare quello bravo.

Il compilatore diventa la normalità

Con il tempo, lavorare attraverso un compilatore è diventato normale. Nell’estate del 1973 il kernel di Unix venne riscritto in C. Una parte centrale di un sistema operativo poteva essere sviluppata in un linguaggio di alto livello. L’assembly continua ad avere i suoi impieghi, mentre moltissimo software viene sviluppato senza scriverlo direttamente.

Oggi possiamo leggere quella vicenda da una posizione comoda. Abbiamo conosciuto un mestiere nel quale delegare quel passaggio era già previsto. Per molti di noi, il compilatore faceva parte dell’arredamento quando siamo arrivati.

E il piacere di programmare?

Gli LLM, invece, sono entrati mentre eravamo alla scrivania.

Mettiamo che un assistente generi in pochi secondi una funzione che avresti saputo scrivere benissimo. La leggi, sistemi due cose, funziona. Hai risparmiato tempo. Puoi esserne soddisfatto e, nello stesso momento, sentire un piccolo fastidio.

Quella funzione ti piaceva saperla scrivere.

Magari era una parte noiosa del lavoro. Magari era proprio la parte divertente. Quando diciamo che uno strumento ci libera da un compito, vale la pena chiedersi se desideravamo davvero essere liberati da quel compito. La soddisfazione di trovare una soluzione elegante non compare nel conteggio delle ore risparmiate.

Poi ci sono le preoccupazioni concrete. Il valore delle proprie competenze, le opportunità, lo stipendio. Il mutuo non accetta «il mestiere si sta evolvendo» come modalità di pagamento. Il fatto che oggi ci fidiamo dei compilatori non rende sciocca la paura di chi vede cambiare il proprio lavoro.

Il futuro del mestiere

Naturalmente, il paragone ha un limite: un compilatore parte da un programma già scritto; a un LLM possiamo chiedere di interpretare ciò che vorremmo ottenere. Quanto questa differenza peserà sul futuro della professione resta una domanda aperta.

Ci abitueremo a leggere meno codice generato, come abbiamo imparato a non ispezionare ogni istruzione prodotta dal compilatore? Oppure avremo bisogno di mantenere con quel codice un rapporto diverso?

La storia dei compilatori ci lascia con un mestiere che ha già cambiato forma. Gli LLM ci mettono nella posizione meno comoda di viverne una trasformazione senza conoscerne il seguito.

Quando diciamo che amiamo programmare, a quale parte stiamo pensando? Alla soddisfazione di scrivere una soluzione elegante, al momento in cui capiamo il problema, al piacere di vedere qualcosa funzionare?

Se queste cose cominciassero a separarsi, quale vorremmo continuare a chiamare il nostro mestiere?

Fonti

• John Backus, Programming in America in the 1950s — Some Personal Impressions — Il racconto di uno dei creatori di FORTRAN sullo scetticismo verso la programmazione automatica e sulla ricerca di codice efficiente.
• Dennis Ritchie, The Development of the C Language — Lo sviluppo del C e la riscrittura del kernel di Unix nel 1973.