Code er en byrde (ikke en eiendel). Tekniske sjefer forstår ikke dette. De mener AI er flott fordi den produserer 10 000 ganger mer kode enn en programmerer, men det betyr bare at den produserer 10 000 ganger flere forpliktelser. 1/

Hvis du vil ha en essayformatert versjon av denne tråden å lese eller dele, her er en lenke til den på min overvåkingsfrie, annonsefrie, sporingsfrie blogg: 2/

KI er asbesten vi skyver inn i veggene i vårt høyteknologiske samfunn: Kode er en risiko. Kodens *kapabiliteter* er ressurser. 3/

Målet med et teknisk studio er å ha kode som genererer mer inntekter enn kostnadene ved å holde koden i gang. 4/

I lang tid har firmaer næret en feilaktig tro på at kode koster mindre å kjøre over tid: etter en innledende prøveperiode hvor feilene i koden er funnet og utbedret, trenger koden ikke lenger meningsfull vedlikehold. 5/

Tross alt er kode en maskin uten bevegelige deler – den slites ikke ut; Den slites ikke engang ned. Dette er tesen i Paul Masons bok fra 2015, *Postkapitalisme*, en bok som har eldet bemerkelsesverdig dårlig (selv om den kanskje ikke er like dårlig som Masons egen politiske troverdighet). 6/

Kode er ikke en uendelig reproduserbar maskin som ikke krever noe arbeid. Snarere er det en sprø maskin som krever stadig mer heroiske tiltak for å holde den i god stand, og som til slutt "slites ut" (i betydningen at den trenger en omstrukturering fra topp til bunn). 7/

For å forstå hvorfor kode er en byrde, må du forstå forskjellen mellom å «skrive kode» og «programvareutvikling». "Å skrive kode" er en utrolig nyttig, morsom og engasjerende fritidsaktivitet. 8/

Det innebærer å dele opp komplekse oppgaver i diskrete trinn, så presist beskrevet at en datamaskin pålitelig kan utføre dem, og optimalisere ytelsen ved å finne smarte måter å minimere kravene koden legger på datamaskinens ressurser, som RAM og prosessorsykluser. 9/

Samtidig er «programvareutvikling» en disiplin som omfatter «å skrive kode», men med fokus på de langsiktige operasjonene til *systemet* koden er en del av. 10/

Programvareutvikling omhandler de oppstrøms prosessene som genererer dataene systemet mottar. Den omhandler de nedstrøms prosessene som systemet sender bearbeidet informasjon til. 11/

Den omhandler de tilstøtende systemene som mottar data fra de samme oppstrømsprosessene og/eller sender ut data til de samme nedstrømsprosessene som systemet sender ut til. 12/

"Å skrive kode" handler om å lage kode som *kjører bra*. "Programvareutvikling" handler om å lage kode som *feiler godt*. Det handler om å lage kode som er lesbar – hvis funksjoner kan forstås av tredjepart som kan bli bedt om å vedlikeholde den. 13/

Disse tredjepartene kan bli bedt om å tilpasse prosessene nedstrøms, oppstrøms eller ved siden av systemet for å hindre at systemet bryter sammen. 14/

Det er nettopp det: all ikke-triviell kode må samhandle med omverdenen, og den ytre verden er ikke statisk, den er *dynamisk*. Omverdenen bryter gjennom antakelsene som programvareutviklere gjør *hele tiden*, og hver gang den gjør det, må programvaren fikses. 16/

Husker du Y2K? Det var en tid da perfekt fungerende kode, som kjørte på perfekt fungerende maskinvare, sluttet å fungere – ikke fordi koden endret seg, men fordi *tiden marsjerte videre*. 17/

Vi er 12 år unna Y2038-problemet, når 32-bits varianter av Unix vil slutte å fungere, fordi også de vil ha gått tom for beregnbare sekunder. 18/

Eksistensen av «verden» er en uunngåelig faktor som sliter ut programvaren og krever at den bygges opp igjen, ofte til enorme kostnader. Jo lenger kode er i bruk, desto mer sannsynlig er det at den vil møte «verden». 20/

Ta koden enhetene bruker for å rapportere sin fysiske plassering. Opprinnelig ble dette brukt til ting som fakturering – å avgjøre hvilken operatør eller leverandørs nettverk du brukte og om du roamte. 21/

Deretter brukte våre mobile enheter denne koden for å hjelpe deg med å bestemme posisjonen din, slik at du kunne gi deg tur-for-sving veibeskrivelse i navigasjonsapper. Deretter ble denne koden omgjort igjen for å hjelpe oss å finne våre tapte enheter. 22/

