Van A(I) naar Beter

Het probleem verdwijnt, de oorzaak blijft

Stel je een enthousiaste junior systeembeheerder voor, slim, snel en eindeloos behulpzaam. Je vraagt: “Kun je dit database-cluster optimaliseren?” Hij komt binnen vijf minuten terug: “Gefikst. De traagste database van het cluster is weg.”

Je kijkt. Hij heeft de database gedropt.

Klacht opgelost, toch? De database is niet meer traag. Hij is er niet meer.

Klinkt als een mop, maar vervang die junior door een AI-tool en dit is een scenario dat we in de praktijk daadwerkelijk tegenkomen. AI lost op wat je vraagt, maar begrijpt niet waarom je het vraagt. Dat verschil merk je pas als het kwaad al is geschied.

Waar AI wél helpt

Ik ben niet tegen AI. We gebruiken het zelf ook. Voor documentatie en uitleg is het fantastisch: een onbekende stored procedure laten uitleggen, commentaar toevoegen aan legacy-code, een migratiepad beschrijven. Dat bespaart echt tijd. Hetzelfde geldt voor het opsporen van basale syntaxfouten, zoals een vergeten join-conditie, een typefout of een ontbrekende index op een voor de hand liggende kolom. AI pikt dat soort dingen er prima uit.

Voor standaard onderhoudsscripts en repetitieve queries is het ook handig, net als voor het doorzoeken van grote hoeveelheden logoutput. Patroonherkenning in metrics en logs is precies waar machine learning sterk in is.

Hier zit wel een voorwaarde aan die veel mensen overslaan. AI maakt een ervaren DBA efficiënter. Het woord “ervaren” maakt hier het verschil. Je hebt iemand nodig die weet wat de output zou moeten zijn, kan beoordelen of wat AI oplevert ook klopt. Iemand die dat niet weet, merkt pas dat het fout zit als de schade al is aangericht.

Wanneer optimalisatie schade aanricht

Over AI en query-optimalisatie wil ik wat genuanceerder zijn dan de hoera-verhalen die je overal leest. “AI kan queries optimaliseren” is een halve waarheid die in de praktijk gevaarlijk uitpakt.

AI optimaliseert lokaal en syntactisch. Het kijkt naar de query die voor zijn neus ligt en maakt die schijnbaar netter. Wat het niet doet, is nadenken over de structuur eronder.

Een voorbeeld dat onze database-engineers regelmatig zien: AI-gegenereerde tabeldefinities die voor zo goed als elke kolom nvarchar(max) gebruiken. Werkt het? Technisch wel. Is het een goed idee? Absoluut niet. Je verliest indexeerbaarheid, je verspilt opslag en geheugen, je krijgt onvoorspelbare query-plannen en je bouwt een performanceprobleem in dat zich pas maanden later openbaart, als de tabel groot genoeg is om pijn te doen.

De AI heeft geen idee dat dit een probleem is. Het heeft een patroon gereproduceerd dat in zijn trainingsdata vaak “werkte”. Werken en goed zijn, dat zijn twee verschillende dingen. Een datatype kiezen is geen syntaxbeslissing; het is een afweging over groei, toegangspatronen en hoe deze tabel zich over jaren gaat gedragen. Die afweging zit in ervaring, niet in een taalmodel.

Gedocumenteerd, niet verzonnen

Sommige AI-tools en automated optimizers beloven dat ze performance optimaliseren en index- of schemawijzigingen aanbevelen én automatisch toepassen. Klinkt mooi. Tot je beseft dat diezelfde categorie tools het nvarchar(max)-antipatroon produceert dat ik net beschreef.

Dat is geen mening van mij. Het is gedocumenteerd. Microsofts eigen documentatie waarschuwt dat tools die de juiste kolomlengte niet kennen standaard naar nvarchar(max) grijpen, de “veilige” route, waarna SQL Server gedwongen wordt tot overmatig geheugengebruik, het overslaan van indexen en hogere CPU-kosten. Zelfs voor doodgewone velden als een voornaam. In de SQL Server-community is het een bekend gegeven dat MAX-datatypes een performancehit van een factor 2 tot 10 kunnen veroorzaken zodra je er een join op uitvoert.

