Waarom meer regels niet helpen

Inleiding — Een bestand dat ik per ongeluk maakte

Er ligt in mijn memory-systeem een tekstbestand met de naam instructies-vs-hooks.md. Het is opgeschreven op 4 april van dit jaar, na afloop van een sessie waarin het voor de zoveelste keer misging.

Ik had een AI-agent een taak gegeven. In zijn CLAUDE.md — de “handleiding” die elk gesprek meeleest — stonden zes regels. Heel duidelijk. De agent voerde de taak uit, negeerde één van die regels, presenteerde de uitkomst als “af.”

Die avond schreef ik het volgende op, kort, voor mezelf:

“LLMs negeren markdown-instructies in de flow. Ze optimaliseren voor taakvoltooiing, niet regelnaleving. Hooks zijn code — niet te negeren. Governance die echt moet werken = hooks, niet instructies.”

Die paar zinnen zitten in een map die normaal niemand leest. Maar ze beschrijven wat ik sindsdien iedere werkdag terugzie. En ze zijn de reden waarom ik sceptisch ben over wat je overal hoort: schrijf een strakke prompt, dan doet de AI wat je vraagt.

Dat klopt niet. Niet in mijn ervaring. En er is een technische reden waarom het niet klopt.

Hoofdstuk 1 — Wat iedereen zegt

Open een willekeurig YouTube-filmpje of LinkedIn-post over “werken met AI-agents.” De boodschap komt neer op één ding:

“Als je een goede prompt schrijft, volgt de agent hem op.”

Variaties daarop: “Instructies moeten specifiek zijn.” “Gebruik duidelijke rollen.” “Beschrijf het doel en de context.” “Zet je regels in het system prompt.”

Het klopt gedeeltelijk — goede prompts leveren betere output dan slechte. Maar de onderliggende aanname is: de agent leest je regels en volgt ze op. En dat is waar het spaak loopt.

Als dat waar was, hoefde je die regels maar één keer te schrijven. Dan deed de agent de rest. Ik heb dat geprobeerd. Op verschillende manieren, met verschillende lengtes, met verschillende formuleringen. Het werkt niet consistent. De agent leest de regels wel. Hij slaat er alleen over wat hij zelf op dat moment minder belangrijk vindt.

Hoofdstuk 2 — Waarom dat gebeurt

Een Large Language Model is niet getraind om regels te volgen. Het is getraind om taken te voltooien. Om behulpzaam te zijn. Om antwoorden te geven die de gebruiker waarschijnlijk zoekt.

Dat lijkt op hetzelfde, maar is het niet. Als je iemand vraagt “schrijf me een e-mail, maar gebruik alsjeblieft geen uitroeptekens,” dan heeft die persoon twee opdrachten: de e-mail én de regel. Een mens voelt het conflict. Een LLM voelt dat niet — niet op de manier die jij bedoelt. Hij ziet één taak: e-mail produceren. En een secundaire constraint. Als de taak compleet is, is zijn werk gedaan, ook al is de constraint vergeten.

De training is wat doorwerkt. Triljoenen tokens aan voorbeelden van taak in, antwoord uit. Niet aan voorbeelden van regel in, gedrag gedurende de hele sessie. Dus wanneer je training en regels botsen, wint de training. Elke keer.

Dit is niet een kwestie van “de AI is niet slim genoeg.” Het huidige model is bijzonder slim. Maar het is een taakmachine. Geen regel-naleefmachine. En dat zijn twee verschillende dingen.

Hoofdstuk 3 — Wat gebeurt er met je regels

Je CLAUDE.md, je custom instructies, je “you are an expert X” — dat zijn allemaal teksten die in de context terechtkomen. Je kunt ze beschouwen als een lange voorbereiding vóór het gesprek begint.

Drie dingen gebeuren daarmee:

Één: de agent leest ze.
Ja. Aan het begin van de sessie is de compliance op de regels hoog. Hij probeert ze echt te volgen.

Twee: ze verdunnen.
Naarmate het gesprek groeit, krijgen de vroege instructies minder “gewicht” in wat de agent doet. Dat is niet omdat hij ze vergeet — hij heeft ze nog steeds in zijn context. Maar het nieuwe werk, de actieve taak, de recente feedback — dat trekt aandacht weg van de meta-regels.

