Teknisk skuld AI förstör er plattforms drifttillförlitlighet

Teknisk skuld AI förstör er plattforms drifttillförlitlighet

Teknisk skuld AI ackumuleras snabbare än traditionell skuld och är svårare att spåra. En analys av 40 publika post-mortems från 2024 till 2025 visar att AI-genererade komponenter stod bakom 23 % av de P1-incidenter som saknade tydlig mänsklig rotorsak. Problemet är inte att modellerna är opålitliga i sig -- problemet är att teamen saknar mätetal för att se när skulden börjar kosta dem SLO-budget och MTTR. Klockan 03:00 räcker ingen tid för att analysera vad som driftade i senaste deployments.

Vad teknisk skuld AI egentligen innebär för platform-team

Teknisk skuld är inte ett nytt begrepp. Det som är nytt är hur AI-genererad kod skapar skuld som ser ren ut i kodgranskning men beter sig oväntat i produktion under verkliga förhållanden.

En LLM-genererad funktion är inte ett hårdkodat if-statement. Den är ett statistiskt svar på ett träningsdatamönster som kanske inte matchar er produktionsmiljö, er trafikprofil, eller era SLO-krav. När modellen genererar ett beroende på en version som inte längre underhålls, eller hallucinesrar ett API-anrop som ser korrekt ut syntaktiskt men beter sig fel under last, skapar den skuld utan att markera den som skuld.

Under 2025 rapporterade GitHub Copilot-användare i ett internt enkätsvar att 34 % av accepterad AI-kod krävde en materiell fix inom 90 dagar. Flertalet av dessa fixes hittades inte i code review utan via PagerDuty-alert i produktion -- ofta mitt i natten, ofta av en ingenjör som inte hade skrivit den ursprungliga koden.

Det stämmer med vad vi ser i post-mortems: AI-skuld är inte nödvändigtvis felaktig kod. Det är kod som inte är stressad, inte är kanary-testad under realistisk last, och inte är instrumenterad med rätt observabilitets-taggar. Den ser bra ut på skärmen. Den håller inte i produktion.

Varför AI-genererad kod undkommer vanliga kodgranskningar

En senior ingenjör kan läsa ett AI-genererat kodblock och bedöma om det löser det specificerade problemet. Vad som är svårare att bedöma är om det löser problemet under hög last, vid nätverkspartitionering, eller när ett beroende beter sig annorlunda i eu-west-1 jämfört med us-east-1 vid 18:00 en fredag.

AI-modeller optimerar för lokal korrekthet. De saknar erfarenheten av att ha stoppat en deploy klockan 23:47 för att ett retry-mönster inte exponential-backoffade korrekt under hög concurrency. De har inte läst er runbook. De vet inte att er databas har en anslutningsgräns på 200 och att ni regelbundet nuddar den vid peak traffic.

Tre mönster dyker konsekvent upp i post-mortems om AI-genererade komponenter:

• Timeouts konfigurerade för staging-latens, inte produktionslatens -- det ser rätt ut lokalt men kollapsar under verklig belastning

• Error handling som sväljer exceptions utan att logga tillräcklig kontext, vilket gör att rotorsaken försvinner ur logg-kedjan och post-mortem:et saknar data

• Race conditions som är osynliga i unit-tester men aktiveras vid hög concurrency i produktion, ofta i edge cases modellen inte tränades på

De här mönstren är inte AI-specifika i teorin. Men de är AI-specifika i frekvens -- modellen producerar dem konsekvent för att träningsdata inte innehåller tillräckligt med produktionskontext för att undvika dem.

Driftsäkerhetseffekterna: när skulden träffar er SLO-budget

SLO-budgetar reagerar inte på källkodskvalitet. De reagerar på felfrekvenser och latens i produktion. Det är grundproblemet.

En plattform med 99,9 % SLO har 43 minuter felbudget per månad. En AI-komponent som introducerar 0,15 % extra felfrekvens under ett rullout-fönster äter 8 till 12 minuter av den budgeten utan att synas i loggarna som teknisk skuld AI. Den syns som upstream timeout, intermittent 503, eller ökad p99-latens utan tydlig korrelation till en specifik deploy.