Dette ble en måte å finne *stjålne* enheter på, et bruksområde som avviker markant fra å finne tapte enheter. Når du finner en tapt enhet, trenger du ikke å forholde deg til muligheten for at en ondsinnet aktør har deaktivert «finn min tapte enhet»-funksjonen. 23/

Disse ekstra bruksområdene – oppstrøms, nedstrøms og tilstøtende – avdekket feil i den opprinnelige koden som aldri dukket opp i de tidligere applikasjonene. 24/

For eksempel må alle lokasjonstjenester ha en eller annen form for standardoppførsel i det (svært vanlige) tilfellet at de ikke er helt sikre på hvor de befinner seg. 25/

Kanskje de har en generell løsning – for eksempel vet de hvilken cellemast de er koblet til, eller de vet hvor de var *sist* gang de fikk en nøyaktig posisjonsfesting – eller kanskje de er helt fortapt. 26/

Det viser seg at i mange tilfeller tegnet lokasjonsapper en sirkel rundt alle stedene de *kunne* være, og satte deretter lokasjonen sin til midten av den sirkelen. 27/

Det er greit hvis sirkelen bare er noen få fot i diameter, eller hvis appen raskt erstatter denne tilnærmingen med en mer presis plassering. Men hva om plasseringen er milevis bred, og lokasjonsløsningen *aldri* blir bedre? 28/

Hva om plasseringen for en hvilken som helst IP-adresse uten definert plassering er oppgitt som *sentrum av det kontinentale USA* og enhver app som ikke vet hvor den er, rapporterer at den er i et hus i Kansas? 29/

Og i byen min Burbank, hvor Googles posisjonsdelingstjeneste en gang fortalte oss at vår da 11 år gamle datter (hvis telefon vi ikke fikk tak i) var 12 miles unna, på en motorveirampe i et ikke-inkorporert område i LA County. 32/

(Hun var i en nærliggende park, men utenfor rekkevidde, og appen anslo posisjonen hennes som sentrum av regionen den sist hadde festet henne i.) (Det var noen tøffe timer.) 33/

Den underliggende koden – koden som bruker en tidligere ufarlig standard for å manipulere ukjente steder – må oppdateres *kontinuerlig*, fordi oppstrøms, nedstrøms og tilstøtende prosesser som er koblet til den endrer seg *konstant*. 34/

Jo lenger koden ligger der, desto mer gammeldags blir dens opprinnelige atferd, og desto mer barokke, grove og tilslørte blir som ligger oppå den. 35/

Kode er ikke en eiendel – det er en byrde. Jo lenger et datasystem har vært i drift, desto mer teknologisk gjeld representerer det. Jo viktigere systemet er, desto vanskeligere er det å ta ned og gjøre helt om. 36/

I stedet legges nye lag med kode oppå den, og der lagene møtes, oppstår det sprekker der disse systemene oppfører seg på måter som ikke helt stemmer overens. 37/

Enda verre: når to selskaper fusjoneres, blir deres sammenflettede, sprukne IT-systemer slått sammen, slik at det nå finnes *tilstøtende* kilder til teknologigjeld, samt oppstrøms og nedstrøms sprekker: 38/

Derfor er gigantiske selskaper så sårbare for løsepengevirusangrep – de er fulle av inkompatible systemer som har blitt overtalt til en kopi av kompatibilitet med ulike former for digital silly putty, snor og baletråd. 39/

De er ikke vanntette og kan ikke gjøres vanntette. Selv om de ikke blir tatt ned av hackere, faller de noen ganger bare over og kan ikke reise seg opp igjen. 40/

Husker du da Southwest Airlines' datamaskiner krasjet hele juleuken 2022, og millioner av reisende ble strandet? 41/

Flyselskaper er spesielt dårlige, fordi de digitaliserte tidlig, og kan aldri slå av de gamle datamaskinene for å erstatte dem med nye. Dette er grunnen til at appene deres er så elendige. 42/

Dette er grunnen til at det er så forferdelig at flyselskapene sparket kundeservicemedarbeiderne sine og krever at passasjerer bruker appene til *alt*, selv om appene ikke fungerer. Disse appene vil aldri fungere. 43/

Grunnen til at British Airways' app viser «En ukjent feil har oppstått» 40-80 % av gangene, er ikke (bare) at de har sparket alle IT-ansatte og satt ut til lavt bud i utlandet. 44/