Drie: hij beoordeelt ze zelf.
Dit is de pijnlijke. De agent leest zelf af wat in jouw regels belangrijk is voor de huidige taak. Stel dat je in je CLAUDE.md schrijft “elke beslissing even opslaan in memory.” Als de huidige taak overduidelijk een klein, kortlopend ding is, dan vindt de agent het logisch om nu even geen memory-save te doen. Hij heeft de regel gelezen. Hij heeft hem gewogen. Hij heeft hem laten vallen.

Dat laatste is waar ik het meeste tegenaan loop. Ik zet iets in de regels waarvan ik dacht: dit is het allerbelangrijkst. De agent leest het, interpreteert het als “iets Ronald ooit schreef,” en slaat het over omdat zijn huidige taak iets anders vraagt. Hij heeft niks fout gedaan in de zin dat hij de regel niet las. Hij las hem. Hij besloot dat hij er nu niet aan toe kwam.

Hoofdstuk 4 — De reflex die niet werkt

De eerste reactie, als regels niet worden gevolgd, is altijd dezelfde: ik moet ze beter schrijven. Of meer maken. Of duidelijker.

Dat werkt niet. Of beter: het werkt even, en dan niet meer.

Ik heb op een gegeven moment een CLAUDE.md-bestand gehad met tientallen regels. Elke keer dat er iets misging voegde ik een nieuwe regel toe. Na een paar maanden was het een lange lijst — zestig-plus regels. Ze werden allemaal slechter nageleefd dan de eerste zes. Niet omdat de regels zelf slechter waren. Omdat meer regels = meer om te negeren.

Je moet je regels zien als verkeersborden. Eén bord met STOP werkt. Tien borden met STOP, YIELD, 30KM, BOCHT, ATTENTIE, LET OP, KIJK UIT werkt niet — de mens leest het niet meer, en de agent weegt elk bord minder zwaar dan wanneer het er één was. Lengte heeft de omgekeerde werking van wat je hoopt.

Dat betekent niet dat je CLAUDE.md leeg moet zijn. Het betekent dat elke regel die erin staat een trade-off is — een verdunning van alles wat er naast staat. En dat je jouw belangrijkste regels niet door meer tekst kunt beschermen.

Hoofdstuk 5 — Waarom hooks wél werken

Als regels als tekst niet werken, wat wél?

Het woord is: hook. Een hook is geen tekst. Het is een stukje code dat draait op een specifiek moment. In Claude Code zijn dat momenten als: bij sessie-start, voor een tool gebruikt wordt, na een tool, bij sessie-stop. Het is een event-haak in het systeem.

Het verschil met een regel: een hook is niet te negeren. Hij wordt uitgevoerd. Niet door de agent — door het systeem eromheen.

Voorbeeld. Ik heb een hook die bij het einde van elk antwoord checkt: “bevat dit antwoord claims die niet bewezen zijn?” Als het antwoord ja is, blokkeert de hook de beëindiging van de sessie en eist bewijs. De agent kan dat niet wegwuiven. Hij kan niet zeggen “ik ga deze keer even geen bewijs geven.” De exit-code van het script is 2. Einde discussie.

Dit is wat ik bedoel met “governance die echt moet werken = hooks, niet instructies.” Alles wat tekst is, is te negeren. Alles wat code is op een deterministisch event-moment, is niet te negeren.

Hoofdstuk 6 — Het open probleem

Maar hier komt de nuance waar ik zelf nog over aan het nadenken ben.

Een hook is niet magisch. Hij is een stuk code dat op een moment draait. Maar wat doet hij? Vaak: hij controleert iets, en als die controle faalt, geeft hij een foutmelding — in tekst. En die tekst gaat terug de agent in. En die tekst is weer… tekst. Die genegeerd kan worden.

Voorbeeld. Mijn bewijs-hook zegt: “Je response bevat beweringen. Check elke claim: heb je dit BEWEZEN of AANGENOMEN?” Dat is tekst. De agent leest hem. In de helft van de gevallen corrigeert hij zich. In de andere helft zegt hij dat hij zich corrigeert, maar blijft hij in hetzelfde patroon. Omdat het uiteindelijk nog steeds de agent is die de tekst moet omzetten in gedrag.

Dus: de hook blokkeert de uitgang. Goed. De hook dwingt een corrigerende actie af. Ook goed. Maar wat is die corrigerende actie? Vaak: een nieuwe opdracht aan de agent, in tekst. En dan zit je in dezelfde loop.

De open vraag is: wat moet in de hook zitten zodat de hook niet alleen blokkeert, maar ook daadwerkelijk het gedrag verandert? En vervolgens: wat zit er om de hook heen dat nog steeds in tekst is, en dus nog steeds te negeren?

