# Når kode ikke længere er menneskets sprog AI kan snart skrive mere kode, end mennesker kan gennemgå. Derfor har vi brug for et nyt sprog, som gør maskinens arbejde forståeligt og kontrollerbart. - Forfatter: Mikkel Freltoft Krogsholm - Type: Essay - Udgivet: 2026-10-03 - Opdateret: 2026-10-03 - Sprog: da - Emner: ai, software, kode, arbejde, menneskelig kontrol - Kanonisk URL: https://mikkelkrogsholm.dk/da/articles/naar-kode-ikke-laengere-er-menneskets-sprog/ --- For nylig sendte jeg et forslag til en ændring i Graphify, et softwareprojekt, hvor koden ligger åbent, så andre kan læse den og bidrage til den. I softwareverdenen bliver sådan et forslag ofte afleveret som en *pull request*. Det er en pakke med den nye kode, en forklaring og en oversigt over, hvad der er blevet ændret. Andre kan læse pakken, stille spørgsmål og godkende den, før ændringen bliver en del af programmet. Normalt bliver man mødt af selve koden. Linjer, der er fjernet, står med rødt. Linjer, der er tilføjet, står med grønt. Hvis ændringen er stor, kan der være tusindvis af dem. Mit forslag til Graphify handlede om at give læseren en anden indgang. I stedet for at begynde med alle de røde og grønne linjer skulle man kunne begynde med nogle almindelige spørgsmål: Hvad er blevet anderledes? Hvilke dele af programmet bliver berørt? Hvad kunne ændringen få betydning for? Og hvor kan jeg se beviset? [Forslaget](https://github.com/Graphify-Labs/graphify/pull/3958) laver derfor en rapport i flere lag. Først en kort fortælling om ændringen. Derefter et billede af de dele af programmet, der hænger sammen. Så en enkel trin-for-trin-beskrivelse af den vigtigste logik. Nederst ligger den faktiske kode. Programmerere kalder nogle gange den enkle trin-for-trin-beskrivelse for *pseudokode*. Det er ikke kode, computeren kan køre. Det ligner mere en opskrift: 1. Modtag en bestilling. 2. Kontrollér, om varen er på lager. 3. Træk varen fra lageret. 4. Send en bekræftelse. Den rigtige kode indeholder alle de præcise regler, formater og undtagelser, som computeren kræver. Pseudokoden forsøger at vise tankegangen uden at kræve, at læseren kender programmeringssproget. Jeg byggede ikke forsøget, fordi den rigtige kode er blevet ligegyldig. Tværtimod. Jeg byggede det, fordi kode er blevet for vigtig til, at menneskelig kontrol må afhænge af, hvor hurtigt et menneske kan læse tusindvis af linjer på et sprog, der aldrig har været vores modersmål. Det problem bliver større, når AI skriver en stigende del af koden. Maskinen bliver hurtigere til at producere. Mennesket er stadig sat til at læse bagefter. Det kan blive den næste store flaskehals i softwareudvikling. ## Fra nuller og ettaller til Python Vi har prøvet noget lignende før. De første programmører arbejdede meget tæt på computerens eget sprog. De skulle beskrive arbejdet som tal og helt konkrete, små operationer. Det var besværligt, langsomt og forbeholdt ganske få mennesker. Senere fik de små operationer navne. Derefter kom sprog som Fortran, hvor et menneske kunne skrive en matematisk formel på en genkendelig måde. Et andet program oversatte så formlen til de mange små instruktioner, computeren kunne udføre. Sådan et oversættelsesprogram kaldes en *compiler*. Navnet er ikke det vigtige. Det vigtige er arbejdsdelingen: Mennesket beskriver opgaven på et niveau, der giver mening for et menneske. Værktøjet oversætter den til et niveau, der giver mening for maskinen. [IBM beskriver](https://www.ibm.com/history/fortran), hvordan en opgave, der tidligere krævede tusind maskininstruktioner, kunne udtrykkes med 47 linjer Fortran. Mange tvivlede på, at den automatisk oversatte kode kunne blive lige så effektiv som kode skrevet direkte til maskinen. Det kunne den næsten. Siden har vi gentaget bevægelsen. Nye programmeringssprog fjernede udvikleren lidt mere fra computerens fysiske indre. Python gjorde det muligt at udtrykke meget med forholdsvis få og læselige linjer. Færdige byggeklodser gjorde det unødvendigt at opfinde alting fra bunden. Man kalder ofte Python for et programmeringssprog på et højere niveau. *Højere* betyder ikke finere eller bedre. Det betyder længere væk fra computerens enkelte operationer og tættere på det problem, mennesket forsøger at løse. Hver gang vi er rykket et niveau op, har mennesket mistet lidt direkte kontakt med det nederste lag. Til gengæld har flere mennesker kunnet bygge mere komplekse ting. Vi har flyttet det sted, hvor mennesket formulerer sin hensigt. AI fortsætter den bevægelse. Nu kan jeg beskrive en ønsket ændring med almindelige ord, og en digital medarbejder kan finde de relevante filer, foreslå den nye kode og kontrollere, om de kendte dele af programmet stadig virker. I [*Da grænsefladen blev valgfri*](https://mikkelkrogsholm.dk/da/articles/da-graensefladen-blev-valgfri/) skrev jeg om netop den oversættelse. AI kan stå mellem menneskets ønske og systemets tekniske materiale. Vi behøver ikke længere selv kende alle knapper, filer og kommandoer for at få noget til at ske. Men når oversættelsen ned til maskinen bliver så god, opstår et nyt problem i den modsatte retning. Hvordan oversætter vi maskinens arbejde tilbage til menneskelig forståelse? ## Koden har haft to læsere Kildekode er de skrevne instruktioner, som bestemmer, hvad et program gør. Den har længe haft to forskellige læsere. Computeren skal kunne omsætte instruktionerne til handling. Men et menneske skal også kunne læse dem for at forstå programmet, finde fejl og beslutte, om en ændring er forsvarlig. Derfor bruger programmører tid på at give ting gode navne og dele arbejdet op på en forståelig måde. Computeren er ligeglad med, om navnet på en del af programmet giver mening. Det er den næste programmør ikke. Den næste programmør har måske bare ændret karakter. Hvis kode i stigende grad bliver skrevet, ændret og vedligeholdt af AI-programmer, der selv kan løse opgaver, kan kildekoden blive et mellemprodukt mellem maskiner. Den er stadig afgørende. Det er stadig her, de præcise instruktioner ligger. Men den behøver ikke være det sted, hvor de fleste mennesker først møder ændringen. De færreste Python-programmører læser i dag de helt grundlæggende maskininstruktioner, som deres program ender med at blive omsat til. De arbejder på et højere niveau, fordi forbindelsen mellem niveauerne er pålidelig nok. Spørgsmålet er, om noget lignende kan ske, når vi gennemgår ny kode. Ikke ved at fjerne koden, men ved at give mennesket et mere forståeligt læselag ovenpå. For en lille ændring kan en opskrift-lignende forklaring ligge tæt på koden. For en meget stor ændring kan selv den forklaring blive lang. Så kan man begynde med et kort overblik og åbne flere detaljer efter behov. Mennesket starter med meningen og bevæger sig ned mod de tekniske instruktioner, når noget er uklart, risikabelt eller vigtigt. Vi har brugt årtier på at bygge lag, der oversætter menneskets ønsker ned til maskinens instruktioner. Måske er tiden kommet til et lag, der oversætter maskinens arbejde op til menneskelig mening. ## Mere kode er ikke det samme som mere fremskridt Det er fristende at gøre det til en enkel historie om fart. AI skriver koden hurtigere. Derfor får vi bedre software hurtigere. Så enkelt ser virkeligheden ikke ud. DORA er et stort forskningsprogram, der undersøger, hvordan software bliver udviklet i virkelige organisationer. I [rapporten fra 2025](https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report) svarede mere end 80 procent af deltagerne, at AI havde øget deres produktivitet. Samtidig havde 30 procent ringe eller ingen tillid til kode skrevet af AI. Organisationer med mere AI fik flere ændringer gennem deres systemer. Men rapporten fandt fortsat en sammenhæng med lavere stabilitet — altså flere problemer med at holde softwaren velfungerende, mens den blev ændret. Andre undersøgelser gør billedet endnu mindre enkelt. GitHub har i et kontrolleret forsøg fundet, at udviklere med AI-hjælp løste en bestemt opgave hurtigere. [Forskningsorganisationen METR fandt derimod](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/), at erfarne udviklere i begyndelsen af 2025 brugte 19 procent længere tid på virkelige opgaver, når de måtte bruge datidens AI-værktøjer. Udviklerne troede selv, at de var blevet hurtigere. Værktøjerne har allerede ændret sig siden. Opgaverne var forskellige, og METR har selv forklaret, hvor svært det er at måle tid, når flere AI-programmer arbejder på samme tid. Tallene kan derfor ikke afgøre, om AI altid gør udviklere hurtigere. De viser noget mere interessant: At producere mere kode er ikke nødvendigvis det samme som at skabe mere fremskridt. Når det bliver billigt at foreslå endnu en ændring, flytter det langsomme led. Det bliver forståelsen, afprøvningen, koordineringen og ansvaret. [Google har undersøgt](https://research.google/pubs/modern-code-review-a-case-study-at-google/) ni millioner foreslåede kodeændringer. Undersøgelsen viste en arbejdsgang bygget omkring små ændringer og hurtig feedback. Gennemgangen handlede ikke kun om at finde fejl. Den handlede også om, at flere mennesker forstod programmet og delte viden om det. Det er værd at hæfte sig ved. Selv før de nuværende AI-programmer var menneskelig forståelse en knap ressource. Hvis AI nu kan producere flere og større ændringer på samme tid, forsvinder behovet ikke. Det vokser. I [*Agent Teams ændrer min softwareproces*](https://brokk-sindre.dk/blog/agent-teams-claude-code) beskrev jeg, hvordan flere AI-programmer kan undersøge, bygge og kontrollere parallelt. Det er en reel gevinst. Men ti af dem kan også skrive hurtigere, end ét menneske kan forstå deres samlede arbejde. På et tidspunkt hjælper det ikke at bede mennesket læse hurtigere. Vi må ændre det, mennesket læser. ## Et resumé kan også skjule Den oplagte løsning er at lade endnu en AI skrive et kort resumé af koden. Det er også den farlige løsning. En AI kan skrive en rolig og overbevisende forklaring på en ændring, den har misforstået. Den kan fremhæve det, udvikleren ønskede at bygge, og overse det, programmet faktisk endte med at gøre. Den kan få fem tusind ændrede linjer til at føles som tre enkle punkter. Jo lettere resuméet er at læse, desto lettere kan det være at glemme, hvor meget der er blevet udeladt. GitHub anbefaler selv, at AI-baseret gennemgang af kode [supplerer og ikke erstatter menneskelig gennemgang](https://docs.github.com/en/copilot/responsible-use/agents). Værktøjet kan overse problemer, især i store og komplicerede ændringer. Det kan også foreslå kritik, der lyder rigtig uden at være det. Men rådet indeholder et paradoks. Hvis AI øger mængden af kode, kan svaret ikke altid være, at mennesket bare skal læse det hele med samme grundighed som før. Så har vi automatiseret produktionen og bevaret kontrollen som manuelt håndarbejde. Derfor må det forståelige lag ikke bare være et resumé. Det skal være en vej ned til beviset. Den korte forklaring skal kunne åbnes og vise den mere detaljerede opskrift. Opskriften skal kunne pege på de dele af programmet, den beskriver. Hvis rapporten siger, at en ændring kan påvirke betalingen, skal den vise, hvorfor. Hvis den siger, at alt virker, skal den vise de automatiske prøver, der blev kørt, og den præcise udgave af programmet, de blev kørt på. I mit Graphify-forsøg bliver der derfor gjort forskel på tre ting: - Det programmet med sikkerhed kan aflæse af strukturen. - Det en AI har fortolket sig frem til. - Det der stadig er uklart. Det er ikke en lille teknisk detalje. Det er forskellen på at vise, hvad vi ved, og hvad vi gætter på. Et menneskeligt læselag skal ikke skjule usikkerheden. Det skal gøre den synlig. ## Et kort, man kan zoome i Jeg forestiller mig fremtidens gennemgang af software som et kort med flere zoomniveauer. Øverst står hensigten: Hvad skulle ændringen opnå? Næste lag viser adfærden: Hvad gør programmet anderledes før og efter? Under det ligger forbindelserne: Hvilke andre dele kan blive påvirket? Så kommer opskriften: Hvordan fungerer den vigtigste logik, forklaret uden programmeringssprogets mange detaljer? Nederst ligger den faktiske kode, de automatiske prøver og historikken over ændringen. Ikke alle mennesker skal læse alle lag hver gang. En rettelse af en stavefejl kræver ikke samme opmærksomhed som en ændring af, hvem der kan få adgang til en bankkonto eller patientjournal. Ved en farlig ændring kan en specialist være nødt til at gå helt ned i koden. En velkendt og afgrænset ændring kan måske godkendes ud fra den synlige adfærd, de automatiske prøver og en klar vej tilbage til detaljerne. Det afgørende er ikke, at det øverste lag indeholder alt. Så ville det blive lige så tungt som koden. Det afgørende er, at enhver vigtig påstand kan efterprøves i laget nedenunder. Det skal være en forkortelse med en vej tilbage. Det kan gøre mere end at aflaste programmøren. Det kan lukke andre fagligheder ind i gennemgangen. En jurist behøver ikke forstå alle tegnene i koden for at vurdere, om en regel er blevet fortolket rigtigt. En læge kan bedre se, om et digitalt patientforløb svarer til den virkelige arbejdsgang. En redaktør kan tage stilling til reglerne for publicering uden først at lære det værktøj, hjemmesiden er bygget med. I dag bliver mange af den slags vurderinger oversat gennem en udvikler. Fagpersonen beskriver hensigten. Udvikleren læser koden. Sammen forsøger de at afgøre, om de taler om det samme. Et godt læselag kan gøre programmets faktiske adfærd til genstand for en mere direkte samtale. Det er den positive mulighed. De højere programmeringssprog gjorde flere mennesker i stand til at bygge software. Et højere sprog for gennemgang kan gøre flere mennesker i stand til at tage ansvar for den. På Digital Medarbejder har jeg skrevet, at [menneskelig kontrol ikke betyder, at et menneske skal godkende hvert eneste trin](https://digitalmedarbejder.dk/viden/menneskelig-kontrol-med-digitale-medarbejdere). Kontrol handler om roller, tilladelser, dokumentation, klare stop og om at vide, hvornår et menneske skal overtage. Det samme gælder her. Menneskelig kontrol med AI-produceret software behøver ikke betyde, at et menneske mekanisk læser hver linje. Det kan betyde, at mennesket ejer hensigten, vurderingen af risikoen og beslutningen om, hvor langt ned i detaljerne det er nødvendigt at gå. Det kan være mere ærlig kontrol end et hurtigt flueben fra en person, der formelt har set ændringen, men reelt ikke har forstået den. ## Hvad skal mennesket stadig kunne? Der findes en stærk indvending mod hele tanken. Hvis mennesker holder op med at læse kode, mister vi så ikke evnen til at opdage, når oversættelsen er forkert? Bliver vi ikke piloter, der kun kan læse instrumentbrættet og ikke længere forstår motoren? Jo, den risiko er reel. Et fag kan blive udhulet, hvis ingen længere lærer det nederste lag. Vi får stadig brug for mennesker, der kan læse og skrive kode, forstå computerens indre arbejde og opdage fejl i de oversættelser, resten af os bruger. Højere niveauer har aldrig gjort de lavere niveauer værdiløse. De har gjort dem mere specialiserede. De fleste Python-programmører skriver ikke computerens mest grundlæggende instruktioner til daglig. Det betyder ikke, at de instruktioner er ophørt med at eksistere, eller at ingen behøver forstå dem. Det betyder, at forståelsen er blevet fordelt anderledes. Det samme kan ske med gennemgangen af software. Nogle mennesker vil gå helt ned i koden. Flere vil kontrollere programmet gennem dets adfærd, de automatiske prøver, forbindelserne til andre dele og forklaringer, der kan efterprøves. Den vigtige opgave bliver at beslutte, hvornår det øverste lag er nok, og hvornår risikoen kræver, at vi går længere ned. Det er ikke et spørgsmål, teknologien kan besvare alene. Det er et spørgsmål om ansvar. En AI kan foreslå, at en ændring er lille. Den kan ikke overtage konsekvensen, hvis vurderingen er forkert. En automatisk prøve kan vise, at de kendte situationer virker. Den kan ikke beslutte, om vi har prøvet det rigtige. En enkel opskrift kan forklare logikken. Den kan ikke alene afgøre, om logikken burde findes. Menneskets vigtigste sprog bliver måske derfor ikke kode, men formål. Hvad prøver vi at opnå? Hvilken adfærd accepterer vi? Hvem kan blive ramt? Hvilken usikkerhed kan vi leve med? Hvornår skal maskinen stoppe? Det er spørgsmål, der altid har ligget bag god software. AI gør dem bare sværere at gemme mellem linjerne. ## Det næste lag Vi har brugt omkring 70 år på at løfte programmeringen væk fra maskinens eget sprog. Hvert nyt lag gjorde det muligt for mennesker at udtrykke mere uden at beskrive alle detaljerne nedenunder. Det gav os mere software, mere komplekse systemer og flere mennesker, der kunne være med til at bygge dem. Nu begynder maskinen selv at skrive på de sprog, vi skabte til mennesker. Det betyder ikke, at udviklingen er slut. Det betyder, at vi får brug for endnu et lag — denne gang i den anden retning. Vi får brug for et sprog, hvor maskinen kan vise sit arbejde på en form, mennesker kan forstå. Et sprog for hensigt, adfærd, forbindelser, risiko og bevis. Den opskrift-lignende pseudokode kan være en del af det. Oversigter, automatiske prøver og gennemspillede eksempler kan være andre dele. Kildekoden forsvinder ikke. Men den behøver måske ikke længere være den hoveddør, alle mennesker skal gå igennem for at føre kontrol. Da vi opfandt de højere programmeringssprog, accepterede vi, at mennesker ikke skulle tænke som maskiner for at få maskiner til at arbejde. Nu bør vi stille det omvendte krav. Mennesker skal ikke lære at læse med maskinens hastighed for at kunne kontrollere maskinens arbejde. Maskinen må lære at forklare sig på menneskets sprog — og vise kvitteringerne. --- ## Kilder og videre læsning - Mikkel Krogsholm: [*feat(prs): export human-readable review artifacts*](https://github.com/Graphify-Labs/graphify/pull/3958), forslag til Graphify. - IBM: [*Fortran*](https://www.ibm.com/history/fortran). - DORA: [*Announcing the 2025 DORA Report: State of AI-Assisted Software Development*](https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report). - METR: [*Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity*](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/) og [*Uplift Update*](https://metr.org/blog/2026-02-24-uplift-update/). - Caitlin Sadowski m.fl.: [*Modern Code Review: A Case Study at Google*](https://research.google/pubs/modern-code-review-a-case-study-at-google/). - GitHub: [*Responsible use of GitHub Copilot coding agent*](https://docs.github.com/en/copilot/responsible-use/agents).