Komplexitet försvinner inte, den flyttar

Frågan

Vad är mitt syfte nu när kod är så billig att den i princip är gratis? Som någon som varit ganska tidig med att ta till mig de här verktygen har jag fått varianter av den frågan slängd på mig av vänner, kollegor, elever och till och med mig själv under de senaste åren. Så även om jag höll det för möjligt att det skulle bli så här, kan jag inte påstå att det har varit självklart för mig att vi skulle hamna där vi är idag. Åtminstone inte hela tiden.

Jag är också väldigt envis med att leta hål i mina egna teorier. Jag litar inte på att jag kan förutse framtiden, så jag försöker tänka igenom de framtider jag kan föreställa mig och fatta mina beslut utifrån dem. I den meningen kan man väl kalla mig en ingenjör med en ingenjörs syn på livet. Det är Murphys lag: allt som kan gå fel kommer att gå fel. Så låt oss försöka lista ut vad som kan gå fel och vilka konsekvenserna blir, så att vi kan göra en riskanalys och sätta igång.

Klart att programmering skulle förändras

Vårt område är teknik, och teknik utvecklas hela tiden. Hur naivt var det inte att tro att programmering inte skulle utvecklas? Vad trodde vi? Att det bara skulle komma nya ramverk varje vecka och att det var höjdpunkten för mjukvaruutveckling?

Jag brukar säga till mina elever, halvt på skämt, att det här området alltid har varit i förändring. Vill du jobba med något som inte förändras får du ge dig in i fysik eller något.

För mig är inget av det här ett problem. Jag är en problemlösare. Jag vill lösa problem, jag älskar att hitta problem, och jag är van vid att kunna lösa dem. Jag kan inte lösa alla problem i världen, men jag kan lösa några av dem och ta oss en liten bit framåt.

Det finns en idé jag hela tiden återkommer till när jag försöker förstå vart vi är på väg, och det är Teslers lag. Den säger att varje system har en viss mängd komplexitet som inte går att reducera bort helt. Den kan bara flyttas, mellan användaren och mjukvaran, eller mellan en del av systemet och en annan. Ha den i bakhuvudet, för jag tror att den förklarar i stort sett allt som händer med vårt yrke just nu.

Koden blev billig, leveranserna blev det inte

Så vad hände egentligen? Agenter gjorde det i princip gratis att skriva kod. Ja, du betalar för tokens, men jämfört med timmarna det brukade ta är det ingenting. Problemet är att allt som kommer efter att koden är skriven inte blev gratis samtidigt.

Titta på siffrorna som Laurie Voss sammanställde i sitt föredrag om det här. Utvecklare som slår på autonoma kodagenter skriver ungefär 741 % mer kod, alltså runt åtta gånger så mycket. Men de levererar bara ungefär 30 % snabbare. Missförstå mig inte, 30 % är mycket. Men åtta gånger så mycket kod för en tredjedel mer leveranser? Något har fastnat.

Det som har fastnat just nu är kodgranskning. Människor kan inte bara granska snabbare. En gammal studie från Cisco visade att vår förmåga att faktiskt förstå kod rasar efter ungefär 450 rader i timmen. Den där diffen på 10 000 rader som din agent precis producerade skulle alltså ta dig ungefär en vecka att granska ordentligt. Var ärlig, ingen gör det.

Det självklara draget är att låta maskinerna granska, och det händer redan. Copilot står för mer än var femte kodgranskning på GitHub. Men maskingranskarna är inte tillräckligt bra än. I en jämförelse hittade fyra AI-granskare riktiga buggar i samma kod, och ingen av dem hittade samma bugg. De som försökte hoppa över granskning helt fick lära sig den hårda vägen: Dex Horthy ägnade sex månader åt att säga åt folk att inte läsa koden innan han erkände att det var ett misstag, och Amazon kräver nu att seniora ingenjörer godkänner koden efter en rad driftstopp som spårades tillbaka till agentskriven kod.

En modell kan klara testerna på runt 87 % av ett benchmark, men när Cognition ställde frågan ”skulle maintainern faktiskt merga det här?” sjönk andelen till 54 %. Det glappet är maintainerns känsla för vad bra betyder: kodstil, sidoeffekter, externa system, historik som lever i någons huvud och inte i kodbasen. Tesler skulle säga att det är komplexiteten som inte försvann när skrivandet gjorde det. Den flyttade bara.

Lös en flaskhals och du får nästa

