Il codice è una responsabilità (non un attivo). I capi della tecnologia non capiscono questo. Pensano che l'AI sia fantastica perché produce 10.000 volte più codice di un programmatore, ma questo significa solo che sta producendo 10.000 volte più responsabilità. 1/

Se desideri una versione in formato saggio di questo thread da leggere o condividere, ecco un link al mio blog, privo di sorveglianza, senza pubblicità e senza tracker: 2/

L'AI è l'amianto che stiamo infondendo nelle pareti della nostra società ad alta tecnologia: Il codice è una responsabilità. Le *capacità* del codice sono beni. 3/

L'obiettivo di un negozio tecnologico è avere codice le cui capacità generano più entrate rispetto ai costi associati al mantenimento di quel codice in esecuzione. 4/

Per molto tempo, le aziende hanno nutrito una falsa convinzione che il codice costi meno da eseguire nel tempo: dopo un periodo iniziale di assestamento in cui vengono trovati e risolti i bug nel codice, il codice smette di necessitare di una manutenzione significativa. 5/

Dopotutto, il codice è una macchina senza parti mobili - non si consuma; non si usura nemmeno. Questa è la tesi del libro di Paul Mason del 2015 *Postcapitalism*, un libro che è invecchiato sorprendentemente male (anche se, forse, non così male come la credibilità politica di Mason).

Il codice non è una macchina riproducibile all'infinito che non richiede lavoro. Piuttosto, è una macchina fragile che richiede misure sempre più eroiche per mantenerla in buone condizioni di funzionamento, e che alla fine "si consuma" (nel senso di necessitare di un rifacimento completo). 7/

Per capire perché il codice è una responsabilità, devi comprendere la differenza tra "scrivere codice" e "ingegneria del software." "Scrivere codice" è un passatempo incredibilmente utile, divertente e coinvolgente. 8/

Comporta la suddivisione di compiti complessi in passaggi discreti, così precisamente descritti che un computer può eseguirli in modo affidabile, ottimizzando le prestazioni trovando modi intelligenti per ridurre al minimo le richieste che il codice pone sulle risorse del computer, come RAM e cicli del processore. 9/

Nel frattempo, "ingegneria del software" è una disciplina che comprende "scrivere codice", ma con un focus sulle operazioni a lungo termine del *sistema* di cui il codice fa parte. 10/

L'ingegneria del software si occupa dei processi a monte che generano i dati che il sistema riceve. Si occupa dei processi a valle ai quali il sistema emette informazioni elaborate. 11/

Si occupa dei sistemi adiacenti che ricevono dati dagli stessi processi a monte e/o emettono dati agli stessi processi a valle a cui il sistema sta emettendo. 12/

"Scrivere codice" riguarda la creazione di codice che *funziona bene*. "Ingegneria del software" riguarda la creazione di codice che *gestisce bene i fallimenti*. Si tratta di creare codice che sia leggibile - le cui funzioni possano essere comprese da terzi che potrebbero essere chiamati a mantenerlo. 13/

Questi terzi potrebbero essere invitati ad adattare i processi a valle, a monte o adiacenti al sistema per evitare che il sistema si rompa. 14/

Questo è il punto: qualsiasi codice non banale deve interagire con il mondo esterno, e il mondo esterno non è statico, è *dinamico*. Il mondo esterno infrange le assunzioni fatte dagli autori del software *tutto il tempo* e ogni volta che lo fa, il software deve essere corretto. 16/

Ricordi Y2K? Quello era un giorno in cui codice perfettamente funzionante, in esecuzione su hardware perfettamente funzionante, smetteva di funzionare - non perché il codice cambiasse, ma perché *il tempo avanzava*. 17/

Siamo a 12 anni dal problema Y2038, quando tutte le versioni a 32 bit di Unix smetteranno di funzionare, perché anche loro avranno esaurito i secondi computabili. 18/

L'esistenza di "il mondo" è un fattore ineludibile che consuma il software e richiede che venga ricostruito, spesso a spese enormi. Più a lungo il codice è in funzione, maggiore è la probabilità che incontri "il mondo." 20/

Prendi il codice che i dispositivi usano per segnalare la loro posizione fisica. Inizialmente, questo veniva utilizzato per cose come la fatturazione - determinare quale rete di operatore o fornitore stavi utilizzando e se eri in roaming. 21/

Poi, i nostri dispositivi mobili utilizzavano questo codice per aiutare a determinare la tua posizione al fine di fornirti indicazioni passo-passo nelle app di navigazione. Poi, questo codice è stato riutilizzato di nuovo per aiutarci a trovare i nostri dispositivi smarriti. 22/

