Teknisk skuld AI: två helt olika problem du måste lösa

Teknisk skuld AI är inte bara duplicerad kod. Hälften av det ser helt okej ut i pull requesten, passerar granskning, skeppas utan invändningar, och visar sig bara sex veckor senare när ingen på teamet kan förklara varför en ändring på ett ställe bröt tre saker som ingen räknade med. Det är två helt olika typer av skuld: kodskuldnad och kognitiv skuld.

Teknisk skuld från AI är två olika problem, inte ett

Fråga fem engineering managers att definiera teknisk skuld från AI och du får fem olika svar, men de brukar dela sig i två helt olika hinkar.

Den första är kodskuldnad: dubblering, inkonsekvent mönster, kod som är tekniskt korrekt men lägger på yta som ingen bad om. Det är den hinkan statiska analysverktyg byggdes för.

Den andra är kognitiv skuld: gapet mellan hur snabbt kod genereras och hur snabbt teamet faktiskt bygger en delad mental modell av vad den gör. Sonars utvecklarundersökning från 2026 visar att 88% av utvecklare rapporterar minst en negativ påverkan från AI på teknisk skuld. 53% säger att AI genererar kod som ser rätt ut men döljer defekter: det är kodskuldnad. Det som undersökningen inte helt fångar är den andra sorten, och LeadDevs rapportering om begreppet är den kläraste behandlingen vi läst.

Tre team av fem blandar ihop de två. Här är vad de andra två gör annorlunda: de spårar kodskuldnad med verktyg, och kognitiv skuld genom samtal.

Kodskulden: Kod som ser rätt ut och inte är det

Kodskuldnad är den bekanta sorten. AI-genererad kod tenderar att duplicera logik som redan finns tre filer bort, för assistenten vet inte att logiken finns om den inte är i context. Sonars undersökning sätter en siffra på det: 40% av utvecklare säger att AI har ökat skulden genom att generera onödig eller duplicerad kod.

Den farliga varianten är inte kod som ser fel ut. Det är kod som ser rätt ut. En funktion passerar sina tester, hanterar den lyckliga vägen rent, och läses som något en senior engineer skulle skriva, förutom att den tyst sänker ett edge case som originalimplementationen hanterade. Granskning fångar stavfel. Granskning är mycket sämre på att fånga en sannolik funktion som subtilt är ofullständig.

// AI-genererad: passerar tester, ser ren ut
function getActiveUsers(users) {
  return users.filter(u => u.status === "active");
}

// Vad originalet hanterade, tre filer bort:
function getActiveUsers(users) {
  return users.filter(u => u.status === "active" && !u.deletedAt);
}

Ingenting här kastar ett fel. Ingenting faller igenom CI. Gapet visar sig bara när en mjukt raderad användare dyker upp i en rapport tre veckor senare, och vem som än blir på stöd måste grep:a, blame:a och fråga omkring för att ta reda på vilken version som är rätt och varför. Den grep-och-fråga-loopen är den faktiska kostnaden, och den är mätbar i timmar: inte i en vag känsla av att något känns fel.

Dokumentationsverktyg som sitter bredvid repot istället för i en separat wiki minskar hur ofta den loopen händer, för resonemangen bakom en funktion är ett klick från funktionen själv istället för i någons minne.

Kognitiv skuld: När teamet glömmer handlingen

Dr. Margaret-Anne Storey, professor i datavetenskap vid University of Victoria, myntade "kognitiv skuld" i oktober 2025 efter att ha sett sina studenter skeppa snabbt med AI och sedan kämpa med att agera på sin egen användarfeedback. Hennes diagnos: studenterna hade inte förlorat greppen om koden, de hade förlorat greppen om vad de byggde och varför, och vem på teamet som visste vad.

Det ramverket lånar från Peter Naurs gamla argument att mjukvara inte egentligen är koden, det är den delade teori i huvudena på de som byggde den. När kod genereras snabbare än teamet kan bygga den teorin, bildas teorin aldrig. Du kan ha en ren, fullt testad kodbas och fortfarande ha betydande kognitiv skuld om de som skeppade den inte helt kan förklara den, eller om bara en person kan.

Det här är delen som standard AI-skuld-mätvärden helt missar, för instrumentpaneler spårar koden, inte förståelsen. Frågan värd att ställa på nästa retro är rakt på sak: sätt upp ett arkitekturdiagram och fråga vem på teamet som kan förklara varje box. Om svaret är "en person, och de är på semester den här veckan," har du kognitiv skuld oavsett vad din linter säger.

En levande intern wiki löser inte kognitiv skuld själv. Den ger teamet en plats att skriva ned "varför" innan det bara lever i en persons huvud, vilket är ett start.

Varför kodgranskning inte hänger med generationshastigheten

Här är det mekaniska problemet under båda skuldslagen: AI låter en enskild engineer generera en veckas värd kod innan lunch, men granskningskapacitet har inte skalats överhuvudtaget. Flaskhalsen förflyttades från skrivning till läsning, och läsningen är delen ingen snabbade upp.

