Undervisning i kodning med kunstig intelligens uden at skabe vibe-kodere: et pædagogisk rammeværk for 2026

Hvis du underviser i programmering i 2026, har du to valgmuligheder, der ikke fungerer, og én, der gør. De to, der ikke fungerer, er velkendte: Forbyd AI i dit fag (umuligt at håndhæve, driver brugen under jorden og efterlader de studerende uforberedte på erhvervslivet) eller lad de studerende bruge AI frit (hvilket skaber kandidater, der kan finde ud af at prompte, men ikke kan ræsonnere). Den løsning, der fungerer, er sværere. Den kræver, at du redesigner, hvordan AI indgår i læringsprocessen — ikke som en problemløser, ikke som et forbudt værktøj, men som en nøje struktureret undervisningsassistent (scaffolded TA), der overlader det kognitive arbejde til de studerende, som AI'en ellers var lige ved at udføre for dem.

Dette er den pædagogiske ramme, du har brug for. Ikke en liste over AI-regler. Ikke et kapløb om detektionsværktøjer. En reel undervisningsmodel, forankret i tre årtiers pædagogisk forskning i læringsstøtte (scaffolding) og zonen for nærmeste udvikling, tilpasset en tidsalder med agentielle kódningsværktøjer, der let kan løse enhver hjemmeopgave.

Denne vejledning er til programmeringsundervisere, der ønsker at opbygge en studieplan, der uddanner rigtige programmører i 2026. Vi vil gennemgå det pædagogiske grundlag, den syvtrinsmodel for AI-understøttet programmeringsundervisning, de mønstre i klasseværelset, vi har set fungere fra CS1 til afsluttende bachelorprojekter, og det værktøjslag — herunder Plagly.ai — der gør modellen praktisk anvendelig i stor skala.

Hvorfor begge ekstremer slog fejl i 2024-2025

Det toårige eksperiment er forbi, og dommen er klar. Uddannelser, der forbød AI fuldstændigt (en lille bølge af CS-afdelinger i 2024), oplevede, at håndhævelsen brød sammen i løbet af et enkelt semester, at de studerende omgik reglerne i al stilhed, og at kløften mellem de studerende og erhvervslivet voksede. Uddannelser, der valgte den modsatte tilgang — ingen regler, lad studerende bruge hvad de vil — producerede hold, der mødte op på arbejdsmarkedet uden at kunne fejlsøge deres egen kód. Rekrutteringsansvarlige svarede igen ved at tilføje live-kódning til jobsamtaler og færdighedstest, som de formelt uddannede kandidater dumpede.

Begge fejltyper deler en fælles årsag. De behandlede AI som et ja/nej-spørgsmål i stedet for en pædagogisk variabel. Det rigtige spørgsmål er ikke, om studerende skal bruge AI. Det er, på hvilket tidspunkt i læringsprocessen AI skal gribe ind, og i hvilken funktion. Det er det spørgsmål, denne model besvarer.

Det pædagogiske grundlag: Produktiv kamp og læringsstøtte (Scaffolding)

To begreber fra læringsvidenskaben understøtter alt det følgende. Det første er produktiv kamp (productive struggle): den kognitive tilstand, hvor en studerende har nok information til at gøre fremskridt, men ikke nok til at gøre fremskridt uden besvær. Forskning viser konsekvent, at læring sker under produktiv kamp. Opgaver, der er for nemme, opbygger ingen færdigheder. Opgaver, der er for svære, opbygger kun frustration. Det ideelle punkt midt imellem — zonen for nærmeste udvikling — er der, hvor de neurale baner for problemløsning reelt dannes.

Det andet begreb er læringsstøtte (scaffolding): den midlertidige støtte, som en mere kapabel aktør (traditionelt en lærer, en medstuderende eller en lærebog) yder, så den studerende kan præstere lige over sit eget uafhængige niveau. Støtten fjernes gradvist, efterhånden som den studerende tilegner sig den underliggende færdighed. God læringsstøtte løser ikke problemet; den støtter den studerende i selv at løse problemet.

Den pædagogiske fiasko ved „vibe coding“ bliver tydelig i denne ramme: En LLM, der leverer en færdig løsning, ødelægger den produktive kamp ved at fjerne det kognitive arbejde, der skaber læring. Det svarer til en tutor, der løser enhver opgave i samme øjeblik, som eleven rynker panden. Eleven sidder nok i stolen, men der sker ingen læring, fordi der ikke er nogen kamp.