Questo è diventato un modo per localizzare i dispositivi *rubati*, un caso d'uso che diverge nettamente dalla ricerca di dispositivi smarriti. Quando si localizza un dispositivo smarrito, non è necessario affrontare la possibilità che un attore malintenzionato abbia disabilitato la funzione "trova il mio dispositivo smarrito". 23/

Questi casi d'uso aggiuntivi - a monte, a valle e adiacenti - hanno esposto bug nel codice originale che non erano mai emersi nelle applicazioni precedenti. 24/

Ad esempio, tutti i servizi di localizzazione devono avere qualche tipo di comportamento predefinito nel caso (molto comune) in cui non siano davvero sicuri di dove si trovano. 25/

Forse hanno una soluzione generale - ad esempio, sanno a quale ripetitore cellulare sono connessi, oppure sanno dove si trovavano l'*ultima* volta che hanno ottenuto una posizione precisa - oppure potrebbero essere completamente persi. 26/

Si scopre che in molti casi, le app di localizzazione tracciavano un cerchio attorno a tutti i luoghi in cui *potevano* trovarsi e poi impostavano la loro posizione al centro di quel cerchio. 27/

Va bene se il cerchio ha solo pochi piedi di diametro, o se l'app sostituisce rapidamente questa approssimazione con una posizione più precisa. Ma cosa succede se la posizione si estende per miglia e miglia, e il fix della posizione *non* migliora mai? 28/

E se la posizione di un indirizzo IP senza una posizione definita fosse data come *il centro degli Stati Uniti continentali* e qualsiasi app che non sa dove si trova riportasse che si trova in una casa in Kansas? 29/

E nella mia città di Burbank, dove il servizio di condivisione della posizione di Google ci ha detto una volta che nostra figlia di allora 11 anni (il cui telefono non riuscivamo a raggiungere) si trovava a 12 miglia di distanza, su una rampa dell'autostrada in un'area non incorporata della contea di LA. 32/

(Era in un parco vicino, ma fuori portata, e l'app ha stimato la sua posizione come il centro della regione in cui l'aveva fissata l'ultima volta.) (Sono state un paio d'ore difficili.) 33/

Il codice sottostante - il codice che utilizza un'impostazione predefinita un tempo innocua per mascherare posizioni sconosciute - deve essere aggiornato *costantemente*, perché i processi upstream, downstream e adiacenti ad esso stanno cambiando *costantemente*. 34/

Più a lungo quel codice rimane lì, più i suoi comportamenti originali diventano superati, e più i patch sovrapposti diventano barocchi, ingombranti e oscuri. 35/

Il codice non è un attivo - è una passività. Più a lungo un sistema informatico è stato in funzione, maggiore è il debito tecnico che rappresenta. Più importante è il sistema, più difficile è fermarlo e rifarlo completamente. 36/

Invece, nuovi strati di codice vengono sovrapposti, e ovunque gli strati di codice si incontrano, ci sono crepe in cui questi sistemi si comportano in modi che non corrispondono esattamente. 37/

Peggio ancora: quando due aziende vengono fuse, i loro sistemi IT incrinati e fessurati vengono messi insieme, così ora ci sono fonti *adiacenti* di debito tecnologico, oltre a crepe a monte e a valle: 38/

Ecco perché le grandi aziende sono così suscettibili agli attacchi ransomware: sono piene di sistemi incompatibili che sono stati costretti a una facsimile di compatibilità con varie forme di pasta modellabile digitale, corda e filo da imballaggio. 39/

Non sono a prova d'acqua e non possono essere resi a prova d'acqua. Anche se non vengono abbattuti dagli hacker, a volte semplicemente cadono e non possono essere rimessi in piedi. 40/

Ricordi quando i computer di Southwest Airlines sono andati in crash per tutta la settimana di Natale 2022, lasciando milioni di viaggiatori bloccati? 41/

Le compagnie aeree sono particolarmente scadenti, perché si sono informatizzate presto e non possono mai spegnere i vecchi computer per sostituirli con quelli nuovi. Ecco perché le loro app sono così scadenti. 42/

Ecco perché è così terribile che le compagnie aeree abbiano licenziato il loro personale di assistenza clienti e richiedano ai passeggeri di utilizzare le app per *tutto*, anche se le app non funzionano. Queste app non funzioneranno mai. 43/

Il motivo per cui l'app di British Airways mostra "Si è verificato un errore sconosciuto" dal 40 all'80% delle volte non è (solo) che hanno licenziato tutto il loro personale IT e hanno esternalizzato a chi offre il prezzo più basso all'estero. 44/

