Koden är en skuld (inte en tillgång). Teknikchefer förstår inte detta. De tycker att AI är bra eftersom det producerar 10 000 gånger mer kod än en programmerare, men det betyder bara att det producerar 10 000 gånger fler ansvar. 1/

Om du vill ha en uppsats-formaterad version av denna tråd att läsa eller dela, här är en länk till den på, min övervakningsfria, annonsfria, spårfria blogg: 2/

AI är asbesten vi skyfflar in i väggarna i vårt högteknologiska samhälle: Kod är en belastning. Kodens *förmågor* är tillgångar. 3/

Målet med en teknikfirma är att ha kod vars kapacitet genererar mer intäkter än kostnaderna för att hålla koden igång. 4/

Under lång tid har företag närt en felaktig tro att kod kostar mindre att köra över tid: efter en inledande genomgångsperiod där buggar i koden hittas och åtgärdas, upphör koden att behöva meningsfullt underhåll. 5/

Kod är trots allt en maskin utan rörliga delar – den slits inte ut; Den slits inte ens ner. Detta är tesen i Paul Masons bok från 2015 *Postkapitalism*, en bok som har åldrats anmärkningsvärt dåligt (även om den kanske inte är lika dålig som Masons egen politiska trovärdighet). 6/

Kod är inte en oändligt reproducerbar maskin som inte kräver något arbete. Snarare är det en skör maskin som kräver allt mer heroiska åtgärder för att hålla den i gott skick, och som till slut "slits ut" (i betydelsen att den behöver en omstrukturering från topp till tå). 7/

För att förstå varför kod är en belastning måste du förstå skillnaden mellan att "skriva kod" och "mjukvaruutveckling." "Att skriva kod" är en otroligt användbar, rolig och fängslande sysselsättning. 8/

Det innebär att komplexa uppgifter delas upp i diskreta steg, så exakt beskrivna att en dator pålitligt kan utföra dem, och optimerar prestandan genom att hitta smarta sätt att minimera de krav koden ställer på datorns resurser, såsom RAM och processorcykler. 9/

Samtidigt är "mjukvaruutveckling" en disciplin som omfattar "kodskrivning", men med fokus på de långsiktiga operationerna i *systemet* som koden är en del av. 10/

Mjukvaruteknik handlar om de uppströmsprocesser som genererar den data systemet tar emot. Den handlar om de nedströmsprocesser som systemet skickar bearbetad information till. 11/

Den handlar om de angränsande systemen som tar emot data från samma uppströmsprocesser och/eller sänder data till samma nedströmsprocesser som systemet sänder ut till. 12/

"Att skriva kod" handlar om att skapa kod som *fungerar bra*. "Mjukvaruutveckling" handlar om att skapa kod som *misslyckas bra*. Det handlar om att skapa kod som är läsbar – vars funktioner kan förstås av tredje part som kan bli ombedda att underhålla den. 13/

Dessa tredje parter kan bli ombedda att anpassa processerna nedströms, uppströms eller intill systemet för att förhindra att systemet går sönder. 14/

Det är just det: all icke-trivial kod måste interagera med omvärlden, och den yttre världen är inte statisk, den är *dynamisk*. Omvärlden bryter igenom de antaganden som mjukvaruutvecklare gör *hela tiden* och varje gång måste mjukvaran fixas. 16/

Kommer du ihåg Y2K? Det var en dag då perfekt fungerande kod, som kördes på fullt fungerande hårdvara, slutade fungera – inte för att koden ändrades, utan för att *tiden gick vidare*. 17/

Vi är 12 år från Y2038-problemet, när 32-bitars varianter av Unix slutar fungera, eftersom även de har slut på beräkningsbara sekunder. 18/

Existensen av "världen" är en oundviklig faktor som nöter ut mjukvara och kräver att den byggs om, ofta till enorma kostnader. Ju längre koden är i drift, desto mer sannolikt är det att den kommer att möta "världen." 20/

Ta koden som enheterna använder för att rapportera sin fysiska plats. Ursprungligen användes detta för saker som fakturering – att avgöra vilken operatör eller leverantörs nätverk du använde och om du roaming. 21/

Sedan använde våra mobila enheter denna kod för att hjälpa till att bestämma din position och ge dig sväng-för-sväng vägbeskrivningar i navigationsappar. Sedan återanvändes denna kod igen för att hjälpa oss hitta våra förlorade enheter. 22/