Den pædagogiske mulighed er dog lige så tydelig. Den samme LLM, der er konfigureret til at bevare den produktive kamp — til at stille diagnostiske spørgsmål, give delvise ledetråde, nægte at skrive kód, som den studerende endnu ikke har gjort sig fortjent til at se — er det mest kraftfulde værktøj til læringsstøtte, der nogensinde er opfundet. Det er tålmodigt. Det er uendeligt tilgængeligt. Det tilpasser sig den enkelte studerende. Det bliver aldrig frustreret. Den samme model, som ødelægger læring, når den er konfigureret på én måde, muliggør læring, når den er konfigureret på en anden.

Ny forskning offentliggjort på arXiv i november 2025 (Scaffolding Metacognition in Programming Education) bekræftede dette empirisk. Undersøgelsen viste, at studerende understregede, at AI-systemer burde „afholde sig fra at give fulde svar for hurtigt“, og foretrak en struktureret tilgang med trin-for-trin-nøgler og adaptive spørgsmål. De studerende bad ikke om mindre AI-hjælp. De bad om bedre designet AI-hjælp.

Syvtrinsmodellen for AI-understøttet kódningsundervisning

Her er den model, vi har finpudset i løbet af de sidste atten måneder sammen med programmeringsundervisere fra CS1 til afsluttende bachelorprojekter. Den opdeler læringsprocessen i syv adskilte faser og foreskriver, hvad AI skal og ikke skal gøre i hver fase. Modellen er holdningspræget — pointen er at give undervisere et standardudgangspunkt, de kan tilpasse, ikke et uendeligt menukort af muligheder.

1. trin: Mødet med problemet

Den studerende læser problemformuleringen. AI's rolle her er ingen. Den studerende skal danne sig en indledende forståelse, før nogen form for AI-hjælp tillades. Dette er ikke til forhandling. At lade AI opsummere eller forklare opgaveformuleringen på dette trin kortslutter forståelsen. I praksis kan dette håndhæves gennem faglige konventioner („ingen AI de første ti minutter“), afleveringsregler (skal indeholde en skriftlig omformulering af problemet før brug af AI) eller blot gennem en konsekvent understøttet kultur i klasseværelset.

2. trin: Dekomponering

Den studerende opdeler problemet i delproblemer. AI's rolle her er diagnostiske spørgsmål. Den studerende skriver et udkast til en dekomponering, og AI stiller sokratiske spørgsmål til det: „Hvad ændrer sig, hvis inputtet er tomt?“ „Hvordan håndterer din plan duplikerede elementer?“ „Hvor i dine delproblemer sker det reelle algoritmiske arbejde?“ Det er forbudt for AI'en at foreslå sin egen dekomponering; den må kun udforske den studerendes.

3. trin: Valg af fremgangsmåde

Den studerende beslutter sig for en algoritmisk strategi (rekursion vs. iteration, hash map vs. array osv.). AI's rolle her er sammenligning og analyse af kompromiser. Når den studerende har foreslået en fremgangsmåde, kan AI sammenligne den med alternativer, artikulere kompromiserne og spørge, om den studerendes valg passer til rammerne. AI vælger ikke. AI hjælper den studerende med at forstå, hvad dennes valg indebærer.

4. trin: Implementering

Den studerende skriver kód. AI's rolle her er den mest nuancerede. Standarden er kun syntaks- og idiomstøtte: AI kan svare på „hvad er Python-syntaksen for en list-comprehension, der filtrerer og transformerer“, men ikke „skriv den list-comprehension, jeg skal bruge til dette problem“. AI kan rette en syntaksfejl, men ikke redesigne funktionen. For avancerede studerende eller i bachelorprojekter kan dette blødes op: AI fungerer som par-programmør, hvor den studerende leder processen. I CS1 bør det ikke tillades.

5. trin: Test og fejlsøgning (Debugging)

Den studerende kører test og støder på fejl. AI's rolle her er guidet generering af hypotese. Når en test fejler, siger AI'en ikke „fejlen er på linje 12“. Den spørger: „Hvor i kóden tror du, fejlen kan være? Hvad returnerer din funktion, hvis inputtet er tomt? Gennemgå sammen med mig, hvad der sker med dette testtilfælde trin for trin.“ Det er her, den største læring finder sted — og her, fristelsen til at springe over gærdet er størst. En AI, der er konfigureret rigtigt her, opbygger en fejlsøgningsintuition, der holder hele karrieren. En dårligt konfigureret AI ødelægger den.

6. trin: Refaktorering og refleksion

