Komforan
EN
Alle indlæg

Det kedelige arbejde var læring

· Henning Kjær

Næsten alle samtaler om AI og softwareudvikling handler om hastighed. Også vores

  • Komforan eksisterer blandt andet fordi AI har minimeret afstanden mellem idé og kørende software. Det er reelt.

Men hvis AI laver det arbejde, folk plejede at lære af, hvor træner vi nu de grundlæggende kompetencer?

Ingen designede læring før - det var en naturlig del af arbejdet

At blive god til softwareudvikling skete helt naturligt. Man lærte syntax og grundlæggende programmering, fik små opgaver, kedelige fejlrettelser, simple skærmbilleder og logfiler, som ingen andre gad læse. Det gav økonomisk mening: billige hænder til ting der skulle laves, med lav risiko.

Utilsigtet fungerede det som pensum. Man lærte ved at sidde fast, tage fejl og blive rettet af en, der havde siddet fast samme sted fem år tidligere.

Det er præcis de opgaver, AI i dag klarer for dig. Forskere fra Seoul National University har interviewet udviklere og beskriver konsekvensen direkte: når AI overtager juniorernes opgaver, forsvinder også den læring man får fra at lave fejl, som former seniorer. Arbejdsmarkedstallene peger samme vej — amerikanske løndata fra Stanford viser, at beskæftigelsen for udviklere mellem 22 og 25 år er faldet med omkring en femtedel siden slutningen af 2022, mens den har været stabil for de ældre. Analyser af jobopslag viser også, at forholdet mellem junior- og seniorstillinger er faldet med cirka 16%.

Overskriften, alle griber fat i, er at "juniorer bliver erstattet". Jeg mener, den rammer ved siden af. Det egentlige problem er, at vi fjernede pensum uden at lægge mærke til, at det var pensum — og vi har indtil videre ikke erstattet det med noget andet.

At det lyder rigtigt er ikke det samme som at forstå det

Der findes nu direkte belæg for, at det her er et læringsproblem og ikke kun et ansættelsesproblem.

I et randomiseret studie fra Anthropic i 2026 skulle 52 primært juniorudviklere lære et Python-bibliotek, de ikke kendte i forvejen. Halvdelen havde AI-hjælp, halvdelen havde ikke. AI-gruppen arbejdede hurtigere og lavede færre fejl undervejs — og scorede bagefter omkring 17 point lavere på en forståelsesprøve uden AI. Glattere output, mindre forståelse.

Men den vigtigste detalje nåede aldrig overskrifterne: resultatet fulgte ikke automatisk af at bruge AI. De deltagere, der brugte AI til at opbygge forståelse — bad om forklaringer, stillede begrebsmæssige spørgsmål, spurgte ind til hvorfor noget virkede - huskede markant mere. Det afgørende var ikke om de brugte AI. Det var hvordan.

Dermed er det ikke en skæbne, men et designproblem. Og designproblemer kan man gøre noget ved.

Grundlæggende færdigheder er det, der gør AI værd at have

Den anden side af sagen er, at faglig dybde ikke bare er nostalgi. Det er den, der afgør, om AI rent faktisk gør dig bedre til dit arbejde.

METR gennemførte et kontrolleret forsøg med 16 erfarne open source-udviklere, som løste 246 reelle opgaver i store, modne kodebaser. Med AI var de 19 % langsommere. Men det mest interessante er egentlig ikke tallet. Det er, at de samme udviklere selv vurderede, at AI havde gjort dem omkring 20 % hurtigere.

Vi er altså ikke nødvendigvis særligt gode til at mærke, om AI faktisk hjælper os.

METR advarede selv mod at generalisere ud fra forsøget, og resultaterne er siden blevet diskuteret. På nye projekter og i ukendte kodebaser ser AI ud til at kunne give en reel gevinst. DORA's tal fra 2026 peger i samme retning: store gevinster på simple, nye opgaver, men langt mindre effekt på kompleks legacy-kode.

Den afgørende færdighed bliver derfor at kunne vurdere, hvilken situation man faktisk står i. Hvornår gør AI mig bedre? Hvornår gør den mig bare hurtigere? Og hvornår gør den mig i virkeligheden langsommere?

Den dømmekraft er grundlæggende. Den er ujævnt fordelt, og den følger ikke med værktøjet.

DORA's egen opsummering rammer det meget godt: AI er en forstærker. Den forstærker styrkerne i en velfungerende udviklingsorganisation – og dysfunktionerne i en dårligt fungerende.

Det samme gælder den enkelte udvikler. AI forstærker den dømmekraft, du allerede har. Og hvis fundamentet er tyndt, bliver det også forstærket – bare hurtigere og pakket ind i et mere overbevisende sprog.

Hvad er så grundlæggende i dag?