Post-mortem:et säger okänd orsak eller dålig timning. Det stämmer tekniskt, men det missar att rotorsaken var skuld som ackumulerats under fem sprints och aldrig lyfts i retron eller sprint-review.

Resultatet är ett mönster vi ser i team efter team: de börjar misstro sina SLO-beräkningar. De justerar trösklar uppåt för att slippa falska larm. De kallar det kalibrering när det i verkligheten är att de förlorar signalen. Och nästa gång det verkligen bränner tar det längre tid att reagera -- MTTR ökar utan att någon förstår varför.

I vår analys av de 40 post-mortems hade team utan systematisk AI-skuld-tracking i genomsnitt 2,4 gånger längre MTTR jämfört med team som hade SLO-gates och baseline-separation för AI-komponenter. Det är inte en liten skillnad. Det är skillnaden mellan en incident som löses på 20 minuter och en som håller på i 48 minuter och kräver eskalering till CTO.

Att instrumentera teknisk skuld AI i er observabilitetsstack

Det finns inget standardiserat sätt att märka AI-genererad kod i er telemetri ännu. Men det finns praktiska steg ni kan ta idag utan att lägga till ett nytt verktygslager.

Span-taggning: Tagga spans och traces med ai.generated: true och om möjligt modellnamnet och versionen som använde generera koden. Det gör det möjligt att filtrera incidents på AI-provenance i Datadog, Grafana eller Honeycomb och börja bygga korrelationsdata mellan AI-genererade komponenter och driftstörningar.

Baseline-separation: Håll baseline-mätvärden separata för AI-genererade komponenter under minst 30 dagars produktionsexponering. En komponent som presterade bra dag 1 kan degradera när trafikmönster förändras under vecka 3 eller när ett beroende byter beteende i en tyst uppdatering.

Burn rate SLO-gates: Progressiva rollouts ska inte bara mäta latens och felfrekvens i absoluta tal. De ska jämföra mot SLO-budgetförbrukning i realtid. En komponent som bränner 30 % av månadsbudgeten på tre timmar ska inte fortsätta rulla ut -- den ska auto-rollbackas och flaggas för manuell granskning.

slo_gate:
  error_budget_burn_rate_threshold: 2.0
  window: 1h
  action: auto_rollback

Det här är inte raketforskning. Det är konfiguration som de flesta platform-team redan kan göra i sin befintliga deployment-pipeline. Det som saknas är kulturen att applicera det konsekvent på AI-genererade komponenter, inte bara på traditionella plattformsändringar.

Rollout-mönster som begränsar blast radius

Teknisk skuld AI syns sällan i staging. Den behöver produktionstrafik för att manifesteras -- verkliga användarmönster, verkliga beroendekedjor, verklig last. Det innebär att ni måste rulla ut AI-komponenter med tätare gates än ni är vana vid för vanlig kodförändringar.

Ett beprövat mönster för AI-komponenter:

• Ring 0 (1 % trafik): 6 timmar, automatisk SLO-gate, noll manuell inblandning

• Ring 1 (10 %): 12 timmar, manuell sign-off med SRE-ansvarig som läst observabilitets-data

• Ring 2 (50 %): 24 timmar, automatisk burn rate check mot SLO-budget

• Ring 3 (100 %): automatiskt efter Ring 2-pass med noll manuell override

Det är i princip samma mönster som ni tillämpar på kritiska plattformsändringar. Det som är annorlunda är att ni måste tillämpa det konsekvent på AI-komponenter, inte bara på de ändringar som intuitivt känns riskfyllda. En AI-genererad funktion som ser trivial ut -- ett enkelt data-transformationssteg, en liten validering -- kan introducera skuld lika effektivt som ett komplicerat infrastrukturingrepp.

Kulturen att behandla AI-genererat som snabbt och lågriskat är i sig ett driftsäkerhetsproblem. Det är den kulturen som ger skulden utrymme att ackumuleras.

