# Technische Schuld AI Vernietigt Platformbetrouwbaarheid URL: https://upstreamapi.com/nl/journal/technische-schuld-ai-platform-betrouwbaarheid Type: blog Locale: nl Published: 2026-08-01 Updated: 2026-08-27 --- > AI-gegenereerde code stapelt onzichtbare schuld op in je productiesysteem. Welke patronen platformen breken en hoe SRE-teams de schade beheersen voordat de post-mortem het vertelt. ## 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. ![Heatmap van onbewaakte AI-codewijzigingen in een deployment-pipeline](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-08/cdcfce-inline1.webp) ## 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. ![Verloop van SLO-budget bij teams met hoge AI-schuldgraad versus teams met gecontroleerde AI-uitrol](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-08/0fdb9a-inline2.webp) ## 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. ![Dashboard voor AI-workflow-eigenaarschap en rollback-status in een platform-engineering-omgeving](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-08/a204cd-inline3.webp) ## 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. ## FAQ ### Wat is technische schuld AI precies? Technische schuld AI is de ophoping van AI-gegenereerde of AI-beinvloede code en automatiseringen die in productie draaien zonder volledige documentatie, eigenaarschap of rollback-strategie. Het verschil met gewone technische schuld is dat AI-schuld onzichtbaar blijft totdat ze faalt op een manier die geen enkel runbook dekt. ### Hoe snel stapelt AI-technische schuld zich op? Snel. In teams die AI-assistenten breed inzetten, zien we binnen zes maanden al een merkbare stijging van MTTR en change failure rate. Een team van 80 engineers dat we volgden, zag MTTR stijgen van 23 naar 47 minuten in een kwartaal. De oorzaak: 60% van de incidenten had een AI-component, maar slechts 12% van die componenten had een gedocumenteerde eigenaar. ### Welke DORA-metrics worden het meest beinvloed door AI-schuld? Change failure rate en MTTR zijn de meest directe indicatoren. Deployment frequency daalt als gevolg, omdat teams voorzichtiger worden na meerdere AI-gerelateerde incidenten zonder duidelijke oorzaak. Lead time for changes stijgt doordat reviewprocessen complexer worden naarmate de AI-component minder begrijpelijk is. ### Hoe weet ik welke code in mijn systeem AI-gegenereerd is? In de meeste codebases weet je dat niet zonder een expliciete taggingstrategie. De praktische aanpak is een audit op ownership: elk component dat geen eigenaar heeft in de on-call rotatie is een kandidaat voor nader onderzoek. Combineer dat met een test coverage delta-analyse om de AI-gegenereerde onderdelen te identificeren. ### Moet ik stoppen met AI-assistenten voor code? Nee. De oplossing is niet minder AI maar meer discipline rond AI-output. Behandel AI-gegenereerde code zoals je elk stuk production-code behandelt: review, eigenaar, test, rollback-strategie. De sleutel is dat de AI-output expliciet geconfigureerd en gedocumenteerd is, niet impliciet geautomatiseerd. ### Wat is een realistisch SLO-budget voor teams met AI-componenten? Er is geen universeel antwoord, maar teams met hoge AI-schuldgraad moeten rekening houden met een conservatiever budget dan normaal totdat de ownership coverage boven de 80% zit. Een SLO-gated rollout met auto-rollback op SLO-breach geeft je de vroegste detectie van AI-component falen, bij minimale blast radius. ### Hoe pak ik bestaande AI-schuld aan zonder de organisatie te lamleggen? Start met een ownership audit: identificeer alle AI-gegenereerde of AI-beinvloede componenten in productie en wijs een eigenaar aan. Schrijf ADRs achteraf voor de belangrijkste componenten. Voer daarna een test coverage delta-analyse uit en prioriteer de componenten met de laagste coverage en hoogste CFR. Doe dit kwartaallijks, niet als eenmalige operatie.