Vibe coding-krisen: hvorfor CS-utdannede ikke lenger kan kode uten AI

I en Reddit-tråd i mars 2026, som raskt passerte 8 000 oppstemmer, publiserte en seniorutvikler i et Series-B-oppstartsselskap skjermbilder av en hjemmeoppgave han nettopp hadde avvist. Kandidaten, en nyutdannet CS-student med 3,9 i GNO fra et respektert program, hadde sendt inn kode som kjørte perfekt under ideelle forhold (happy path), men som i stillhet korrumperte data ved hvert grensetilfelle (edge case). Da kandidaten ble bedt om å gå gjennom logikken i en oppfølgingssamtale, kunne han ikke forklare hvorfor en av hans egne funksjoner brukte rekursjon. Linjen som fikk tråden til å eksplodere var hans ærlige svar: “Jeg fortalte bare Claude hva vi trengte, og den skrev dette. Jeg pleier bare å lese koden hvis den ikke fungerer.”

Dette er vibe coding-krisen, og i 2026 har den migrert fra utvikler-Twitter til rekrutteringsprosesser, evalueringer etter intervjuer og i økende grad til kontorene til prefekter ved CS-avdelinger som prøver å forstå hva som nettopp skjedde med deres uteksaminerte studenter. Begrepet ble myntet av Andrej Karpathy i februar 2025 for å beskrive en positiv ny arbeidsmåte: beskriv din hensikt, aksepter hva modellen produserer, lever. Innen et år ble den samme frasen bransjens kortnavn for en generasjon programmerere som kan skrive prompter flytende, maer som ikke kan resonnere rundt hva koden deres faktisk gjør.

For programmeringslærere er dette ikke et hypotetisk problem om arbeidets fremtid. Det er en akutt pedagogisk nødsituasjon i nåtid angående de studentene dere uteksaminerer akkurat nå. Denne artikkelen undersøker hva forskningen og feltrapportene faktisk viser om AI-indusert kompetansesvekkelse (atrophy), hvorfor CS1 til siste års eksamensarbeid er unikt sårbare, og hvordan en liten, men voksende gruppe lærere strukturerer om kursene sine for å sikre at studenter uteksamineres med evnen til å kode — ikke bare med evnen til å prompte.

Hva vibe coding faktisk betyr (og hvorfor Karpathy sa at det burde være gøy)

Karpathys opprinnelige innramming var spesifikk. Vibe coding innebar å akseptere at programmering for personlige prosjekter nå kunne føles som kreativ lek: du forteller modellen hva du vil ha, den produserer kode, du justerer prompten snarere enn koden, og du leverer noe som fungerer. Han noterte uttrykkelig at han ikke lenger leste kode linje for linje for sine egne sideprosjekter. Innrammingen handlet om glede, produktivitet og den legitime observasjonen at for mindre viktige engangsprosjekter er en grundig manuell granskning overflødig.

Begrepet spredte seg deretter til det bredere feltet, der det landet i to svært forskjellige sammenhenger:

• Seniorutviklere som bruker det bevisst: Behandler AI-generert kode som et utkast, leser og strukturerer den om før commit, bruker AI for å slippe rutinemessig mal-kodeskriving, men anvender tiår med mønstergjenkjenning for å evaluere resultatet. Dette var hva Karpathy beskrev, og det fungerer.
• Juniorutviklere og studenter som antar det som sin standardmodus: Behandler AI-generert kode som et ferdig resultat, aksepterer den uten å lese, feilsøker kun når tester feiler, vender seg til en senior eller lærer først når AI-en ikke kan fikse sin egen kode. Dette var hva Karpathy ikke beskrev, og det fungerer ikke.

Det pedagogiske problemet er den andre gruppen, og de utgjør majoriteten av studentene som begynner på CS-programmene i 2026. Karpathy selv backet fra sin innramming senere i 2025 og noterte at vibe coding er rimelig for eksperter på personlige prosjekter, men skadelig for alle andre.

Kompetansesvekkelsen i faktiske tall

