# Stijn de Ruijter — Full Content > Freelance Data & Analytics Consultant based in the Netherlands. Helps scale-ups and mid-size companies connect AI and LLMs to the data that actually matters. This file contains the full text of all published articles, newest first, for AI tools that want the complete content in one fetch. The index version is at https://stijnderuijter.nl/llms.txt --- # Self-service analytics of dashboards? Published: 2026-06-17 (Dutch) URL: https://stijnderuijter.nl/writing/self-service-analytics-dashboards Business analytics gaat om betere keuzes maken. Dashboarding helpt om die keuze duidelijk en transparant te houden, en om een organisatie op één lijn te brengen. De voorbeelden hieronder pak ik steeds vanuit een marketinghoek, zodat de drie soorten dashboards concreet worden. De indeling zelf geldt net zo goed voor andere domeinen. ## Drie soorten dashboards Ik houd ervan om dashboards op grote lijnen in te delen in drie soorten: 1. Strategisch dashboard: de high-level KPI's die de strategie zíjn, uitgedrukt in cijfers. - Wat is onze Customer Lifetime Value : Cost of Acquisition op bedrijfsniveau? - Welk % van de omzet is marketing-sourced? - Wat is onze jaarlijkse retentie / churn? 2. Tactisch dashboard: de tactische laag bevat je veronderstelde causale drivers, de leading indicators die, als ze bewegen, later de strategische KPI zouden moeten bewegen. - Wat is de CAC per kanaal deze maand, en welk kanaal loopt op? - Hoe ontwikkelt de conversieratio per funnelstap zich (trend)? - Wat is de ROAS per campagne ten opzichte van target? - Hoe ontwikkelt het leadvolume / de pipeline zich richting doel? - Wat is de engagement-trend per retentiecohort? 3. Operationeel dashboard: dit gaat over de gezondheid van het proces en directe actie. Het dashboard dat je opent om te beslissen waar iemand aan moet werken. - Welke campagnes lopen vandaag over of onder budget (pacing)? - Werkt onze conversietracking nog (tags, dataLayer, datakwaliteit)? Vooral het tactische segment kan snel groot worden, doordat je continu probeert de KPI te optimaliseren. ## Waar self-service analytics binnenkomt En precies daar komt self-service analytics binnen. Zo kun je sneller subanalyses doen en checks automatiseren die zelf suggesties aandragen. Werk dat voorheen een data-analist of soms zelfs een data scientist kostte, kan nu direct gedaan worden door degene die de campagne beheert. Het is een laag bovenop je bestaande dashboarding. Daarbij moet je kritisch kijken naar welke statistieken je echt wekelijks nodig hebt om bij te sturen, en welke eigenlijk niet in een statisch dashboard thuishoren. ## Wat self-service analytics vergt Self-service analytics stelt wel voorwaarden. Zo moet: - de datakwaliteit op orde zijn; - de data governance zeer scherp zijn; - er een semantische laag over de data liggen: je moet hebben afgesproken wat de definities van specifieke begrippen zijn. Wat is één sale? Wat is een lead? Welke kosten horen daarbij? - elk concept gekoppeld zijn aan de data (pre-defined SQL queries); - onderhoud een engineeringtaak zijn. Klopt de documentatie nog met hoe we werken? Zijn er businessprocessen aangepast die niet in de semantic layer zijn verwerkt? - er evals zijn tegen testdatasets (wat voorheen bijvoorbeeld een dashboard was). In plaats van een data-analist die voor elke vraag een ad-hocanalyse of dashboard maakt (en impliciet het dataonderhoud doet), verschuift het werk meer naar onderhoud. En dat vergt een stevige data-governancestructuur. ## Mijn visie en volgorde van stappen 1. Vastgesteld datamodel. De implementatie: governed tabellen, kolommen, transforms. Één gezaghebbende bron per concept, duplicaten gesnoeid. 2. Semantische laag erbovenop. Koppelt het concept (begrip in businesstaal) aan de definitie (de precieze afspraak) en wijst naar de implementatie uit stap 1. Hier krijgt iedereen hetzelfde getal. 3. Dashboards op strategisch / tactisch / operationeel niveau. Tevens je ijklat. 4. Self-service-laag (tooling + procedurele werkwijze) voor de long tail. 5. Herhaal: onderhoud, evals en herkomstsignalen om stap 1 t/m 4 heen. Elke laag steunt op de laag eronder. Je bouwt van onderaf op. Pas met een vast datamodel en een semantische laag draagt self-service analytics echt. --- # Een vastgoedfonds in een uur op de kaart Published: 2026-06-09 (Dutch) URL: https://stijnderuijter.nl/writing/vastgoedfonds-op-de-kaart Een jaarverslag, de TomTom API en wat Python. Meer heb je niet nodig om 653 zorgpanden van Aedifica op de kaart te zetten. En in een uur snap je het profiel van het fonds beter dan uit het hele jaarverslag. Ik houd een database bij met zo'n tachtig Europese vastgoedfondsen. Koers, NAV, korting op de NAV, dividendrendement, LTV. Allemaal nuttig. Maar een spreadsheet vertelt je waar een fonds waard is, niet waar het staat. En bij vastgoed is "waar" het halve verhaal. Een zorgpand in een welvarende forensenplaats is iets heel anders dan hetzelfde pand in een krimpregio. Dat zie je niet in een cel met een getal. Dat zie je op een kaart. Het goede nieuws: die locatiedata staat gewoon in het jaarverslag. Het slechte nieuws: begraven in een bijlage van achttien pagina's, als platte tekst in een PDF. ## De bron: de bijlage die niemand leest Aedifica is een Belgische zorgvastgoed-REIT. Achterin het jaarverslag 2024, onder "Summary of investment properties", staat de complete portefeuille. Per pand: naam, oppervlakte, aantal bewoners, huur, bouwjaar en, cruciaal, de locatie. 653 panden, verspreid over acht landen. Geen straat en huisnummer overigens. Alleen stad en land. ## De pijplijn: PDF naar coördinaten naar kaart 1. De PDF uitlezen. pdfplumber trekt de tekst uit de bijlage. De tabel is rommelig, want de zijbalk van het jaarverslag lekt dwars door de regels heen, maar met een paar reguliere expressies houd je per pand een schone regel over. 2. Geocoderen met TomTom. Hier komt de API binnen. Voor elk pand stuur je "naam, stad, land" naar de TomTom Search API en krijg je een breedte- en lengtegraad terug. Vindt de API de naam van het zorgpand niet, dan val je terug op het centrum van de stad. TomTom levert ook de kaarttegels, dus je hele kaart draait op één API. Had Google Maps gekund? Zeker, en met rijkere context: reviews, foto's, openingstijden, bezoekersdrukte. Voor dit soort profielwerk kan dat goud waard zijn. Maar TomTom, een Nederlands bedrijf uit Amsterdam, heeft een verrassend royale gratis tier. Duizenden requests per dag, ruim genoeg om deze hele portefeuille twee keer over te geocoderen zonder dat het een cent kost. Voor pure geocoding en kaarttegels is dat een prima alternatief, en nog van eigen bodem ook. Chapeau daarvoor. 3. Opslaan en tonen. De coördinaten gaan in een klein SQLite-bestand. De kaart is Leaflet met TomTom-tegels en marker-clustering, zodat 653 punten niet in één bruine vlek veranderen. Eén vertrouwenscheck voordat je iets gelooft: tel de oppervlakte van alle panden die je hebt geparseerd op en leg dat naast het totaal dat het fonds zelf rapporteert. Bij mij: 2.231.810 m² geparseerd tegen 2.229.804 m² gerapporteerd. 0,09% verschil. Dan weet je dat je parser niet stiekem panden laat vallen. Resultaat van het geocoderen: 584 panden exact, 69 op stadsniveau, 0 mislukt. ## Wat je in een uur ziet En dan staat het er. (653 zorgpanden, geclusterd per land, op een interactieve kaart.) Drie dingen vallen meteen op die je uit de cijfers nooit had gehaald. Finland heeft de meeste panden. 235 van de 653 panden. Maar het zijn kleine units, kinderdagverblijven en kleinschalige zorg. In het jaarverslag is dat één regel; op de kaart is het een wolk. Nederland zit in de dure catchments. De panden clusteren in Amstelveen, het Gooi, Heemstede, Oegstgeest. Welvarende forensenplaatsen, precies waar private-pay zorg het sterkst is. Dat is geen toeval, dat is strategie, en je ziet het in één oogopslag. Het is modern vastgoed. Zet er een scatterplot van huur tegen oppervlakte naast en de bouwjaren komen mee: mediaan 2017. Eén uitschieter, Parc Imstenrade in Heerlen, ligt ver onder de mediane huur per m². Een groot, ouder complex. Op de kaart een stip, in de grafiek meteen een vraag voor het volgende gesprek. ## De prijs per m² verraadt waar het geld zit Nog een lens. Reken voor elk pand de huur per m² per maand uit en zet ze als losse punten neer, gegroepeerd per land. Twee dingen springen eruit. Ten eerste de rangorde: de hoogste huren per m² staan in het noorden. Zweedse panden zitten rond de 22 euro per m² per maand, Finse rond de 19. Daaronder het VK en Ierland rond de 15, dan Nederland en België, en onderaan Duitsland rond de 10. Ten tweede, en dat is wat een staafdiagram zou verbergen: de spreiding binnen een land is enorm. In het VK staat een pand op 5 euro per m² per maand en een ander op 36. Eén gemiddelde per land zou dat platslaan. De losse punten laten zien dat "het VK" geen prijs heeft, maar een wolk. Leg dit naast de kaart en je ziet de tegenstelling. Op de kaart oogt Nederland het meest premium, met al die dure forensenplaatsen. In de huur per m² is Nederland gewoon middenmoot. De catchment is duur, de huur per m² niet uitzonderlijk. Dat is precies het soort vraag dat je wilt stellen: betaalt Aedifica in Nederland voor de locatie, terwijl de echte huuropbrengst per m² in Scandinavië zit? Twee grafieken, twee verhalen. Pas als je ze naast elkaar legt, zie je waar je dieper moet graven. ## Waar het misgaat (en waarom dat oké is) Eerlijk zijn: het jaarverslag geeft alleen stad, geen straat. "Exact" betekent dus vaak dat TomTom het zorgpand op naam vond, niet dat ik een huisnummer had. Een handvol punten landt in de verkeerde plaats, zoals een Iers pand dat ineens in Denemarken opduikt. Voor een eerste profielschets maakt dat niet uit. Voor due diligence wel; dan is de volgende stap straatadressen toevoegen en treffers buiten de landsgrens weggooien. En als je zo'n kaart publiceert: je TomTom-sleutel staat dan in de browser. Zet 'm in het TomTom-dashboard vast op je eigen domein, anders draait iemand anders 'm leeg. ## Vroeger dagen, nu een uur werk Het eerlijke deel dat vaak ontbreekt: dit soort analyse kostte vroeger dagen. Data uit een PDF peuteren, opschonen, een geocoder aan de praat krijgen, een kaart en grafieken bouwen, alles controleren. Een week werk was zo verdampt. Met Claude is de pijplijn een kwestie van minuten. En dan ben je er nog niet, want de eerste versie zit vol kleine fouten: een Zweeds pand in kronen in plaats van euro's, een ontwikkelproject zonder bouwjaar, een stad die in het verkeerde land landt. Reken op een paar uur voordat je de inzichten echt te pakken hebt en vertrouwt. Maar uren, geen dagen. Dat verschil verandert wat je überhaupt de moeite waard vindt om uit te zoeken. ## De echte les Dit gaat niet over Aedifica. Het gaat erover dat publieke data plus één API plus een uurtje genoeg is om een asset-zwaar bedrijf echt te begrijpen. Niet de samenvatting, maar de werkelijke spreiding. En het werkt alleen omdat de data, hoe begraven ook, gestructureerd genoeg was om eruit te trekken. Dat is dezelfde wet die ik eerder over vergelijkers schreef: wat machine-leesbaar is, wint. Een fonds dat zijn portefeuille netjes in een tabel zet, kun je in een middag doorgronden. Een fonds dat het in plaatjes verstopt, dwingt je tot giswerk. Blijft de vraag: wanneer gaan bedrijven hun data standaard machine-leesbaar delen, in plaats van weggestopt in een PDF? Wie dat als eerste doet, wordt ook als eerste begrepen. --- # Google wordt de nieuwe Independer. Gaan churn rates door het dak? Published: 2026-05-21 (Dutch) URL: https://stijnderuijter.nl/writing/google-wordt-de-nieuwe-independer Ik heb aan beide kanten van dit verhaal gezeten. Eerst bij een energiebedrijf, waar we elke maand keken hoeveel klanten er via verschillende affiliates binnenkwamen. Daarna in de verzekeringswereld, waar het vergelijkingsmodel nóg dieper in het verdienmodel zit. De aankondiging van Google tijdens I/O 2026 gaat beide sectoren raken. Maar niet op dezelfde manier. Tijdens Google I/O 2026 werden drie dingen duidelijk. AI Mode wordt de standaard. Geen tien blauwe links meer, maar een AI die direct antwoord geeft. Inclusief prijsvergelijkingen, productvergelijkingen en servicevergelijkingen. Google bouwt dus zelf de vergelijker. Agents die namens jou handelen. Google's agentic layer kan straks namens jou een energiecontract afsluiten of een verzekering overzetten op het moment dat het voor jou het gunstigst is, zonder dat je er iets voor hoeft te doen. Personal Intelligence. Google combineert data uit Gmail, Foto's en Agenda om jou proactief te adviseren. Verhuisd? Je agent checkt of je energiecontract nog de beste deal is. Auto gekocht? Je autoverzekering wordt automatisch vergeleken. Dit is de kern: Google bouwt precies wat Independer, Pricewise en Geld.nl doen maar dan beter, sneller en geïntegreerd in het moment dat je iets nodig hebt. Vandaag werkt het zo: je googelt "goedkoopste energieleverancier", klikt op Independer, vult je gegevens in, en kiest een aanbieder. Morgen geeft Google je het antwoord direct. Zonder tussenstop. Zonder affiliate fee. Voor vergelijkingswebsites is dit existentieel. Hun hele model draait om het afvangen van zoekverkeer en het doorsturen naar aanbieders, met een commissie per lead. Als Google die stap overslaat, valt de bodem onder dat model weg. Bij een energiebedrijf waar ik werkte, kwamen veel klanten binnen via vergelijkingsplatforms. Dat was duur, maar het werkte. De vraag is: wat doe je als dat kanaal opdroogt? Het eerlijke antwoord: voor energiebedrijven is dit vooral een distributieprobleem. En daar bestaat een verdediging voor: verticale integratie. Voor energiebedrijven betekent dit: niet alleen stroom, maar bundelen met hardware (slimme thermostaten, thuisbatterijen), software (apps die je verbruik optimaliseren) en data. Die combinatie kan een horizontale AI-agent niet zomaar repliceren. En geeft klanten een reden om niet zomaar over te stappen. Verticale integratie helpt, vooral bij bestaande klanten. Voor nieuwe klanten zal de propositie vooral goed AI-leesbaar moeten zijn. Agents vergelijken wat ze kunnen opvragen. Bedrijven die hun prijzen verstoppen achter "vraag een offerte aan" verliezen van bedrijven die hun tarieven publiceren, gestructureerd en/of via een API. Gestructureerd, API-toegankelijk, en historisch vergelijkbaar. Zodat een agent kan antwoorden op "welke Nederlandse dynamische leverancier had de afgelopen 12 maanden de laagste prijzen?" In de verzekeringswereld ligt het fundamenteel anders. Daar wordt niet één laag geraakt, maar drie tegelijk. Acquisitie. Vergelijkingswebsites zoals Independer zijn voor veel verzekeraars de belangrijkste bron van nieuwe klanten. Als Google die functie overneemt, valt dat kanaal weg. Retentie. En dit is waar het echt pijn doet. Het verdienmodel van veel verzekeraars draait om inertie, klanten die hun polis niet opzeggen, ook al is er een betere deal (renewals = cash cow). Maar een AI-agent die continu je polissen monitort en automatisch overstapt als dat gunstiger is? Dan breekt die inertie. Churn gaat omhoog. Fors. Underwriting. Personal Intelligence geeft Google toegang tot precies de data waar verzekeraars al decennialang naar zoeken: life events, bezittingen, gedragspatronen. Google weet dat je verhuisd bent voordat je verzekeraar het weet. Dat verschuift de macht fundamenteel. Al blijft het wel de vraag in hoeverre Google deze data mag inzetten. Kort samengevat: energie heeft een distributieprobleem met een verdediging plus retentie. Verzekeringen hebben een structureel probleem zonder sterke verdediging. Vooral monolijn schadeverzekeraars en bedrijven die afhankelijk zijn van vergelijkingsverkeer gaan het zwaar krijgen. Commerciële lijnen, multi-product carriers en gebonden distributie houden het langer vol. Of je nu in energie of verzekeringen zit, twee dingen zijn urgent. Word machine-leesbaar. Publiceer je tarieven, voorwaarden en track record gestructureerd. Niet achter een formulier, niet in een PDF. Als een agent je niet kan bevragen, besta je niet. Bouw een relatie die een agent niet kan vervangen. In energie betekent dat: bundel contract, hardware en optimalisatie zo strak dat overstappen meer kost dan het oplevert. In verzekeringen betekent dat: investeer in advisering, preventie en service die verder gaan dan een polis vergelijken op prijs. De bedrijven die dit het eerst snappen, winnen. De rest levert straks marge in aan een AI die onderhandelt namens hun klanten. --- # Stop Guessing at Prompts Published: 2026-05-11 (English) URL: https://stijnderuijter.nl/writing/stop-guessing-at-prompts Your eval set doesn't just tell you how your model is doing. It's the objective function you need to make it better, automatically. In my last piece I argued that evals are the real moat. A golden dataset that tells you whether your LLM output is good enough. But once teams have that dataset, most do something bizarre: they go back to tweaking prompts by hand. "Let me add 'think step by step.' Let me rephrase paragraph three. Let me try telling it to be a doctor." This is not engineering. This is tinkering. And there are better options now. ## The optimization problem you already know If you've ever fit a logistic regression, you understand prompt optimization. You have an objective function (your eval metric). You have parameters you want to tune (the prompt text). And you want to find the parameter values that maximize your objective. With logistic regression, you use gradient descent. With prompts, you can't compute a gradient on text. But you can do something almost as good: let an LLM read the failures, reason about what went wrong, and propose a better prompt. That's it. That's the entire field. ## GEPA: the optimizer that won GEPA (Genetic-Pareto optimization) has become the default prompt optimizer to reach for. It was published as an ICLR 2026 Oral and now lives inside DSPy as dspy.GEPA. Why it won: it outperforms reinforcement learning approaches by up to 20% and the previous best optimizer (MIPROv2) by 13% on aggregate, while using 35 times fewer evaluations. Better results, way cheaper. That combination tends to end debates. What makes GEPA different is the Pareto frontier. Most optimizers maintain one "best" prompt and try to improve it. That sounds reasonable until you realize your inputs are heterogeneous. In my declarability classifier at Reg4U, a clinical note about a phone consult looks nothing like a lab result or a mental health intake. A single prompt can't be equally good at all of them. GEPA maintains a frontier of candidate prompts, each specializing in different input types. In every iteration, it picks a candidate, runs it on a sample, reads the execution traces, and uses an LLM to reason about why specific predictions failed. Then it proposes a targeted improvement. It's not random mutation. It's reflective optimization. ## The other options MIPROv2 is the alternative worth knowing. It searches over both instructions and few-shot demonstrations using Bayesian optimization. Choose MIPROv2 when examples matter. Clinical text classification, for instance, benefits from showing the model what correct output looks like. In practice, many teams run MIPROv2 first (fast, demo-driven) and then GEPA on top for the cases MIPROv2 misses. TextGrad introduced the concept of "textual gradients": using an LLM to generate feedback that functions like a gradient. Conceptually elegant, but in head-to-heads it's been outclassed by GEPA on heterogeneous tasks. TextGrad still works when your inputs are uniform. For most real-world problems, they're not. ## What actually matters in practice Feed the optimizer text, not just numbers. This is the single biggest lever. GEPA's reflective model needs to understand why predictions fail. Don't just return a 0 or 1 from your eval metric. Return a short explanation: "predicted declarabel but the note says 'telefonisch overleg met collega,' which is a niet-declarabel marker." That explanation flows into the reflection step and dramatically improves sample efficiency. Separate the what from the how. Define what your module should do separately from how it does it. When your specification and implementation are decoupled, swapping GEPA for MIPROv2, or re-optimizing when a new model drops, is a configuration change, not a rewrite. Watch your train/val/test split. Prompt optimizers overfit. GEPA's Pareto frontier mitigates this somewhat, but the failure mode where an optimizer memorizes quirks of your training set is real. It's especially easy to miss because your metric keeps going up during optimization. Hold out a true test set and only evaluate on it after you've committed to a prompt. Don't over-optimize cheap models. Sometimes the answer is Claude Opus with a basic prompt, not Haiku with 50 hours of optimization. Run both as baselines before investing in optimization. The goal is the best outcome for the cost, not the most sophisticated prompt. ## The takeaway If you have evals (and after the last article, you should) you already have everything you need to stop guessing. Plug your eval set into an optimizer, let it run, and compare the result to your handwritten prompt on a held-out test set. The prompt you spent hours crafting? The optimizer will probably beat it in twenty minutes. And unlike your intuition, it gets better every time you add data. --- # Evals zijn de echte moat Published: 2026-04-28 (Dutch) URL: https://stijnderuijter.nl/writing/evals-zijn-de-echte-moat Iedereen bouwt LLMs in zijn workflows. Vraag aan tien teams hoe ze meten of het werkt, en je krijgt tien keer hetzelfde antwoord: "het lijkt te werken." Dat antwoord is geen meting. En je merkt het pas op het moment dat het niet meer werkt. ## De val Zolang je hetzelfde model gebruikt, op dezelfde prompt, met dezelfde input, lijkt alles stabiel. Maar dat duurt nooit lang. Anthropic releast een nieuwe Claude. OpenAI deprecieert je modelversie. De rekening loopt op en je wilt switchen naar een goedkopere variant. Een teamlid heeft "even de prompt verbeterd." De legal afdeling wil dat je naar een Europees model gaat. Op dat moment moet je een beslissing maken. Verandert het wat eruit komt? Wordt het beter of slechter? Wat is het effect op je klant? Zonder data is je antwoord een gok onderbouwd met een paar voorbeelden die je je herinnert. En als die LLM in productie staat met klanten erachter, gok je met meer dan je denkt. ## Het saaie antwoord Dit is geen nieuw probleem. Het is een hele oude, in een nieuwe jas. LLM-evaluatie is gewoon standaard statistisch werk. Train, test, validatie split. Een gelabelde dataset. Een metriek die past bij je business. Mijn achtergrond in Economics en mijn MSc Data Science komen hier toch wel weer van pas. Andrew Ng schreef hier al jaren over: dezelfde discipline die toen werkte voor classifiers werkt nu voor LLMs. Wat wel veranderd is: het pluche. LLMs zien er zo magisch uit dat we vergeten dat het modellen zijn. En modellen evalueer je. Hamel Husain noemt evals het belangrijkste dat je voor een AI-product kunt doen, en in de praktijk gaat dat over precies dezelfde dingen: gelabelde voorbeelden, een harness, een metriek, en de discipline om dat consistent door te zetten. Het nieuws is dus dat het nieuws is. ## In de praktijk Een concreet voorbeeld uit mijn werk. Bij Reg4U bouw ik aan declaratiescan: een classificatiesysteem dat huisartsdossiers analyseert om te bepalen welke medische verrichtingen declarabel zijn bij de zorgverzekeraar. De input is ruw. Afkortingen die per regio en per huisarts verschillen. Jargon. Halve zinnen. Geanonimiseerde namen. Een notitie van zes woorden waar een heel consult achter zit. Grote modellen (Claude Opus, GPT-4-class) pakken die nuance vaak goed. Ze hebben genoeg medische context gezien om "BD 140/90" als bloeddrukmeting te lezen, om afkortingen in context te plaatsen, en om de impliciete logica achter een huisartsnotitie te volgen. Kleinere modellen (goedkoper, sneller) kunnen dat soms ook. Maar soms niet. En het verschil zit precies in het soort detail dat je niet opmerkt zonder meting. Mijn golden dataset is hoe ik dat meet. Het is een set handmatig gelabelde records, input plus de juiste output, vastgelegd door domeinexperts. Voor elk nieuw model, elke prompt-iteratie en elke architectuurwijziging draai ik de hele set door de pipeline en vergelijk de voorspellingen met de labels. De metriek die ik gebruik is F2, niet F1. Het verschil zit in hoe zwaar je recall meeneemt. Een gemiste declarabele verrichting is verloren omzet voor de klant: geld. Een vals-positieve is extra controlewerk: tijd. Geld weegt zwaarder. F2 maakt die afweging expliciet, en dwingt me om er ook expliciet over te zijn in plaats van impliciet "een beetje van allebei" te willen. Het echte voordeel komt als je dit combineert met slimme modelkeuze. Denk aan performance marketing. Daar betaal je meer voor zoekwoorden waar je weet dat de ROI groot is, en minder voor zoekwoorden met een kleine kans op conversie. Hetzelfde principe geldt hier. Op een huisartsnotitie waar potentieel een hoge declaratie achter zit, gebruik je gerust een groot, duur model. Op routinegevallen met een lage waarde gebruik je een goedkoper model. Maar zonder eval-harness kun je dat onderscheid niet maken zonder het te raden. Wat dit oplevert: modelkeuzes worden saai. Nieuwe Claude release? Run de eval, zie het delta, beslis op cijfers. Zonder eval-harness is elke beslissing een onderbuikgevoel onderbouwd met een paar cherry-picked voorbeelden. Met een eval-harness is het een experiment. ## De kosten en de valkuilen Dit is niet gratis. Een goede golden dataset bouwen kost tijd en domeinkennis. Iemand moet labelen, en die iemand moet weten waar hij naar kijkt. In ons geval is dat duur en traag. Maar het alternatief, modellen blind in productie wisselen, is duurder. Twee dingen om in de gaten te houden. Goodhart's law geldt ook hier: zodra je een metriek begint te optimaliseren, is de metriek niet meer de werkelijkheid. Je gaat de eval jagen, niet het echte probleem. Het tegenwicht is periodiek de set zelf herzien. Drift erin, scope-veranderingen, edge cases die je miste, nieuwe categorieën die in productie zijn opgedoken. Een eval-set die nooit verandert, is een eval-set die langzaam loskomt van wat je product eigenlijk doet. En: een golden dataset is geen rotsvast iets. Hij groeit mee met je product. Elke keer dat je in productie iets vindt dat fout ging, is dat een kandidaat-record voor je eval-set. Op die manier wordt je harness scherper naarmate je product ouder wordt, en dat is precies de eigenschap die je wilt. De échte moat van een LLM-product is niet je prompt. Prompts kopieer je. Modellen zijn voor iedereen beschikbaar. De moat is je eval-set: de gelabelde, domein-specifieke ground truth die niemand anders heeft. Dat is wat je in staat stelt om sneller én met minder risico te bewegen dan je concurrenten. Of, simpeler: zonder golden dataset is elke modelkeuze een gok.