Det er det, ja, men også at BAs første datamaskiner gikk på elektromekaniske ventiler, og alt siden da må være bakoverkompatibelt med et system som en av Alan Turings protegéer gnagde ut av en hel stokk med sine egne fortenner. 45/

Kode er en byrde, ikke en eiendel (BAs nye app er flere år bak skjema). Kode er en risiko. Serverne til Bloomberg-terminalene som gjorde Michael Bloomberg til milliardær, drevet av RISC-brikker. 46/

Dette betyr at de er bundet til å bruke et stadig mindre antall spesialiserte maskinvare- og datasenterleverandører, betale spesialiserte programmerere, og bygge skjøre kodekjeder for å koble disse RISC-systemene til deres mindre eksotiske ekvivalenter i verden. Kode er ikke en ressurs. 47/

AI kan skrive kode, men AI kan ikke drive med programvareutvikling. Programvareutvikling handler om å tenke gjennom *kontekst* – hva vil komme før dette systemet? Hva vil komme etterpå? Hva vil ligge ved siden av den? Hvordan vil verden forandre seg? 48/

Programvareutvikling krever et veldig bredt «kontekstvindu», det AI ikke har, og ikke kan ha. AI-kontekstvinduet er smalt og grunt. Lineære økninger i AIs kontekstvindu krever *geometriske* utvidelser av beregningsbehov: 49/

Å skrive kode som fungerer, uten å ta hensyn til hvordan den vil feile, er en oppskrift på katastrofe. Det er en måte å skape teknologisk gjeld i stor skala. Det er å skyve asbest inn i veggene i vårt teknologiske samfunn. 50/

Sjefer *vet ikke* at kode er en byrde, ikke en ressurs. Derfor vil de ikke holde kjeft om chatbotene som skriver ut 10 000 ganger mer kode enn noen menneskelig programmerer. 51/

De tror de har funnet en maskin som produserer *ressurser* i 10 000 ganger hastigheten til en menneskelig programmerer. Det har de ikke. De har funnet en maskin som produserer *ansvar* i 10 000 ganger hastigheten til en menneskelig programmerer. 52/

Vedlikeholdbarhet handler ikke bare om hardt tilkjempet erfaring som lærer deg hvor fallgruvene ligger. 53/

Det krever også dyrking av «Fingerspitzengefühl» – «fingertuppfølelsen» som lar deg gjøre rimelige gjetninger om hvor aldri før sett fallgruver kan oppstå. 54/

Det er en form for prosesskunnskap. Det er uunngåelig. Den er ikke latent engang i det største kodekorpuset du kan bruke som treningsdata: *Gutt* teknologisjefer skjønner virkelig ikke dette. 55/

Ta Microsoft. Deres store innsats akkurat nå er på «agentisk AI». De vil installere spionprogramvare på datamaskinen din som fanger opp hvert tastetrykk, hver kommunikasjon, hver skjerm du ser, og sender det til Microsofts sky, og gir et mangfold av chatboter tilgang til det. 56/

De hevder at du vil kunne si til datamaskinen din: «Bestill et tog til Cardiff til meg og finn det hotellet Cory nevnte i fjor, og bestill et rom der» og at det ordner seg. Dette er en utrolig urealistisk idé. 57/

Ingen chatbot er i nærheten av å kunne gjøre alle disse tingene, noe Microsoft fritt krever. I stedet for å gjøre dette med én chatbot, foreslår Microsoft å dele den opp i dusinvis av chatboter, hvor hver enkelt Microsoft håper å oppnå opptil 95 % pålitelighet. 58/

Det er en helt usannsynlig chatbot-standard i seg selv, men tenk på dette: sannsynlighetene er *multiplikative*. Et system som inneholder to prosesser som opererer med 95 % pålitelighet, har en netto pålitelighet på 90,25 % (0,95 * 0,95). 59/

Bryt opp en oppgave mellom et par dusin 95 % nøyaktige bots, og sjansen for at denne oppgaven blir utført riktig rundes til *null*. 60/

I mellomtiden havnet en Microsoft-leder i trøbbel i desember i fjor da han postet på Linkedin og kunngjorde sin intensjon om at AI skulle omskrive *all* Microsofts kode. 63/

Å refaktorere Microsofts kodebase gir mye mening. Microsoft – som British Airways og andre etablerte selskaper – har mye veldig gammel kode som representerer uholdbar teknologigjeld. 64/

