När AI skriver koden måste vi lära ut omdöme

Idag är systemtänkande, samarbete, problemlösning, robust mjukvara, produktdesign och arkitektur viktigare än programmering. Det är sådant jag försöker lära mina elever.

Förståelse för sociotekniska system väger tyngre än något enskilt programmeringsspråk. På sätt och vis har det alltid varit så, men förr lärde man sig de här förmågorna genom att börja som programmerare. Ju bättre man lärde känna verksamheten, desto mindre kodade man.

Vad kodandet lärde oss

Det är lätt att läsa det som att kodandet bara var något man gjorde tills man lärt sig det som verkligen räknades. Men kodandet var det långsamma och smärtsamma sättet att få känsla för system. Man lärde sig vad robusthet betydde när en bugg i ens egen kod väckte en klockan 03:00. Man förstod varför arkitektur spelar roll efter att ha slitit sitt hår i en usel arkitektur. Systemtänkande som lärs ut med powerpoint blir å andra sidan lätt bara ord. Eleverna kan säga ”feedback loop” och ”single point of failure” utan att någonsin ha bränt sig på någon av dem. Begreppen är lätta att lära sig utantill, men de betyder inte mycket förrän man faktiskt har upplevt dem.

Den svåra frågan är alltså inte om sociotekniska förmågor betyder mer än syntax. Den är vad som ska ersätta den långsamma, smärtsamma återkoppling som kodandet gav.

Ansvar ger återkoppling

Jag tror att man lär sig mer av att ansvara för ett system efter lanseringen än av kodgranskningar. När du själv måste drifta ett system som går sönder på oväntade sätt i sämsta tänkbara ögonblick, lär du dig vad robusthet faktiskt kostar.

Stakeholders som ändrar sig halvvägs tvingar fram ett tänkande kring produktdesign som ingen spec kan ge.

Kaosövningar och postmortems som eleverna skriver själva gör samma sak när det gäller fel. De fungerar bäst när eleverna spårar en incident tillbaka till en organisatorisk orsak i stället för en teknisk.

Att bedöma genererad kod mot krav, risker och underhållbarhet är nog det som idag ligger närmast vad seniora utvecklare faktiskt gör. AI är juniorprogrammeraren vars kod du måste granska. Granskning kräver mindre egen kodning än förr. Men förvånansvärt nog är heller inte lösningen att inte koda alls.

Gemensamt för allt detta är att kalibrering bara kommer av upprepad kontakt med verkligheten. Därför behövs ansvar efter lanseringen, riktiga stakeholders och en del handskriven kod. Powerpoint ger kunskapen. Kontakten med verkligheten ger omdömet.

Det modellen saknar

Det omdömet är precis vad en LLM saknar idag. En modell bär på enorma mängder kunskap: bästa praxis från generationer av utvecklare, komprimerad i dess vikter. Det den saknar är kalibrering mot ditt system, dina användare och dina konsekvenser. Inom en session kan den köra dina tester, läsa dina loggar och se ditt system gå sönder. Men det den lär sig där stannar inte kvar. Minnesfiler och context engineering hjälper, men det den lärde sig idag finns inte i vikterna imorgon. Hos människor avgör det som står på spel vilka lärdomar som fastnar. För en modell står ingenting på spel, och den har inget bestående minne av vad som gick fel. Den kan producera något som ser ut som säkert omdöme, men den kan inte kalibrera omdömet över tid.

Omdömet måste därför ligga hos den som granskar koden. Det är därför eleverna fortfarande behöver bygga upp det, även när modellen skriver koden.