Detta blev ett sätt att hitta *stulna* enheter, ett användningsfall som skiljer sig markant från att hitta förlorade enheter. När du hittar en förlorad enhet behöver du inte hantera möjligheten att en illvillig aktör har inaktiverat funktionen "hitta min förlorade enhet". 23/

Dessa ytterligare användningsområden – uppströms, nedströms och angränsande – avslöjade buggar i den ursprungliga koden som aldrig dök upp i de tidigare applikationerna. 24/

Till exempel måste alla platstjänster ha någon form av standardbeteende i det (mycket vanliga) fallet att de inte riktigt är säkra på var de befinner sig. 25/

Kanske har de en allmän fix – till exempel vet de vilken cellmast de är kopplade till, eller så vet de var de var *senast* gången de fick en exakt positionsfix – eller så är de helt vilse. 26/

Det visar sig att i många fall ritade platsappar en cirkel runt alla platser där de *kunde* vara och sedan satte sin plats till mitten av den cirkeln. 27/

Det är okej om cirkeln bara är några fot i diameter, eller om appen snabbt ersätter denna approximation med en mer exakt position. Men tänk om platsen är mil efter mil tvärs och platsfixen *aldrig* förbättras? 28/

Vad händer om platsen för vilken IP-adress som helst utan definierad plats anges som *centrum av det kontinentala USA* och alla appar som inte vet var de är rapporterar att de är i ett hus i Kansas? 29/

Och i min stad Burbank, där Googles platsdelningstjänst en gång berättade för oss att vår då elvaåriga dotter (vars telefon vi inte kunde nå) låg 12 miles bort, på en motorvägsavfart i ett icke-inkorporerat område i LA County. 32/

(Hon var i en närliggande park, men utom räckhåll, och appen uppskattade hennes plats som centrum för den region där hon senast hade varit inflyttad.) (Det var ett tufft par timmar.) 33/

Den underliggande koden – koden som använder någon tidigare ofarlig standard för att fuska med okända platser – måste uppdateras *konstant*, eftersom processerna uppströms, nedströms och angränsande som är kopplade till den ändras *konstant*. 34/

Ju längre koden ligger där, desto mer överåldrade blir dess ursprungliga beteenden, och desto mer barocka, smutsiga och fördunklade blir de fläckar som lagts ovanpå den. 35/

Kod är ingen tillgång – det är en belastning. Ju längre ett datorsystem har varit igång, desto mer teknikskuld representerar det. Ju viktigare systemet är, desto svårare är det att ta ner och helt göra om. 36/

Istället läggs nya lager av kod ovanpå, och där kodlagren möts finns det sprickor där dessa system beter sig på sätt som inte riktigt stämmer överens. 37/

Ännu värre: när två företag slås ihop slås deras sammanflätade, sprickiga IT-system ihop, så att det nu finns *angränsande* källor till teknikskulder, samt uppströms och nedströms sprickor: 38/

Det är därför jättestora företag är så sårbara för ransomware-attacker – de är fulla av inkompatibla system som har lockats till en kopia av kompatibilitet med olika former av digital silly putty, snöre och baltråd. 39/

De är inte vattentäta och kan inte göras vattentäta. Även om de inte tas ner av hackare ramlar de ibland bara omkull och kan inte ställas upp igen. 40/

Minns du när Southwest Airlines datorer kraschade under hela julveckan 2022 och lämnade miljontals resenärer strandsatta? 41/

Flygbolag är särskilt dåliga eftersom de datoriserade tidigt och aldrig kan stänga ner de gamla datorerna för att ersätta dem med nya. Det är därför deras appar är så usla. 42/

Det är därför det är så hemskt att flygbolagen sparkade sin kundtjänstpersonal och kräver att flygare använder apparna för *allt*, trots att apparna inte fungerar. Dessa appar kommer aldrig att fungera. 43/

Anledningen till att British Airways app visar "Ett okänt fel har inträffat" 40–80 % av gångerna är inte (bara) att de sparkade all IT-personal och outsourcade dem till lågpristagare utomlands. 44/

