De gevaarlijkste bug die ik ken kleurt je testrapport niet rood. Hij kleurt het groen.

Iedereen kent de bug die zich meldt: een test faalt, een pagina geeft een foutmelding, een build breekt af. Vervelend, maar eerlijk. Je ziet hem, je fixt hem. De bug waar ik hier over schrijf is het tegenovergestelde. Alles staat op groen. De tests slagen, de code compileert, de server geeft netjes een 200 terug. En toch is het fout. Ik noem het “slaagt maar fout”, en het is de valkuil waar Ai-software je met open ogen in laat lopen. Juist omdat het er geslaagd uitziet, glipt het langs je heen.

Laat me vertellen hoe ik er bijna zelf intrapte, en waarom uitgerekend een Ai-agent me tegenhield.

De schakelaar die alles stil kon breken#

In een van mijn projecten bouw ik een SaaS voor meerdere klanten tegelijk: een meertenant-applicatie. Dat betekent dat de gegevens van klant A en klant B in dezelfde database staan, en dat een onzichtbare laag ervoor zorgt dat klant A nooit iets van klant B te zien krijgt. Facturen, klantgegevens, documenten: strikt gescheiden. Voor zo’n product is die scheiding niet een feature, het is het hele fundament. Lekt het één keer, dan is het vertrouwen weg en waarschijnlijk het bedrijf erbij.

Tijdens de bouw stond die scheiding in een tussenstand. De onderdelen waren er wel (elk record wist bij welke klant het hoorde), maar de harde afdwinging stond nog uit. In technische termen: er was één instelling die zei “voorlopig mag alles nog alles zien”. Die instelling omzetten naar “vanaf nu ziet elke klant alléén zijn eigen data” was, letterlijk, één schakelaar. Verleidelijk om gewoon om te zetten en klaar te zijn.

De testsuite was groen. Ruim driehonderd tests, nul fouten. Elk normaal instinct zegt dan: dit is af, druk maar door.

En precies dat instinct was de val.

Waarom groen hier niets bewees#

Het probleem zat in wat die tests niet controleerden, en wat er zou gebeuren op het moment van de flip zelf.

Twee dingen zouden misgaan zodra ik die schakelaar had omgezet zonder de rest op orde te hebben.

Ten eerste: bestaande gegevens waren nog niet allemaal aan een klant gekoppeld. Er stonden records in de database zonder eigenaar. Zodra de scheiding hard werd afgedwongen, zouden die records simpelweg verdwijnen uit beeld. Niet met een foutmelding, gewoon weg. De app zou keurig een lege lijst tonen. Geen crash, geen rode test. Een schone, geslaagde, lege pagina waar eigenlijk tien facturen hadden moeten staan.

Ten tweede: de code die de gegevens ophaalt, was nog niet overal verteld voor wélke klant hij aan het werk was. Op tientallen plekken in de applicatie (ik telde er zo’n tweeëndertig, met bij elkaar rond de negentig leesacties) moest expliciet meegegeven worden: haal de data op voor déze klant. Deed je de flip vóór al die plekken op orde waren, dan kreeg de ingelogde gebruiker overal lege schermen. En de tests? Die draaiden in een opzet waar dat detail niet uitkwam. Groen bleef groen.

Dat is de essentie van “slaagt maar fout”: de testomgeving en de echte, draaiende applicatie zijn niet hetzelfde. Een halve verbouwing kan in de tests perfect ogen en tegelijk de live-app stil uithollen. Lege lijsten die eruitzien als “er is niks”, terwijl het in werkelijkheid “ik mag het niet meer vinden” is. Voor een boekhoudproduct is er weinig engers dan een klant die zijn facturen ziet verdampen zonder één foutmelding.

De agent die “nee” zei tegen de grote knal#

Hier komt het deel dat me het meest is bijgebleven. Ik laat een deel van dit soort werk voorbereiden door Ai-agents, binnen strakke kaders. De opdracht was: breng deze klantscheiding een stap verder. De voor de hand liggende, luie uitvoering zou zijn: zet de schakelaar om, draai de tests, zie groen, klaar.