Den studerende har fungerende kód. AI's rolle her er kritik og præsentation af alternativer. AI kan nu vise, hvordan en erfaren softwareudvikler ville skrive den samme kód, forklare, hvorfor dennes version er bedre eller anderledes, og bede den studerende om at forholde sig til sammenligningen. Dette er det trin, hvor AI kan være mest generativ — den underliggende læring har allerede fundet sted, og merværdien er eksponeringen for mønstre af højere kvalitet.

7. trin: Generalisering

Den studerende skal overføre færdigheden til et mærkbart anderledes problem. AI's rolle her vender tilbage til ingen. En lille variant af det oprindelige problem præsenteres, og den studerende løser det uden AI-hjælp. Dette er selve evalueringsmomentet. Hvis den studerende har internaliseret den underliggende færdighed, er varianten ligetil. Hvis ikke, blotlægger varianten hullet i forståelsen.

Omsætning af modellen til praksis i klasseværelset

Modellen er princippet. Mønstrene i klasseværelset nedenfor er praksis. Hvert mønster operationaliserer et eller flere trin i modellen til en konkret opgave eller aktivitet. Undervisere rapporterer konsekvent, at det er disse mønstre, der fungerer.

• Den tosporede opgave. Enhver væsentlig opgave har en solo-del (trin 7 generalisering, ingen AI) og en værktøjs-del (trin 1-6, understøttet AI). Solo-delen er kortere, men tæller lige så meget i karakteren. Dette fanger, hvad den studerende reelt kan præstere på egen hånd, mens de får lov til at lære af AI'en på det større arbejde.
• Aflevering af dekomponering først. Før der overhovedet skrives kód, afleverer den studerende en skriftlig opdeling af problemet. AI er forbudt på dette trin ifølge fagsreglerne. Der gives karakter for tankens klarhed, ikke for den endelige korrekthed. Dette udgør ofte 20-30 % af opgavens samlede karakter.
• AI-stiller-spørgsmål-chatbotten. Giv eleverne en kursusspecifik AI-vejleder (en systemprompt, der håndhæver frameworkets trin 2-5-adfærd), som de skal bruge for at få hjælp, og som nægter at give direkte kode. Flere universiteter har bygget disse internt; Off-the-shelf muligheder som Code.org's AI Tutor integrerer sokratiske principper direkte.
• Kun fejlretningsvurderingen. Giv elever, der arbejder med AI-genereret kode med subtile fejl, og bedømme deres evne til at finde og rette dem. Dette træner trin 5 direkte og belønner den færdighed, AI selv klarer sig dårligst til.
• Spørg-og-evaluer-øvelsen. Eleverne beder AI om at løse et problem, evaluerer svaret for korrekthed og effektivitet, identificerer eventuelle fejl eller stilistiske problemer og indsender både prompten og en rettet version. Behandler AI flydende som en gradueret færdighed snarere end en løsning.
• Det mundtlige forsvar. Fem minutter pr. elev på væsentlige opgaver. To diagnostiske spørgsmål: Gå mig igennem denne funktion, og modificer den til at håndtere en lille variant. Fanger alt, hvad rammerne var designet til at lære og næsten intet andet.
• Kohortebekræftelsesscanningen. Hver indsendelse løber gennem et verifikationslag, der viser indsendelser, der er værd at undersøge nærmere. Pointen er ikke at fange enhver snyder. Det er at holde den sociale norm om at udføre arbejdet intakt, så rammerne fortsætter med at fungere.

Værktøjslaget: Hvad gør dette praktisk i skala

En CS1 med 200 elever kan ikke manuelt verificere hver opgave, manuelt stilladsere hver elevs AI-interaktioner eller manuelt udføre mundtlige forsvar ved hver aflevering. Rammen er kun realistisk, hvis værktøjslaget fjerner volumenarbejdet fra instruktørens tallerken og efterlader mennesket i løkken for de tilfælde, hvor menneskelig dømmekraft er unikt værdifuld. Dette er Plagly.ais praktiske rolle i et kursus bygget op omkring rammen.