Det är här verktygjämförelsen faktiskt spelar roll, och det lönar sig att vara specifik istället för vag. Copilot och Cursor är snabba på att generera kod inuti filen du redan har öppen, vilket är precis varför de är bra på att producera mer kod än ett team kan granska. Cody och Continue.dev lutar mer mot hämtning över repot innan de genererar, vilket hjälper till att undvika dubleringproblemet ovan, men ingen ersätter det mänskliga steget att besluta om ny kod passar hur systemet ska fungera. Ingen av dem säger dig om personen som slår på PR:n faktiskt förstår vad som ändrades, vilket är en annan fråga än om difsen är syntaktiskt fin.

Fråga-din-kodbas-verktyg finns på grund av exakt detta gap: det snabbaste sättet att granska AI-genererad kod väl är att kunna fråga på vanligt språk "var finns det här mönstret på andra ställen" eller "vad hanterar redan det här fallet," innan du godkänner merge:n. Den frågan brukade ta en senior engineer tjugo minuter grep och blame. Det borde det inte.

Det finns också en repo-storlek-effekt värd att namnge. På en 5000-rads-tjänst kan en granskare hålla mest av systemet i sitt huvud, så en sannolik funktion sticker ut för att den inte matchar granskarens mentala modell. På en 80 000-rads-monorepo berörd av sex team har ingen granskare längre den mentala modellen, så sannolik kod seglar igenom bara för att ingen i rummet har contexten för att märka att den är fel. Ju större repot, desto mer beror granskningflaskhalsen på verktyg istället för en senior engineers minne.

Juniora betalar denna skuld först, och snabbast

Anthropic körde en kontrollerad studie i januari 2026, en randomiserad försök med 52 juniora utvecklare, och fann att de som använde AI-assistenter fick 17% lägre poäng på kodförståelse-tester, ungefär två bokstavsbetyg. Infobips interna ingenjörsteam, som körde ett praktikantprogram sedan 2022 över 225 praktikanter, såg samma mönster i verklig longitudinell data: pre-AI-kohorter växte i genomsnitt 2,50 poäng i självbedömd teknisk skicklighet under en praktikperiod; AI-era-kohorter växte 1,56.

Mekanismen är inte AI-användning i sig. Två praktikanter i Infobips senaste kohort använde AI med samma frekvens, med motsatta resultat. Den ena ställde följdfrågor och kunde helt förklara vad AI producerade; deras tillväxt var högst i kohorta. Den andra accepterade output med minimal granskning, behandlade det som en svart låda, och växte med noll. Verktyget var identiskt. Relationen till det var det inte.

Om du spelar in parprogrammering och arkitektur-genomgångar, och gör dem sökbara efteråt, får juniora något att komma tillbaka till istället för att föra samma fråga igen till vem som helst som är ledig. Det ersätter inte en mentor, men det sänker kostnaden för att fråga två gånger.

Hoppa över "förbjud AI för juniora" lösningen

Varje sammanfattning om det här ämnet landar på samma rekommendation så småningom: begränsa AI-åtkomst för juniora engineers tills de har "tjänat det." Hoppa över den. Det matchar inte vad team som faktiskt mätte problemet fann, och det byter ett felsätt mot ett annat lika verkligt; juniora som inte kan använda verktygen sitt team levererar med faller bakom på ett annat sätt.

Vad som fungerade för Infobip var istället sekvensering, inte förbudande: försök problemet först, kontrollera med AI andra, så van av eget tänkande bildas innan AI blir standarddraggandet. De lade till AI-fria kontrollpunkter, inte som straff utan som kalibrering, så både praktikant och mentor vet var skicklighet faktiskt står. Mentorer skiftade också från att granska pull request till att spåra process: vem frågade vad, vem fastnade var, vem förklarade sin egen ändring utan hjälp.

Nöjdhetspoäng steg hela tiden medan skicklighetstillväxt föll, vilket är den riktiga varningen i deras data: om du bara spårar hur folk känner om verktygen, ser du inte det här komma. 20% av praktikanter i Infobips senaste kohort visste inte ens vad som förväntades av en juniora engineer på deras nivå till att börja med, vilket gjorde självbedömning nästan meningslös. Du kan inte mäta ett gap mot en referenspunkt ingen skrev ned.

Vad vi skulle faktiskt ändra denna sprint

Börja med retro-frågan ovan: vem kan förklara varje del av systemet, högt och tydligt, redan nu. Den enda frågan ytar mer kognitiv skuld på tio minuter än någon instrumentpanel någonsin kommer.

För kodskuldnad, håll statisk analys i loopen. Sonars utvecklarundersökning från 2026 visar att 70% av utvecklare redan använder den, och team som kör den rapporterar meningsfullt bättre resultat på omarbetningskostnad än team som hoppas över den. Det är inte en kontroversiell rekommendation, det är bara en team hoppas över när de rör sig snabbt för att AI-output såg färdig.

Det arbetet som AI tar bort från skrivkod försvinner inte. Sonar kallar detta "den stora arbetsskiftet": det dyker upp igen längre bort, i att hantera skuld och rätta AI-output. Om du automatiserar de återkommande delarna av triajen, flaggar stulna PR:er, ruttar granskningsförfrågningar, jagar uppföljningar, frigörs seniortiid för den del som faktiskt kräver en människa: att besluta om teamet förstår vad det just skeppade.

Mäta bana, inte tillfredsställelse. Ett team som känner sig bra med AI och inte kan förklara sin egen arkitektur om sex månader har inte sparat tid. Det har lånat den, till en ränta ingen skrev ned.