Noen av dere *er* programvareingeniører som har funnet chatboter utrolig nyttige for å skrive kode for dere. Dette er et vanlig AI-paradoks: hvorfor synes noen som bruker AI at det er veldig hjelpsomt, mens andre misliker det? 66/

Er det slik at de som ikke liker AI er «dårlige på AI»? Er det fordi AI-fansen er late og ikke bryr seg om kvaliteten på arbeidet sitt? 67/

Det finnes utvilsomt noe av begge deler, men selv om du lærer alle å bli AI-eksperter, og fjerner alle som ikke er stolte av arbeidet sitt fra utvalget, vil paradokset fortsatt besto. 68/

Den sanne løsningen på AI-paradokset ligger i automatiseringsteori, og konseptet «kentaurer» og «omvendte kentaurer»: 69/

I automatiseringsteori er en «kentaur» en person som får hjelp av en maskin. En «omvendt kentaur» er en person som har blitt innkalt til å *assistere en maskin*. 70/

Si at du er en programvareingeniør som bruker AI til å skrive rutinekode som du har tid og erfaring til å validere, og bruker din Fingerspitzengefühl- og prosesskunnskap for å sikre at den er egnet til formålet. 71/

Det er lett å forstå hvorfor du kan synes det er nyttig å bruke AI (når du velger det, på måter du ønsker, i et tempo du velger å gå i). Men si at du er en programvareingeniør som har fått ordre om å produsere kode til 10 ganger, eller 100 ganger så mye som tidligere. 72/

Si at den eneste måten å gjøre det på er via AI, og det finnes ingen menneskelig måte du kan gjennomgå koden på og sikre at den ikke går i stykker ved første kontakt med verden, du vil hate den: 73/

(Du vil hate det enda mer hvis du har blitt gjort til AI-ens ansvarlighetssluk, personlig ansvarlig for AI-ens feil.) Det finnes en annen måte programvareingeniører synes AI-generert kode er utrolig nyttig på: når koden er *isolert*. 74/

Hvis du gjør ett enkelt prosjekt – for eksempel konverterer én batch filer til et annet format, bare én gang – trenger du ikke bekymre deg for prosesser nedstrøms, oppstrøms eller tilstøtende prosesser. Det finnes ingen. 75/

Du skriver kode for å gjøre noe én gang, uten å samhandle med andre systemer. En *mye* koding er denne typen nytteprosjekt. Det er kjedelig, utakknemlig og modent for automatisering. 76/

Mange personlige prosjekter faller inn under denne kategorien, og selvfølgelig, per definisjon, er et personlig prosjekt et kentaurprosjekt. Ingen tvinger deg til å bruke AI i et personlig prosjekt – det er alltid ditt valg hvordan og når du personlig bruker et verktøy. 77/

Men det faktum at programvareingeniører noen ganger kan gjøre arbeidet sitt bedre med AI, ugyldiggjør ikke det faktum at kode er en byrde, ikke en ressurs, og at AI-kode representerer ansvarsproduksjon i stor skala. 78/

I historien om teknologisk arbeidsledighet finnes ideen om at ny teknologi skaper nye jobber samtidig som den gjør gamle overflødige: for hver smed som blir satt ut av jobben av bilen, venter det en jobb som mekaniker. 79/

I årene etter at AI-boblen begynte å blåse seg opp, har vi hørt mange versjoner av dette: AI ville skape jobber for «prompt engineers» – eller til og med skape jobber vi ikke kan forestille oss, fordi de ikke vil eksistere før AI har forandret verden til det ugjenkjennelige. 80/

Jeg ville ikke satset på å få jobb i et fantasifullt yrke som bokstavelig talt ikke kan forestilles fordi bevisstheten vår ikke er så endret av AI at de har fått evnen til å konseptualisere disse nye arbeidsmåtene. 81/

Men hvis du *er* på jakt etter en jobb som AI definitivt vil skape, i milliontall, har jeg et forslag: digital asbestfjerning. 82/

AI-kode – skrevet i 10 000 ganger hastigheten til enhver menneskelig koder, designet for å fungere godt, men ikke for å feile grasiøst – er den digitale asbesten vi fyller veggene våre med. Våre etterkommere vil bruke generasjoner på å grave ut asbesten fra murene. 83/

Det vil bli mye arbeid med å fikse det vi ødela takket være den farligste AI-psykosen av alle – den hallusinatoriske troen på at «å skrive kode» er det samme som «programvareutvikling». 84/

I det tempoet vi går, vil vi ha full sysselsetting for generasjoner av asbestfjernere. 85/