• Bekræftelse af indsendelse af kode. Hver uploadet fil gennemgår en AI-generationsscanning, der returnerer en konfidensscore og flag pr. linje. Plagly.ai opnår 99 % nøjagtighed på tværs af GPT-5.5, Claude 4.6, Gemini 3.1 og de agentiske kódningsværktøjer, der kombinerer dem. Indsendelser med lave AI-score behøver ingen yderligere inspektion. Highscore-indlæg til det mundtlige forsvar.
• Mønsteranalyse på holdniveau (kohorte): Når otte studerende på et hold producerer løsninger med samme unikke variabelnavngivning, samme kommentarhusthed og samme defensive standardskabelon, kortlægges dette automatisk. Dette fanger de svigt, som analyse af enkelte afleveringer ikke kan afsløre.
• Verifikation af processpor: For større projekter genererer Plagly.ai's Agentic Council — syv domæneekspertmodeller, der analyserer afleveringen på tværs af skrivekvalitet, struktur, AI-detektion, originalitet og konsistens — en dokumenteret rapport. Rapporten dokumenterer, om afleveringen udviser de spor af iterativt forfatterskab, som reelt studerende arbejde normalt udviser.
• Humanize-i-bakgear til undervisning: Humanize-funktionen viser, hvordan typisk AI-kód ser ud. Brugt i klasseværelset bliver det et undervisningsværktøj: Vis studerende en funktion skrevet i typisk AI-stil ved siden af den samme funktion i de studerendes egen stil, og lad dem opliste de synlige forskelle. Dette trénere de genkendelsesfærdigheder, som modellens øvelser på trin 2 afhænger af.
• Understøttelse af flere sprog: Signalerne fungerer i Python, JavaScript, Java, TypeScript, C++, Rust, Go og andre udbredte undervisningssprog. Læreplanens design behøver ikke at bøje sig for værktøjsbegrænsninger.

Hvordan modellen ser ud for de forskellige niveauer

Modellen er den samme på tværs af niveauer, men kalibreringen ændrer sig. Jo længere en studerende er nået, desto mere autonomi får de på hvert trin. Tre referencheckboxe:

CS1 (Introduktion til programmering)

Streng håndhævelse af modellen. Trin 1, 4 og 7 har minimal AI-adgang. Trin 2-3 bruger kun AI i spørgefunktion. Fejlsøgning på trin 5 er stærkt understøttet. Underviserens mål i CS1 er at opbygge den kognitive infrastruktur: Evnen til at læse kód, spore kørsel (trace execution) og danne hypoteser om fejl. At lade AI gøre noget af dette arbejde i CS1 skaber studerende, som aldrig udvikler disse evner. Kombiner dette med obligatorisk problemløsning i klassen og et mundtligt forsvar for hver væsentlig opgave.

Datastrukturer og algoritmer

Moderat håndhævelse af modellen. Trin 4-6 kan løsnes en smule. AI kan nu bruges som par-programmør til implementering, men først efter at den studerende uafhængigt har forpligtet sig til en fremgangsmåde (trin 3). Fejlsøgning forbliver stærkt understøttet. Generaliseringsopgaverne på trin 7 bliver mere abstrakte: Bevis, at din algoritme kører i O(n log n), eller modificer din implementering til at håndtere en yderligere begrænsning, der kræver en væsentlig genovervejelse. Det er her, stærke studerende begynder at bruge AI produktivt, og svage studerende bliver afsløret af generaliseringsopgaverne.

Afsluttende bachelorprojekter og software engineering

Løs håndhævelse af modellen, stor synlighed af processen. På det sidste år bør de studerende arbejde tættere på erhvervslivets model: AI som samarbejdspartner, den studerende i spidsen. Verifikationslaget flyttes fra AI-detektion pr. aflevering til synlighed af processen: Commit-historik, dokumentation af designbeslutninger og optagede kódgennemgange. Det mundtlige forsvar bliver til en designgennemgang — kan den studerende retfærdiggøre de arkitektoniske valg, forklare kompromiserne og ændre designet som svar på en ny begrænsning? Det er her, modellens investering i CS1 bærer frugt, eller fejler.

Hvad man skal holde op med at gøre i 2026

Fem praksisser, der overlevede fra læreplanen før AI, og som nu skal væk. Hver af dem undergraver aktivt modellen, hvis de bevares.

