Vibe coding-krisen: varför CS-examinerade inte längre kan koda utan AI

I en Reddit-tråd i mars 2026, som snabbt passerade 8 000 uppröster, publicerade en senior utvecklare på ett Series-B-startup skärmdumpar av en hemuppgift han just hade avvisat. Kandidaten, en nyutexaminerad CS-student med 3,9 i GNO från ett respekterat program, hade skickat in kod som kördes perfekt under ideala förhållanden (happy path) men tyst korrumperade data vid varje gränsfall (edge case). När kandidaten ombads att gå igenom logiken i ett uppföljande samtal, kunde han inte förklara varför en av hans egna funktioner använde rekursion. Raden som fick tråden att explodera var hans ärliga svar: “Jag berättade bara för Claude vad vi behövde och den skrev detta. Jag brukar bara läsa koden om den inte fungerar.”

Detta är vibe coding-krisen, och år 2026 har den migrerat från utvecklar-Twitter till rekryteringsprocesser, utvärderingar efter intervjuer och i allt högre grad till kontoren hos prefekter på CS-avdelningar som försöker förstå vad som just hände med deras examinerade studenter. Termen myntades av Andrej Karpathy i februari 2025 för att beskriva ett positivt nytt arbetssätt: beskriv din avsikt, acceptera vad modellen producerar, skeppa. Inom ett år blev samma fras branschens kortnamn för en generation programmerare som kan skriva prompter flytande men inte kan resonera om vad deras kod faktiskt gör.

För programmeringslärare är detta inte ett hypotetiskt problem om arbetets framtid. Det är en akut pedagogisk nödsituation i nutid gällande de studenter ni examinerar just nu. Denna artikel undersöker vad forskningen och fältrapporterna faktiskt visar om AI-inducerad kompetensförsvagning (atrophy), varför CS1 till sista årets examensarbete är unikt sårbara, och hur en liten men växande grupp lärare strukturerar om sina kurser för att säkerställa att studenter tar examen med förmågan att koda — inte bara med förmågan att prompta.

Vad vibe coding faktiskt betyder (och varför Karpathy sa att det borde vara roligt)

Karpathys ursprungliga inramning var specifik. Vibe coding innebar att acceptera att programmering för personliga projekt nu kunde kännas som kreativ lek: du berättar för modellen vad du vill ha, den producerar kod, du justerar prompten snarare än koden, och du skeppar något som fungerar. Han noterade uttryckligen att han inte längre läste kod rad för rad för sina egna sidoprojekt. Inramningen handlade om glädje, produktivitet och den legitima observationen att för mindre viktiga engångsprojekt är en noggrann manuell granskning överdriven.

Termen spreds sedan till det bredare fältet, där den landade i två mycket olika sammanhang:

• Seniora utvecklare som använder det medvetet: Behandlar AI-genererad kod som ett utkast, läser och strukturerar om den före commit, använder AI för att slippa rutinmässig kodmallskrivning men tillämpar decennier av mönsterigenkänning för att utvärdera resultatet. Detta är vad Karpathy beskrev, och det fungerar.
• Juniora utvecklare och studenter som antar det som sitt standardläge: Behandlar AI-genererad kod som ett färdigt resultat, accepterar den utan att läsa, felsöker endast när tester misslyckas, vänder sig till en senior eller lärare först när AI:n inte kan fixa sin egen kod. Detta är vad Karpathy inte beskrev, och det fungerar inte.

Det pedagogiska problemet är den andra gruppen, och de utgör majoriteten av de studenter som börjar på CS-programmen 2026. Karpathy själv backade från sin inramning senare under 2025 och noterade att vibe coding är rimligt för experter på personliga projekt men skadligt för alla andra.

Kompetensförsvagningen i faktiska siffror