È vero, certo - ma anche che i primi computer della BA funzionavano con valvole elettromeccaniche, e tutto da allora deve essere retrocompatibile con un sistema che uno dei protetti di Alan Turing ha scavato da un intero tronco con i suoi stessi denti anteriori. 45/

Il codice è una responsabilità, non un attivo (la nuova app di BA è in ritardo di anni). Il codice è una responsabilità. I server per i terminal Bloomberg che hanno reso Michael Bloomberg un miliardario funzionano su chip RISC. 46/

Questo significa che è bloccato nell'utilizzo di un numero sempre minore di fornitori di hardware specializzati e di data center, pagando programmatori specializzati e costruendo catene di codice fragili per collegare questi sistemi RISC ai loro equivalenti meno esotici nel mondo. Il codice non è un asset. 47/

L'AI può scrivere codice, ma l'AI non può fare ingegneria del software. L'ingegneria del software riguarda tutto il pensare attraverso il *contesto* - cosa ci sarà prima di questo sistema? Cosa ci sarà dopo? Cosa si troverà accanto ad esso? Come cambierà il mondo? 48/

L'ingegneria del software richiede una "finestra di contesto" molto ampia, cosa che l'AI non ha e non può avere. La finestra di contesto dell'AI è stretta e superficiale. Aumenti lineari della finestra di contesto dell'AI richiedono espansioni *geometriche* nelle richieste computazionali: 49/

Scrivere codice che funziona, senza considerare come potrebbe fallire, è una ricetta per il disastro. È un modo per creare debito tecnologico su larga scala. È come gettare amianto nelle pareti della nostra società tecnologica. 50/

I capi *non sanno* che il codice è una passività, non un attivo. Ecco perché non smettono di parlare dei chatbot che producono 10.000 volte più codice di qualsiasi programmatore umano. 51/

Pensano di aver trovato una macchina che produce *asset* a 10.000 volte il tasso di un programmatore umano. Non è così. Hanno trovato una macchina che produce *passività* a 10.000 volte il tasso di qualsiasi programmatore umano. 52/

La manutenibilità non è solo una questione di esperienza acquisita con fatica che ti insegna dove si trovano le insidie. 53/

Richiede anche la coltivazione del "Fingerspitzengefühl" - il "sentimento delle punte delle dita" che ti consente di fare ipotesi ragionevoli su dove potrebbero emergere insidie mai viste prima. 54/

È una forma di conoscenza del processo. È ineluttabile. Non è latente nemmeno nel più grande corpus di codice che potresti usare come dati di addestramento: *Ragazzo* se i capi della tecnologia non capiscono questo. 55/

Prendi Microsoft. La loro grande scommessa in questo momento è su "AI agentica." Vogliono installare spyware sul tuo computer che cattura ogni battitura, ogni comunicazione, ogni schermo che vedi e lo invia al cloud di Microsoft, dando accesso a una miriade di chatbot.

Affermano che potrai dire al tuo computer: "Prenotami un treno per Cardiff e trova quell'hotel di cui Cory ha parlato l'anno scorso e prenotami una stanza lì" e lui lo farà. Questa è un'idea incredibilmente impraticabile. 57/

Nessun chatbot è in grado di fare tutte queste cose, qualcosa che Microsoft afferma liberamente. Invece di farlo con un solo chatbot, Microsoft propone di suddividere il compito tra dozzine di chatbot, ciascuno dei quali Microsoft spera di portare fino al 95% di affidabilità. 58/

Questo è uno standard di chatbot assolutamente implausibile in sé, ma considera questo: le probabilità sono *moltiplicative*. Un sistema che contiene due processi che operano con una affidabilità del 95% ha un'affidabilità netta del 90,25% (0,95 * 0,95). 59/

Dividi un compito tra un paio di dozzine di bot con il 95% di precisione e la possibilità che questo compito venga svolto correttamente si avvicina a *zero*. 60/

Nel frattempo, un dirigente di Microsoft ha avuto problemi lo scorso dicembre quando ha pubblicato su Linkedin annunciando la sua intenzione di far riscrivere *tutto* il codice di Microsoft dall'AI. 63/

Rifattorizzare il codice di Microsoft ha molto senso. Microsoft - come British Airways e altre aziende storiche - ha molto codice molto vecchio che rappresenta un debito tecnologico insostenibile. 64/

Alcuni di voi *sono* ingegneri del software che hanno trovato i chatbot incredibilmente utili per scrivere codice per voi. Questo è un comune paradosso dell'AI: perché alcune persone che usano l'AI la trovano davvero utile, mentre altre la detestano? 66/

