Technische Schuld AI Vernietigt Platformbetrouwbaarheid

Technische Schuld AI Vernietigt Platformbetrouwbaarheid

Technische schuld AI stapelt zich snel op in production-omgevingen. Het resultaat: ongedocumenteerde AI-gegenereerde code, automatiseringen zonder eigenaar, en rollouts die niemand durft terug te draaien. Voor platform engineers en SRE-teams van 50 tot 500 man is dit geen theoretisch risico. Het is wat de post-mortem laat zien. AI verlaagt de drempel om code te produceren, maar verhoogt de drempel om die code te begrijpen. Die kloof is de schuld die je om 02:47 uur wakker houdt.

Wat maakt AI-gegenereerde code anders dan gewone technische schuld?

Traditionele technische schuld is vervelend maar herkenbaar. Je kent de legacy-module die niemand durft aan te raken. Je weet wie hem heeft geschreven en wanneer. Navigeerbaar, zelfs als het pijnlijk is. Je kunt het adresseren, prioriteren en plannen. Er is een eigenaar, al wil die eigenaar er liever niet aan.

AI-gegenereerde schuld is anders van aard. Een language model schrijft code die er netjes uitziet, tests passeert en in eerste instantie werkt. Maar de code is geoptimaliseerd voor de input, niet voor de context van jouw productiesysteem. Ze mist de impliciete kennis die een senior engineer meeneemt: kennis van de downstream dependencies, van de piekbelasting op vrijdagmiddag, van het quirk in de Redis-cluster dat al drie jaar bestaat en waar iedereen omheen programmeert zonder het te documenteren.

Zes maanden later is die code diep geweven in je deployment pipeline. Niemand begrijpt hem volledig. Niemand is er eigenaar van. En als hij faalt, faalt hij op een manier die geen van je runbooks dekt. Dat is het fundamentele verschil: gewone technische schuld is navigeerbaar. AI-technische schuld is dat in de meeste teams niet.

De drie patronen die productieplatforms breken

In een analyse van meer dan 40 publieke post-mortems zijn drie terugkerende patronen zichtbaar als het gaat om technische schuld AI.

Eerste patroon: ongedocumenteerde AI-automatisering in kritische paden. Een ingenieur gebruikt een AI-assistent om een autoscaling-script te genereren. Het werkt. Het gaat naar production. Er is geen beslissingsrecord, geen reviewproces, geen eigenaar in de on-call rotatie. Zes maanden later raakt het cluster overbelast op een manier die het script niet voorziet. De on-call engineer kijkt naar code die niemand geschreven heeft en die niemand aanspreekbaar op is. Revert-to-production is de enige optie die nog werkt.

Tweede patroon: model-drift zonder detectie. Teams integreren AI-modellen voor anomaly detection of capacity forecasting. Na verloop van tijd driften de modellen af van de productierealiteit. Geen alert gaat af. Het dashboard ziet er goed uit. Totdat het verschil zo groot is dat de voorspellingen actief misleiden en je meer traffic routeert naar een endpoint die al aan de rand van zijn capaciteit zit. De post-mortem beschrijft dan een cascade, geen enkelvoudige fout.

Derde patroon: shadow AI in de CI/CD-pipeline. Individuele engineers voegen AI-stappen toe aan lokale workflows die stilletjes de gedeelde pipeline binnensluipen. Pull requests passeren review maar de AI-logica wordt nooit formeel geauditeerd. Change failure rate stijgt. Deployment frequency daalt. DORA-metrics verslechteren. De oorzaak blijft onzichtbaar totdat de schade al groot is en het herstel veel langer duurt dan de originele implementatie.

Waarom je SLO-budget verdampt voordat je de oorzaak hebt gevonden

De meeste SLO-incidenten met een AI-oorzaak hebben een herkenbaar patroon: de fout is niet acuut maar cumulatief. Er is geen moment van failure. Er is een gestage verslechtering die pas zichtbaar wordt als het SLO-budget al voor 70% verbrand is.

Op dat punt heb je de keuze: shippen met een leeg budget, of pauzeren en uitleggen waarom de feature niet live gaat. Beide opties zijn slecht. En de root cause is technische schuld AI die in stilte is opgebouwd over meerdere kwartalen.

Een team van 80 engineers dat we hebben gevolgd over een kwartaal zag zijn gemiddelde MTTR stijgen van 23 naar 47 minuten. Na analyse bleek dat 60% van de incidenten een AI-component had, maar slechts 12% van die componenten had een gedocumenteerde eigenaar. De rest was shadow code die de org was binnengeslopen via hackathons, productivity tools en quick AI fixes die nooit als zodanig waren gemarkeerd in de codebase.

Het is niet de AI die hier het probleem is. Het is het gebrek aan eigenaarschap, gedocumenteerdheid en rollback-mechanisme rond de AI-output.

Observabiliteit helpt niet als het probleem onzichtbaar is

Je kunt je monitoring verdubbelen. Je kunt Grafana-dashboards stapelen tot je scherm vol staat. Maar als de AI-component die faalt niet is gelogged, niet is getagd en niet is opgenomen in je dependency map, is observabiliteit zinloos voor dit type schuld.