Bevisene er nå omfattende, og de peker i én retning. En analyse i desember 2025 publisert av CodeRabbit, som undersøkte pull requests i hundrevis av åpne kildekodeprosjekter, fant at kode skrevet sammen med generativ AI inneholdt omtrent 1,7x flere “større” problemer enn menneskelig skrevet kode. Logikkfeil (feilaktige avhengigheter, mangelfull kontrollflyt) og sikkerhetssårbarheter var begge signifikant forhøyet, der sikkerhetsbrister oppsto i 2,74x takten sammenlignet med kode skrevet av utelukkende mennesker.

En TechSpot-rapport i slutten av 2025 undersøkte yrkesaktive utviklere angående de kognitive effektene av påtvingede vibe coding-arbeidsflyter. Det felles rapporterte mønsteret: økende feilsøkingsstid, minkende evne til å mentalt simulere kode, og en svekket intuisjon for hvordan kode av produksjonskvalitet ser ut. En utvikler beskrev opplevelsen sin etter seks måneder med vibe-først-arbeid som å helt "miste kasthafrminnet" for problemløsning.

Den tydeligste illustrasjonen kom fra en utvikler som kjørte et 30-dagers eksperiment i starten av 2026: ingen AI-hjelp i en måned, og reflekter deretter over forskjellen. Skriften på dev.to, I Coded Without AI for 30 Days: The Results Were Embarrassing, ble et av årets mest delte utvikler-essays. Det sentrale resultatet: en yrkesaktiv seniorutvikler med åtte års erfaring kunne ikke lenger skrive en enkel traversering av et binært tre (binary tree traversal) fra minnet. Ferdigheten var lagt ut på anbud og deretter stille visnet bort.

Hvis en yrkesaktiv seniorutviklers feilsøkingsmuskel svekkes innen få måneder med AI-avhengighet, tenk da på banen for en CS1-student som aldri har hatt den muskelen fra starten av — hvis hele opplevelse av programmering har blitt formidlet via en LLM som produserer en fungerende løsning innen ti sekunder etter å ha sett problemformuleringen.

Hvorfor programmeringsundervisning er unikt sårbar

Andre disipliner håndterer AI i utdanningen ufullstendig, men de fleste har fortsatt intakte evalueringsrammer. En student i litteratur kan fortsatt bes om å diskutere et avsnitt i et seminar. En student i kjemi kan fortsatt bes om å utføre en laboratorieprosedyre. En student i matematikk kan stilles opp for å utlede et bevis på tavlen. Programmeringsundervisning har ingen av disse intakte evalueringsmåtene. Nesten hver programmeringsoppgave er hjemmearbeid, evaluert ut fra om koden klarer tester — og en AI i 2026 klarer de testene trivielt.

Dette skaper tre sårbarheter som er spesifikke for programmering:

• Oppgave-test-sløyfen er fullt automatiserbar. Codex, Claude Code og Cursor leser oppgaven, skriver koden, kjører testsuiten, itererer ved feil og sender inn en fungerende løsning. Den fullstendige syklusen som en student forventes å utføre — forstå krav, designe en løsning, implementere den, feilsøke den — kan utføres av AI-en raskere enn studenten kan lese spesifikasjonen.
• Muntlig evaluering er logistisk dyrt. En CS1-klasse med 200 studenter kan ikke realistisk gjennomføre et fem minutters muntlig forsvar på hver oppgave uten å brenne tjue timer av lærerassistentenes tid per oppgavesyklus. Den økonomiske modellen for store CS-kurs forutsetter asynkron hjemmearbeidsretting.
• Fusket er usynlig for studenten. En student som kopierer et essay vet at de fusker. En student som prompter en AI til å løse en oppgave vil kanskje ikke oppfatte det som fusk — den sosiale normen har skiftet raskere enn retningslinjene, og handlingen føles uatskillelig fra å slå opp noe. Når de når siste år og må tenke selv, har de tilbrakt fire år uten å bygge opp noen relevant ferdighet.

Resultatet er en evalueringskjede som produserer studenter med meritter som ikke lenger korrelerer med ferdighet. Rekryteringsansvarlige i 2026 går i økende grad forbi CV og karakterer til fordel for live teknisk evaluering, nettopp fordi karaktersystemet har blitt koblet fra den underliggende evnen.

Hvordan “å lære ingenting” ser ut på CS-kontortider