De tool die belooft je performance te optimaliseren, bouwt ondertussen het klassieke performanceprobleem in dat database-professionals al sinds SQL Server 2005 proberen te vermijden. Dat is geen speculatie over een onzekere AI-toekomst. Het is een meetbaar, reproduceerbaar feit dat we in productieomgevingen tegenkomen.

Waarom AI faalt bij troubleshooting

Bij troubleshooting onder druk is AI fundamenteel het verkeerde gereedschap.

Troubleshooting draait om het onderscheid tussen symptoom en oorzaak. Een AI die de opdracht krijgt een probleem op te lossen, neigt ernaar het symptoom te laten verdwijnen. Trage database? Drop de database. Foutmelding op een constraint? Verwijder de constraint. Replicatie loopt achter? Zet replicatie uit. Het probleem is weg, in de zin dat de foutmelding weg is. De onderliggende oorzaak (en vaak de data zelf) ook.

Dat is geen randgeval. Het is de standaardneiging van een systeem dat is gebouwd om de melding te laten verdwijnen, niet om de oorzaak te begrijpen en de schade te beperken.

Daarnaast mist AI iets wat elke doorgewinterde DBA als reflex heeft: voorzorgsmaatregelen. Iemand die een probleem in productie ziet, denkt niet alleen “hoe los ik dit op” maar vooral “hoe zorg ik dat ik niets onherstelbaar beschadig terwijl ik het oplos”. Eerst een back-up draaien, dan op een staging-omgeving testen, de impact inschatten, een rollback-plan klaarleggen. Die afweging tussen oplossen en beschermen heeft een AI niet. Het heeft geen besef van onomkeerbaarheid, geen gevoel voor wat er op het spel staat.

Een mens vraagt zich af: “wat als ik het mis heb?” Een AI voert uit.

Brede consensus in de branche

Branche-experts erkennen breed dat AI de DBA niet vervangt maar het werk verschuift. De veelgehoorde conclusie is dat AI context niet kan onderscheiden of informatie niet kan valideren zoals iemand die de techniek kent dat doet, en dat je voor performance-suggesties iemand nodig hebt die de uiteindelijke beslissing neemt. Zelfs leveranciers van AI-DBA-oplossingen geven toe dat hun systemen niet volledig autonoom zijn en menselijk toezicht vereisen bij schema-migraties en architectuurwijzigingen.

Het verschil is dit: de meeste van die verhalen blijven hangen bij “AI mist context” als abstracte waarschuwing. Ik laat liever zien hóé dat eruitziet. Een nvarchar(max) over de hele linie. Een trage database die “opgelost” wordt door hem te droppen. Een constraint die verdwijnt in plaats van de fout die hem triggerde. Dat zijn geen filosofische bezwaren tegen AI. Het zijn de concrete dingen die we opruimen bij klanten die te veel vertrouwen op een tool zonder iemand die meekijkt.

De DBA-rol verschuift naar oordeel

De verschuiving die ik zie is niet “AI vervangt de DBA”. Het is subtieler en ook ongemakkelijker.

AI verlaagt de drempel om iets te doen met een database. Een developer zonder database-achtergrond kan met AI verbluffend snel een schema neerzetten, een query schrijven, een probleem “oplossen”. Dat voelt als vooruitgang. Soms is het dat ook.

Het risico verschuift naar achteren. De fouten zie je niet op het moment dat je ze maakt. Ze openbaren zich maanden later, als de data is gegroeid, als de architectuurkeuze niet meer terug te draaien is, of als er in een crisis een onomkeerbare “oplossing” is doorgevoerd.

Zonder goede DBA zie je fouten pas later, en zie ze dan nog maar eens te herstellen.

De rol van de database-expert verschuift dus niet weg van het vak. Hij verschuift naar de plek waar het oordeel zit: datatype-keuzes met het oog op groei, architectuur die over vijf jaar nog houdbaar is, en het verschil weten tussen een probleem oplossen en een probleem laten verdwijnen.

Een instrument, geen vervanging

Een ijverige junior systeembeheerder is waardevol, mits er iemand meekijkt die weet wanneer “gefikst” in werkelijkheid “kapot” betekent. Zo kijken wij ook naar AI in ons eigen werk: een instrument dat onze mensen sneller maakt. Nooit een vervanging voor het oordeel dat het vak juist tot een vak maakt.

Benieuwd hoe dat er in de praktijk uitziet? We praten er graag over.