De agent weigerde die route. Niet uit koppigheid, maar omdat de kaders hem dwongen te redeneren over omkeerbaarheid en over wat er in de echte applicatie zou gebeuren, niet alleen in de tests. Zijn conclusie, die ik in mijn eigen woorden teruglees in de projectnotities: een big-bang-flip is te groot en te risicovol voor één autonome stap. Een halve flip houdt de suite groen maar breekt de draaiende app stil. En piecemeal, stukje bij beetje de scheiding aanzetten, zou onderweg de gegevens zonder eigenaar laten verdwijnen.

Dus in plaats van de grote knal bouwde de agent een lange trap van kleine, omkeerbare stappen. Een stuk of vijftien voorbereidingen, elk op zichzelf veilig en terug te draaien, elk met eigen tests. Onder andere: zorg dat élke plek die nieuwe gegevens aanmaakt voortaan de klant erbij zet. Maak de bestaande gegevens zonder eigenaar alsnog koppelbaar met een backfill-hulpmiddel. Zorg dat de voorbeelddata en de testopzet vanaf de bron al klantbewust zijn. Maak de uniciteitsregels per klant in plaats van globaal. En pas dáárna, plek voor plek, de leesacties aan zodat ze weten voor wie ze werken.

En toen het aankwam op de flip zelf, de daadwerkelijke onomkeerbare schakelaar, deed de agent iets wat ik het liefst in élke automatisering zie: hij legde hem niet zelf om. Hij escaleerde. Dit hoort bij een mens, in één gecoördineerde, bewaakte actie, met een handmatige controle van de echte applicatie erna. Niet als losse nachtelijke run tussen de bedrijven door.

Dat is precies de scheiding die ik overal aanhoud: een Ai-agent is uitstekend in veilige, kleine, omkeerbare stappen. Zodra iets onomkeerbaar of gecoördineerd is, is de juiste actie niet “doen” maar “escaleren”.

Wat betekent dit voor jouw bedrijf?#

Je hoeft geen meertenant-SaaS te bouwen om hier last van te krijgen. Zodra je Ai code laat schrijven, data laat migreren of processen laat aanpassen, loop je tegen “slaagt maar fout” aan. De Ai is er verbluffend goed in om iets op te leveren dat er af uitziet. Of het ook klopt, is een andere vraag.

Vier dingen die bij mij het verschil maken:

  1. “Tests groen” is geen bewijs dat het werkt. Het is bewijs dat de dingen die je getest hebt nog werken zoals je ze getest hebt. Bouw altijd een controle die de échte flow nabootst: log in als een echte gebruiker, klik door het echte scherm, kijk of er staat wat er hoort te staan.

  2. Wees extra bang voor lege resultaten. Een crash zie je. Een lege lijst, een verdwenen record, een pagina die “netjes niks” toont: dat is de gevaarlijke variant. Vraag bij elke wijziging expliciet: kán dit ergens data stil laten verdwijnen?

  3. Knip onomkeerbaar werk op in omkeerbare stappen. Bijna elke grote, enge verandering is op te delen in een reeks kleine die je stuk voor stuk terug kunt draaien. De grote knal bewaar je voor één bewust moment, met een mens erbij.

  4. Laat Ai voorbereiden, laat een mens het onomkeerbare moment nemen. De voorbereiding mag autonoom. De schakelaar die je niet terug kunt draaien, hoort bij iemand die de gevolgen overziet.

De rode draad: de duurste fouten van Ai-software zien er niet uit als fouten. Ze zien er uit als succes. Je verdediging is niet meer testen van hetzelfde soort, maar een tweede paar ogen dat naar de echte uitkomst kijkt.

Zelf aan de slag#

Waar mag Ai in jouw bedrijf zelfstandig handelen, en waar hoort een mens de knop te bedienen? Dat is precies de vraag die ik heb uitgewerkt in het Ai-stoplicht: een gratis hulpmiddel waarmee je per proces bepaalt wat je een Ai-agent wél en niet uit handen geeft. Je vindt het bij de downloads op deze site.

Wil je sparren over waar in jouw processen de “slaagt maar fout”-risico’s zitten en hoe je ze afvangt? Kijk dan op de consulting-pagina hoe ik werk.