Bevisen är nu omfattande, och de pekar i en riktning. En analys i december 2025 publicerad av CodeRabbit, som undersökte pull requests i hundratals öppna källkodsprojekt, fann att kod skriven tillsammans med generativ AI innehöll ungefär 1,7x fler “större” problem än mänskligt skriven kod. Logikfel (felaktiga beroenden, bristfälligt kontrollflöde) och säkerhetssårbarheter var båda signifikant förhöjda, där säkerhetsbrister uppträdde i 2,74x takten jämfört med kod skriven av enbart människor.

En TechSpot-rapport i slutet av 2025 undersökte yrkesverksamma utvecklare angående de kognitiva effekterna av påtvingade vibe coding-arbetsflöden. Det gemensamma rapporterade mönstret: ökande felsökningstid, minskande förmåga att mentalt simulera kod, och en försämrad intuition för hur kod av produktionskvalitet ser ut. En utvecklare beskrev sin upplevelse efter sex månader av vibe-först-arbete som att helt "förlora kasthafrminnet" för problemlösning.

Den tydligaste illustrationen kom från en utvecklare som körde ett 30-dagarsexperiment i början av 2026: ingen AI-hjälp under en månad, och reflektera sedan över skillnaden. Skriften på dev.to, I Coded Without AI for 30 Days: The Results Were Embarrassing, blev en av årets mest delade utvecklar-essäer. Det centrala resultatet: en yrkesverksam senior utvecklare med åtta års erfarenhet kunde inte längre skriva en enkel traversering av ett binärt träd (binary tree traversal) ur minnet. Färdigheten hade lagts ut på entreprenad och sedan tyst tynat bort.

Om en yrkesverksam senior utvecklares felsökningsmuskel försvagas inom några månader av AI-beroende, föreställ dig då banan för en CS1-student som aldrig har haft den muskeln från början — vars hela upplevelse av programmering har förmedlats via en LLM som producerar en fungerande lösning inom tio sekunder efter att ha sett problemformuleringen.

Varför programmeringsundervisning är unikt sårbar

Andra discipliner hanterar AI i utbildningen ofullständigt, men de flesta har fortfarande intakta examinationsramar. En student i litteratur kan fortfarande beas att diskutera ett stycke i ett seminarium. En student i kemi kan fortfarande beas att utföra en laboratorieprocedur. En student i matematik kan fortfarande beas att härleda ett bevis på svarta tavlan. Programmeringsundervisning har inget av dessa intakta examinationssätt. Nästan varje programmeringsuppgift är hemarbete, utvärderad utifrån om koden klarar tester — och en AI 2026 klarar de testerna trivialt.

Detta skapar tre sårbarheter som är specifika för programmering:

• Uppgift-test-loopen är fullt automatiserbar. Codex, Claude Code och Cursor läser uppgiften, skriver koden, kör testsviten, itererar vid misslyckanden och skickar in en fungerande lösning. Den fullständiga cykel som en student förväntas utföra — förstå krav, designa en lösning, implementera den, felsöka den — kan utföras av AI:n snabbare än studenten kan läsa specifikationen.
• Canli utvärdering är logistiskt dyr. En CS1-klass med 200 studenter kan inte realistiskt genomföra ett fem minuters muntligt försvar på varje uppgift utan att bränna tjugo timmar av lärarassistenters tid per uppgiftscykel. Den ekonomiska modellen för stora CS-kurser förutsätter asynkron hemarbetesrättning.
• Fusket är osynligt för studenten. En student som kopierar en uppsats vet att de fuskar. En student som promptar en AI att lösa en uppgift kanske inte uppfattar det som fusk — den sociala normen har skiftat snabbare än policyn, och handlingen känns oskiljbar från att slå upp något. När de når sista året och behöver tänka själva, har de tillbringat fyra år utan att bygga upp någon relevant skicklighet.

Resultatet är en examinationskedja som producerar studenter med meriter som inte längre korrelerar med skicklighet. Rekryteringsansvariga 2026 går alltmer förbi CV och betyg till förmån för live teknisk utvärdering, just för att betygssystemet har kopplats bort från den underliggande förmågan.

Hur “att lära sig ingenting” ser ut på CS-mottagningstider

