”AI skriver kod snabbare” är inte omstritt. Om den skriver kod sämre är en egen, empirisk fråga — och vi besvarar den hellre med mätningar än med någondera sidans talepunkter. Tre oberoende studier, med tre olika metoder, konvergerar mot samma svar.
Utgångspunkten: en dokumenterad defektfrekvens
Grundstudien behandlar vi i detalj i A Clean Benchmark Is Not a Clean Codebase (på engelska): Pearce m.fl. (IEEE S&P 2022) fann att omkring 40 % av 1 689 Copilot-genererade program var sårbara för svaghetsklasserna i MITRE:s Top 25. Studien är numera gammal nog att dess siffra inte bör läsas som aktuell — modellerna har förändrats sedan 2022. Vad den etablerade, och vad senare arbete bygger på: frågan är verklig och kan besvaras med standardmetoder — riktade scenarier, ett stort urval, statisk analys mot en namngiven svaghetslista.
Mekanismen: inte slumpmässiga buggar, utan en systematisk frånvaro
En siffra ensam säger inte vad man ska göra. En kontrollerad jämförelse av människoskriven och LLM-genererad kod — datastrukturer, algoritmer, kryptografiska rutiner och LeetCode-liknande uppgifter, med enhetstester, fuzzning och statisk analys (arXiv:2409.19182) — gick längre och fann detta: LLM-genererad kod är mindre säker framför allt därför att den saknar defensiva programmeringskonstruktioner — de gränskontroller och den indatavalidering en noggrann ingenjör lägger till av vana, inte funktionen som faktiskt efterfrågades. Den frånvaron är vad som bjuder in buffert- och heltalsöverskridanden. Under fuzzning var LLM-genererad kod mer benägen till hängningar och krascher än den människoskrivna jämförelsebasen. Korrekthetsfel kunde vara subtila snarare än uppenbara: i ett fall producerade modellen en felaktig SHA-1-implementation som ändå kompilerade rent — fel, och tyst om saken.
Fyndet som borde oroa var och en som betraktar ”be modellen laga det” som ett skyddsnät: samma studie byggde en återkopplingsslinga och bad modellen återgenerera koden och eliminera problem den just visats. Det fungerade inte tillförlitligt. I vissa fall lyckades rättningen. I andra innehöll den ”lagade” koden nya problem — och i några fall förde själva promptandet in problem i filer som varit rena innan. Att låta författaren rätta sina egna prov är inte granskning.
Produktionsbelägget: kostnaden försvinner inte med nyhetens behag
Det färskaste belägget kommer helt utanför laboratoriet. En studie följde 807 kodförråd med öppen källkod på GitHub som införde AI-kodassistenten Cursor mellan januari 2024 och mars 2025, mot en kontrollgrupp på 1 380 jämförbara förråd utan den — med SonarQube som mätinstrument för statiska analysvarningar, duplicering och komplexitet, fram till augusti 2025. Produktivitetshistorien utspelade sig som väntat: en kortlivad topp i commits och tillagda rader de första en till två månaderna, tillbaka till baslinjen den tredje. Kvalitetskostnaden försvann inte med den. Statiska analysvarningar steg cirka 30 % efter införandet och förblev förhöjda. Kodkomplexiteten steg med mer än 40 % — mer än vad kodbasens tillväxt ensam skulle förklara. Fartvinsten var tillfällig. Skulden var det inte.
En ärlig gräns
Detta är inte påståendet att AI-genererad kod alltid är sämre, som allmän lag. Uppgift, modell och arbetssätt spelar alla roll — och ett team som behandlar AI-utdata som ett första utkast som förtjänar samma granskningsdisciplin som en juniör ingenjörs pull request ser andra resultat än ett team som levererar den ogranskad. Studierna ovan testar inte varje modell eller varje arbetssätt, och ingen isolerar granskningsdisciplin som variabel. Vad de konsekvent etablerar, över tre oberoende metoder (riktade CWE-tester, kontrollerad jämförelse, longitudinella produktionsdata): effekten är verklig och systematisk snarare än tillfällig — och att be modellen kontrollera sitt eget arbete ersätter inte att någon annan gör det.
Varför detta är en efterlevnadsfråga, inte bara en ingenjörsfråga
Enligt cyberresiliensförordningen ska en tillverkare säkerställa att produkter med digitala element ”utformas, utvecklas och produceras på ett sådant sätt att de säkerställer en lämplig cybersäkerhetsnivå baserat på riskerna” och ”tillhandahållas på marknaden utan kända sårbarheter som kan utnyttjas” (förordning (EU) 2024/2847, bilaga I del I punkterna 1 och 2 a). Ingen av klausulerna nämner hur koden skrevs. Båda blir svårare, inte lättare, att uppfylla ju mer av en kodbas yta som producerats av en process med en uppmätt, systematisk brist i exakt de konstruktioner — gränskontroller, indatavalidering — som hindrar en känd svaghetsklass från att bli utnyttjbar. Snabbare generering utan motsvarande mer granskning är ingen genväg runt den skyldigheten. Det är ett växande avstånd till den.
Varför det angår oss
På CounterProof bedriver vi adversariell granskning av maskinskriven kod, och dessa tre studier beskriver exakt det gap vår verksamhet finns för att stänga: att behandla AI:ns utdata — den som genererar och den som granskar — som ett påstående att kontrollera, inte ett resultat att lita på. Se systerstycket A Clean Benchmark Is Not a Clean Codebase (på engelska) om vad som händer när även kontrollverktyget är AI-baserat och dess egen tillförlitlighet lämnas oprövad. Det längre argumentet, inklusive den villkorade formen av varje påstående ovan, finns i vårt arbetspapper om kollationering och proveniens för maskingenererad text, läsbart i sin helhet här (på engelska). Det är ett utkast till preprint, inte referentgranskat, och det säger det.
Källorna ovan har kontrollerats mot sina publicerade sammanfattningar. Siffran från Pearce m.fl. är från IEEE S&P 2022 och beskriver Copilot som det såg ut vid den studiens tid, inte dagens modeller. Cursor-siffrorna kommer från en longitudinell studie av 807 förråd mot en kontrollgrupp på 1 380, följda januari 2024 till augusti 2025. Citerade CRA-bestämmelser avser förordning (EU) 2024/2847 och har kontrollerats mot den officiella svenska språkversionen. Denna sida är en översättning av det engelska originalet; vid avvikelser gäller originalet. Om något här är fel rättar vi det skriftligt på denna sida.