È vero che le persone che non amano l'AI sono "scarse nell'AI?" È vero che i fan dell'AI sono pigri e non si preoccupano della qualità del loro lavoro? 67/

C'è senza dubbio un po' di entrambi in corso, ma anche se insegni a tutti a diventare esperti di AI e escludi tutti coloro che non si prendono cura del proprio lavoro dal campione, il paradosso rimarrà comunque. 68/

La vera soluzione al paradosso dell'AI risiede nella teoria dell'automazione e nel concetto di "centauri" e "centauri inversi": 69/

Nella teoria dell'automazione, un "centauro" è una persona assistita da una macchina. Un "centauro inverso" è qualcuno che è stato arruolato per *assistere una macchina*. 70/

Diciamo che sei un ingegnere del software che utilizza l'AI per scrivere codice di routine che hai il tempo e l'esperienza di convalidare, impiegando il tuo Fingerspitzengefühl e la tua conoscenza del processo per garantire che sia adatto allo scopo. 71/

È facile capire perché potresti trovare utile utilizzare l'AI (quando scegli di farlo, nei modi che scegli, al ritmo che scegli di seguire). Ma supponiamo che tu sia un ingegnere del software a cui è stato ordinato di produrre codice a 10 volte, 100 volte o 10.000 volte il tuo tasso precedente. 72/

Dì che l'unico modo per farlo è tramite AI, e non c'è modo umano in cui tu possa rivedere quel codice e assicurarti che non si rompa al primo contatto con il mondo, lo odierai: 73/

(Lo odierai ancora di più se sei stato trasformato nel bacino di responsabilità dell'AI, personalmente responsabile degli errori dell'AI.) C'è un altro modo in cui gli ingegneri del software trovano il codice generato dall'AI incredibilmente utile: quando quel codice è *isolato*. 74/

Se stai facendo un singolo progetto - diciamo, convertire un lotto di file in un altro formato, solo una volta - non devi preoccuparti dei processi a valle, a monte o adiacenti. Non ce ne sono. 75/

Stai scrivendo codice per fare qualcosa una sola volta, senza interagire con altri sistemi. Un *gran* parte della programmazione è questo tipo di progetto utilitario. È noioso, ingrato e pronto per l'automazione. 76/

Molti progetti personali rientrano in questa categoria e, per definizione, un progetto personale è un progetto centauro. Nessuno ti costringe a usare l'AI in un progetto personale: è sempre una tua scelta come e quando fare uso personale di qualsiasi strumento. 77/

Ma il fatto che gli ingegneri del software possano a volte migliorare il loro lavoro con l'AI non invalida il fatto che il codice è una responsabilità, non un'attività, e che il codice AI rappresenta una produzione di responsabilità su larga scala. 78/

Nella storia della disoccupazione tecnologica, c'è l'idea che la nuova tecnologia crei nuovi posti di lavoro anche mentre rende obsoleti quelli vecchi: per ogni fabbro messo fuori lavoro dall'automobile, c'è un lavoro che aspetta come meccanico. 79/

Negli anni da quando la bolla dell'AI ha iniziato a gonfiarsi, abbiamo sentito molte versioni di questo: l'AI creerebbe posti di lavoro per "prompt engineers" - o addirittura creerebbe lavori che non possiamo immaginare, perché non esisteranno fino a quando l'AI non avrà cambiato il mondo oltre ogni riconoscimento. 80/

Non punterei a trovare lavoro in un mestiere fantasioso che letteralmente non può essere immaginato perché le nostre coscienze non sono state così alterate dall'AI da acquisire la capacità di concettualizzare queste nuove modalità di lavoro. 81/

Ma se stai *cercando* un lavoro che l'AI creerà sicuramente, per milioni, ho un suggerimento: rimozione dell'amianto digitale. 82/

Il codice AI - scritto a 10.000 volte la velocità di qualsiasi programmatore umano, progettato per funzionare bene, ma non per fallire in modo elegante - è l'amianto digitale con cui stiamo riempiendo le nostre pareti. I nostri discendenti passeranno generazioni a estrarre quell'amianto dalle pareti. 83/

Ci sarà molto lavoro per sistemare le cose che abbiamo rotto grazie alla più pericolosa psicosi dell'AI di tutte: la credenza allucinatoria che "scrivere codice" sia la stessa cosa di "ingegneria del software." 84/

Con il ritmo che stiamo seguendo, avremo piena occupazione per generazioni di rimuovitori di amianto. 85/