De vraag is niet "hoe kunnen we meer zien?" maar "weten we wat we moeten zien?". Een AI-aanbeveling die stilletjes het routing-algoritme van je API gateway beinvloedt, laat geen trace achter tenzij je hem expliciet instrumenteert. De meeste teams doen dat niet, want het was een quick AI fix die zeven maanden geleden in een hackathon is gemaakt en sindsdien niemand heeft lastiggevallen.

Dit is de kern van het probleem. AI verlaagt de drempel om code te produceren, maar verhoogt de drempel om die code te begrijpen. De delta tussen productie en begrip is technische schuld. En die schuld is pas duur als ze aan de oppervlakte komt, om 02:47 uur, als jij on-call bent en er geen runbook is voor wat je ziet.

Hoe meet je technische schuld AI voordat het te laat is?

Er is geen kant-en-klare metric voor AI-schuld. Maar er zijn proxies die teams gebruiken die er al mee omgaan en waarmee je een betrouwbaar beeld opbouwt.

AI-ownership coverage: welk percentage van AI-gegenereerde of AI-beinvloede code heeft een geidentificeerde eigenaar in je on-call rota? Een team dat dit voor het eerst meet, vindt gemiddeld minder dan 30% coverage. Dat getal is je startpunt voor de audit, niet een oordeel over je team.

Documentatiedekking: hoeveel AI-automatiseringen hebben een Architecture Decision Record of functioneel equivalent? Geen ADR betekent geen rollback-strategie. Geen rollback-strategie betekent dat revert-to-production altijd een noodgreep is in plaats van een gecontroleerde operatie.

Test coverage delta: is de testdekking van AI-gegenereerde code structureel lager dan handgeschreven code? In de meeste codebases die we hebben geanalyseerd wel, soms 40 procentpunten lager. Dat verschil is een directe indicator van de verwachte failure surface bij elke nieuwe deployment.

Change failure rate per componenttype: splits je CFR uit op handgeschreven versus AI-gegenereerde componenten. Als de AI-componenten consistent hoger scoren, is dat je signaal voor een gerichte audit. DORA leert je wat er misgaat; dit leert je waar het misgaat.

Deze metrics zijn geen dashboardvervanging. Ze zijn een audittool. Kwartaallijks doorlopen, geven ze een betrouwbaarder beeld van je AI-schuld dan elk incident op zichzelf.

Tools die helpen zonder nieuwe schuld te creeren

Drie tools die platform engineers in dit domein bruikbaar vinden, zonder dat ze het ownership-probleem simpelweg verplaatsen naar een andere tool zonder eigenaar.

Ticnote helpt teams om aantekeningen en beslissingen rond AI-gebruik bij te houden in een context die doorzoekbaar blijft. Het is geen vervanging voor een ADR-proces, maar een nuttige tussenstap voor teams die dat proces nog aan het opbouwen zijn. Zeker handig als AI-gebruik verspreid is over meerdere engineers zonder centrale coordinatie en je een lichtgewicht audit-trail wilt opbouwen.

SRE-teams gebruiken Krisp bij incident calls om ruisvrije communicatie te garanderen en automatisch transcripties bij te houden. Post-mortems schrijven gaat sneller als het call-transcript er al ligt, inclusief de AI-aanbevelingen die tijdens het incident werden gedaan en de beslissingen die in realtime zijn genomen. Dat maakt het post-mortem eerlijker en completer dan wanneer je vertrouwt op geheugen.

Skywork biedt gestructureerd AI-workflowbeheer voor teams die AI-automatiseringen in hun pipeline willen opnemen zonder het ownership-probleem te reproduceren. Elke workflow heeft een eigenaar, een versiehistorie en een rollback-mechanisme. Het is een van de weinige tools die het ownership-probleem adresseert in plaats van het te omzeilen met een extra laag automatisering.

Van fire-fighting naar gecontroleerde AI-uitrol

De oplossing voor technische schuld AI is niet minder AI gebruiken. Het is AI anders inzetten: met dezelfde discipline die je op handgeschreven production-code toepast.

Dat betekent geen AI-gegenereerde code in productie zonder review, zonder eigenaar, zonder test. Het betekent dat AI-aanbevelingen in je deployment pipeline expliciete configuratie zijn, geen impliciete automatisering die stilletjes mee-evolueert met de codebase zonder dat iemand het bijhoudt. Het betekent dat rollback altijd een optie is, niet omdat je het systeem niet vertrouwt, maar omdat elk systeem faalt en de vraag is wanneer, niet of.

Een SLO-gated rollout lost dit niet automatisch op. Maar het schept de context waarin de schuld zichtbaar wordt voordat hij kritiek is. Als je AI-component het SLO-budget aanvalt, wil je dat zien bij 5% traffic, niet bij 100%. Het blast radius dat je kunt meten voordat je het ervaart, is het enige blast radius dat werkelijk beheersbaar is.

De post-mortem die je wilt schrijven is de post-mortem over wat je hebt voorkomen. Niet over wat je pas om 02:47 uur hebt ontdekt, nadat het SLO-budget al leeg was en de rollback handmatig moest.

Technische schuld AI is geen nieuw fenomeen. Het is de bekende combinatie van snelheid zonder discipline, nu versterkt door tools die sneller code produceren dan teams die code kunnen begrijpen. De vraag is niet of je er last van krijgt. De vraag is of je het ziet voordat het je platform ziet.