Agenti AI e la fine del codice che dura

Questo articolo è stato pubblicato su LinkedIn, clicca per leggere...

Ogni anno l'agenzia delle tasse americana elabora le dichiarazioni di milioni di contribuenti su un sistema chiamato Individual Master File, scritto in COBOL e Assembler all'inizio degli anni Sessanta. Quando quelle righe furono battute per la prima volta, l'uomo non aveva ancora messo piede sulla Luna. Girano ancora. E non è un reperto isolato: un sondaggio su duecento banche britanniche ha trovato che il sedici per cento dipende tuttora da software degli anni Sessanta, e quasi il quaranta per cento da codice degli anni Settanta.

Per mezzo secolo abbiamo scritto codice perché durasse. Lo versionavamo, lo commentavamo, lo coprivamo di test come si fascia un edificio destinato a reggere terremoti che forse non arriveranno mai. Quel software sopravvive perché qualcuno, allora, lo aveva pensato per restare. Il codice era il luogo dove la decisione si sedimentava. Memoria istituzionale solidificata in sintassi.

L'ipotesi che circola con crescente insistenza è che questa epoca stia finendo. Non perché scriveremo codice migliore, ma perché smetteremo di scriverlo nel senso in cui lo intendiamo. Un paper recente di Zhenfeng Cao, uscito all'inizio di giugno con il titolo programmaticamente apocalittico The End of Software Engineering, prova a dare forma teorica a un'intuizione che molti hanno già in punta di dita: nei sistemi costruiti attorno a un agente, dove un modello linguistico fa da motore di ragionamento, il codice non è più il sistema. È uno strumento che l'agente genera, usa e butta. Tooling effimero per un ciclo di ragionamento che dura il tempo di un compito.

Vale la pena fermarsi su questa inversione, perché è più radicale di quanto la parola automazione lasci intendere.

Per cinquant'anni il codice ha avuto lo statuto della parola scritta. Qualcosa che si fissa, si conserva, si interpreta. Il sorgente era il testo, il binario la sua liturgia eseguibile, e tra i due correva tutta la filologia del versioning, del diff, della code review. Leggere il codice di un altro era un atto ermeneutico: ricostruire un'intenzione a partire dalle sue tracce, come si fa con un manoscritto.

Nel paradigma agentico il codice scivola verso lo statuto della parola detta. Viene pronunciato per l'occasione e si dissolve appena ha agito. Non lo si conserva perché non porta più il peso della decisione: la decisione vive altrove, nel modello e nella memoria che lo accompagna, e il codice ne è soltanto l'esalazione momentanea. Cao traccia un arco storico che dal software in licenza passa al SaaS e arriva a quello che chiama Agent-as-a-Service, dove non compri più un programma né un abbonamento ma un esito. Paghi il risultato e ignori di proposito la macchina che lo produce, come quando accendi la luce senza pensare un istante alla centrale elettrica.

Fin qui la diagnosi è elegante, e in buona parte la condivido. Il problema è la prognosi. E ancora di più il titolo.

The End of Software Engineering è un titolo che vende. L'autore firma da una società di investimento, e il dettaglio non è un'insinuazione gratuita: chi scrive di paradigmi che finiscono mentre gestisce capitale ha un interesse strutturale a suonare la campana un'ottava più alta del dovuto. Il corpo del testo, letto senza l'eco del titolo, dice qualcosa di assai più sobrio. Dice che oggi l'intelligenza artificiale è potentissima come amplificatore del programmatore, e che l'autonomia piena resta a diversi anni di distanza. Tra la fine dell'ingegneria del software e uno strumento che ci rende molto più rapidi mentre impariamo a fidarci corre la stessa distanza che separa una profezia da un piano di progetto.

C'è poi un punto su cui il paper inciampa, e vale la pena dirlo perché è istruttivo. Per dimostrare la necessità del nuovo paradigma, l'autore propone una piccola formalizzazione: la complessità di un sistema con molti componenti esploderebbe in modo combinatorio, e quindi nessuna mente umana potrebbe più dominarla. L'argomento applica il rigore a un lato solo della bilancia. La complessità del software viene gonfiata come se ogni componente parlasse con ogni altro, ignorando che la modularità esiste da sempre proprio per impedirlo, mentre la capacità dell'agente di reggere quella complessità viene semplicemente postulata in crescita esponenziale, senza uno straccio di prova. Si misura col bilancino la fragilità dell'avversario e si tira a occhio la forza del campione. È una scorrettezza retorica che conviene riconoscere, perché è la stessa che attraversa metà del discorso pubblico sull'AI.

