Ninety Percent of the Problems Are AI-Generated
April 2026

Ninety Percent of the Problems Are AI-Generated

Nittio procent av problemen är AI-genererade

En CTO jag arbetar med har gjort något ovanligt. Under åtta månader har han granskat varje commit som passerar genom teamets CICD-pipeline. Varje pull request. Varje kodändring. Inte stickprov — allt.

Hans slutsats: nittio procent av den problematiska koden är AI-genererad.

Inte nittio procent av all kod. Nittio procent av problemen.

Det ingen vill höra

Det här är det som gör insikten obekväm: verktygen fungerar. De gör exakt vad de ska. De genererar kod snabbt, i stora volymer, med hög syntaktisk kvalitet. Koden kompilerar. Den passerar grundläggande tester. Den ser professionell ut.

Och den skapar teknisk skuld i en takt som ingen manuell utvecklare hade kunnat åstadkomma.

Det är inte ett argument mot AI. Det är ett argument för att sluta behandla AI-genererad kod som om den vore gratis.

Multiplikatorn slår åt båda hållen

Jag har skrivit förut om att AI förstärker det du redan kan. Att en senior med rätt verktyg blir extraordinär. Det är sant. Men det jag inte betonade tillräckligt var den andra sidan.

En utvecklare som inte förstår uppgiften, som inte kan tolka krav, som inte ser arkitekturella konsekvenser — den personen blev inte bättre av AI. Den personen blev farligare.

Tidigare producerade den utvecklaren medioker kod långsamt. Nu producerar samma person medioker kod i en takt som översvämmar systemet. Fler filer, fler moduler, fler beroenden — allting genererat, ingenting granskat, allt teknisk skuld.

CTO:n uttryckte det så: "De som kan uttrycka sig tydligt och förstår uppgiften får bra resultat. De som inte kan det skapar större problem med AI än utan."

Det är det som saknas i branschens berättelse. AI gör inte alla bättre. AI gör alla snabbare. Och snabbare åt fel håll är värre än långsamt åt rätt håll.

Teknisk skuld, 2026-versionen

Teknisk skuld är inget nytt. Varje utvecklingsteam lever med den. Men 2026-versionen ser annorlunda ut.

Traditionell teknisk skuld uppstår gradvis: genvägar under tidspress, halvfärdiga lösningar som blir permanenta, dokumentation som aldrig skrivs. Du ser den komma. Du kan hantera den.

AI-genererad teknisk skuld uppstår omedelbart och i volym. En junior utvecklare som ber en LLM generera en hel modul på en eftermiddag skapar mer teknisk skuld än samma utvecklare hade producerat på en månad manuellt. Koden ser ren ut. Den följer konventioner. Men antagandena är fel, edge cases saknas, och arkitekturen matchar inte resten av systemet.

Och det värsta: det syns inte vid en ytlig granskning. Koden ser professionell ut. Du måste förstå systemet för att se att den är fel. Och om du förstår systemet tillräckligt väl för att se det — då hade du inte behövt AI för att skriva den.

Riktlinjerna som ingen följde

CTO:n hade gjort sin del. Han hade skapat ett development skills-paket. Arkitekturstandarder. Definierade lager i applikationen. Use case-mallar med aktörer, flöden, affärsregler. Allt dokumenterat, allt distribuerat till teamet.

Nästan ingen följde dem.

Inte för att de var dåliga. Inte för att de var otydliga. Han vet inte varför — för feedbacken uteblev. Ingen sa att det var svårt. Ingen sa att det inte fungerade. Ingen sa någonting alls.

Det är den tysta katastrofen. Du bygger strukturen. Du delar den. Du väntar på att den ska adopteras. Och du upptäcker först åtta månader senare, genom att granska varje rad kod, att den aldrig användes.

Utan feedback-loop finns det ingen adoption. Utan adoption finns det ingen struktur. Utan struktur finns det teknisk skuld.

Vad siffrorna faktiskt säger

Nittio procent av problemen är AI-genererade. Det säger tre saker:

Det säger att verktyget är neutralt. AI genererar exakt det du ber om. Om du ber om rätt saker med rätt kontext och rätt förståelse får du extraordinära resultat. Om du inte gör det får du extraordinära problem.

Det säger att granskning inte är valfritt. CTO:n hittade problemen för att han läste varje rad. I ett team utan den granskningen hade samma kod passerat obemärkt. Kontrollpunkten är inte ett steg i processen — den ÄR processen.

Det säger att utbildning inte handlar om verktygen. Ingen i teamet behövde lära sig mer om AI. De behövde lära sig mer om hur man uttrycker en uppgift, följer en arkitektur, och validerar ett resultat. Det är inte AI-utbildning — det är professionell utveckling som råkar involvera AI.

Året vi slutar låtsas

2024 var året alla började använda AI. 2025 var året alla pratade om produktivitetsvinster. 2026 borde vara året vi slutar låtsas att AI bara skapar värde.

Det skapar värde — enormt värde — i rätt händer. Men i fel händer skapar det teknisk skuld snabbare, elegantare, och svårare att upptäcka än något vi sett förut.

Nittio procent av problemen är AI-genererade. Det är inte en anklagelse mot verktygen. Det är en påminnelse om att verktygen bara är så bra som personen som använder dem.

Du äger fortfarande varje rad.


Jag skrev i serie 6 att du inte kan validera det du inte förstår. Det här är beviset: en CTO mätte det.

Se även: Kontrollpunkten är jobbet (serie 11) och AI tvingar dig att tänka hårdare (serie 12).

Mindtastic om varför domänkunskap multiplicerar AI-output — Domain knowledge multiplies AI output.

Was this helpful?