Hvis du underviser i programmering, har du sannsynligvis sett dette mønsteret, selv om du ikke har satt ord på det ennå. Vi har samlet de vanligste diagnostiske signalene fra lærere i CS1, datastrukturer og eksamenskurs under slutten av 2025 og begynnelsen av 2026.

• Studenten kan ikke finne sin egen bug. Innleveringen kjørte perfekt. Ny enhetstest feiler. Studenten åpner filen, ser på koden som om de så den for første gang, scroller opp og ned uten en hypotese, og sier til slutt “Jeg spør bare Claude hva som er feil.” Den første reaksjonen på en mislykket test er å henvende seg til AI i stedet for å formulere en hypotese.
• Studenten kan ikke svare på “hvorfor”. På spørsmål “hvorfor brukte du en hash map her i stedet for en array,” blir svaret “det var det AI-en foreslo.” Valget ble tatt; resonnementet bak det ble aldri internalisert. Det finnes ingen kognitiv modell under koden.
• Studenten kan ikke gjøre en liten variant. “Modifiser dette slik at det også håndterer negative tall” burde være en tretti sekunders redigering. For den AI-avhengige studenten blir det en fem minutters promptesjon fordi de må mate inn begrensningen i modellen i stedet for å tenke ut hvor i den eksisterende koden endringen skal gjøres.
• Studenten er flytende i verktøy, analfabet i problemer. De kan konfigurere Vercel, bygge en React-komponent, sette opp en Postgres-database, driftssette med Docker. De kan bruke hele den moderne verktøykjeden. Be dem implementere quicksort. Taushet.
• Eksamensprosjektets avsløring. Det siste årets eksamensprosjekt, det øyeblikket da akkumulert ferdighet burde gi uttelling, er i økende grad et øyeblikk da akkumulert mangel på ferdighet avsløres. Team som vibe-kodet seg gjennom CS1 til tredje år ankommer eksamensprosjektet ute av stand til å designe et system, ute av stand til å dele opp en funksjon, ute av stand til å håndtere de delene av programmeringen som AI gjør dårligst.

Den pedagogiske løsningen: Behandle AI-flytende som en reell ferdighet (og gjør den fortjent)

De lærerne som håndterer denne overgangen bra er ikke de med de strengeste AI-forbudene. Det er de som har bygd om kursene sine rundt et tydelig skille: AI er et verktøy som studenter skal lære å bruke godt, OG studenter må selvstendig demonstrere de kognitive ferdighetene som AI-en utøver. De to kravene står ikke i konflikt — de utfyller hverandre, og kursene som gjør dette riktig produserer kandidater som presterer bedre enn både vibe-kodere og AI-bannlyste grupper.

De spesifikke designmønstrene vi ser fungere i 2026s programmeringskurs:

• 1. To-spors-oppgaven. Hver oppgave har en “solo”-del (ingen AI tillatt, ofte en liten del i klasserommet) og en “verktøy”-del (AI tillatt men dokumentert). Solo-delen fanger opp hva studenten faktisk kan gjøre. Verktøydelen lærer dem å gjøre mer.
• 2. AI-flytende som en karaktersatt kompetanse. Studentene sender inn de AI-promptene de brukte, svarene de fikk og en analyse av hvor AI-en tok feil eller var ineffektiv. Å lese AI-output kritisk behandles som et kursmål, ikke en snarvei.
• 3. Evalueringer kun i feilsøking. Studentene gis fungerende AI-generert kode med subtile bugger (off-by-one, feilaktig basistilfelle, manglende null-kontroll, sikkerhetssårbarhet) og karaktersettes på evnen sin til å finne og rette dem. Dette trener den ferdigheten som AI presterer dårligst på og som arbeidsgivere verdsetter mest.
• 4. Prosessgjørlig karaktersetting. Påkrevd commit-historikk, obligatoriske kommentarer som dokumenterer designbeslutninger, innspilte gjennomganger. Kildekoden alene er ikke lenger hele karakteren.
• 5. Live tekniske samtaler. En kort, strukturert muntlig del på hver betydelig oppgave. Fem minutter per student, fokusert på ett eller to diagnostiske spørsmål. Friksjonen er reell; signalet er utmerket.
• 6. Autentisitetsverifisering på systemnivå. Verktyg som Plagly.ai skanner innleveringer etter AI-genereringsmønstre, stilistisk ensartethet på gruppenivå og fraværet av de iterative sporene av skapelse som ekte studentarbeid vanligvis oppviser. Dette er ikke karakteren; det er et flagg som løfter frem de innleveringene som er verdt samtalen i kontortiden.