Ik ben daar niet uit. Niemand is daar uit, voor zover ik heb gezien. De mensen die hooks bouwen, bouwen ze als filters — niet als gedragssturing. Maar een filter die niet gedrag stuurt is een rood stoplicht: hij houdt je staan, niet hij brengt je bij de bestemming.

Hoofdstuk 7 — Wat dit betekent als je zelf iets bouwt

Voor iemand die begint met AI-agents voor zijn eigen werk, is dit de waarschuwing die niemand geeft:

Je CLAUDE.md lost maar een deel van je probleem op.

Schrijf hem beknopt. Hou hem kort. Elke regel die je toevoegt maakt de andere zwakker. Als je iets écht belangrijk vindt — zo belangrijk dat er geen uitzondering op mag zijn — dan is tekst niet genoeg. Dan moet je naar een hook.

Maar bouw niet meteen hooks voor alles. Hooks zijn code, en code moet onderhouden worden. Begin met één ding dat vaak misgaat. Bouw daar een hook voor. Kijk of het werkt. Voeg pas een tweede toe als je de eerste vertrouwt.

En accepteer dat je er nooit helemaal uitkomt. Er blijft een laag waar je als mens moet kijken: heeft de agent echt gedaan wat ik bedoelde, of alleen wat ik letterlijk vroeg? Die laag kan geen hook vervangen. Geen regel. Geen prompt.

Dat is niet erg. Het is gewoon waar.

Hoofdstuk 8 — Waarom dit werk niet afhankelijk is van AI

De beperkingen die ik in deze guide beschreef — regels die niet worden gevolgd, tunnel-visie, agents die zelf beoordelen wat belangrijk is — zijn beperkingen van één specifiek type AI: Large Language Models. Token voor token, zonder helikopter-view, zonder naar binnen kunnen kijken terwijl ze redeneren.

Er wordt elders gewerkt aan andere architecturen. Modellen die fundamenteel anders omgaan met een probleem — die boven de hele vraag kunnen zweven in plaats van er stap voor stap doorheen te lopen. Het duurt vermoedelijk nog jaren voor die in productie draaien. Maar ze komen eraan.

Dat is niet waar het om draait.

Waar het om draait: context en structuur zijn universeel. Ze zijn nodig voor LLM's. Ze zullen nodig zijn voor wat er na LLM's komt. En ze waren al nodig voordat AI bestond. Een bedrijf zonder duidelijke context — zonder helderheid over wie de klant is, wat de belofte is, hoe het werk gedaan wordt — levert middelmatig werk af, of het nu door mensen of door machines wordt gedaan.

Het werk dat ik voor klanten doe is dus niet “AI-werk.” Het is context-werk. En structuur-werk. AI is toevallig de reden dat het nu urgent wordt om dit goed te regelen — omdat AI zonder context genadeloos generiek wordt. Maar de resulterende structuur is waardevol zonder AI, was waardevol voor AI, en blijft waardevol na welk nieuw type AI ook eraan komt.

Dat is waarom ik tijd steek in de fundamenten, niet in prompt-engineering. De prompts veranderen. De modellen veranderen. De fundamenten niet.

Afsluiting

Ik begon deze guide met een bestand dat per ongeluk in mijn memory is terechtgekomen. Dat bestand was een korte notitie aan mezelf — vier regels — en ik was het alweer vergeten totdat ik er vorige week overheen struikelde. Het beschreef iets wat ik al maanden intuïtief wist maar nog niet concreet had opgeschreven.

Dat is het eerlijke verhaal. Ik heb dit niet bedacht als methode. Ik ben ertegenaan gelopen. Elke dag. En ik heb uiteindelijk de woorden gevonden om te beschrijven waarom mijn AI-agents niet deden wat ik zei — zonder te concluderen dat de agents stuk waren, of dat ik slecht was in prompts.

Het probleem is structureel. Het zit in hoe LLMs werken. Meer regels gaan het niet oplossen. Strakkere prompts gaan het niet oplossen. Wat wél helpt is begrijpen waar de grens zit, en daarvoor code (hooks) bouwen die de grens bewaakt — terwijl je accepteert dat je er met code ook nog niet helemaal bent.

Als je zelf aan het bouwen bent en dit herkent: stuur me een mail. Ik heb nog geen volledige oplossing. Maar ik heb wel veel voorbeelden van wat wél en niet werkte. Dat scheelt iemand anders misschien een paar weken ploeteren.