Om du undervisar i programmering har du förmodligen sett detta mönster, även om du inte har satt ord på det ännu. Vi har sammanställt de vanligaste diagnostiska signalerna från lärare i CS1, datastrukturer och examenskurser under slutet av 2025 och början av 2026.

• Studenten kan inte hitta sin egen bugg. Inlämningen kördes perfekt. Nytt enhetstest misslyckas. Studenten öppnar filen, tittar på koden som om de såg den för första gången, scrollar upp och ner utan en hypotes, och säger slutligen “Jag frågar bara Claude vad som är fel.” Den första reaktionen på ett misslyckat test är att vända sig till AI istället för att formulera en hypotes.
• Studenten kan inte svara på “varför”. På frågan “varför använde du en hash map här istället för en array,” blir svaret “det var det AI:n föreslog.” Valet gjordes; resonemanget bakom det internaliserades aldrig. Det finns ingen kognitiv modell under koden.
• Studenten kan inte göra en liten variant. “Modifiera detta så att det även hanterar negativa tal” borde vara en trettio sekunders redigering. För den AI-beroende studenten blir det en fem minuters promptsession eftersom de behöver mata in begränsningen i modellen istället för att tänka ut var i den befintliga koden ändringen ska göras.
• Studenten är flytande i verktyg, analfabet i problem. De kan konfigurera Vercel, bygga en React-komponent, sätta upp en Postgres-databas, driftsätta med Docker. De kan använda hela den moderna verktygskedjan. Be dem implementera quicksort. Tystnad.
• Examensprojektets avslöjande. Det sista årets examensprojekt, det ögonblick då ackumulerad skicklighet borde ge utdelning, är alltmer ett ögonblick då ackumulerad brist på skicklighet avslöjas. Team som vibe-kodade sig igenom CS1 till tredje året anländer till examensprojektet oförmögna att designa ett system, oförmögna att dela upp en funktion, oförmögna att hantera de delar av programmeringen som AI gör sämst.

Den pedagogiska lösningen: Behandla AI-flytande som en verklig skicklighet (och gör den förtjänt)

De lärare som hanterar denna övergång väl är inte de med de strängaste AI-förbuden. Det är de som har byggt om sina kurser kring en tydlig distinktion: AI är ett verktyg som studenter ska lära sig att använda väl, OCH studenter måste självständigt visa de kognitiva färdigheter som AI:n utövar. De två kraven står inte i konflikt — de kompletterar varandra, och kurserna som gör detta rätt producerar examinerade som presterar bättre än både vibe-kodare och AI-bannlysta grupper.

De specifika designmönster vi ser fungera i programmeringskurser under 2026:

• 1. Tvåspårs-uppgiften. Varje uppgift har en “solo”-del (ingen AI tillåten, ofta en liten del i klassrummet) och en “verktygs”-del (AI tillåten men dokumenterad). Solo-delen fångar vad studenten faktiskt kan göra. Verktygsdelen lär dem att göra mer.
• 2. AI-flytande som en betygssatt kompetens. Studenterna skickar in de AI-prompter de använde, svaren de fick och en analys av var AI:n hade fel eller var ineffektiv. Att läsa AI-output kritiskt behandlas som ett kursmål, inte en genväg.
• 3. Examinationer enbart i felsökning. Studenterna ges fungerande AI-genererad kod med subtila buggar (off-by-one, felaktigt basfall, saknad null-kontroll, säkerhetssårbarhet) och betygssätts på sin förmåga att hitta och åtgärda dem. Detta tränar den skicklighet som AI presterar sämst på och som arbetsgivare värderar mest.
• 4. Processgörlig betygssättning. Krävd commit-historik, obligatoriska kommentarer som dokumenterar designbeslut, inspelade genomgångar. Källkoden ensam är inte längre hela betyget.
• 5. Live tekniska samtal. En kort, strukturerad muntlig del på varje betydande uppgift. Fem minuter per student, fokuserad på en eller två diagnostiska frågor. Friktionen är verklig; signalen är utmärkt.
• 6. Autenticitetsverifiering på systemnivå. Verktyg som Plagly.ai skannar inlämningar efter AI-genereringsmönster, stilistisk enhetlighet på gruppnivå och avsaknaden av de iterativa spår av skapande som verkligt studentarbete vanligtvis uppvisar. Detta är inte betyget; det är en flagga som lyfter fram de inlämningar som är värda mottagningstidssamtalet.