Verktøylaget som gjør dette praktisk

Den største innvendingen mot modellen over er logistisk. Virkelige klasser har hundrevis av studenter; virkelige lærere har ikke tid til å lese hver innlevering linje for linje, gjennomføre et muntlig forsvar på hver oppgave, eller oppdage mønstre på gruppenivå med det blotte øye. Verktøyet må gjøre yteskanningen slik at mennesket kan bruke skjønn på de tilfellene som betyr noe.

Hvordan dette ser ut i praksis for en CS1-gruppe med 200 studenter:

• Automatisk skanning av innleveringer: Hver opplastede fil går gjennom en AI-deteksjon som returnerer en konfidensscore og flagg per blokk. Plagly.ai utfører denne analysen med 99 % nøyaktighet over GPT-5.5, Claude 4.6, Gemini 3.1 og andre ledende modeller, inkludert de spesifikke kodevariantene som disse modellene foretrekker.
• Instrumentpanel på gruppenivå: Læreren ser en klustering av stilistiske mønstre over gruppen. Når åtte innleveringer deler idiomatiske fraser, identisk kommentar-tetthet og samme defensive grensetilfelletmønster, løftes klusteret frem for granskning.
• Skapelsesspor: Plagly.ai:s Agentic Council — sju ekspertmodeller som analyserer innleveringen ut fra skrivekvalitet, struktur, AI-deteksjon, originalitet og konsistens — produserer en referert rapport. Rapporten påstår ikke akademisk uærlighet; den dokumenterer de mønstrene som læreren kan undersøke.
• Målrettede samtaler i kontortiden: Studenter hvis innleveringer løftes frem får den fem minutter lange muntlige sjekken. De fleste klarer seg raskt; det lille antallet som ikke gjør det blir de tilfellene som læreren håndterer ettertenksomt og formelt.

Poenget er ikke å ta hver fuskere. Poenget er å holde læringssløyfen intakt for de studentene som vil lære. En klasse uten verifisering er en klasse der studentene som utnytter systemet setter normen, og studentene som jobber ærlig blir taperne. En klasse med verifisering er en klasse der den sosiale normen holder — oppgavene lærer fortsatt bort, karakterene betyr fortsatt noe, og de uteksaminerte kan fortsatt kode.

18-månedersutsikten for programmeringsutdanning

De fleste virksomme programmeringslærere vi snakker med i 2026 deler følelsen av at den nåværende situasjonen er uholdbar. Hjemmeoppgaver som evalueres gjennom godkjente tester er strukturelt inkompatible med forekomsten av uavhengige kodingsverktøy. Noe må gi etter. Tre sannsynlige retninger, i omtrent økende rekkefølge av sannsynlighet:

• Totale AI-forbud: Enkelte institusjoner vil prøve, og de fleste vil mislykkes. Forbudene er ugjennomførbare, retningslinjene blir inkonsekvente og de studentene som følger reglene uteksamineres mindre skikkelige enn de som ikke gjør det. Dette er det verste av to verdener og har allerede diskreditert seg på flere universiteter som prøvde i 2023-2024.
• Ferdighetsforskyvning nedover i læreplanen: CS1 starter senere, med mer vekt på konseptuelle grunnlag. CS2 dekker hva CS1 pleide å dekke. Avanserte kurs blir mer teoretiske fordi implementeringsdelen ikke lenger er der læringen skjer. Dette skjer, langsomt.
• Evalueringsforskyvning mot live-demonstrasjon: Hjemmeoppgaver blir formative. Summative karakterer bestemmes av live-koding under tilsyn, muntlige forsvar og prosessgjørlig arbeid. Dette er den retningen de sterkeste CS-programmene allerede beveger seg mot, og det er den retningen vi tror de fleste programmer til slutt vil lande i.

