Mag ik een AI-suggestie ooit toepassen zonder hem te controleren?

Bij een read-only query of een wegwerp-staging site is de kost van een fout laag. Op een live database of een productieconfiguratie: doorloop de vier stappen. De check kost minuten; een storing kost dat niet.

Welke van de vier stappen is het snelst?

De aanpassing in gewone taal verwoorden. Daar heb je geen terminal voor nodig en het vangt het meest. Kun je niet zeggen wat de wijziging doet, dan heb je het probleem gevonden voor je iets gedraaid hebt.

Hoe reproduceer ik een bug die AI zegt op te lossen?

Bij SQL: draai eerst EXPLAIN op de trage query. Bij PHP of .htaccess: lok het kapotte gedrag uit en leg de fout vast. Kun je het niet reproduceren, dan lost de aanpassing misschien een probleem op dat je niet hebt.

AI-suggesties: controleer in vier stappen voor je ze toepast

Het chatvenster geeft een diff terug. Je vroeg waarom het productarchief van de webshop er vier seconden over doet om te renderen, en het antwoord is één regel SQL die je niet zelf schreef en maar half herkent. Het ziet er aannemelijk uit. Het raakt ook een tabel met 480.000 rijen op een live verouderde site. Een AI-suggestie toepassen die je niet helemaal begrijpt, is hoe een dinsdagmiddag een dinsdagavond wordt.

De reflex is om hem op goed vertrouwen toe te passen of hem uit principe te weigeren. Allebei fout. Een AI-suggestie is een hypothese, en hypotheses worden getest voor ze de deur uit gaan. Dit is de check in vier stappen die we doorlopen voor we iets toepassen dat we niet uit ons hoofd kunnen uitleggen.

Verwoord de aanpassing in je eigen woorden

Voor er iets draait, schrijf je de aanpassing terug in gewone taal. Lukt dat niet, dan begrijp je hem nog niet, en dat is precies het signaal. Stel dat de suggestie dit is:

ALTER TABLE wp_postmeta
  ADD INDEX meta_key_value (meta_key(191), meta_value(100));

In gewone taal: "voeg een samengestelde index toe zodat lookups die op meta_key en meta_value samen filteren niet langer de hele tabel scannen." Nu komen de stukken die je had overgeslagen vanzelf bovendrijven. Waarom 191? Waarom 100? De 191 is het plafond voor de prefixlengte van utf8mb4 onder de oudere indexlimiet van 767 byte. De 100 is een willekeurige prefix op een longtext-kolom die niet volledig geïndexeerd kan worden. Dat zijn geen weetjes. Ze veranderen wat de index daadwerkelijk kan doen.

Een AI-suggestie verpakt als een zelfverzekerde one-liner verbergt zijn aannames. Door hem te verwoorden maak je ze zichtbaar.

Reproduceer de bug voor je de fix vertrouwt

Een aanpassing lost iets op. Bevestig dat dat iets echt bestaat, en dat het is wat je denkt dat het is. Bij een trage query betekent dat: EXPLAIN draaien voor je iets aanraakt:

EXPLAIN SELECT post_id FROM wp_postmeta
WHERE meta_key = '_wc_average_rating' AND meta_value > '4';

De output die telt:

type: ALL
possible_keys: meta_key
rows: 481204
Extra: Using where

type: ALL en 481.204 gescande rijen bevestigen de full-table scan. De AI-suggestie heeft nu een probleem dat ze aantoonbaar oplost. En passant het vermelden waard: meta_value is tekst, dus > '4' is een stringvergelijking, geen numerieke. Dat is een tweede bug die de index niet oplost, en je ziet hem alleen omdat je de query goed genoeg gelezen hebt om hem te reproduceren.

Had de EXPLAIN type: ref en een paar honderd rijen getoond, dan zou de aanpassing een probleem oplossen dat je niet hebt, en had je dat hier opgemerkt voor de prijs van één read-only query. Reproduceren is goedkoop. Spijt niet.

Breng in kaart wat de wijziging nog meer raakt

Een wijziging heeft een impactstraal. Breng die in kaart voor je toepast, niet erna. Begin met wat er al is:

SHOW INDEX FROM wp_postmeta;

WordPress levert wp_postmeta al met indexen op post_id en meta_key, zoals de database-beschrijving uitlegt. Een nieuwe samengestelde index is niet gratis: elke INSERT en UPDATE op de tabel onderhoudt nu een extra B-tree, en op een schrijfintensieve shop is die kost reëel en permanent. Je ruilt schrijfsnelheid in voor leessnelheid. Die ruil kan hier juist zijn. Het punt is dat je hem bewust maakt.

Dezelfde stap geldt buiten de database. Is de AI-suggestie een rewrite-regel in .htaccess, vraag dan welke andere regels erboven staan en of de volgorde verandert. Is het een regel in wp-config.php, vraag dan welke plugins die constante uitlezen. De discipline is identiek: benoem alles dat stroomafwaarts van de wijziging zit voor ze landt.

Op MySQL 5.6 en ouder, of op elke tabel die nog MyISAM gebruikt, kopieert ALTER TABLE ... ADD INDEX de hele tabel en blokkeert het schrijfacties zolang dat duurt. Op een wp_postmeta van 480k rijen kan dat betekenen dat de winkelpagina een minuut of langer fouten gooit. Check eerst de engine en de versie. De online DDL van MySQL maakt deze operatie veilig, en die is niet overal beschikbaar.

Pas toe met een uitweg die al klaarligt

De eerste drie stappen gaan over de aanpassing begrijpen. De vierde gaat over overleven als hij tóch fout blijkt. Voor je de wijziging draait, zorg dat je hem zonder nadenken ongedaan kunt maken. Bij een schemawijziging betekent dat: een snapshot van de tabeldefinitie en een uitgeschreven DROP INDEX-rollbackregel, bewaard naast de ALTER. Bij een bestandswijziging betekent dat: een kopie van het origineel, vastgelegd op een plek die je vertrouwt, geen .bak waarvan je vergeet dat hij bestaat.

Een uitweg die je onder druk moet improviseren, is geen uitweg. Het moment om de rollback te schrijven is terwijl je rustig bent, voor de aanpassing in de buurt van productie komt.

Bij het bouwen van Pier liepen we precies hiertegen aan. Hoe we het uiteindelijk hebben aangepakt: elke wijziging, of die nu van AI komt of met de hand getypt is, landt als een item in de versiegeschiedenis, zodat de revert één klik is en de diff leesbaar blijft. De MySQL-editor toont het EXPLAIN-plan en de bestaande indexen in hetzelfde paneel als de suggestie, wat grotendeels stap twee en drie is met minder tabbladgewissel.

De volgende keer dat de chat je een regel aanreikt die je niet kunt lezen, doe dan alleen stap één: verwoord de aanpassing in gewone taal voor je iets anders doet. Komt de zin niet, dan heb je je antwoord gratis gevonden.