Det är det, visst – men också att BAs första datorer kördes på elektromekaniska ventiler, och allt sedan dess måste vara bakåtkompatibelt med ett system som en av Alan Turings skyddslingar gnagt ur en hel stock med sina egna framtänder. 45/

Kod är en belastning, inte en tillgång (BA:s nya app är flera år efter schemat). Kod är en belastning. Servrarna för Bloomberg-terminalerna som förvandlade Michael Bloomberg till miljardär och körde på RISC-chip. 46/

Detta innebär att de är låsta till att använda ett minskande antal specialiserade hårdvaru- och datacenterleverantörer, betala specialiserade programmerare och bygga sköra kodedjor för att koppla dessa RISC-system till deras mindre exotiska motsvarigheter i världen. Kod är ingen tillgång. 47/

AI kan skriva kod, men AI kan inte göra mjukvaruutveckling. Mjukvaruutveckling handlar om att tänka igenom *kontext* – vad kommer före detta system? Vad kommer efter det? Vad kommer att stå bredvid den? Hur kommer världen att förändras? 48/

Mjukvaruutveckling kräver ett mycket brett "kontextfönster", det som AI inte har, och inte kan ha. AI-kontextfönstret är smalt och ytligt. Linjära ökningar av AI:s kontextfönster kräver *geometriska* utvidgningar av beräkningskrav: 49/

Att skriva kod som fungerar, utan att tänka på hur den kommer att misslyckas, är ett recept på katastrof. Det är ett sätt att skapa teknikskuld i stor skala. Det skyfflar asbest in i väggarna i vårt teknologiska samhälle. 50/

Chefer *vet inte* att kod är en belastning, inte en tillgång. Det är därför de inte kan hålla käften om chatbots som skiter ut 10 000 gånger mer kod än någon mänsklig programmerare. 51/

De tror att de har hittat en maskin som producerar *tillgångar* i 10 000 gånger hastigheten av en mänsklig programmerare. Det har de inte. De har hittat en maskin som producerar *ansvar* i 10 000 gånger högre takt än någon mänsklig programmerare. 52/

Underhållbarhet handlar inte bara om hårt förvärvad erfarenhet som lär dig var fallgroparna finns. 53/

Det kräver också odling av "Fingerspitzengefühl" – "fingertoppskänslan" som låter dig göra rimliga gissningar om var aldrig tidigare skådade fallgropar kan uppstå. 54/

Det är en form av processkunskap. Det är oundvikligt. Den finns inte latent ens i den största kodkorpusen som du kan använda som träningsdata: *Oj* teknikchefer förstår verkligen inte detta. 55/

Ta Microsoft. Deras stora satsning just nu är på "agentisk AI." De vill installera spionprogram på din dator som fångar varje tangenttryckning, varje kommunikation, varje skärm du ser och skickar det till Microsofts moln och ge en mängd chattbotar tillgång till det. 56/

De påstår att du kan säga till din dator, "Boka ett tåg till Cardiff åt mig och hitta det hotell Cory nämnde förra året och boka ett rum där" och det kommer att fungera. Detta är en otroligt ogenomförbar idé. 57/

Ingen chatbot är ens i närheten kapabel att göra allt detta, något som Microsoft fritt föreskriver. Istället för att göra detta med en chatbot föreslår Microsoft att dela upp den i dussintals chatbots, där Microsoft hoppas kunna nå upp till 95 % tillförlitlighet. 58/

Det är en fullständigt osannolik chatbot-standard i sig, men tänk på detta: sannolikheter är *multiplikativa*. Ett system som innehåller två processer som arbetar med 95 % tillförlitlighet har en nettotillförlitlighet på 90,25 % (0,95 * 0,95). 59/

Bryt upp en uppgift mellan ett par dussin 95 % noggranna bots och chansen att denna uppgift blir korrekt utförd går till *noll*. 60/

Under tiden hamnade en Microsoft-chef i trubbel i december förra året när han postade på Linkedin och meddelade sin avsikt att låta AI skriva om *all* Microsofts kod. 63/

Att refaktorera Microsofts kodbas är mycket vettigt. Microsoft – liksom British Airways och andra äldre företag – har mycket mycket gammal kod som representerar ohållbar teknikskuld. 64/

Några av er *är* mjukvaruingenjörer som har funnit chatbots otroligt användbara för att skriva kod åt er. Detta är en vanlig AI-paradox: varför tycker vissa som använder AI att det är väldigt hjälpsamt, medan andra avskyr det? 66/