Verktygsskiktet som gör detta praktiskt

Den största invändningen mot modellen ovan är logistisk. Verkliga klasser har hundratals studenter; verkliga lärare har inte tid att läsa varje inlämning rad för rad, genomföra ett muntligt försvar på varje uppgift, eller upptäcka mönster på gruppnivå med blotta ögat. Verktyget måste göra ytskanningen så att människan kan tillämpa omdöme på de fall som betyder något.

Hur detta ser ut i praktiken för en CS1-grupp med 200 studenter:

• Automatisk skanning av inlämningar: Varje uppladdad fil går igenom en AI-detektering som returnerar en konfidenspoäng och flaggor per block. Plagly.ai utför denna analys med 99 % noggrannhet över GPT-5.5, Claude 4.6, Gemini 3.1 och andra ledande modeller, inklusive de specifika kodvarianter som dessa modeller föredrar.
• Instrumentpanel på gruppnivå: Läraren ser en klustring av stilistiska mönster över gruppen. När åtta inlämningar delar idiomatiska fraser, identisk kommentarstäthet och samma defensiva gränsfallsmönster, lyfts klustret fram för granskning.
• Skapandespår: Plagly.ai:s Agentic Council — sju expertmodeller som analyserar inlämningen utifrån skrivkvalitet, struktur, AI-detektering, originalitet och konsistens — producerar en refererad rapport. Rapporten påstår inte akademisk ohederlighet; den dokumenterar de mönster som läraren kan undersöka.
• Målmedvetna mottagningstidssamtal: Studenter vars inlämningar lyfts fram får den fem minuter långa muntliga kontrollen. De flesta klarar sig snabbt; det lilla antalet som inte gör det blir de fall som läraren hanterar eftertänksamt och formellt.

Poängen är inte att sätta dit varje fuskare. Poängen är att hålla lärandeloopen intakt för de studenter som vill lära sig. En klass utan verifiering är en klass där studenterna som utnyttjar systemet sätter normen och studenterna som arbetar ärligt blir förlorarna. A klass med verifiering är en klass där den sociala normen håller — uppgifterna lär fortfarande ut, betygen betyder fortfarande något, och de examinerade kan fortfarande koda.

18-månadersutsikten för programmeringsutbildning

De flesta verksamma programmeringslärare vi talar med 2026 delar känslan av att den nuvarande situationen är ohållbar. Hemuppgifter som utvärderas genom godkända tester är strukturellt inkompatibla med förekomsten av oberoende kodningsverktyg. Något måste ge vika. Tre troliga riktningar, i ungefär ökande ordning av sannolikhet:

• Totala AI-förbud: Vissa institutioner kommer att försöka, och de flesta kommer att misslyckas. Förbuden är ogenomförbara, policyerna blir inkonsekventa och de studenter som följer reglerna tar examen mindre skickliga än de som inte gör det. Detta är det sämsta av två världar och har redan misskrediterat sig på flera universitet som försökte under 2023-2024.
• Färdighetsförskjutning nedåt i läroplanen: CS1 startar senare, med mer betoning på konceptuella grunder. CS2 täcker vad CS1 brukade täcka. Avancerade kurser blir mer teoretiska eftersom implementeringsdelen inte längre är där lärandet sker. Detta sker, långsamt.
• Examinationsförskjutning mot live-demonstration: Hemuppgifter blir formativa. Summativa betyg bestäms av live-kodning under övervakning, muntliga försvar och processgörligt arbete. Detta är den riktning de starkaste CS-programmen redan rör sig mot, och det är den riktning vi tror att de flesta program till slut kommer att landa i.

