Week 38: De aanname die het niet hield
Een week waarin bijna elke zekerheid sneuvelde zodra ik hem ging meten — van een vuistregel voor AI-kosten tot een bugfix die zijn eigen spiegelbeeld bleek.
Deze week had een terugkerend patroon, en het duurde tot donderdag voor ik het echt zag: bijna elke keer dat ik iets aannam in plaats van mat, bleek de aanname net iets anders te liggen dan ik dacht. Niet dramatisch fout. Net genoeg fout om de conclusie om te draaien.
Een vuistregel die alleen bij één leverancier klopte
Voor mijn boek over AI-kostenbeheersing gebruikte ik een bekende vuistregel: ongeveer vier tekens per token, en voor Nederlands zou je daar wat vanaf moeten trekken omdat onze taal meer tokens per woord kost dan Engels. Die claim stond al een tijd in het manuscript.
Toen ik hem eindelijk ging meten — met de tokenizers van OpenAI, Anthropic en Google naast elkaar — bleek de vuistregel voor Nederlands prima te kloppen bij OpenAI en Google. Alleen bij Anthropic zat het er flink naast. Het verschil zat dus niet in de taal, maar in de tokenizer van de leverancier. Een claim die ik als taalkundig feit had opgeschreven, was in werkelijkheid een eigenschap van één specifiek product. Dat vereiste een andere zin in het boek, maar vooral een andere manier van kijken: bij AI-kosten is “het ligt aan de taal” bijna nooit de volledige verklaring. Het ligt aan de leverancier, en soms verandert dat nog met de volgende modelgeneratie ook.
De bugfix die zijn eigen fout herhaalde
Iets soortgelijks gebeurde bij het kostendashboard van de podcast. Een bug zorgde ervoor dat plays op de verkeerde maand werden geboekt — geregistreerd op het moment dat het harvestscript draaide, niet op het moment dat de aflevering echt gepubliceerd was. De eerste fix leek voor de hand liggend: het venster afkappen zodat launch-plays niet meer naar de vorige maand weglekken.
Een code review ontdekte iets anders: die fix maakte precies dezelfde fout in spiegelbeeld. Het venster kon namelijk ook weken vóór de publicatiedatum beginnen, en zonder een correcte ondergrens verdween er nu data aan de andere kant. De oplossing die het probleem moest oplossen, voegde het probleem opnieuw toe, alleen in de andere richting. Pas door het venster aan beide kanten aan published_at te knopen, klopte het beeld weer.
Wat me hier trof: niemand had dit expres fout gedaan. De aanname “afkappen aan één kant volstaat” voelde compleet logisch, tot iemand anders er met frisse ogen naar keek.
Acht prompts, twee weken kapot, niemand die het zag
De hardste les kwam uit een promptinventarisatie. Acht van de zevenentwintig productieprompts bleken al meer dan twee weken kapot door een bibliotheekupdate die een argument ongeldig had gemaakt. Niemand had het gemerkt — sterker nog, het kostendashboard toonde in die periode juist lagere kosten. Een storing die zich verkleedt als besparing.
Dat is precies het soort blinde vlek waar het boek over gaat, en het overkwam mezelf terwijl ik eraan schreef. Een dalend getal wordt te makkelijk gelezen als goed nieuws. Het vraagt om een tweede vraag: daalt dit omdat iets beter werkt, of omdat iets stopt met werken?
Een bezinkperiode met de verkeerde onderbouwing
Ook de aanpassing van het kostendashboard zelf paste in het patroon. Ik had een bezinkperiode van zeven dagen ingesteld met als reden: plays harden nog een tijdje na het passeren van de maandgrens. Logisch klinkende aanname, maar onjuist. Empirisch onderzoek toonde aan dat plays meteen vaststaan op het moment van de harvestrun. Wat wél nog nahangt, zijn kostenregels van maandafsluittaken die met vertraging binnenkomen. Het getal zeven bleef geschikt — alleen de reden erachter moest volledig herschreven worden.
Wat dit met me deed
Ik was deze week vaker bezig met corrigeren dan met bouwen, en dat voelde in eerste instantie als vertraging. Maar het patroon is te consistent om toeval te zijn: token-tellingen, bugfixes, bezinkperiodes, kostendashboards — telkens bleek de eerste, intuïtieve verklaring niet de hele waarheid, en telkens was het een concrete meting of een tweede blik die dat blootlegde.
Dat maakt me voorzichtiger met mijn eigen aannames, ook buiten de code. Als ik merk dat een verklaring “voelt” als vanzelfsprekend, is dat precies het moment om even te gaan meten in plaats van door te schrijven. Niet omdat intuïtie waardeloos is — elke aanname deze week begon als een redelijk vermoeden — maar omdat de plek waar intuïtie het meest zeker aanvoelt, kennelijk ook de plek is waar hij het vaakst een stapje mist.
Het patroon
De gemeenschappelijke deler was niet een gebrek aan zorgvuldigheid. Iedere aanname deze week was op het moment zelf redelijk. Het verschil zat in wat er ná die aanname gebeurde: een meting, een code review, een tweede blik van iemand zonder de context van de eerste beslissing. Steeds was het niet de oorspronkelijke gedachte die de fout ving, maar een onafhankelijke check erna.
Dat is misschien de nuttigste conclusie van deze week: bouw die tweede blik in vóórdat je hem nodig hebt, niet nadat een dalend kostengetal je iets wijsmaakt.
Deze blogpost is geschreven met AI-ondersteuning op basis van mijn dagelijkse journals en Claude Code sessiesamenvattingen uit het “365 Days of AI Code” experiment.