Vannacht heeft een Ai-agent aan mijn website gewerkt. Terwijl ik sliep, heeft hij de code bekeken, één kleine verbetering gemaakt, gecontroleerd of alles nog compileerde, en een commit klaargezet. Een script heeft die wijziging vervolgens getest, live gezet en hergemeten. Het zou hem automatisch hebben teruggedraaid als er iets mis was.
Vanochtend zag ik in de publieke changelog van de site wat er gebeurd was. Dat is alles. Geen tickets, geen sprint, geen review-meeting.
De site is footballoracle.nl, mijn hobbyproject: een voorspellingsplatform voor het WK 2026. Het voorspelmodel zelf is bewust géén Ai-chatbot maar klassieke statistiek; daarover een andere keer. Waar het vandaag over gaat: rondom die site draait een optimalisatie-agent die ongeveer tien keer per dag mag proberen de site iets beter te maken. Performance, SEO, toegankelijkheid, presentatie.
Dat klinkt als een recept voor chaos. Dat is het niet, maar alleen omdat de kaders strenger zijn dan de agent slim is. En omdat ik onderweg een pijnlijke les heb geleerd over wat je wél en níét mag claimen. Beide verhalen krijg je hieronder.
Hoe het werkt: een slimme agent in een dom harnas#
Het systeem bestaat uit twee delen, en die scheiding is het hele geheim.
Deel één is de Ai-agent. Tien keer per dag wordt hij wakker gemaakt door een simpele cron-taak. Zijn opdracht is bewust smal: maak hoogstens één kleine, omkeerbare verbetering. Eén run, één wijziging, enkele bestanden. Geen grote refactors, geen “nu ik toch bezig ben”. Vindt hij niets dat duidelijk veilig én zinnig is, dan is de juiste uitkomst: niets doen. Dat staat letterlijk in zijn instructies: liever geen actie dan een twijfelachtige wijziging op een live site. Veel runs eindigen dan ook zonder wijziging, en dat is prima. Kwaliteit boven activiteit.
Daarbovenop ligt een verbodslijst. De agent mag aan de presentatielaag komen: HTML, CSS, afbeeldingen, meta-tags, laadgedrag. Hij mag niet aan het voorspelmodel, niet aan de database, niet aan de data-pipeline, niet aan authenticatie, niet aan secrets of infrastructuur. Alles wat de uitkomsten van de site zou kunnen veranderen, is verboden terrein en vereist een mens. En de belangrijkste regel van allemaal: twijfel je of iets veilig is, dan is het niet veilig.
Deel twee is een dom script. En met “dom” bedoel ik: deterministisch, voorspelbaar, geen Ai. De agent commit alleen zijn wijziging; hij deployt nooit zelf. Het script doet daarna het gevaarlijke werk, elke keer op exact dezelfde manier: het bouwt de wijziging eerst op een aparte testomgeving en controleert of de site daar gezond opstart en de sleutelpagina’s bereikbaar zijn. Pas als dat groen is, promoveert het diezelfde geteste versie naar productie: geen herbouw, geen verrassingen. Daarna volgt een tweede controle op productie zelf, inclusief een verse Lighthouse-meting op zowel mobiel als desktop.
Vóór de agent überhaupt begon, had het script al een baseline gemeten. De regel: de slechtste score van de site mag na de wijziging maximaal twee punten lager liggen dan die baseline. Zakt hij verder, of faalt de gezondheidscheck? Dan draait het script de wijziging automatisch terug, code én draaiende versie, en gaat de site verder alsof er niets gebeurd is. De mislukte poging wordt niet weggegooid maar bewaard onder een label, zodat ik later kan analyseren wat er misging.
Dan de noodrem, in drie lagen. Eén: een circuit-breaker. Een paar mislukte pogingen achter elkaar en het hele systeem stopt zichzelf: geen nieuwe poging, wel een berichtje naar mijn telefoon dat er een mens nodig is. Twee: een pauzeschakelaar waarmee ik de agent in één handeling stil zet tot ik hem bewust weer aanzet. Dat is bewust laagdrempelig: pauzeren moet makkelijker zijn dan doorgaan. Drie: bewaking op vastlopers. Ooit hield een hangende build de hele pijplijn bijna een etmaal ongemerkt in gijzeling; sindsdien wordt een run die te lang duurt als dood beschouwd en opgeruimd.
En omdat vertrouwen om zichtbaarheid vraagt: elke wijziging die de agent doorvoert, krijgt een mens-leesbare regel in de publieke changelog op de site, met een versienummer. Bezoekers kunnen live meekijken met wat de Ai aan de site verandert. Dat is niet alleen transparantie als principe, het dwingt ook discipline af. Wat je publiekelijk moet verantwoorden, bouw je zorgvuldiger.
Het eerlijke deel: toen drie Ai-reviewers mijn eigen verhaal fileerden#
Nu het deel dat ik makkelijk had kunnen weglaten.
Mijn ambitie voor footballoracle.nl reikte verder dan de presentatielaag. Het plan was een écht zelfverbeterend systeem: een leer-loop die voorspellingen zou vergelijken met echte uitslagen en het model daar automatisch op zou bijstellen. “Een site die zichzelf verbetert, zonder mens”: dat was de beoogde kernbelofte, de USP.
In juni 2026 liet ik dat plan adversarieel reviewen: drie Ai-agents met opzettelijk tegengestelde rollen (een business-criticus, een technisch criticus en een risico/juridisch criticus) kregen de expliciete opdracht het plan te fileren, niet te bevestigen.
De technische criticus dook in de daadwerkelijke code en kwam terug met een sneer die pijn deed omdat hij klopte: de zelfverbeter-loop bestond niet. De componenten die van uitslagen moesten leren, bleken stubs: functies die lege lijsten of niets teruggaven. De “geleerde” gewichten bereikten het voorspelmodel nooit. En een modelversie die ik voor een vrucht van dat leerproces aanzag, bleek gewoon een handmatige aanpassing van mijzelf. Het oordeel, letterlijk: de USP rust op niet-werkende code. Belangrijk daarbij: dit speelde in de plannen en de code, vóór het als claim naar buiten ging.
De juridische criticus deed er een schep bovenop: “draait zonder mens” is voor een publiek product een claim die je simpelweg niet wilt maken als hij niet volledig waar is. En hij was niet volledig waar: er is wel degelijk een mens die kaders stelt, verbodslijsten schrijft, bij de circuit-breaker inspringt en het model reviewt.
De uitkomst van die review is de framing die ik sindsdien overal gebruik: Ai-gedreven, mens-bewaakt. De Ai doet het werk, tien keer per dag, ook ‘s nachts. Maar een mens heeft de grenzen getekend, een mens wordt gebeld als het twee keer misgaat, en een mens beslist over alles wat de kern raakt. Dat is de enige versie van het verhaal die waar is. En eerlijk gezegd: het is ook een béter verhaal. Een gelogde kritische review die “de motor werkt nog niet” durft te zeggen, is geloofwaardiger dan welke gepolijste claim ook.
Dus als je mij hoort zeggen dat mijn website zichzelf verbetert: de presentatie- en kwaliteitslaag, ja, aantoonbaar en dagelijks. Het voorspelmodel zelf: dat verbetert alleen met een mens erbij, en dat blijft voorlopig zo.
De fix die geen code-fix was#
Nog één les uit de praktijk, omdat hij zo herkenbaar zal zijn voor iedereen die met autonome systemen werkt.
De SEO-score van de site bleef hangen op 92. Punten die je laat liggen zijn voor zo’n optimalisatie-agent een rode lap: hij wil fixen. Maar de oorzaak zat helemaal niet in mijn code. De CDN-laag vóór de site serveerde zijn eigen robots.txt-regels en eigen cache-instellingen aan de buitenwereld. Bezoekers (en Google, en Lighthouse) kregen dus iets anders te zien dan wat mijn server uitstuurde.
De les die daaruit kwam, is inmiddels een huisregel: controleer eerst met een simpele curl wat productie écht serveert, en vergelijk dat met wat je server uitstuurt, vóór je een “bug” in je code gaat fixen. Anders repareert je agent (of jijzelf) eindeloos iets dat niet stuk is.
Belangrijker nog: die blocker staat nu expliciet in de instructies van de agent, als iets waar hij niet aan mag werken. Een agent die weet wat hij níét moet fixen, is waardevoller dan een agent die overal aan sleutelt.
Wat betekent dit voor jouw bedrijf?#
Je hoeft geen WK-voorspeller te bouwen om hier iets aan te hebben. De vraag die op steeds meer MKB-tafels ligt: mag Ai aan onze website, onze webshop, onze processen sleutelen? Mijn antwoord: ja, maar pas nadat je de kaders hebt staan. Dit zijn de zes die bij mij het verschil maken:
- Scheid beslissen van uitvoeren. Laat Ai voorstellen en bouwen; laat een deterministisch, voorspelbaar proces (script of mens) live zetten en terugdraaien. Ai hoort niet op de productie-knop te drukken.
- Schrijf de verbodslijst vóórdat je begint. Betalingen, klantdata, inloggen, alles wat geld of vertrouwen raakt: verboden terrein, mens verplicht. Niet achteraf bedenken.
- Alleen kleine, omkeerbare stappen. Eén wijziging per keer, automatisch terug te draaien. Grote sprongen zijn voor mensen met review.
- Meet vóór en na, tegen een objectieve lat. Zonder baseline en hermeting weet je niet of Ai je site verbetert of sloopt; je hóópt het alleen.
- Bouw de noodrem eerst. Een circuit-breaker die na een paar fouten stopt en een mens waarschuwt, en een pauzeknop die iedereen zonder technische kennis kan bedienen. Failsafes zijn goedkoper dan incidenten.
- Wees eerlijk in je claims. “Volledig autonoom” klinkt stoer, maar “Ai-gedreven, mens-bewaakt” is verdedigbaar, tegenover klanten én juristen. Laat desnoods een kritische buitenstaander (of een adversariële Ai) je eigen verhaal fileren voordat de markt het doet.
De rode draad: autonomie is geen tool die je aanzet, maar een architectuur die je ontwerpt. Het meeste werk zit niet in de Ai (die is verrassend capabel), maar in het harnas eromheen.
Verder praten?#
Op footballoracle.nl kun je in de changelog live meekijken met wat de agent dagelijks doet: transparantie als bewijs. En denk je na over wat Ai in jouw bedrijf wél en niet autonoom zou mogen doen? Leg dat per proces vast met het Ai-stoplicht, een gratis werkdocument dat groen, geel en rood onderscheidt. Over de noodrem zelf schreef ik eerder uitgebreid in de noodrem: circuit-breakers voor autonome Ai. Wil je sparren over de kaders voor jouw situatie? Op de consulting-pagina lees je hoe ik werk.