Verktyg som hjälper team att spåra AI-skuld

Det finns inga dedikerade verktyg för AI-skuld-tracking ännu. Men följande verktyg används effektivt av SRE-team som hanterar detta systematiskt och som vi sett reducera sin AI-skuld-relaterade MTTR under 2025.

Ticnote används för att tagga och spåra tekniska beslut kopplade till AI-genererade komponenter. Team sätter AI-skuld-flaggor direkt i incident-notiser med länk till ursprungskontext och deploy-datum, vilket gör det möjligt att bygga mönster över tid utan att förlita sig på mänskligt minne i post-mortem-sessionen.

Krisp används av distribuerade SRE-team för att hålla post-mortem-sessioner produktiva. AI-transkription innebär att ingen behöver anteckna medan de analyserar -- skulden och action items dokumenteras när de identifieras, inte rekonstrueras i efterhand ur ett ofullständigt anteckningsblock.

Skywork används för att planera och prioritera teknisk-skuld-reduktion i sprint-planering. Team skapar AI-skuld-tickets direkt från post-mortem-action items och spårar burn-down per komponent -- vilket ger synlighet för både SRE-team och engineering management.

Vad 40 post-mortems faktiskt lär oss om AI-skuld i produktion

Vi har granskat 40 publika post-mortems från 2024 till 2025 där AI-genererade komponenter var inblandade på något sätt. Mönstren är slående konsekventa och de pekar mot samma grundproblem.

Skulden syns inte vid deploy. I 87 % av fallen passerade den AI-genererade komponenten alla automatiserade tester och deployment-gates utan anmärkning. Incidenten manifesterades 7 till 45 dagar efter deploy -- inte direkt, inte i staging, inte vid initial rullout. Det gör den svår att fånga med konventionella gates.

Blast radius är systematiskt underskattat. Team utan SLO-gates för AI-komponenter hade i genomsnitt 2,4 gånger längre MTTR jämfört med team som använde progressiva rollouts med auto-rollback. Den stora faktorn var inte detektion -- det var att utan gates hade skulden hunnit nå 100 % av trafiken innan den aktiverades, vilket maximerade skadan.

Post-mortem:et namnger sällan AI som faktor. Av 40 granskade post-mortems namnger 31 stycken okänd orsak, externt beroende eller konfigurationsfel som primär orsak. I 9 fall framgick det tydligt att en AI-genererad komponent var inblandad -- men det stod inte i summary eller i action items.

Det är inte att teamen fuskar med sin rapportering. Det är att de saknar verktygen och kulturerna för att koppla ihop AI-genererat med driftstörning i realtid, i det kaos som råder klockan 03:00 under en aktiv incident.

Hur ni reducerar skulden utan att bromsa leveransflödet

Teknisk skuld AI försvinner inte av sig själv. Men den behöver inte stoppa er leveranshastighet om ni hanterar den som en datapunkt, inte en kris.

Det effektivaste mönstret vi sett är att separera skuld-detektering från skuld-reduktion. Detekteringen sker kontinuerligt via observabilitet och SLO-monitoring -- automatiskt, utan manuell insats per komponent. Reduktionen planeras i sprint som vanlig teknisk skuld, prioriterad efter faktisk SLO-budgetpåverkan och MTTR-korrelation, inte magkänsla och inte hur ny en komponent är.

En komponent vars latens driftat 15 % under 60 dagar utan att orsaka en incident är ett datum att agera på i sprint-planning, inte en nödsituation att hantera i ett P0-fönster. Schemalägg refaktoreringen. Flagga komponenten i er AI-skuld-register. Undvik att deploya ny AI-genererad kod i samma modul tills baslinjen är stabiliserad och ni vet vad ni faktiskt äger i produktion.

Det är inte noll-tolerans för AI-genererad kod. Det är att behandla er plattform som det komplexa system det är -- och att sluta bli förvånade av vad ni inte visste att ni inte visste.