Inget av dessa scenarier löser frågan om vad man ska göra den här terminen, med de studenter man har. För det är det praktiska steget en hybrid: behåll dina nuvarande uppgifter, lägg till ett verifieringsskikt som fångar de värsta fallen, lägg till en eller två personliga examinationskomponenter per kurs, och påbörja det långsammare arbetet med att designa om läroplanen för en värld där oberoende AI är grundnivån. Verifieringsverktyget köper dig tid att göra om läroplanen utan att förlora den här kohorten till vibe coding under tiden.

Vanliga frågor

Är vibe coding alltid dåligt, eller är det ibland legitimt?

Det är legitimt för erfarna utvecklare som arbetar med sidoprojekt med låg risk där kostnaden för buggar är låg och utvecklaren har den underliggande skickligheten att utvärdera resultatet när det betyder något. Det är skadligt för studenter som fortfarande bygger upp den underliggande skickligheten, eftersom det kortsluter det kognitiva arbete som programmeringsutbildningen är tänkt att utveckla. Skillnaden är ungefär densamma som skillnaden mellan att en kock beställer hämtmat (helt okej) och att en kulinarisk student beställer hämtmat till sin slutexamen (inte okej). Båda innebär att de tar emot mat som de inte själva har lagat. Endast det ena undergräver lärandet.

Kan studenter hävda att de skrivit AI-detekterad kod själva?

Det kan de, och ibland har de rätt. Falska positiva resultat vid koddetektering är vanligast när studenter skriver kod i väldigt läroboksstil som råkar matcha mönster som AI vanligtvis producerar. Det försvarbara arbetsflödet behandlar inte en detekteringspoäng som en dom — det behandlar den som en startpunkt för ett fem minuters samtal. En student som skrev sin egen kod kan förklara den, modifiera den på plats och spåra dess körning. En student som prompade den kan nästan aldrig det. Samtalet, inte poängen, är det som löser frågan. Plagly.ai:s rapporter är utformade för att stödja det samtalet, inte för att ersätta det.

Hur skiljer sig AI-detektering för kod från AI-detektering för prosa?

Koddetektering använder liknande statistiska grunder — perplexity, burstiness, stilometriska fingeravtryck — men tillämpar dem på andra ytliga egenskaper. I kod är de mest informativa signalerna strukturella snarare än lexikala: variabelnamnsmönster, kommentarstäthet och stil, idiomatiska biblioteksval, felhanteringsmallar och valet av idiomatiska konstruktioner. Multi-modell toplighetsdetektorer uppnår 90-95 % noggrannhet på enskilda kodinlämningar 2026, och stiger väl över 95 % när mönsteranalys på gruppnivå kombineras med poängsättning på filnivå.

Vad händer med studenter som genuint använder AI som en handledare utan att kopiera dess output?

Detta är den grupp som verifieringsskiktet är explicit utformat för att inte straffa. En student som använde AI för att förstå ett koncept och sedan skrev sin egen lösning producerar kod som inte matchar AI-genereringsmönster på radnivå. Detekteringssignaler fångar resultatet, inte forskningsprocessen. Om din kurspolicy tillåter AI som handledare — och vi tycker att den borde göra det — fortsätter arbetsflödet att fungera. Du kontrollerar inlämningen, inte studentens lärandemetod.

Fungerar detta för projektbaserade kurser och examensarbeten?

Ja, med anpassning. För flerveckors-, flerfilsprojekt skiftar de mest användbara signalerna mot processgörlighet: analys av commit-historik (dök koden upp i en enda stor commit, eller utvecklades den över tid?), skrivtutseende-konsistens över filer (läses kodbasen som om en person skrev den, eller ser det ut som att olika lappar har sytts ihop?), samt dokumentation av designbeslut (kan studenten förklara varför specifika arkitektoniska val gjordes?). Examensprojekt drar störst nytta av ett strukturerat muntligt försvar plus en skriftlig designmotivering, med AI-detektering som en tertiär signal snarare än den primära.