• Hold op med at lade hjemmeopgaver tælle 70 %+ af karakteren. Vurderings- og testcyklussen er fuldt automatiserbar. En karaktersammensætning, der afhænger af præstationen derhjemme, måler ikke længere det, den påstår at måle. Flyt vægten mod problemløsning i klassen, mundtlige forsvar og overvågede projektmilesten.
• Hold op med at bruge resultatet fra auto-graderen som den eneste karakter. Auto-graderen ved ikke, om det er den studerende, der har skrevet kóden. Kombiner auto-graderens score med verifikationslaget, og lad væsentlige scorer kræve mundtligt forsvar.
• Hold op med at stille banale opgaver med bredt publicerede løsninger. Hvis problemet findes på LeetCode, GeeksforGeeks eller i en lærebog udgivet før 2024, kender AI'en løsningen. Kursusspecifikke problemformuleringer, datasæt og begrænsninger tvinger AI'en til reelt at arbejde frem for blot at huske.
• Hold op med at behandle AI som noget uden for pensum. AI-færdighed er nu en del af det, programmører gør i erhvervslivet. Opgaver, der eksplicit involverer at evaluere AI-output, fejlsøge AI-genereret kód eller kritisere AI-foreslåede designs, lærer de studerende en færdighed, som arbejdspladsen har brug for.
• Hold op med at skjule bekræftelseslaget. Fortæl eleverne åbent, at afleveringer scannes for AI-generering, hvad rammens stadier forventer, og hvad konsekvenserne af misbrug er. Gennemsigtighed forbedrer den sociale norm. Skjult håndhævelse avler modstandsdygtig adfærd.

Ofte stillede spørgsmål

Fungerer denne ramme for selv-tempo og asynkrone kurser?

Ja, med to tilpasninger. Først flytter det mundtlige forsvar til en optaget videogennemgang, som eleven afleverer med hver væsentlig opgave. Videoen er kort (to til fem minutter) og besvarer to diagnostiske spørgsmål, der følger med opgaven. For det andet bliver AI-stilladsværktøjet vigtigere, fordi instruktøren ikke er i lokalet for at omdirigere elever, der glider ind i solver-mode. En kursusspecifik AI-vejleder med sokratiske begrænsninger (eller en omhyggelig systemprompt på et generelt værktøj) gør dette brugbart.

Hvad med elever, der lærer bedre ved at læse arbejdskode?

Rammen imødekommer dette eksplicit på trin 6 (refaktorering og refleksion). Efter at den studerende har produceret deres egen arbejdskode, er eksponering for AI-genererede alternativer eller ekspertrefaktorer af høj værdi. Begrænsningen især: AI-som-eksemplar kommer efter elevens eget arbejde, ikke før. At læse god kode lærer, når læseren allerede har prøvet problemet; at læse god kode som erstatning for at forsøge problemet lærer næsten intet.

Hvordan håndterer jeg studerende, der allerede bruger AI intensivt og modarbejder denne model?

Forklar argumenterne klart og åbent, helst på førstedagen. Vis dem CodeRabbit-dataene fra december 2025 om 1,7x højere fejlfrekvens i kód skrevet sammen med AI. Henvis til dev.to-artiklen 30 Days Without AI. Tal om live-kódningsinterviews og hvad rekrutteringsansvarlige rent faktisk foretager sig i 2026. De studerende, der modarbejder modellen, er som regel dem, der har mest brug for den. Mange af dem har endnu ikke mærket konsekvenserne af vibe coding, og når de gør det (ofte i deres første tekniske interview), ønsker de som regel, at de havde taget modellen mere alvorligt meget tidligere.

Kan jeg implementere modellen gradvist i stedet for at omstrukturere hele mit fag på én gang?

Ja. Den absolut mindste implementering er at tilføje tre ting til dit eksisterende fag: Et krav om at odevzde dekomponering først på én stor opgave, et kort mundtligt forsvar på den samme opgave og et verifikationslag (et værktøj, der scanner afleveringer og afdækker mønstre), der kører stille i baggrunden. Disse tre tilføjelser flytter dig det meste af vejen uden at kræve en komplet omstrukturering af læreplanen. De fleste undervisere, vi har arbejdet med, starter her og udvider til den fulde model over to til tre semestre.

Hvad hvis min institution ikke har vedtaget klare AI-retningslinjer endnu?

De fleste har ikke, og de fleste leder efter input fra underviserne. Ved at indføre modellen på fagniveau får du en solid og velbegrundet model, du kan tage med til samtaler om retningslinjer på afdelingsniveau: Her er, hvad vi gør i CS1, her er argumenterne, og her er resultaterne. Undervisere, der proaktivt viser vejen med god pædagogik på dette område, er i stigende grad dem, der er med til at forme institutionens retningslinjer. Modellen er designet til at blive forsvaret i de diskussioner — henvisningerne til læringsvidenskaben, kildehenvisningerne til peer-reviewed forskning og den eksplicitte forankring i produktiv kamp og læringsstøtte (scaffolding) tjener alle som det retoriske stillads for arbejdet med retningslinjerne.