Det är här min ingenjörshjärna börjar köra scenarier. Goldratts begränsningsteori (theory of constraints) säger att varje system har en flaskhals, och att det inte hjälper att snabba upp något som inte är flaskhalsen. Vi snabbade upp koden men inte granskningen. Okej. Men hans andra poäng är den viktiga: när du löser en flaskhals försvinner den inte. Den flyttar, och arbetet hopar sig mot nästa. Det är Teslers lag igen, fast i en fabrik i stället för ett användargränssnitt.

Så låt oss se vad som händer sedan. Säg att vi löser automatiserad kodgranskning, och jag tror att vi gör verkliga framsteg där ganska snart. Vad kommer sen? Förmodligen drift. Hur driftsätter jag det här, hur skalar jag det? Sen säkerhet. Hur håller jag det säkert, privat och från att spåra ur i stor skala?

Nu gör jag det stora antagandet: vi löser dem också. Inte nästa år, jag skulle gissa mer som fem till tio år. Men människor har skrivit enormt mycket om drift och säkerhet, och allt vi kan skriva ner kan vi till slut träna en modell på. Cursors Bugbot gör om varje tumme ner till en regel och sitter på tiotusentals av dem. I samma ögonblick som kunskap lämnar någons huvud och hamnar någonstans där en modell kan lära sig av den, flyttar flaskhalsen igen.

Lägg till ett antagande till som jag tycker är mycket lättare att försvara: efterfrågan på mjukvara är i praktiken oändlig. Tänk på din banks webbplats, frisörens bokningssida, myndighetsportalen du använde förra månaden. De är inte dåliga för att ingen vet hur man gör dem bra. De är dåliga för att det är dyrt och för att de som skulle kunna fixa dem är upptagna med annat.

Oändlig efterfrågan, och plötsligt nästan oändligt utbud. Så var hamnar komplexiteten? Vilken del går inte att flytta över till maskinen?

Delen som inte går att flytta

Min gissning är att det som blir kvar är att ta reda på vad människor faktiskt vill ha, och att definiera vad det innebär att ha löst deras problem.

Varje mjukvara är en formalisering av något en människa ville få gjort. En kund säger ”jag behöver hålla koll på mina beställningar”. Det finns tusentals program som håller koll på beställningar. Men vad det betyder för ett bageri är något helt annat än för en bildelsbutik eller en stor tillverkare. Kravet i sig räcker inte. Hela jobbet är att ta reda på vad de faktiskt menar, och den kunskapen finns inte i träningsdatan. Den finns i huvudet på den som driver verksamheten, och det enda sättet att få ut den är att sätta sig ner och prata med dem.

Den går inte heller att överföra. En kalenderapp och en bokningsapp löser nästan samma problem, och de är ändå två helt olika program med två olika definitioner av bra. Om du någon gång har använt ett verktyg med tusen inställningar som ändå inte gör det du behöver, så har du träffat resultatet av mjukvara som försöker vara allt för alla.

Inget av det här är nytt, förresten. Fred Brooks delade upp svårigheten i mjukvara i tillfällig komplexitet (verktygen, språken, syntaxen) och väsentlig komplexitet, alltså själva problemet. Redan 1986 förutspådde han att inget enskilt verktyg skulle göra oss tio gånger mer produktiva, eftersom den väsentliga delen är den svåra. Vi gjorde koden åtta gånger snabbare och leveranserna blev 30 % snabbare. Jag skulle säga att Brooks håller ganska bra.

Och det är precis vad Teslers lag förutsäger. Agenterna har tagit en stor del av den tillfälliga komplexiteten från oss. Den väsentliga komplexiteten finns kvar, den har bara landat någon annanstans. Som Sean Grove på OpenAI uttryckte det: kod är en projektion av specifikationen där information går förlorad. Så den som skriver specen är programmeraren nu.

Så vad är jobbet? Produktingenjören

På 1960-talet fanns ett yrke som hette systemanalytiker. Deras jobb var inte att skriva kod. Det var att prata med verksamheten och ta reda på vad problemet var. Med tiden blev den rollen det vi kallar produktchef, och vi fick två yrken där det tidigare fanns ett och ett halvt. Jag tror att de håller på att smälta ihop till ett igen.

Namnet jag gillar för det är produktingenjör: någon som tar reda på vad människor behöver, definierar hur ett bra resultat ser ut och levererar det, med agenter som gör skrivandet. Gergely Orosz beskrev den produktinriktade ingenjören redan 2019 som en trevlig egenskap för en ingenjör att ha. Idag skulle jag säga att det har gått från trevligt till nödvändigt. Man ser redan att marknaden betalar för det: platsannonserna för forward deployed engineers, som liknar den här rollen mycket, ökade med runt 800 % på nio månader under 2025.