Il momento più onesto del paper è quando cita un benchmark chiamato EvoClaw. L'idea è semplice e cattiva: invece di valutare gli agenti su compiti isolati, li si mette a far evolvere un software nel tempo, una milestone dopo l'altra, costringendoli a non rompere ciò che hanno costruito ieri. I numeri sono un secchio d'acqua gelata. Gli stessi sistemi che superano l'ottanta per cento sui compiti singoli crollano ad al massimo il trentotto per cento quando il lavoro diventa continuo, cumulativo, esposto al debito tecnico e alle regressioni.

Qui di solito si liquida la cosa così: limite temporaneo, questione di memoria e di contesto, lo risolveremo. Forse. Ma sospendiamo per un istante l'ottimismo d'ufficio e guardiamo cosa misura davvero EvoClaw. Misura la capacità di tenere coerente un sistema mentre il tempo lo erode. Misura, in altre parole, esattamente quella complessità essenziale che Fred Brooks, quarant'anni fa, indicava come il cuore duro dell'ingegneria del software: non la fatica di scrivere una riga, ma quella di tenere insieme un significato che si stratifica e si contraddice mentre passano gli anni.

Se il punto più difficile del mestiere è sempre stato questo, allora la domanda su chi lo sappia fare cambia il quadro intero.

Avevamo immaginato una divisione del lavoro consolante. L'intelligenza artificiale avrebbe preso la manutenzione noiosa, i CRUD, il boilerplate, e avrebbe lasciato a noi l'architettura nobile e la creazione. Il dato suggerisce il contrario. L'agente eccelle proprio nell'effimero, nella generazione brillante e istantanea del codice che risolve il problema di adesso. Vacilla precisamente dove l'essere umano era insostituibile: nel tenere insieme la coerenza attraverso il tempo, nella memoria che ricorda perché tre anni fa avevamo deciso così, nella responsabilità che risponde di un sistema quando nessuno ricorda più chi lo abbia scritto.

Lo strumento usa e getta, per esistere, ha bisogno di un custode che non sia usa e getta. Più il codice diventa parola detta, più qualcuno deve incarnare la parola scritta: l'intenzione che persiste, il criterio che giudica, la continuità che non si dissolve a fine compito. Non è un ruolo di scarto. È il ruolo che la stessa accelerazione rende più prezioso, non meno.

Si capisce allora perché il consiglio che Demis Hassabis ripete a chi studia oggi non sia imparate a scrivere prompt migliori. Il prompt engineering, nella sua lettura, è una competenza di transito: utile adesso, intermedia, destinata a sciogliersi man mano che i modelli imparano ad agire da soli. Chi si ferma alla superficie, a confezionare la richiesta giusta, costruisce su una zattera. Quello che indica come durevole è di un altro ordine: fondamenta solide di matematica e di pensiero scientifico, codice capito e non solo invocato, la capacità di imparare a imparare, l'attitudine a muoversi tra discipline, l'arte di mettere questi strumenti dentro processi reali e ragionamenti complessi. Sono, a guardarle bene, le competenze del custode della continuità, non quelle del battitore di prompt.

Cosa diventa il coding Se il codice è esalazione, l'ingegneria non evapora con lui: migra verso l'alto. Smette di essere l'atto di scrivere la logica e diventa l'atto di specificare l'intento con precisione sufficiente perché una macchina lo realizzi, di disegnare la verifica che distingue un risultato giusto da uno soltanto plausibile, di governare il ciclo dentro cui l'agente lavora. Il programmatore non scompare. Si sposta dal centro del fare al centro del giudicare. Diventa, per usare l'espressione di Cao che è forse la cosa migliore del suo paper, un architetto dell'intenzione.

Resta una domanda che nessun benchmark misura. Un sistema di cui nessun umano legge più il codice, di cui nessuno custodisce la storia perché la storia si rigenera a ogni invocazione, è un sistema di cui ci possiamo ancora fidare? Per decenni abbiamo scritto codice perché durasse, e nel farlo abbiamo lasciato che fosse il codice a ricordare per noi. Forse il compito che ci aspetta non è insegnare alle macchine a scrivere meglio. È decidere quanta parte della nostra memoria siamo disposti ad affidare a qualcosa che, per come è fatto, è fatto per dimenticare.