Ingen av disse scenariene løser spørsmålet om hva man skal gjøre denne terminen, med de studentene man har. For det er det praktiske trinnet en hybrid: behold dine nåværende oppgaver, legg til et verifiseringslag som fanger de verste tilfellene, legg til en eller to personlige evalueringskomponenter per kurs, og påbegynn det langsommere arbeidet med å designe om læreplanen for en verden der uavhengig AI er grunnlinjen. Verifiseringsverktøyet kjøper deg tid til å gjøre om læreplanen uten å miste denne kohorten til vibe coding i mellomtiden.

Vanlige spørsmål

Er vibe coding alltid dårlig, eller er det noen ganger legitimt?

Det er legitimt for erfarne utviklere som jobber med sideprosjekter med lav risiko der kostnaden for bugger er lav og utvikleren har den underliggende ferdigheten til å evaluere resultatet når det betyr noe. Det er skadelig for studenter som fortsatt bygger opp den underliggende ferdigheten, fordi det kortslutter det kognitive arbeidet som programmeringsutdanningen er ment å utvikle. Forskjellen er omtrent den samme som forskjellen mellom at en kokk bestiller hentemat (helt okei) og at en kulinarisk student bestiller hentemat til sin slutteksamen (ikke okei). Begge deler innebærer at de tar imot mat som de ikke selv har laget. Bare det ene undergraver læringen.

Kan studenter hevde at de har skrevet AI-detektert kode selv?

Det kan de, og noen ganger har de rett. Falske positive resultater ved koddeteksjon er vanligst når studenter skriver kode i veldig lærebokstil som tilfeldigvis matcher mønstre som AI vanligvis produserer. Det forsvarbare arbeidsopplegget behandler ikke en deteksjonsscore som en dom — det behandler den som et startpunkt for en fem minutters samtale. En student som skrev sin egen kode kan forklare den, modifisere den på stedet og spore kjøringen. En student som prompet den kan nesten aldri det. Samtalen, ikke scoren, er det som løser spørsmålet. Plagly.ai:s rapporter er utformet for å støtte den samtalen, ikke for å erstatte den.

Hvordan skiller AI-deteksjon for kode seg fra AI-deteksjon for prosa?

Koddeteksjon bruker lignende statistiske grunnlag — perplexity, burstiness, stilometriske fingeravtrykk — men bruker dem på andre overfladiske egenskaper. I kode er de mest informative signalene strukturelle snarere enn leksikalske: variabelnavnsmønstre, kommentar-tetthet og stil, idiomatiske biblioteksvalg, feilhåndteringsmaler og valget av idiomatiske konstruksjoner. Multi-modell toplighetsdetektorer oppnår 90-95 % nøyaktighet på enkeltkodinnleveringer i 2026, og stiger godt over 95 % når mønsteranalyse på gruppenivå kombineres med scoring på filnivå.

Hva skjer med studenter som genuint bruker AI som en veileder uten å kopiere outputen?

Dette er den gruppen som verifiseringslaget er eksplisitt utformet for ikke å straffe. En student som brukte AI til å forstå et konsept og deretter skrev sin egen løsning produserer kode som ikke matcher AI-genereringsmønster på radnivå. Deteksjonssignaler fanger opp resultatet, ikke forskningsprosessen. Hvis kurspolicyen din tillater AI som veileder — og vi mener den bør gjøre det — fortsetter arbeidsflyten å fungere. Du kontrollerer innleveringen, ikke studentens læringsmetode.

Fungerer dette for prosjektbaserte kurs og eksamensarbeider?

Ja, med tilpasning. For flervekers-, flerfilsprosjekter skifter de mest nyttige signalene mot prosessgjørlighet: analyse av commit-historikk (dukket koden opp i en enkelt stor commit, eller utviklet den seg over tid?), skrivesignatur-konsistens over filer (leses kodebasen som om én person skrev den, eller ser det ut som at forskjellige lapper har blitt sydd sammen?), samt dokumentasjon av designbeslutninger (kan studenten forklare hvorfor spesifikke arkitektoniske valg ble tatt?). Eksamensprosjekter drar størst nytte av et strukturert muntlig forsvar pluss en skriftlig designbegrunnelse, med AI-deteksjon som et tertiært signal snarere enn det primære.