Jag vet vad några av er tänker: det där är inte programmering. Ni har rätt, det är det inte. Programmeringen görs av en agent. Men det är fortfarande i högsta grad mjukvaruutveckling. Vi kommer att behöva vänja oss vid tanken att det inte längre är samma sak att vara mjukvaruutvecklare och att vara programmerare.

Och eftersom jag lovade att leta hål i mina egna teorier, här är det uppenbara. Det är väldigt bekvämt att komma fram till att allt kan automatiseras utom just det jag råkar tycka om. Det är jag medveten om. Kanske har jag fel, kanske blir även det att definiera vad bra betyder automatiserat. Men i så fall måste komplexiteten fortfarande bo någonstans, och jag står hellre där den landar än där den lämnade.

Vad kan gå fel: juniorerna

Nu till riskanalysen, för det är här saker faktiskt går fel, och det har de redan gjort.

Sättet vi brukade lära upp juniora utvecklare på var att ge dem en välspecificerad ticket, låta dem skriva koden och sedan berätta allt de gjort fel. Det är exakt det vi gör med kodagenter nu. Det steget in i yrket är borta. Arbetsmarknadsstatistik sedan 2023 visar att sysselsättningen för ingenjörer mellan 22 och 25 år rasar, medan efterfrågan på ingenjörer i 40-årsåldern har ökat. Seniora personer är mer värdefulla än någonsin, och juniorerna lämnas ute i kylan.

Det här berör mig personligen, för det är mina elever. Om efterfrågan på mjukvara är nära oändlig behöver vi ett enormt antal produktingenjörer, och vi måste få dem någonstans ifrån. Googles program för associate product managers producerar kanske 50 personer om året, och alla liknande program tillsammans runt tusen. Vi behöver minst tio gånger så många. Universiteten lär ut datastrukturer, bootcamps lär ut React, men ingen lär ut ”gå och sitt med en bagare i en vecka och kom tillbaka med en spec”.

Så om du leder ett team kommer du att behöva odla de här människorna medvetet. IBM håller redan på att göra om sina ingångsroller kring att prata med kunder och skriva specar i stället för att skriva kod. Och om du är lärare som jag är jobbet att lära eleverna att hitta problem och definiera dem, inte bara att lösa de problem de får i handen.

Dagen jag hittade datorer

Jag minns dagen jag hittade datorer, och jag menar verkligen hittade datorer. Jag hade använt dem på olika sätt i ett par år, men det var inte förrän vi fick en PC som jag verkligen hittade dem. Eller mer korrekt: det var inte förrän jag hade sönder den datorn och var tvungen att laga den själv. Det tog ett tag, men till slut lyckades jag få Windows 95 att fungera igen. Jag lärde mig den dagen att vissa filer i mappen C:\Windows\System inte var bra att ta bort.

Problemet löst. Jag hade väl kunnat gå vidare då. Datorer var lösta.

Det är så många låter idag. De hittade något de gillade, nu håller det på att bli löst, och de flippar ur. Var och en får tycka som de vill. Jag bryr mig inte så mycket, och jag misstänker att inte de flesta andra gör det heller, om du inte är en av just de personerna. Det finns nya problem att lösa, och det är det som är intressant för mig.

Jag vill ändå inte vifta bort det helt. Många kom in i det här för hantverkets skull: en ren abstraktion, att äntligen knäcka en elak bugg, att få en maskin att göra exakt det du sa åt den. De valde inte yrket för att intervjua bagare. Men jag skulle be dem fundera på vad de egentligen älskade. För mig var det aldrig skrivandet. Det var ögonblicket precis innan skrivandet, när problemet klickade och jag kunde se hur jag skulle göra om det till något som fungerar. Det ögonblicket försvinner inte. Och hantverket kommer att överleva på samma sätt som snickeriet överlevde möbelfabriken. Folk kommer fortfarande att programmera för att de älskar det. Det blir bara inte det de flesta av oss får betalt för.

Så, nu sätter vi igång

Riskanalysen är gjord, så vad gör vi faktiskt på måndag?

De närmaste åren kommer att bli röriga. Verktygen kommer innan vi är redo, och juniorstegen försvann innan vi hunnit bygga en ny. Men det här har hänt förut. Kompilatorer, ramverk och öppen källkod gjorde var och en en hel generations skrivande onödigt, och varje gång kom vi ut på andra sidan med fler mjukvaruutvecklare, inte färre. Vi ändrade bara vad jobbet betydde.

Så, vad är mitt syfte nu när kod är gratis? Samma som det alltid har varit. Teslers lag säger att komplexiteten aldrig försvinner, den flyttar bara. Mitt jobb är att följa efter den, hitta problemet och lösa det. Murphy garanterar att det alltid kommer att finnas ett till.