Är det så att de som inte gillar AI är "dåliga på AI"? Är det så att AI-fansen är lata och inte bryr sig om kvaliteten på sitt arbete? 67/

Det finns säkert en del av båda som pågår, men även om du lär alla att bli AI-experter och rensar bort alla som inte är stolta över sitt arbete ur urvalet, kommer paradoxen ändå att finnas kvar. 68/

Den verkliga lösningen på AI-paradoxen ligger i automationsteorin och begreppet "kentaurer" och "omvända kentaurer": 69/

Inom automationsteori är en "kentaur" en person som assisteras av en maskin. En "omvänd kentaur" är någon som har blivit inkallad till *att assistera en maskin*. 70/

Säg att du är en mjukvaruingenjör som använder AI för att skriva rutinkod som du har tid och erfarenhet att validera, och använder din kunskap om Fingerspitzengefühl och processer för att säkerställa att den är ändamålsenlig. 71/

Det är lätt att förstå varför du kan tycka att det är användbart att använda AI (när du väljer, på sätt du vill, i den takt du väljer att gå i). Men säg att du är en mjukvaruingenjör som har fått order att producera kod med 10x, 100x eller 10 000x högre hastighet än tidigare. 72/

Säg att det enda sättet att göra det är via AI, och det finns inget mänskligt sätt för dig att granska koden och säkerställa att den inte går sönder vid första kontakten med världen, då kommer du att hata det: 73/

(Du kommer att hata det ännu mer om du har blivit AI:ns ansvarssänkare, personligen ansvarig för AI:ns misstag.) Det finns ett annat sätt som mjukvaruingenjörer tycker att AI-genererad kod är otroligt hjälpsam: när den koden är *isolerad*. 74/

Om du gör ett enda projekt – till exempel konverterar en batch filer till ett annat format, bara en gång – behöver du inte oroa dig för processerna nedströms, uppströms eller angränsande processer. Det finns inga. 75/

Du skriver kod för att göra något en gång, utan att interagera med några andra system. *Mycket* kodning är den här typen av verktygsprojekt. Det är tråkigt, otacksamt och redo för automatisering. 76/

Många personliga projekt faller inom denna kategori, och naturligtvis är ett personligt projekt per definition ett kentaurprojekt. Ingen tvingar dig att använda AI i ett personligt projekt – det är alltid ditt val hur och när du använder ett verktyg personligen. 77/

Men det faktum att mjukvaruingenjörer ibland kan förbättra sitt arbete med AI ogiltigförklarar inte det faktum att kod är en belastning, inte en tillgång, och att AI-kod representerar ansvarsproduktion i stor skala. 78/

I berättelsen om teknologisk arbetslöshet finns idén att ny teknik skapar nya jobb samtidigt som den gör gamla föråldrade: för varje smed som bilen tvingar bort sitt arbete finns det ett jobb som fastnat som mekaniker. 79/

Under åren sedan AI-bubblan började växa har vi hört många versioner av detta: AI skulle skapa jobb för "prompt engineers" – eller till och med skapa jobb som vi inte kan föreställa oss, eftersom de inte kommer att existera förrän AI har förändrat världen bortom igenkänning. 80/

Jag skulle inte satsa på att få arbete inom ett fantasiyrke som bokstavligen inte kan föreställas eftersom våra medvetanden inte har förändrats så mycket av AI att de har fått förmågan att konceptualisera dessa nya arbetssätt. 81/

Men om du *är* ute efter ett jobb som AI definitivt kommer att skapa, i miljontal, har jag ett förslag: digital asbestborttagning. 82/

AI-kod – skriven i 10 000 gånger hastigheten hos någon mänsklig kodare, designad för att fungera bra men inte för att misslyckas med värdighet – är den digitala asbesten vi fyller våra väggar med. Våra ättlingar kommer att tillbringa generationer med att gräva ut asbesten ur murarna. 83/

Det kommer att finnas gott om arbete med att laga det vi förstörde tack vare den farligaste AI-psykosen av alla – den hallucinatoriska tron att "skriva kod" är samma sak som "mjukvaruutveckling." 84/

I den takt vi går kommer vi att ha full sysselsättning för generationer av asbestborttagare. 85/