Mindre har ændret sig, end man skulle tro. Men det, vi skal være gode til, har ændret sig markant.

At kunne læse kode, man ikke selv har skrevet – hurtigt, kritisk og uden at tage noget for givet. Det er ikke længere noget, man gør en gang imellem. Det er blevet en central del af arbejdet.

At kunne fejlsøge sig frem fra symptom til årsag uden at få svaret serveret. Det afgørende er ikke kun at kunne rette fejlen, men at kunne finde og forstå den.

At vide, hvad "korrekt" betyder, før man ser løsningen. At kunne få øje på grænsetilfælde, fejlscenarier og de krav, ingen fik skrevet ned.

At kunne sige: "Nej, det her er forkert" til et svar, der både lyder overbevisende og er formuleret med stor sikkerhed. Det er sværere, end det lyder – og evnen bliver dårligere, hvis den ikke bliver brugt.

At vide, hvornår man ikke skal uddelegere til AI. At overlade en opgave, man allerede mestrer, koster ikke nødvendigvis noget. Men overlader man en opgave, man selv var i gang med at lære, risikerer man også at uddelegere selve læringen.

Intet af det er nyt.

Det nye er, at vi ikke længere kan regne med, at det kommer af sig selv.

Det er et teamproblem, ikke et individuelt

Standardsvaret er ofte en individuel udviklingsplan og et håb om, at folk selv finder tiden. Men den taber næsten altid til den næste deadline. Organisationen belønner det, der bliver leveret nu, mens det at vælge den langsommere vej for at lære noget typisk er en investering, den enkelte selv må betale for. Overlader man ansvaret alene til den enkelte, er resultatet derfor ret forudsigeligt.

Det bliver anderledes, når teamet tager et fælles ansvar for læringen. I praksis kan det blandt andet betyde:

Beslut fra opgave til opgave, om det er en uddelegeringsopgave eller en læringsopgave. Begge dele er legitime. Problemet opstår, når vi glider fra det ene til det andet uden at opdage det.

Når noget er nyt, så brug AI til at forstå før du bruger den til at løse. Spørg hvorfor og hvordan, før du beder om koden. Det tvinger forståelsen foran løsningen.

Arbejd indimellem uden AI. Små, regelmæssige og bevidste perioder. Ikke fordi der er noget særligt nobelt i at undvære AI, men for at kalibrere sig selv. Man er nødt til en gang imellem at finde ud af, hvad man faktisk stadig kan uden hjælp.

Gennemgå AI-genereret kode mindst lige så kritisk som menneskeskrevet kode, og brug reviewet som en samtale om løsningen – ikke bare som en kontrolpost, der skal passeres.

Lad den svære fejlsøgning gå på skift i stedet for altid at give den til den, der kan løse problemet hurtigst. Det kan koste lidt fart i dag, men alternativet kan være et team, hvor kritisk viden kun findes hos én person.

Spørg jævnligt: "Hvem andre på teamet kunne løse det her?" Hvis svaret er "ingen", har I fundet noget, der er værd at gøre noget ved.

Det sidste er også en del af grunden til, at vi bygger det, vi bygger. Man kan ikke arbejde målrettet med et teams kompetencer, hvis man ikke kan se dem. Hvad kan vi allerede? Hvor er vi sårbare? Hvor mangler vi dybde? Og hvem er i gang med at lære hvad?

At gøre kompetencerne synlige er ikke målet i sig selv. Det er det, der gør det muligt at udvikle dem bevidst.

Mesterlæren døde ikke, den holdt op med at være gratis

I årtier fik softwarebranchen en stor del af sin kompetenceudvikling foræret gennem det daglige arbejde. Folk lærte, fordi de selv skulle skrive koden, finde fejlene, læse sig ind i ukendte systemer og kæmpe sig frem til løsninger. Arbejdet skulle laves alligevel, og læringen fulgte med.

Med AI forsvinder en del af den læring, uden at vi nødvendigvis opdager det.

Det betyder ikke, at vi ikke længere kan udvikle dygtige udviklere. Men vi bliver nødt til at gøre mere af det bevidst. Den læring, der før opstod som en naturlig del af arbejdet, kommer ikke nødvendigvis af sig selv længere.

Og konsekvenserne viser sig langsomt. Hvis en udviklers læring går i stå i 2026, opdager vi det måske ikke i 2027 eller 2028. Det bliver først for alvor synligt flere år senere, når vi forventer den dømmekraft, erfaring og faglige dybde, der normalt følger med ancienniteten.

De teams, der kommer bedst igennem den udvikling, bliver derfor ikke nødvendigvis dem, der tog AI hurtigst til sig.

Det bliver dem, der forstod, hvad alt det trivielle arbejde faktisk lærte os – og besluttede at lære det med vilje, når arbejdet ikke længere gør det for os.

Kilder