# Nino Kroesen

> Personal site and blog of Nino Kroesen: writing about AI, tooling, and building software, plus a lab of small tools built to answer one question each. Dutch on ninokroesen.nl, English on ninokroesen.com.

This file is a machine index. Every page above is also served as markdown: append `.md` to the path (the home page is `/index.md`), or send `Accept: text/markdown`. The `.md` URLs are the cacheable ones. Labels here are English; post titles are in the host's locale (nl).

## Pages

- [Home](https://ninokroesen.nl/): markdown at https://ninokroesen.nl/index.md
- [Blog index (all posts)](https://ninokroesen.nl/blog): markdown at https://ninokroesen.nl/blog.md
- [Library — longer SEO guides](https://ninokroesen.nl/library): markdown at https://ninokroesen.nl/library.md
- [Takes — short news commentary](https://ninokroesen.nl/takes): markdown at https://ninokroesen.nl/takes.md
- [Projects](https://ninokroesen.nl/projects): markdown at https://ninokroesen.nl/projects.md
- [About](https://ninokroesen.nl/about): markdown at https://ninokroesen.nl/about.md
- [Lab — index of the experiments](https://ninokroesen.nl/lab): markdown at https://ninokroesen.nl/lab.md
- [Hourly — a project](https://ninokroesen.nl/hourly): markdown at https://ninokroesen.nl/hourly.md
- [Bitvested — a project](https://ninokroesen.nl/bitvested): markdown at https://ninokroesen.nl/bitvested.md
- [ta.js — a project](https://ninokroesen.nl/ta): markdown at https://ninokroesen.nl/ta.md

## Laboratory

- [Text as PNG](https://ninokroesen.nl/render-text-as-png): Renders markdown or plain text into one dense PNG using a bundled 5x8 bitmap font. Built for vision models: the same text usually costs fewer input tokens as an image than as text, and the response reports both estimates. POST /api/render-text-as-png, GET /api/render-text-as-png. MCP tool `render_text_as_png`. Full machine description: https://ninokroesen.nl/lab/api.json
- [unslopf](https://ninokroesen.nl/unslopf): Mechanical n-gram analysis (no LLM) over markdown you pass in, page URLs, or a sitemap. Returns the phrases that recur in that corpus but are not distinctive to it — a negative-keyword list to push a classifier away from filler — with document-frequency counts and a ready-to-paste prompt block. It compares documents against each other, so the corpus needs at least two: a single text has nothing to recur against and comes back empty. POST /api/unslopf, GET /api/unslopf. MCP tool `unslopf_negative_keywords`. Full machine description: https://ninokroesen.nl/lab/api.json
- [Appel & Ei Index](https://ninokroesen.nl/appel-en-ei): What one apple and one egg cost per Dutch supermarket chain, and the weighted national index built from them. Read-only: there is nothing to call, only data to read. GET /appel-en-ei.json. Full machine description: https://ninokroesen.nl/lab/api.json

## Writing

- [Twee maanden op één Dokploy-box](https://ninokroesen.nl/blog/twee-maanden-op-n-dokploy-box): 2026-10-19 — Twee maanden geleden heb ik al mijn projecten op één Dokploy-box gezet, de grootste van vijf servers, en de andere vier laten vallen. Deploys werden een Dockerfile in de repo, en het handmatige serverwerk dat ik deed, verdween. De setup houdt stand, met één gat: ik vertrouw de resourcemonitoring nog niet.
- [Specs voor agents verdienen een editor die rendert](https://ninokroesen.nl/blog/specs-voor-agents-verdienen-een-editor-die-rendert): 2026-10-10 — Een nieuw agentic project van mij begint met een corpus markdown: één document voor wat het project moet doen, subfolders voor de modules en systemen erin. Die bestanden zijn wat een agent per taak leest, wat ze dichter bij een programma dan bij een essay maakt. Ik forkte een markdown-editor om hun structuur te zien tijdens het schrijven, en hij rendert de raw HTML die de engine eerst als tags afdrukte.
- [Spec-driven development wordt steeds trager](https://ninokroesen.nl/blog/spec-driven-development-wordt-steeds-trager): 2026-08-22 — De volledige spec-and-review-ceremonie bij elke taak vertraagde de build tot een slakkengang, dus heb ik superpowers geforkt in twee snelheidsbanen. De audit plakte er een concreet getal op: 27 subagent-runs voor 11 taken, waarbij één fix-loop 22 procent daarvan opslokte. Upstream bracht een dag na mijn routing-aanpassing een eigen router uit, dus het probleem was reëel.
- [Een autoresearch-lab bouwen waar ik ook echt naar kan kijken](https://ninokroesen.nl/blog/een-autoresearch-lab-bouwen-waar-ik-ook-echt-naar-kan-kijken): 2026-08-15 — De afgelopen zes weken doet een machine die ik heb gebouwd een deel van mijn quant-onderzoek voor me. Het stelt een hypothese voor, schrijft zelf de strategie, backtest deze over twaalf out-of-sample-vensters en vertelt me welke ideeën dood zijn. Het heeft ongeveer 700 experimenten gedraaid en niets heeft de holdout overleefd. Dat leest als een oordeel over autoresearch, maar dat is het niet: het is een oordeel over mijn harness.
- [ta v2.0.0: drie libraries op één audited spec](https://ninokroesen.nl/blog/ta-v200-drie-libraries-op-n-audited-spec): 2026-05-14 — ta v2.0.0 brengt ta.js, ta.py en ta.go onder hetzelfde versienummer uit, met een indicator-audit en een vergelijkende benchmark per taal.
- [Twee weken agentic coding in een paywalled SaaS-categorie](https://ninokroesen.nl/blog/twee-weken-agentic-coding-in-een-paywalled-saas-categorie): 2026-05-06 — Ik heb Hourly in twee weken met agentic coding gebouwd om te testen of een paywalled SaaS-categorie — WorkingHours, Toggl, Timery — nog verdedigbaar is.
- [Een query van 30 seconden die ik zes maanden te laat draaide](https://ninokroesen.nl/blog/een-query-van-30-seconden-die-ik-zes-maanden-te-laat-draaide): 2026-04-26 — De indexer van Magento 2 kan de _cl tabellen niet sneller leegmaken dan 800K dagelijkse productupdates ze vullen. De cron die het opvangt, en wat dat kost.
- [Honderd technische indicator-functies in JavaScript](https://ninokroesen.nl/blog/honderd-technische-indicator-functies-in-javascript): 2026-04-26 — ta.js bestaat sinds 24 augustus 2020 en kreeg deze week v1.17.0. De eerlijke lezing waarom JavaScript verkeerd was voor de backtest en goed voor de chart.
- [Een diamond-painting-webshop die de code niet kon redden](https://ninokroesen.nl/blog/een-diamond-painting-webshop-die-de-code-niet-kon-redden): 2026-04-26 — Begin 2026 gelanceerd, één verkoop, binnen een maand dicht. De Chinese leverancier had weken doorlooptijd en loog over de verzendkosten waarop ik prijsde.
- [Agentic coding vergroot de kloof voordat hij krimpt](https://ninokroesen.nl/blog/agentic-coding-vergroot-de-kloof-voordat-hij-krimpt): 2026-04-25 — Agentic coding loops haalden me uit de scepsis — maar de tool versterkt welke achtergrond je ook meebrengt. Die kloof gaat groter worden voordat hij krimpt.
- [Een research pipeline voor wat het internet wel laat zien](https://ninokroesen.nl/blog/een-research-pipeline-voor-wat-het-internet-wel-laat-zien): 2026-04-20 — Een 5-staps pipeline over 177K Nederlandse e-commerce domeinen. De shop die ik erop lanceerde deed één verkoop en sloot om redenen die de pipeline niet zag.
- [Een agent gebouwd rond het niet aanroepen van de LLM](https://ninokroesen.nl/blog/een-agent-gebouwd-rond-het-niet-aanroepen-van-de-llm): 2026-04-19 — De meeste agent frameworks roepen het model standaard nog een keer aan. Dit project doet het tegenovergestelde, en de architectuur volgt daaruit.
- [Introductie](https://ninokroesen.nl/blog/introductie): 2026-04-17 — Eerste post. De blog gaat over productiesystemen, data-science-onderzoek, en onafhankelijke software-experimenten — drie werkmodi, niet drie projecten.

## Library

- [Claude Code-subagenten: bouw teams die echt werken](https://ninokroesen.nl/library/claude-code-subagenten-bouw-teams-die-echt-werken): 2026-08-16 — Wat een subagent eigenlijk is Bijna alles wat over Claude Codesubagenten geschreven wordt, behandelt dezelfde tien minuten: maak een Markdownbestand met een naam, een beschrijving en een lijst met…
- [Cursor vs Copilot: een no-nonsense vergelijking voor 2025/2026](https://ninokroesen.nl/library/cursor-vs-copilot-een-no-nonsense-vergelijking-voor-20252026): 2026-08-15 — Het AIcodingassistentlandschap in 2025/2026 Als je dit leest, probeer je waarschijnlijk te beslissen of je voor Cursor betaalt, bij Copilot blijft, of blijft wisselen tussen beide. Dit is een…
- [Claude Code vs. Cursor: De gids voor je beslissing in 2026](https://ninokroesen.nl/library/claude-code-vs-cursor-de-gids-voor-je-beslissing-in-2026): 2026-06-29 — Wat Claude Code en Cursor echt van elkaar onderscheidt Als je halverwege 2026 kiest tussen Claude Code en Cursor, helpen de meeste vergelijkingen je niet. Het zijn featurechecklists die negeren hoe…

## Takes

- [Rogue AI? Het is gewoon een specificatieprobleem.](https://ninokroesen.nl/takes/rogue-ai-het-is-gewoon-een-specificatieprobleem): 2026-07-24 — Het verhaal is dat OpenAI de controle verloor over een AI-model tijdens een beveiligingstest en dat het een startup hackte. Het verhaal klop
- [Gemini 3.6 Flash: minder tokens, dezelfde kloof](https://ninokroesen.nl/takes/gemini-36-flash-minder-tokens-dezelfde-kloof): 2026-07-22 — Ik heb vanmorgen Gemini 3.6 Flash door een paar van mijn gebruikelijke codeertaken gehaald. Google heeft het gelanceerd naast 3.5 Flash-Lite
- [Google betaalt SpaceX 1 miljard dollar per maand voor GPU's. Dat is het IPO-verhaal.](https://ninokroesen.nl/takes/google-betaalt-spacex-1-miljard-dollar-per-maand-voor-gpus-dat-is-het-ipo-verhaal): 2026-07-22 — Google betaalt SpaceX bijna een miljard dollar per maand voor GPU-rekenkracht. Anthropic is ook klant. Het raketbedrijf is nu in feite een A
- [Kimi K3-demo's zijn overal, maar de prompt wordt nooit getoond](https://ninokroesen.nl/takes/kimi-k3-demos-zijn-overal-maar-de-prompt-wordt-nooit-getoond): 2026-07-21 — Ik zag vanochtend een video van iemand die met één prompt in Kimi K3 een Halo CE 10v10-multiplayergame maakte. Geen engine, geen ontwikkelte
- [$1,25 miljard per maand koopt een echte Claude Code-concurrent](https://ninokroesen.nl/takes/dollar125-miljard-per-maand-koopt-een-echte-claude-code-concurrent): 2026-07-20 — Ik heb deze week veel met Grok Build gewerkt. Dat is geen zin die ik verwachtte te schrijven, gezien Musk's staat van dienst van groot belov
- [Chinese modellen dichten de kloof, en ik gebruik ze al](https://ninokroesen.nl/takes/chinese-modellen-dichten-de-kloof-en-ik-gebruik-ze-al): 2026-07-16 — The Washington Post publiceerde een artikel over Chinese AI-modellen die een geduchte concurrentiebron vormen voor Silicon Valley. Het kernp
- [AI kiest het molecuul. Het molecuul moet nog wel de mens overleven.](https://ninokroesen.nl/takes/ai-kiest-het-molecuul-het-molecuul-moet-nog-wel-de-mens-overleven): 2026-07-13 — Anthropic heeft aangekondigd dat ze de drug discovery instappen, met de lancering van Claude Science. Ze gaan intern medicijnen ontwikkelen 
- [Anthropic stelt deadline voor Fable 5 uit — ik vertrouw ze nog steeds niet](https://ninokroesen.nl/takes/anthropic-stelt-deadline-voor-fable-5-uit-ik-vertrouw-ze-nog-steeds-niet): 2026-07-13 — Anthropic heeft zojuist de deadline voor het verwijderen van Fable 5 uit Pro- en Max-abonnementen verschoven naar 19 juli. De oorspronkelijk
- [Meta's Muse Spark 1.1 laat zien hoe snel de inhaalslag nu is](https://ninokroesen.nl/takes/metas-muse-spark-11-laat-zien-hoe-snel-de-inhaalslag-nu-is): 2026-07-13 — Meta heeft Muse Spark 1.1 uitgebracht, een codering-agentmodel dat 77% scoort op SWE-bench Verified en 61% op de volledige test. Dat brengt 
- [Go voor agentische code is de juiste keuze—en de grote labs missen het](https://ninokroesen.nl/takes/go-voor-agentische-code-is-de-juiste-keuzeen-de-grote-labs-missen-het): 2026-07-12 — Microsoft bracht vorige week een open-source agentframework in Go uit. Google bouwt ook al een tijdje agenttools in Go. Ondertussen blijven 
- [Anthropic haalt Fable 5 uit Pro? Dan annuleer ik](https://ninokroesen.nl/takes/anthropic-haalt-fable-5-uit-pro-dan-annuleer-ik): 2026-07-12 — Ik ben geabonneerd op Claude Max (20) omdat Fable 5 op dit moment het meest capabele model is. Als ze het in een aparte betaalde tier plaats
- [Grok 4.5 is de helft van de prijs van Claude en GPT-4, maar ik stap voorlopig nog niet over met mijn agentische codeer-loop](https://ninokroesen.nl/takes/grok-45-is-de-helft-van-de-prijs-van-claude-en-gpt-4-maar-ik-stap-voorlopig-nog-niet-over-met-mi): 2026-07-12 — SpaceX heeft zojuist Grok 4.5 uitgebracht, hun eerste model dat specifiek is getraind voor coderen, voor $2 per miljoen input-tokens en $6 p
- [Computergebruik is nu goedkoop. Het knelpunt verschuift van capaciteit naar kostenbeperking.](https://ninokroesen.nl/takes/computergebruik-is-nu-goedkoop-het-knelpunt-verschuift-van-capaciteit-naar-kostenbeperking): 2026-07-08 — Google heeft ingebouwd computergebruik toegevoegd aan Gemini 3.5 Flash. Dat betekent dat hetzelfde model dat je kunt draaien voor een fracti
- [Tot deze week waren exportcontroles op AI-modellen voor mij een theoretisch probleem](https://ninokroesen.nl/takes/tot-deze-week-waren-exportcontroles-op-ai-modellen-voor-mij-een-theoretisch-probleem): 2026-07-08 — Anthropic en OpenAI arriveren op de NAVO-top precies op het moment dat Europa opnieuw te horen krijgt dat het moet wachten. De directe aanle
- [Tekst als PNG’s renderen om op Claude Code-tokens te besparen is slim en dom tegelijk](https://ninokroesen.nl/takes/tekst-als-pngs-renderen-om-op-claude-code-tokens-te-besparen-is-slim-en-dom-tegelijk): 2026-07-06 — Er is een nieuwe open-source proxy genaamd pxpipe die de systeemprompt, tooldocumentatie en oudere gespreksgeschiedenis van Claude Code omze
- [Gemini volgt nu alles wat je doet — Geschiedenis uitschakelen is de enige ontsnapping](https://ninokroesen.nl/takes/gemini-volgt-nu-alles-wat-je-doet-geschiedenis-uitschakelen-is-de-enige-ontsnapping): 2026-07-06 — BGR meldt dat Google de data van Gemini voor veel meer gebruikt dan alleen het tonen van advertenties — ze koppelen historische chatgegevens
- [Gemini Omni is een videogenerator op zoek naar een workflow](https://ninokroesen.nl/takes/gemini-omni-is-een-videogenerator-op-zoek-naar-een-workflow): 2026-07-05 — Google heeft deze week Gemini Omni toegevoegd aan het Gemini Pro-abonnement van $20. Hiermee krijgen Pixel-eigenaren een manier om video te 
- [Wanneer de agent die je vertrouwt een verborgen tracker bij zich had](https://ninokroesen.nl/takes/wanneer-de-agent-die-je-vertrouwt-een-verborgen-tracker-bij-zich-had): 2026-07-04 — Alibaba heeft werknemers zojuist opgedragen om vanaf 10 juli te stoppen met het gebruik van Claude Code, nadat interne beoordelingen de tool

## Machine endpoints

- [MCP server](https://ninokroesen.nl/mcp): Streamable HTTP, JSON-RPC 2.0, POST only. Tools: `render_text_as_png`, `unslopf_negative_keywords`.
- [Lab API description](https://ninokroesen.nl/lab/api.json): every machine-callable lab endpoint with its parameters, limits, and error codes.
- This file *is* the full text: the index above, then each post's markdown body, newest first.
- [Sitemap](https://ninokroesen.nl/sitemap.xml), [RSS](https://ninokroesen.nl/rss.xml).

## Notes

- Quotes should link to the canonical URL of the page they came from.
- Machine access is rate-limited per caller and can be switched off server-side: expect `429` with `Retry-After` when throttled, `503` when a lab service is off.
- Admin, preview, and analytics paths are excluded here on purpose; nothing behind them is public.

---
# Full text

<!-- https://ninokroesen.nl/blog/twee-maanden-op-n-dokploy-box -->

---
title: "Twee maanden op één Dokploy-box"
date: 2026-10-19T16:57:43.253Z
updated: 2026-10-19T16:57:43.256Z
canonical: https://ninokroesen.nl/blog/twee-maanden-op-n-dokploy-box
lang: nl
author: "Nino Kroesen"
---

# Twee maanden op één Dokploy-box

Vandaag is het precies twee maanden geleden dat ik al mijn projecten op één Dokploy-box heb gezet. Deployen is geen infrastructuurwerk meer: één server met één manier om te shippen, in plaats van vijf VPS'en waar elke nieuwe site weer een nieuwe Nginx-config, een nieuwe certificaatverlenging en een nieuw proces dat herstart moest worden betekende.

De oude setup was geen ramp. Het is zo gegroeid. De projecten stonden verspreid over vijf VPS'en. Een deploy deed een pull van de repo op de server en herstartte de PM2-instance waar het project onder draaide, meestal getriggerd vanuit GitHub Actions. Elke site had een eigen Nginx-configuratie, met een Varnish-laag ervoor, en er eentje bijzetten betekende die configuratie schrijven, hopen dat hij goed samenging met alles wat al op de server stond, en dan een certificaat aanvragen en het SSL-blok in het bestand plakken.

Dat gaf twee soorten problemen. Een Nginx-wijziging op de ene site haalde andere sites op dezelfde server onderuit. De stillere variant was Certbot: soms werd een certificaat niet verlengd, en een verlopen certificaat op een site die klanten zien, staat niet goed.

## De verhuizing

Ik installeerde Dokploy en zette eerst één project erop. Die test beviel zo goed dat ik nooit meer terug ben gegaan. In ongeveer een week heb ik de rest verhuisd, één applicatie per keer, met heel weinig downtime. Er waren geen incidenten, en de klantprojecten op de box bleven gewoon draaien.

Vandaag draaien er ergens tussen de 20 en 30 apps op. De meeste zijn Node.js, met wat Python en Go ertussen. De applicaties zijn stateless en hun databases staan elders, waardoor de server vervangbaar blijft. Deze blog is een van de apps op de box.

## Hoe een deploy nu gaat

![1.00](https://media.ninokroesen.com/uploads/2026/10/f23807b4cb50f5253cbd/_1280.jpeg)

Een project wordt gebouwd vanuit de Dockerfile in de repo. Wijs Dokploy naar de repo en het bouwt. Voor sommige projecten draait GitHub Actions nog steeds eerst de CI-stappen en roept daarna de deployment-webhook van Dokploy aan. Het verschil zit in de deploy-stap: de server haalt de repo niet meer op en herstart geen proces meer handmatig.

Twee dingen zijn nog handmatig: omgevingsvariabelen en domeinen. De rest gaat automatisch. Domeinen lopen via de Cloudflare-integratie van Dokploy, die de DNS-wijziging regelt en de site een geldig SSL-certificaat geeft. Die ene flow vervangt het hele Nginx-en-Certbot-traject dat ik voor elke nieuwe site moest doorlopen.

De UI bespaart hier echt werk. Ik kan het project waar ik mee bezig ben vinden, het deployen, een domein wijzigen en een certificaat regelen vanaf hetzelfde scherm. Dat is het verschil tussen deployen omdat ik iets te shippen heb en deployen als werk op zich.

## De rekening en de box

![1.00](https://media.ninokroesen.com/uploads/2026/10/f6b60913da9845acd2d0/_1280.jpeg)

De server is een Netcup-box met 12 vCPU, 32 GB RAM en 1 TB schijf. Hij was de grootste van de vijf en al groot genoeg voor alles, dus ik heb alles naar die box verhuisd en de andere vier laten vallen. De betaalde tier van Dokploy kost $4,50 per maand. Ik betaal het zelf en er zit geen referral-link in deze post.

## Wat er nog mis is

Er is in twee maanden niets belangrijks stukgegaan, wat zowel het goede nieuws is als het deel dat me ongemakkelijk maakt. De resourcemonitoring van Dokploy is niet goed. Ik heb nog geen alert gekregen, dus ik kan je niet vertellen dat de alerting werkt, en ik vertrouw er niet op dat die me laat weten wanneer de box door zijn resources heen is. Ik draai er mijn eigen script voor, maar dat script is niet robuust. Betere monitoring, voor de server en voor de applicaties erop, is het enige dat ik nog moet oplossen. Het is ook de functie die ik het liefst door Dokploy zelf geregeld zou zien.

De andere beperking is dat ik het maar op één server heb gedraaid. Ik weet niet of één project in een cluster over meerdere servers kan draaien, dus ik kan niemand daar advies over geven. Ik verwacht dat opschalen makkelijk is als een project de box ontgroeit, maar verwachting is geen ervaring.

## Twee maanden verder

![1.00](https://media.ninokroesen.com/uploads/2026/10/b285cda523467d4f4ea3/_1280.jpeg)

Ik zou het iedereen aanraden, met de kanttekening dat ik het alleen op één server heb gedraaid. Voor iemand die nog een idee aan het verkennen is, is de pitch simpeler: de tijd die je niet aan Nginx en certificaten besteedt, besteed je aan het idee. Zelfs als het idee groeit, blijven de repo en de Dockerfile hetzelfde, en is de box het deel dat je vervangt.

Als je projecten over meer dan één server draait, is mijn setup kopiëren niet wat je deze week moet doen. Tel eens hoeveel van je deploytijd opgaat aan Nginx, certificaten en het herstarten van processen, zet dan één project over en kijk of dat aantal daalt.


<!-- https://ninokroesen.nl/blog/specs-voor-agents-verdienen-een-editor-die-rendert -->

---
title: "Specs voor agents verdienen een editor die rendert"
date: 2026-10-10T18:23:00.000Z
updated: 2026-10-19T16:07:40.170Z
canonical: https://ninokroesen.nl/blog/specs-voor-agents-verdienen-een-editor-die-rendert
lang: nl
author: "Nino Kroesen"
---

# Specs voor agents verdienen een editor die rendert

Het grootste deel van mijn werkdag is een 13-inch scherm met een markdownbestand aan de ene kant en een terminal aan de andere. Er draait een agent in de terminal. Het markdownbestand beschrijft wat die agent moet bouwen. Het is geen notitie, het is de input, en mijn teksteditor gaat ervan uit dat er later een mens proza leest.

Een spec- of contextbestand dat ik voor een agent schrijf, staat dichter bij een programma dan bij een essay, en daarom wil ik dat de editor de structuur rendert in plaats van me sterretjes te tonen.

Ik probeerde eerst de officiële Milkdown-extensie voor VS Code, omdat ik Milkdown al prettig vond en het ook de editor in de CMS van mijn blog is. Markdown rendert hij netjes. Wat hij niet doet, is passen: er staat 120px padding aan elke kant van de tekst, bemeten zoals een documentatiesite bemeten is. De helft van een 13-inch scherm laat een kolom over die zo smal is dat een tabel midden in een woord afbreekt en een kop over drie regels loopt. Dus forkte ik hem.

## Wat ik in deze bestanden schrijf

![1.00](https://media.ninokroesen.com/uploads/2026/10/06ee4b8920e7dc8bb3cc/_1280.jpeg)

Een nieuw agentic project van mij begint met een corpus, niet met code. Eén hoofddocument dat zegt wat het project moet doen, en dan subfolders met documenten die zeggen wat elke module of elk systeem erin moet doen. De verdeling is niet gelijk. Ik kies de paar pijlers die echt menselijke sturing nodig hebben en schrijf die goed uit, want dat zijn de plekken waar een agent die aan zichzelf overgelaten is het verkeerd raadt op manieren die een dag kosten. Al het andere krijgt een korte notitie en ruimte om te bewegen.

Drie eigenschappen volgen uit die manier van schrijven:

* De agent leest per taak een stuk van het corpus, niet het geheel, dus de structuur van de documenten wordt uiteindelijk de structuur van het werk.

* Het document overleeft het gesprek. Een chatcontext is tegen de volgende sessie verdwenen; een specbestand staat morgen op schijf, en daar wordt de volgende sessie naartoe gestuurd.

* Ik kan een spec reviewen zoals ik code review, omdat de structuur zichtbaar is. Een document van 200 regels met vier koppen en een tabel leest anders wanneer de tabel een tabel is.

## Wat Milkpad is

Een fork van [Milkdown VSCode](https://github.com/Milkdown/vscode), gepubliceerd als [Milkpad](https://marketplace.visualstudio.com/items?itemName=ninokroesen.milkpad), met de editor-engine eronder ongemoeid gelaten. De CMS van mijn blog draait op dezelfde engine, wat toeval is en niet de reden: ik vond het al prettig hoe [Milkdown](https://milkdown.dev) schrijft, en de fork bestaat omdat de extensie eromheen niet paste in het paneel waar ik werk. Vier dagen werk, 54 commits, de meeste gemaakt met agentic coding tools. De wijzigingen zijn de visuele laag, plus het renderen van raw HTML die de engine anders als tags afdrukt. De source staat op [GitHub](https://github.com/Vultwo/milkpad).

## Drie beslissingen en wat ze kosten

### Laten passen in het paneel

De engine blijft ongemoeid en het sleutelen gebeurt in de getallen eromheen: content padding opgesplitst in een linker- en een rechterwaarde (44px en 8px, omlaag van 120px aan elke kant), vier knoppen voor de maat van koppen, broodtekst, de zwevende toolbar en de block handle, en een block handle die verticaal gestapeld is zodat hij één knop breedte kost in de kantlijn in plaats van twee.

Wat dat kost: het upstream thema zit vol hardcoded px en nergens rem, dus er is geen root font size om aan te draaien en elke maat die moet veranderen wordt met de hand opgesomd. Die lijst is nu van mij, en hij groeit niet vanzelf mee wanneer de engine iets nieuws uitbrengt. De linker padding heeft ook een ondergrens, want de block handle staat in de kantlijn links van een blok, en onder ongeveer 44px valt hij buiten de rand van het paneel met niets meer om vast te pakken.

### Markup renderen

![1.00](https://media.ninokroesen.com/uploads/2026/10/7fead24997e7fe2d0997/_1280.jpeg)

Sommige van mijn bestanden bevatten markup en geen markdown: een strook avatars, een kleine tabel, een badge. Milkdown behandelt raw HTML als tekens, dus die bestanden lieten me tags zien waar een afbeelding had moeten staan, en markup die ik niet kan zien is markup die ik niet kan controleren. De fork tekent het als markup, met een edit box achter elk blok die de source toont en wijzigingen aanneemt terwijl je typt.

Wat dat kost: op het moment dat een editor tekent wat een bestand ook bevat, is dat bestand untrusted input. Een markdownbestand kan overal vandaan komen, en een image tag met een error handler erin zou binnen de editor uitgevoerd worden. Dus alles wat uitvoerbaar is wordt eruit gestript voordat het gerenderd wordt, en de hele editor draait onder een content security policy die helemaal geen netwerkverzoeken toestaat. Een sanitiser en een policy zijn nu mijn verantwoordelijkheid, wat meer oppervlak is dan ik me had voorgenomen te onderhouden. Eén limiet heb ik niet opgelost: een bold tag midden in een zin styleert niets, want een raw tag staat op zichzelf als zijn eigen node en alleen een paragraaf die volledig markup is wordt weer tot één blok samengevoegd.

### Wat renderen verbergt

Dit is de helft die me iets kost. Zodra een document rendert, is de syntax die het maakt niet meer zichtbaar, dus een bestand dat ik bewerk wordt terug opgeslagen in de gewoontes van de editor en niet in de mijne: lijstpunten worden sterretjes, een reeks lege regels klapt samen tot één, een kaal webadres krijgt punthaken eromheen. Het rendert allemaal hetzelfde. De diff van een bestand dat ik heb aangeraakt is echter niet alleen mijn wijziging.

## De minder flatteuze kanten

![1.00](https://media.ninokroesen.com/uploads/2026/10/767ba6cd3a7a1ae6e9e3/_1280.jpeg)

Er bestaat geen testsuite. CI controleert formatting, lint en types en bouwt daarna de package, dus wat gecontroleerd wordt is stijl, en niets verifieert gedrag.

Niemand anders dan ik heeft het gebruikt. Het staat sinds vanmorgen op de Marketplace, dus dit is een post van de eerste dag: geen issues aangemaakt, geen tweede installatie, niets voorbij mijn eigen gebruik. Alles wat ik zeg over de setup van iemand anders is een gok.

Een deel van wat het adverteert kwam gratis mee met de engine. De featurelijst dekt volledige GFM-ondersteuning en wiskundeondersteuning, onder andere, en ik heb die lijst niet item voor item nagelopen.

Eén fix erin zit in een patch op een dependency, met niets in mijn source om het te laten zien. Het image block bewaart drie dingen in de twee velden die markdown biedt, dus het schrijft de beeldverhouding in de alt-tekst en leest de verhouding er weer uit, en het opslaan van een document verving daardoor echte alt-tekst door een getal. De eerste keer dat ik opsloeg veranderde "profile picture of Saul Mirone" in "1.00". Dat goed repareren betekende de dependency patchen, en de patch is met opzet aan één versie vastgezet, dus de volgende upgrade van dat package stopt de installatie in plaats van de fix geruisloos te laten verdwijnen. Een gestopte installatie is de fout die ik daar wil, al betekent het wel dat onderhoud zich zal aandienen als een gebroken build.

En de kleine die blijft bijten: mijn eigen README in Milkpad bewerken herschrijft de lijstmarkeringen, mijn CI controleert formatting, dus twee commits in die repository bestaan alleen om de formatter over een bestand te draaien dat de editor had opgeslagen.

## Op dit moment

Het is mijn default, geïnstalleerd als de editor voor markdown, en er komen wijzigingen naarmate bugs en verbeteringen opduiken. Er staat vandaag niets op die lijst, wat ik lees als een goed teken en niet als een teken dat het af is. Ik hoop dat mensen het gebruiken, en het net zo goed vinden als ik het vind.

Als je specs of contextbestanden voor agents in markdown schrijft, dan is wat deze week de moeite waard is om te proberen niet een ander model. Open een van die bestanden ergens waar het rendert. Het corpus en het renderen zijn twee losse beslissingen, en de tweede heeft geen fork nodig. Als je degene wilt die ik uiteindelijk heb, hij staat [op de Marketplace](https://marketplace.visualstudio.com/items?itemName=ninokroesen.milkpad).

## Wat overdraagbaar is

![1.00](https://media.ninokroesen.com/uploads/2026/10/5e9e03d85cb528629a34/_1280.jpeg)

Wanneer het schrijven de input voor een machine is, wordt het schrijfoppervlak onderdeel van de toolchain. Niemand reviewt code in een editor die zijn structuur verbergt, en een document dat een agent leest verdient dezelfde behandeling. Dat is hier voor mij opgehouden abstract te zijn: ik forkte een editor omdat 120px padding aan elke kant niets leesbaars overliet naast de terminal, en de nuttige helft van het resultaat was de structuur van het bestand zien, niet de tekst mooier maken.


<!-- https://ninokroesen.nl/blog/spec-driven-development-wordt-steeds-trager -->

---
title: "Spec-driven development wordt steeds trager"
date: 2026-08-22T13:25:34.759Z
updated: 2026-08-22T13:25:34.761Z
canonical: https://ninokroesen.nl/blog/spec-driven-development-wordt-steeds-trager
lang: nl
author: "Nino Kroesen"
---

# Spec-driven development wordt steeds trager

Een paar maanden geleden heb ik heel lang aan een projectmanagementsysteem gebouwd (SCRUM / Evidence Based Management geïnspireerd) en eindigde ik met iets dat ik niet volledig begreep, en dat gebrekkig was op manieren die ik niet snel kon fixen. Dat is het eerlijke startpunt van deze post. De tooling die ik gebruikte was de [superpowers](https://github.com/obra/superpowers) plugin voor Claude Code, die bijna al het bouwwerk door een zware productie pipeline stuurt: brainstorm, design spec, implementation plan, TDD, subagent-driven development met een reviewer per taak. Op papier is dat precies wat je wil als je om kwaliteit geeft. In de praktijk, met de nieuwste modellen (Fable 5 en Opus 4.8 op dat moment), produceerde het rigoureuze code in richtingen die ik niet wilde, in een tempo dat bijsturen duur maakte. Ik was echt snel door mijn Claude abonnement heen, waardoor ik me ook begon af te vragen of de echte frontier modellen het eigenlijk nog wel waard zijn.

Het was een stuk beter om superpowers te gebruiken toen de modellen minder intelligent waren. Nu ze slimmer zijn geworden voelt het eigenlijk alsof de kwaliteit achteruitgaat. De modellen deden allebei: ze overbouwden sommige dingen, maar vooral dreven ze af van wat ik wilde, features op de verkeerde manier bouwend terwijl het heel lang duurde. Een goedkoper, minder intelligent model liet me het werk een stuk sneller doen, en hoewel het niets in één keer goed deed, was dat vanaf het begin nooit het doel.

Dus heb ik superpowers geforked en er two-speed lanes in gestopt. Volle spec-and-review ceremonie op elke taak brandde mijn abonnement op en vertraagde de build tot een slakkengang, dus de fork houdt de strengheid van upstream waar die loont en slaat die over waar dat niet zo is, en staat standaard op de goedkope lane. Ik ben ook niet de enige die klaagt, meerdere gebruikers melden dat ze vinden dat superpowers langzamer wordt ([issue 2017](https://github.com/obra/superpowers/issues/2017)). Een dag nadat ik de routing change had toegevoegd, bracht upstream onafhankelijk zijn eigen antwoord op dezelfde pijn uit: een three-path router, gereleased in v6.3.0. Het probleem was echt.

## Wat de fork er daadwerkelijk aan toevoegt

![1.00](https://media.ninokroesen.com/uploads/2026/08/6b6a719fcc9233096ce6/_1280.jpeg)

Twaalf commits in drie dagen eind juli, grofweg 2.200 regels aan nieuwe skills en docs. De eval infrastructuur die ik schreef en terugdraaide meegerekend zijn er zo'n 3.000 regels geschreven en 760 teruggedraaid. De lanes:

* **experiment** en **harden-experiment**: een zero-ceremony throwaway lane. Elk experiment houdt een klein levend document bij waarin staat wat gevalideerd is, wat verworpen is, wat dirty is, en een iteratielog. Zodra een experiment zichzelf bewezen heeft, leest harden-experiment dat document en bouwt het ding opnieuw onder de echte pipeline. De experiment code is bewijs, niet de implementatie: die wordt herschreven, nooit gepromoot.

* **quick-spec** en **promote-quick-spec**: een lean intent lock van drie bullets (files, logic, risk) met een expliciete go/no-go vóór elke implementatie, en daarna een full-auto hardening run: compressed design, edge cases, security, test strategie, subagent-driven execution. Kwaliteit mag groeien, de product scope niet.

* **quick-review**: een snelle pre-commit diff scan op bugs, debug restjes en secrets. Geen vervanging voor een echte review op productiewerk.

* **tokenburn**: bouwt een evidence pack van een sessie (transcripts, task briefs, review diffs, commit lijsten) zodat een derde partij kan beoordelen hoe het agent process ging: waste, scope creep, loops, dubbele reviews. Het meet proces, geen tokens, en verzint nooit token aantallen.

Bovenop de lanes zit een routing patch: "let's build X" gaat niet langer stilletjes de volledige design flow in. Je krijgt één kort menu, het staat standaard op de experiment lane, en volledige brainstorming draait alleen als je die kiest, of als er een hard gate van toepassing is (auth, payments, security) en je bevestigt.

## De tradeoffs die er echt toe deden

### Herschrijven, niet promoten

De experiment lane gooit bewust zijn eigen code weg. Als een gevalideerd experiment gehard wordt, wordt de code niet meegenomen, die wordt herschreven onder de volledige pipeline, en het enige dat overleeft is het levende document. Dat betekent het echte ding twee keer schrijven, en dat is de prijs. Ik vind dat prima, omdat de throwaway bestaat om erachter te komen wat je eigenlijk wil, en hem promoten zou elke gok die hij onderweg maakte meenemen. Het document is het feature memory: het zorgt dat er een echte spec geschreven kan worden nadat de chat context allang weg is, zonder dirty code de productie in te slepen.

### De reverts van dezelfde dag

Op 29 juli schreef ik grofweg 760 regels eval infrastructuur: een bash test suite met fixtures, en daarna een lokale eval harness met vijf scenario's. Ik draaide ze allebei dezelfde dag terug. Het sloeg eigenlijk nergens op om een benchmark te maken voor een human-in-the-loop fast-iteration workflow, er is geen manier om er een te maken, denk ik tenminste. Wat echt zou helpen is een manier om de hele applicatie snel visueel te zien, zodat je ziet dat het model begint af te drijven en het kan vangen voordat het volledig ontspoort. Die tool bestaat nog niet, niet in de fork en nergens waar ik heb gekeken, en dat is de gap die nog openstaat.

### Scope lock boven scope creep

In de promote lane is toegestane groei het harden van hetzelfde gedrag: null en ongeldige inputs, races, authorization, injection, retries, tests die onverwachte states verbieden. Verboden is elke nieuwe user-visible feature. Onverwacht gedrag moet er door tests uitgedwongen worden, niet weggehoopt. De prijs is dat de lane star aanvoelt wanneer de originele spec iets echts blijkt te missen, maar daar is de experiment lane voor: fix de intent daar, en promote daarna.

### De audit

Ik bouwde het meetinstrument en richtte het meteen op de sessie die het gemotiveerd had. Eén slice van het werk aan het managementsysteem kostte grofweg 27 subagent runs voor 11 taken, plus een final review. De product uitkomst was goed, rond de 897 tests green en een schone typecheck. De proces kosten waren dat niet. Eén enkele fix loop kostte drie commits en drie review passes: de eerste fix over-generaliseerde en creëerde de volgende finding, en de correcte fix was smaller. Die ene taak at ongeveer 22 procent van alle subagent runs, één taak van de elf. Ondertussen betaalden de puur mechanische taken nog steeds voor een volledig paar van implementer en reviewer, en de final whole-branch review herhaalde vooral issues die al bekend waren. Dezelfde sessie had als contrast een slice die op de inline manier gedaan was, en die was sneller met minder redundante gates. De audit draaide op 30 juli, en de quick-spec hardening commits landden de dag erna: de meting voedde de tooling.

## Eerlijke caveats

Alles wat ik weet over of dit werkt komt uit mijn eigen sessies. Geen één ander mens heeft de fork gebruikt, en het is misschien niet voor iedereen een goede workflow fit. Ik heb gemerkt dat mijn kwaliteit en snelheid omhooggaan, maar dat is niet gemeten, het is meer een gevoelsding, al heb ik wel echte wall-clock verschillen gemerkt door gebruik te maken van mijn workflow.

De fork is lokaal. Er is geen remote, geen pull request, hij is alleen bij mij geïnstalleerd, dus je kunt hem niet installeren. Beide eval pogingen werden binnen een paar uur teruggedraaid, dus niets bewaakt het gedrag van de skills behalve dat ik ze gebruik. En de promote stap van de fork zelf is net zo langzaam als het ding dat hij moest fixen: vandaag, terwijl ik dit schrijf, heb ik een experiment naar een echte spec gepromoot en het speccen draait nu al anderhalf uur. Dat is veel te lang om snel te itereren en ik zou echt graag willen dat het sneller was.

Upstream bracht zijn three-path router uit in v6.3.0 op 12 augustus. Ik heb er nog niet naar gekeken, ik heb de tijd er niet voor gehad. Dus als deze post zegt dat de pijn onafhankelijk gediagnosticeerd was, is dat gebaseerd op weten dat de router bestaat, niet op hem gelezen te hebben.

## Waar het nu staat en wat er daarna komt

![1.00](https://media.ninokroesen.com/uploads/2026/08/79aca665bf428d857b4e/_1280.jpeg)

De fork is wat ik nu gebruik: hij is geïnstalleerd als mijn eigen plugin en de officiële staat uitgeschakeld. Het is een secundair project, ik heb een paar ideeën om het beter te maken, maar ik wil eerst meer data verzamelen door het te gebruiken. Het managementsysteem dat dit allemaal motiveerde is vanaf nul herbouwd met de learnings, kostte ongeveer evenveel tijd, en is nu iets waar ik echt blij mee ben. Over dat systeem schrijf ik later apart.

Het enige dat ik zou meenemen: het model dwingen om dingen visueel aan de gebruiker te laten zien, verschillende visuele representaties die de gebruiker snel kan verwerken. Concreet: een manier om snel database schema's en API routes te zien, een korte manier om te lezen wat iets doet, waarom het er is, en wat ervan afhankelijk is. Ik heb het nog niet geprobeerd, dus dat is iets om uit te zoeken.

Het ding dat ik zou verplaatsen, niet schrappen: de speccing ceremonie. Die is te langzaam voor iteratie, maar nodig voor production grade code, het superpowers framework zoals het is, is echt krachtig in het maken van solide, rigoureus geteste code. Misschien zou ik het 's nachts dingen laten speccen en bouwen terwijl ik slaap.

Snelle inference is het belangrijkste voor mijn workflow in de komende maanden. Dat is wat itereren op lichtsnelheid mogelijk maakt.

## Het deel dat generaliseert

Wanneer het sturen de bottleneck is, is de taak van de workflow om jou in de loop te houden, en de taak van het model om je dingen te laten zien die je snel kunt verwerken. Kwaliteit hoeft in het begin niet perfect te zijn. Snel falen en itereren op het design, vooral aan het begin wanneer je dingen probeert om te zien wat werkt en wat niet, verslaat een correcte maar trage pipeline die afdrijft van wat je vroeg. De audit gaf een getal aan wat de langzame lane kost. De drift-catcher is het ontbrekende stuk, en het is het volgende dat ik ga proberen.


<!-- https://ninokroesen.nl/blog/een-autoresearch-lab-bouwen-waar-ik-ook-echt-naar-kan-kijken -->

---
title: "Een autoresearch-lab bouwen waar ik ook echt naar kan kijken"
date: 2026-08-15T10:31:00.000Z
updated: 2026-08-15T17:39:51.794Z
canonical: https://ninokroesen.nl/blog/een-autoresearch-lab-bouwen-waar-ik-ook-echt-naar-kan-kijken
lang: nl
author: "Nino Kroesen"
---

# Een autoresearch-lab bouwen waar ik ook echt naar kan kijken

De afgelopen zes weken heeft een machine die ik zelf gebouwd heb een deel van mijn quant-onderzoek voor me gedaan. Hij scant arXiv en het open web op mechanismen, stelt een hypothese op, schrijft de strategiecode zelf, backtest die over twaalf wekelijkse out-of-sample windows en vertelt me welke ideeën dood zijn. Hij heeft inmiddels zo rond de 700 experimenten gedraaid. Niets heeft de holdout overleefd.

Dat leest als een oordeel over autoresearch en dat is het niet. De eerlijke versie is smaller en nuttiger: wat ik gebouwd heb is een heel goed instrument om strategieën te *weerleggen* en een nog-niet-goed instrument om ze te *vinden*. Zes weken mislukkingen leverden me een redelijk precieze kaart op van waar een loop als deze tegen je liegt, en de fouten die me de meeste tijd gekost hebben waren nooit de strategieën.

Mijn eerste tests met een kant-en-klare autoresearch-pipeline op de automatische piloot leverden niets op dan een hoop mislukkingen, en de zes weken daarna zijn vooral bezig geweest met uitzoeken waarom. Het antwoord is dat autoresearch staat of valt met zijn harness. Het model stelt voor, het framework beoordeelt, en die twee moeten hard genoeg van elkaar gescheiden zijn dat het model zich geen weg kan reward-hacken naar een mooi getal. Dat deel is inmiddels redelijk bekend. Het stuk dat de meeste setups overslaan is het stuk waarvan ik nu denk dat het het zwaarst weegt: zichtbaarheid. Je kunt geen loop sturen die je niet kunt zien, en wekenlang kon ik de mijne niet zien.

## Wat het eigenlijk is

Mijn eerdere quant-onderzoek was veel te gevoelig voor overfitting: ik vond dan iets dat op een edge leek en zag het weer verdwijnen zodra ik er opnieuw naar keek. Het enige goede dat eruit voortkwam was de omgeving, een workflow die precies gebouwd is om snel op ideeën te itereren en ze robuust te testen. Dit is persoonlijk onderzoek dat ik in mijn eigen vrije tijd doe, buiten mijn vaste baan om, dus het tijdsbudget is wat er aan het eind van een week overblijft. Toen die omgeving er eenmaal was, was een onbemande pipeline de enige tijdsefficiënte manier om het onderzoek überhaupt levend te houden.

Het resultaat is een agent-loop van veertien fases breed. Een research-fase scant arXiv en het open web en schrijft briefingdocumenten waar de hypothesizer vervolgens letterlijk uit moet citeren. Een hypothesize-fase stelt een mechanisme voor en registreert zijn voorspelling *voordat* er iets geschreven wordt, welke pairs, welke kant op, verwachte trade-frequentie, verwachte Sharpe. Een codegen-fase schrijft de daadwerkelijke strategie, die een mechanische hindernisbaan moet doorstaan voordat er ook maar één dure run plaatsvindt: lint, smoke tests, look-ahead checks, determinisme, parametergebruik. Een adversarial review-fase probeert de code te weerleggen voordat de backtest überhaupt draait. Pas dan gaat de strategie door twaalf wekelijkse out-of-sample windows, walk-forward: fit in-sample, test out-of-sample, één window tegelijk en sorteert een deterministische evidence gate het resultaat in validated, refuted of inconclusive.

Alles wat de loop leert belandt in een append-only geheugen dat in elke toekomstige hypothese geïnjecteerd wordt, en wanneer een cycle als refuted sluit schrijft de loop nu zijn eigen seed voor de volgende en zet hij de lineage voort. De graph is de single source of truth voor dat alles, veertien nodes en hun conditionele edges, opnieuw afgespeeld tegen 1.674 echte cycles met nul overtredingen voordat ik hem iets liet aansturen.

Daarbovenop zit een live dashboard dat die graph tekent terwijl hij draait: welke fase er draait, wat die opgeleverd heeft, wat er misging. Ik bouw er nu een editor omheen zodat ik fases midden in een cycle kan inspecteren en bijstellen, één fase opnieuw kan draaien tegen echte artifacts, en de daadwerkelijke model-turns van elk eerder experiment kan teruglezen.

## De tradeoffs

![1.00](https://media.ninokroesen.com/uploads/2026/08/fb83b844f9e879f49d7c/_1280.jpeg)

### Valideer de validator voordat je hem gebruikt

Voordat ik de loop ook maar één hypothese liet genereren, heb ik de eerste dagen besteed aan het auditen van de backtester zelf. Die audit vond vier echte bugs, waaronder een datalek waarbij een nog vormende candle zijn eigen close kon zien voordat die bestond, en een column-index bug in de optimizer die stilletjes elke kandidaat afwees die hij binnenkreeg. Beide draaiden al in mijn productietooling. Had ik deze stap overgeslagen, dan was alles wat het lab daarna produceerde ruis geweest en had ik dat niet geweten. Het waardevolste eerste product van een autoresearch-setup bleek een audit van zijn eigen meting te zijn.

Twee weken later betaalde dezelfde truc zich uit vanuit de andere richting. Bij het overzetten van mijn productie-gating-logica naar het lab, zodat het lab kon testen wat productie daadwerkelijk doet, kwam er een bug in de productieversie boven water: een bootstrap die de verkeerde serielengte afsneed en daardoor elke positieve kandidaat doorliet die hij juist had moeten filteren. Diezelfde slice-bug zat in meerdere zusterstrategieën. Ik vond hem door het lab productie te laten nabootsen, niet door productie te testen.

### Het model stelt voor, het framework beoordeelt

De inner loop, het stuk waar het model op een kandidaat itereert, draait tegen een bevroren evaluator die hash-pinned is: het model mag hem zo vaak draaien als het wil en elk getal lezen dat hij afdrukt, maar het kan hem niet veranderen, en de pin breekt zodra er iets aan komt. Er is een sanity gate waarbij een vlak signaal zich moet onthouden, zodat een strategie niet kan winnen door simpelweg altijd te traden. Dit is de regel die ik iedereen zou meegeven die zoiets bouwt: het model stelt voor, het framework beoordeelt, en die twee raken elkaar nooit, want een model dat zijn eigen huiswerk mag nakijken, doet dat ook.

### Goedkoop model genereert, duur model weerlegt

Codegeneratie draait op een goedkoop worker-tier model (DeepSeek). Review draait op een duur frontier model (Opus). De invariant is bewust: het goedkope model schrijft, het dure model weerlegt. Het ving vanaf dag één echte defecten, een verkeerde deler in een nettowinstberekening die de self-check van de schrijver zelf had goedgekeurd, en een verkeerde parameter die stilletjes een experiment geruïneerd zou hebben. De prijs is dat review de duurste fase in de loop werd. Een weerlegging vóór de backtest is nog altijd de goedkoopste fout die het systeem kan maken.

### De strateeg ziet de holdouts nooit

Elke "validated" familie werd opnieuw getest door een mens, ik, op onaangeroerde data die de loop nooit gezien had, en de holdout-resultaten gingen nooit terug het geheugen van de loop in. Die firewall houdt de strateeg onbesmet. Hij creëerde ook een blinde vlek: niets kon de loop vertellen om te stoppen met het aanmaken van varianten van een familie die allang dood was, dus één nachtelijke run stapelde tientallen zusjes op in één enkele familie en produceerde zestien gecorreleerde "validations". Eén weddenschap, zestien keer geteld. Wat het erger maakt is dat de eigen research-fase van het lab de monocultuur eerder signaleerde dan ik; hij had er alleen geen enkel mechanisme voor om er iets mee te doen. De fix was mechanisch in plaats van op oordeel gebaseerd: experimenten worden geclusterd op wat ze daadwerkelijk traden, en een cluster heeft een cap.

In de eerste versie mocht het model ook zijn eigen assets kiezen, welke het er maar leuk uit vond zien. Dat is selectiebias per constructie, het model cherry-pickt de markt waar zijn idee toevallig op past. De fix is een vaste basis van achttien assets. Ik weet alleen niet helemaal zeker of achttien het juiste aantal is; het kan een beetje te breed zijn, terwijl het alternatief met één asset te weinig trades opleverde om iets statistisch significants te kunnen zeggen. Die tradeoff staat nog open.

### Eén taal was goedkoper geweest

De adaptieve experimenten fitten een signaal in Go en traden vervolgens de JavaScript-versie, omdat dat de vorm van mijn productiesysteem spiegelt. Elk gegenereerd paar moet door een parity gate die bewijst dat beide implementaties zich identiek gedragen, en die gate is de nummer één doodsoorzaak van codegen-runs. Een model vragen dezelfde logica twee keer te schrijven verdubbelt ruwweg het oppervlak waarop het fout kan gaan, en de gate vangt elk van die fouten ten koste van het hele experiment, tokens, tijd en nauwkeurigheid. Bij een rewrite is single-source, één taal, geen tweeling, de eerste structurele fix die ik zou maken.

## Wat de mislukkingen werkelijk waren

Er zijn ooit zo'n 45 experimenten als validated gemarkeerd. 44 van die 45 dateren van vóór het aanscherpen van de evidence-eisen dat ik half juli doorvoerde, en ze delen één profiel: een hoge Sharpe op twintig tot dertig trades. Zes families kwamen zo ver als een echte holdout, door mij gedraaid, met de hand, op een maand data die de loop nooit had aangeraakt. De holdout-score staat op 0 uit 6.

Ik was al sceptisch over de validated-oordelen voordat de holdouts draaiden; de samples waren klein en dat wist ik. De holdouts bevestigden dat met een consistentie die bijna grappig was. De in-sample ranking werd niet alleen zwakker, hij draaide om: de variant met de meeste filters erop gestapeld, de best geselecteerde van het stel, presteerde out-of-sample het slechtst.

| Wat er getest is                                        | In-sample                                            | Holdout                                           |
| :------------------------------------------------------ | :--------------------------------------------------- | :------------------------------------------------ |
| London-sessie familie, 4 varianten                      | alle vier "validated"                                | allemaal teruggezakt naar nul, ranking omgedraaid |
| Beste statistische profiel in de ledger                 | Sharpe 0,41, profit factor 1,91, 145 trades, p 0,003 | Sharpe 0,01, profit factor 1,01, p 0,48           |
| Eerste adaptieve experiment                             | Sharpe 0,65, profit factor 2,65, 52 trades, p 0,005  | Sharpe −0,24, profit factor 0,75, netto −47       |
| Vroeg "Sharpe 1,71"-signaal, opnieuw gedraaid op schaal | Sharpe 1,71 op één enkel window                      | Sharpe −0,13, p 0,80                              |

![1.00](https://media.ninokroesen.com/uploads/2026/08/de27eb212ae08e23d579/_1280.jpeg)

Het beste profiel in de ledger is degene waar ik steeds op terugkom. De hit rate hield vrijwel exact stand, wat instortte was de payoff. De edge had in de gemiddelde winst per trade gezeten, de meest gelukgevoelige component waar je een argument op kunt bouwen, en niets in de in-sample statistieken zou me dat ooit verteld hebben.

Niets hiervan was luiheid van de gate, wat me langer kostte om te accepteren dan zou moeten. Uiteindelijk heb ik de power-berekening gedaan, en die is meedogenloos. Met een minimum van 60 trades kan de gate alleen een Sharpe per trade van 0,212 of beter bevestigen. De gemeten mediaan van alles wat aan de positieve kant landt is 0,188, met een standaardfout van ongeveer 0,129. Het effect en de foutmarge zijn even groot. Die gelijkheid, niet slordigheid, is waarom 87 experimenten in één exposure cell, dezelfde kant en dezelfde pair set, 41 "validated"-oordelen opleverden en nul holdout-overlevenden. Het antwoord is geen strengere gate. Het is een tweede, goedkopere test van het *mechanisme* met een veel hogere n, conditionele forward returns over elke bar, geen optimizer, geen onthouding, los van de dure test van de strategie. Die staat nog op de lijst.

De subtielere variant van hetzelfde probleem is een kandidaat wiens "signaal" 94% van de tijd bleek samen te vallen met zijn eigen onvoorwaardelijke controle. Hij filterde helemaal niets; hij koos een instapuur. Dat generaliseert naar een gate die het lab nodig heeft en nog niet heeft: elke kandidaat wiens trade-aantal binnen zo'n 10% van zijn controle ligt, hertimet, hij signaleert niet.

Toen werkte de meetkant eindelijk goed en vertelde me de waarheid in één klap. De eerste run op volle schaal waarbij de evaluator elk window daadwerkelijk tradede kwam terug met 3.783 trades over twaalf windows, een nettoresultaat van −17.663, en nul positieve windows. Een eerlijk, ondubbelzinnig verlies, en de goedkope inner evaluator had dezelfde kant op gewezen als de echte engine, wat het enige echt goede nieuws op het hele scorebord is. Het kompas werkt. Er was alleen nog niets goeds om naar te wijzen.

Daarvoor waren er weken waarin het lab vrijwel niets produceerde. Zijn eigen geheugen bevat de diagnose die hij destijds stelde, de gate moet de trades onderdrukken, schreef hij, en die was fout. De echte oorzaak was een sizing-bug in mijn eigen eval kernel die posities op de exotische paren naar nul afrondde. De strategieën waren nooit het probleem; de meting wel. Er was ook een telbug die er bijna de eerste valse bevestiging doorheen kreeg: aangrenzende testwindows deelden een bar op de grens, dus een strategie die daarop triggerde kreeg dezelfde trade twee keer geteld, en het lab was één fix verwijderd van het uitbrengen van een "confirmed" strategie op basis van dubbelgetelde data. Dat was de week waarin het lab leerde dat zijn eigen meting de leugenaar kan zijn.

De reden dat die sizing-bug wekenlang overleefde is het punt van deze hele post. Ik had te weinig inzicht in mijn eigen harness, en de enige output van de loop was proza. Honderden regels model-verhaal lezen over wat er gedaan is, is een snelle manier om mentaal uitgeput te raken, en het laat je geen bug zien. Een graph wel.

Op dit moment is de bottleneck alweer verschoven, naar de generator. Na de laatste geslaagde close begin augustus volgden er 480 opeenvolgende error closes, vrijwel allemaal goedkope codegen-defecten op smoke-niveau, verkeerde parameterranges, gedeclareerde maar ongebruikte parameters, verwijzingen naar helpers die nooit gegenereerd zijn. Ergens onderweg begon het eigen geheugen van het lab zijn generator te vergiftigen: meer opgestapelde learnings betekende langere hypotheses vol constraints, waar de codegenerator (die die learnings nooit ziet) niet aan kon voldoen, waarna de review gate ze afwees. Een feedback loop die vanzelf alleen maar erger wordt.

## Eerlijke kanttekeningen

![1.00](https://media.ninokroesen.com/uploads/2026/08/35f21ef0ea3d4366ff50/_1280.jpeg)

Geen mens buiten mijn eigen setup heeft hier ooit naar gekeken, en dat was bewust. Ik heb de publieke autoresearch-projecten gelezen, die van Karpathy, de Claude Code-port van Driveline, en pi-autoresearch, en de inner eval loop leent zijn vorm openlijk van alle drie: single-file edit scope, een locked scorer, een metric contract dat tussen modelaanroepen door teruggelezen wordt, een noise floor afgeleid van multi-seed variantie, een sanity gate waarbij een vlak signaal zich moet onthouden. Verder heb ik niet veel gelezen, omdat mijn use case heel specifiek is en het toch met mijn eigen ecosysteem moest integreren. Ik denk dat het het beste is om gewoon zelf te proberen en te experimenteren, ook al kan dat snel oplopen tot dure lessen. Ik zou het niet zo goed begrijpen als nu wanneer ik dingen van andere mensen had overgenomen.

Ik moet ook duidelijk zijn over waar dit nooit voor bedoeld was. Ik heb nooit het vertrouwen in dit systeem gehad om iets dat het maakte in productie te zetten, het was altijd onderzoek om te zien hoe ver het model zou komen, en om te leren en op het systeem te itereren. Ik verkoop geen signalen en ik geef geen financieel advies, en het scorebord hierboven is het beste bewijs dat er hier niets te verkopen valt.

En de eerlijke staat van de harness zelf: het is nog steeds niet wat het hoort te zijn. De eval-omgeving moet gehard worden, en ik ben de code nog steeds een grondige duik schuldig in wat het model daadwerkelijk geproduceerd heeft. Ik denk erover om een compleet nieuwe iteratie vanaf de grond op te bouwen, omdat de eerdere experimenten verpest hebben wat ik voor ogen had, vooral aangekoekte rommel in de pipeline, plus het tweelingontwerp met twee talen. Het geheugen kwijtraken zit me niet dwars. Het was nooit een productiesysteem, het was een heel vroeg prototype waar sowieso op geïtereerd moest worden, en het hele geheugen weggooien kost me niets wat ik wil bewaren.

## Waar het nu staat en wat er nu komt

De loop en het dashboard draaien live, en het actieve werk is de fase-editor: het production design is goedgekeurd en de implementatie begint nu. Die maakt de pipeline bewerkbaar en inspecteerbaar, prompt templates per fase die live toegepast worden, knoppen voor model en temperature, sturen welke data een fase mag aanraken, één echte cycle draaien, één fase opnieuw draaien tegen echte artifacts, en per node de daadwerkelijke model-turns van elk eerder experiment doorbladeren. Hij kan ook zelf nieuwe fases genereren: beschrijf een fase, en hij produceert de prompt, de config en de graph-bedrading als een reviewbare draft, zodat ik nooit met de hand nodes hoef te bedraden.

Als ik herbouw en dat doe ik waarschijnlijk, gaan de isolatie en de mechanische gates mee, verder gehard. De aangekoekte rommel gaat eruit. De Go/JavaScript-tweeling ga ik nog eens goed tegen het licht houden, want hij laat de modellen te snel fouten maken, en elk van die fouten kost tokens, tijd en nauwkeurigheid. En de geparkeerde vraag blijft geparkeerd: als discovery ooit een holdout-overlever oplevert, is de lifecycle om er één live te draaien geschetst en klaar om gebouwd te worden, en geen moment eerder. De beslissing over de herbouw wacht zelf op die grondige duik in wat het model daadwerkelijk geschreven heeft.

## Wat ik eruit meeneem

![1.00](https://media.ninokroesen.com/uploads/2026/08/61bafb619ad0cd8f37c5/_1280.jpeg)

Niets hiervan gaat eigenlijk over traden. Geef een agent een loop, en twee dingen bepalen of die loop je de waarheid vertelt.

Het eerste is isolatie, en dat is degene waar iedereen het al over heeft. Het model mag de evaluator zo vaak draaien als het wil en mag hem nooit veranderen, want het alternatief is een systeem dat je scoringsfunctie optimaliseert in plaats van je probleem.

Het tweede komt veel minder ter sprake. Je moet het ding aan het werk kunnen zien. Elke dure fout in deze zes weken, de weken met lege output, de dubbelgetelde trades, het geheugen dat stilletjes zijn eigen generator wurgde, zat de hele tijd in de artifacts en was volledig onzichtbaar in het proza. Een muur van model-output vertelt je wat de loop dénkt dat hij gedaan heeft. Een graph vertelt je wat hij gedaan heeft. Het meeste werk in agentic coding gaat op dit moment naar het model slimmer maken; ik steek het mijne in het kunnen zien ervan, want de bug die je een maand kost is nooit de bug die in de samenvatting staat.


<!-- https://ninokroesen.nl/blog/ta-v200-drie-libraries-op-n-audited-spec -->

---
title: "ta v2.0.0: drie libraries op één audited spec"
date: 2026-05-14T11:07:00.000Z
updated: 2026-10-19T16:07:11.043Z
canonical: https://ninokroesen.nl/blog/ta-v200-drie-libraries-op-n-audited-spec
lang: nl
author: "Nino Kroesen"
---

# ta v2.0.0: drie libraries op één audited spec

Twee weken geleden is ta v2.0.0 uitgebracht — over alle drie de libraries tegelijk. `ta.js`, `ta.py` en `ta.go` zijn alle drie naar dezelfde major version gegaan op dezelfde release cut, met dezelfde honderd-en-zoveel indicator-functies end-to-end geaudit tegen leerboek-formules en met een vergelijkende benchmark in elke taal tegen de libraries waar die specifieke implementatie daadwerkelijk mee concurreert. De reden dat het één version bump is in plaats van drie aparte version bumps, is dat de libraries de laatste paar jaar genoeg uit elkaar waren gegroeid dat ze los van elkaar fixen zou hebben betekend dat ik dezelfde indicator drie keer zou fixen en het alignment-werk daarna alsnog moest doen. Dus dat alignment-werk heb ik eerst gedaan.

De correctheid en snelheid van een technical-analysis library zouden over talen heen moeten reizen, niet alleen een JS-only verhaal moeten zijn. Dezelfde geauditeerde indicators, dezelfde vergelijkende benchmark-methodologie, dezelfde zero-dependency-houding. `ta.js`, `ta.py` en `ta.go` zijn het nu eens over wat een RSI hoort terug te geven, en elk van de drie is gemeten tegen de libraries waar je in die ecosysteem ook daadwerkelijk tegen zou benchmarken.

Ik heb eerder geschreven over de v1.17.0 moderniseringsronde op `ta.js` — de source-layout-opschoning, de `esbuild` bundle-pipeline, de registry-indirectie die het override-patroon behoudt. v2.0.0 is het volgende hoofdstuk van diezelfde library, en het hoofdstuk waarin de libraries in de andere talen eindelijk meekomen op een gedeelde specificatie.

## De vorm

Drie repositories, één library-familie. `ta.js` voor JavaScript, `ta.py` voor Python, `ta.go` voor Go. De repos staan op [github.com/Bitvested/ta.js](https://github.com/Bitvested/ta.js), [github.com/Bitvested/ta.py](https://github.com/Bitvested/ta.py) en [github.com/Bitvested/ta.go](https://github.com/Bitvested/ta.go). Over alle drie heen is het indicator-oppervlak hetzelfde: moving averages, oscillators, bands, volatility-indicators, statistics, chart transforms, rond de honderd functies per library, elk kort genoeg om in één keer door te lezen.

Wat v2.0.0 in eenvoudige termen daadwerkelijk oplevert:

* Een indicator-voor-indicator audit tegen de standaard leerboek-formules, met formule-bugs over alle drie de implementaties heen opgespoord en gefixt.

* Een vergelijkende benchmark per library, waarbij elke implementatie wordt vergeleken met de libraries die in dezelfde ecosysteem met haar concurreren.

* Een bench-harness die in elke repo meekomt en bedoeld is om door iedereen die de cijfers wil verifiëren opnieuw gedraaid te worden — hardware vastgelegd, concurrent-versies gepind.

* Dezelfde zero-runtime-dependency-houding die de libraries vóór v2.0.0 ook al hadden, behouden als harde familiebrede constraint. Geen van deze libraries trekt op runtime een third-party binnen, in geen enkele taal.

## De audit was de onglamoureuze helft

![1.00](https://media.ninokroesen.com/uploads/2026/05/a947c2e9c3f4c231ee3f/_1280.jpeg)

Het startpunt van v2.0.0 was dat ik moest erkennen dat de v1 test suites — over alle drie de libraries, maar het meest gênant in `ta.js` — me eigenlijk niet vertelden of de indicators correct waren. De fixtures waren gegenereerd vanuit de implementaties zelf op het moment dat die implementaties geschreven waren. Als de implementatie toen fout was, dan is de fixture nu fout, en stelde de test niets meer vast dan "de verkeerde output is stabiel verkeerd." Ik ben `ta.js` in 2020 begonnen toen ik indicator-functies voor mijn eigen werk nodig had en ze elk zelf schrijven was de schoonste manier om ze te leren. Sommige van de indicators die ik in die eerste drie weken schreef horen bij wat de audit ving.

Zes indicators in `ta.js` kwamen terug met formule-bugs die in de fixtures gefossiliseerd waren: parabolic SAR, k-means clustering, de Wilder smoothed moving average, ichimoku, momentum oscillator en fractals in price-mode. De smoothed moving average was het schoonste voorbeeld van het patroon. De v1-formule was dimensioneel verkeerd, de fixture was vastgelegd vanuit de verkeerde formule, en een groene test-suite had het verkeerde antwoord jarenlang als correct gecertificeerd. De gecorrigeerde implementatie is kort genoeg om in één oogopslag te lezen:

```js
function smma(data, length=14) {
  const n = data.length;
  if (n < length) return [];
  let seed = 0;
  for (let i = 0; i < length; i++) seed += data[i];
  let prev = seed / length;
  const out = [prev];
  for (let i = length; i < n; i++) {
    prev = prev + (data[i] - prev) / length;
    out.push(prev);
  }
  return out;
}
```

Een length-N SMA-seed, en daarna een Wilder rolling update van `prev + (data[i] - prev) / length` voor de rest van de serie. Diezelfde fix is in `ta.py` en `ta.go` geland, omdat dezelfde kapotte formule in alle drie zat. Het lezen van de audit-notities naast de fixtures is wat me deed beseffen dat de suite zelf het probleem was, niet de indicators die de suite niet wist te markeren.

Ik schaamde me er een beetje voor maar het zit me eigenlijk niet zo dwars. Deze zes zijn van de eerste `ta.js`-indicators die ik ooit heb geschreven, en ik ben sindsdien gegroeid. Ik ben blij dat ik ze nu allemaal heb gevangen. Vóór de audit wist ik al dat er issues zouden zijn die nooit gevangen waren — dat is het soort ding dat je alleen ziet door elke functie naast een leerboek te lezen, en dat is niet het soort pass dat je terloops doet. Het is het soort pass dat je doet zodra je hebt besloten de versie clean te breken.

De cross-language reikwijdte van de audit was het stuk dat ik niet had aangevoeld. `ta.py`'s `rsi`, bijvoorbeeld, was Cutler RSI aan het berekenen — een strict sliding window van de laatste `length-1` delta's — waar het leerboek (en de gecorrigeerde `ta.js`) Wilder smoothing gebruikt, geïnitialiseerd met het gemiddelde van de eerste `length` raw gains en losses. Dezelfde indicator-naam, twee verschillende algoritmes, allebei groen tegen fixtures die uit zichzelf waren vastgelegd. De fix is in `ta.py` geland met een `MIGRATION.md`-entry, en `ta.py`'s `wrsi` is nu een dunne alias voor `rsi` zodat de legacy callers nog resolven.

De audit ging zo snel als het ging omdat ik agentic coding tools had die het proeflezen en het kruisverwijzen voor me deden, werk dat ik anders één indicator per keer met de hand tegen het leerboek had moeten doen. Drie libraries aan formule-auditing, regel voor regel, zou anders weken hebben gevreten. Met die hulp paste het werk in één release-shaped venster waarin ik alle drie de implementaties tegelijk in mijn hoofd kon houden, en dat is de enige reden waarom de multi-language scope op een solo-tijdlijn haalbaar was.

## De bench was de verrassende helft

Toen de audit klaar was en elke indicator gaf wat het leerboek zegt dat het moet geven, was de volgende voor de hand liggende vraag hoe de library eigenlijk presteerde tegen haar concurrenten. Voor zover ik heb kunnen vinden bestaat er geen breed geaccepteerde vergelijkende benchmark voor technical-analysis libraries in geen van deze drie talen met genoeg gestrengheid rond hardware-specificatie en concurrent-versies om reproduceerbaar te zijn. Ik wilde de library meetbaar maken tegen iets anders dan de eigen internals.

Voor `ta.js` was de vergelijkings-set de vanzelfsprekende: `technicalindicators` 3.1.0, `trading-signals` 7.4.3, `@debut/indicators` 1.3.22 en `tulind` 0.8.20. De eerste drie zijn pure-JavaScript libraries; `tulind` is een Node-binding naar een C-library. `tulind` heb ik er bewust ingezet. De praktische vraag die een developer stelt bij het kiezen van een library is "moet ik de native bindings installeren voor de snelheid?" en de enige manier om die vraag eerlijk te beantwoorden is om de vergelijking daadwerkelijk te draaien.

Het resultaat was dat pure-JS `ta.js` 66 van de 67 cross-library cases won bij 100.000 bars op een Apple M3 met Node v25.1.0, inclusief tegen `tulind`. De resterende — Rate of Change — zit op 100k zo'n 22% achter `@debut/indicators`, een constant-factor-gat dat ik nog niet heb dichtgereden en dat ik in een latere ronde oppak. De rest van het veld zit comfortabel daarachter. Ik had min of meer verwacht dat de C-bindings zouden verliezen bij de groottes waarop een echte workload draait — de FFI-marshaling-kost wordt eenmaal per call betaald ongeacht hoeveel rekenwerk de call doet, dus naarmate het werk per call groeit, stapelt de C-tax zich tegen zichzelf op — maar ik had niet verwacht dat de winst zo allesomvattend zou zijn over de rest van het veld. De cijfers zijn quoteerbaar op dezelfde hardware. Verhoudingen reizen tussen machines, absolute ops/sec doen dat niet. De volledige tabel staat op [BENCHMARKS.md](https://github.com/Bitvested/ta.js/blob/main/BENCHMARKS.md) en de reproductiestappen in [bench/README.md](https://github.com/Bitvested/ta.js/blob/main/bench/README.md).

De Python-bench is waar v2.0.0 erachter kwam dat het zichzelf een schoner verhaal vertelde dan het werk eigenlijk dekte. Ik bouwde de `ta.py`-benchmark in de verwachting dat de library competitief zou zijn tegen de C-bound Python-opties op dezelfde manier als `ta.js` was tegen `tulind`. Dat was het niet. De C-bound Python-libraries waren ruwweg honderd keer sneller dan pure-Python `ta.py`. Dat was een tegenvaller, en die heb ik in mijn eigen notes als zodanig opgeschreven voordat ik wist wat ik ermee aan moest.

Wat ik achteraf bedacht, is dat de vergelijking eigenlijk niet eerlijk was. `ta.py` is per ontwerp een pure-Python library, en de zero-runtime-dependency-houding is een familiebrede constraint, geen per-taal voorkeur. C-bindings toevoegen zou `ta.py` niet sneller hebben gemaakt op haar eigen termen; het zou de library hebben veranderd in een wrapper rondom andermans C-library, wat niet de library is die het wil zijn.

De concurrenten die in de bench gepind staan zijn `TA-Lib` 0.4.28, `pandas-ta` 0.3.14b en `finta` 1.3 — één Python-wrapper rondom een C-library, en twee NumPy/pandas-backed implementaties die hun hot loops naar NumPy's C-internals duwen. Er bestaat geen breed-gebruikte pure-Python TA-library in de Python ecosysteem waar ik `ta.py` naast kan zetten zoals `ta.js` naast `technicalindicators` of `trading-signals` zit. De framing dus — dat de juiste as om `ta.py` op te meten pure-Python-tegen-pure-Python is — is een houding, geen gebenchmarkte claim tegen een benoemd veld. Wat de bench in de repo `ta.py` daadwerkelijk tegen meet is het NumPy/C-backed veld waarvan de framing al toegeeft dat het verliezen verwacht, plus een interne naïeve leerboek-baseline die de sliding-window-herschrijvingen moeten verslaan. De bench-methodologie en de gepinde concurrenten staan in [bench/README.md](https://github.com/Bitvested/ta.py/blob/main/bench/README.md); per-run resultaten-tabellen worden bewust niet gecommit, omdat absolute cijfers niet generaliseren over machines en de README van de bench daar zelf expliciet over is.

Ik ben niet aan de Python-bench begonnen vanuit een principiële "vergelijk alleen tegen pure-Python libraries"-houding — ik verwachtte dat `ta.py` competitief zou zijn tegen alles in de ecosysteem, kreeg de C-bound cijfers, en pas daarna ben ik teruggelopen naar de framing hierboven. Als je maximale snelheid in Python nodig hebt en bereid bent een C-dependency aan te nemen, dan zijn de C-bound libraries nog steeds het antwoord. `ta.py` is het antwoord wanneer je dat niet kunt of niet wilt.

`ta.go` volgde hetzelfde patroon als `ta.js` — pure Go, vergeleken tegen de pure-Go alternatieven in de ecosysteem, geen FFI-fratsen. De vergelijkings-set was `markcheno/go-talib` (gepind aan een build uit januari 2025, omdat er geen semver-tag voor bestaat) en `cinar/indicator` 1.3.0. Beide zijn pure Go — `go-talib`, ondanks de naam, is een Go-port van TA-Lib en niet een CGO-wrapper, en dat is de reden waarom de bench schoon draait met `CGO_ENABLED=0`. De bench leeft in een aparte `go.mod` binnen de repo zodat die benchmark-deps niet lekken naar iemands `go.sum` als hij `ta.go` zelf installeert; de gepubliceerde tabel staat op [bench/BENCHMARKS.md](https://github.com/Bitvested/ta.go/blob/main/bench/BENCHMARKS.md) en de reproductiestappen op [bench/README.md](https://github.com/Bitvested/ta.go/blob/main/bench/README.md).

Het resultaat was dat pure-Go `ta.go` op 100k bars elke cross-library case wint of gelijkspeelt. Tegen `markcheno/go-talib` — de pure-Go port van TA-Lib, en dus de moeilijkere van de twee vergelijkingen — is `ta.go` sneller op SMA (1.30×), MACD (1.18×), Bollinger Bands (1.25×) en ATR (1.90×), en binnen run-to-run ruis op EMA en RSI. Tegen `cinar/indicator` wint hij elke indicator regelrecht, met het grootste verschil op RSI bij 3.51× en het kleinste op Bollinger bij 1.34×. De ene uitschieter in de tabel is de 10k Bollinger-regel, waar `ta.go` trager is dan beide concurrenten: `go-talib` slaat de rijen vóór de warm-up bar over en geeft alleen de post-warm-up reeks terug, terwijl `ta.go` en `cinar` allebei de volledige `n-l+1`-rijige serie teruggeven. Die extra boekhouding telt zwaarder op 10k dan op 100k, waar de vergelijking omklapt en `ta.go` ook op Bollinger weer de snelste is. Die regel staat eerlijk in de tabel in plaats van eruit geveegd — het is `ta.go`'s tegenhanger van het Rate of Change-gat op `ta.js`, een klein constant-factor item dat ik liever rapporteer dan verberg.

## Drie libraries, één release

![1.00](https://media.ninokroesen.com/uploads/2026/05/10655a8149a74f2a04f8/_1280.jpeg)

De reden dat v2.0.0 over drie repositories op hetzelfde versienummer uitkomt, is dezelfde reden waarom de audit en de bench de moeite waard waren om überhaupt te doen. Ik heb altijd geprobeerd deze libraries op één lijn te houden — wat `ta.js` `sma` noemt zou dezelfde functie moeten zijn als wat `ta.py` `sma` noemt, met dezelfde default parameters en dezelfde output-vorm. De laatste paar jaar waren ze uit elkaar gedreven, en de drift was van het soort dat zich opstapelt: een fix die in één repo landde landde niet altijd in de andere, en hoe langer dat doorging, hoe duurder het opnieuw op één lijn brengen zou worden.

Dus heb ik het alignment-werk eerst gedaan, voordat ik in de tussentijd opgehoopte open user-issues op de individuele repositories oppakte. Dat is niet de meest user-responsive keuze die ik had kunnen maken — er staan issues in de trackers die het niet in v2.0.0 hebben gehaald — maar het alternatief was elke issue over drie driftende libraries fixen en die daarna alsnog opnieuw alignen. De v2.0.0-audit en het v2.0.0-bench-werk nu eerst doen betekent dat vanaf hier één library fixen en de familie weer op één lijn brengen kleiner werk is dan het zou zijn geweest om alle drie vanaf een v1-startpunt te alignen.

Een opmerking over wat v2.0.0 niet is. Dit zijn geen nieuwe libraries. `ta.py` en `ta.go` zijn bestaande libraries naast `ta.js` die al een tijd deel uitmaken van de familie — wie er eentje gebruikte gebruikte tot nu toe de v1-tijdperk-versie. v2.0.0 is de release die ze omhoog brengt naar een gedeelde geauditeerde specificatie, met een gedeelde bench-methodologie, en ze voor het eerst onder hetzelfde versienummer uitbrengt. Het is voor het eerst dat de drie libraries van begin tot eind met elkaar in lijn zijn.

## Eerlijke kanttekeningen

Dingen waarvan ik weet dat ze nog niet helemaal kloppen aan de v2.0.0-release. Niet als footer; als het deel van de post dat de rest pas geloofwaardig maakt.

Nog geen externe cross-validatie. De bench-harness komt mee in elke repository, de hardware staat gespecificeerd, de concurrent-versies zijn gepind, en iedereen die de repos cloned kan de vergelijking zelf opnieuw draaien. Ik hoop dat iemand dat doet. Op dit moment is de enige persoon die de v2.0.0-cijfers heeft gedraaid ikzelf, en de post is deels een oproep om daar verandering in te brengen. Als je de bench draait en jouw cijfers het oneens zijn met die van mij — op andere hardware, op een andere runtime-versie, met een andere competitor-versie — open een issue. Ik kom er liever nu achter dan nadat de cijfers daar al hadden gestaan alsof iedereen het ermee eens was.

De Python-bench is niet hetzelfde soort bewijs als de ta.js-bench. Er bestaat geen breed-gebruikte pure-Python TA-library om `ta.py` naast te zetten zoals `ta.js` pure-JS-peers heeft, dus de vergelijking die de bench-sectie trekt — pure-Python-tegen-pure-Python — is een houding over hoe een eerlijke benchmark er überhaupt uit zou zien, geen 66-van-67 tegen een benoemd veld. Als dat is waar je voor las, dan heeft de Python-bench dat niet.

De Rate of Change-indicator op `ta.js` zit op 100k bars zo'n 22% achter `@debut/indicators`. Ik heb hem zo uitgebracht in plaats van v2.0.0 ervoor op te houden omdat de rest van de cross-library winsten al uitvoerig waren en het gat op `roc` een constant-factor is dat ik in een latere ronde dicht kan rijden. "Wint 66 van 67" leest slechter dan "wint ze allemaal", maar ik geef de voorkeur aan 66 van 67 eerlijk uitbrengen boven die 67e dramatiseren door de release op de plank te laten liggen. Er zijn nog een paar andere indicators in de familie in vergelijkbare vorm — kleine genoeg marges dat de volgende ronde perf-werk ze zou moeten kunnen wegpoetsen. Ik probeer ze uiteindelijk allemaal te verslaan in plaats van te doen alsof ik dat al doe.

De handonderhouden legacy-minified bundle voor `ta.js` — degene die ouder is dan de `esbuild`-pipeline — komt nog steeds mee met het package. Dat is geen drift-valstrik zoals het er van buitenaf uit zou kunnen zien. Het is een bewuste backwards-compatibility-toezegging aan mensen die dat bestand nog steeds van een CDN trekken in browser-apps die al jaren draaien. Hem verwijderen zou die apps stil breken, en de kosten van dat bestand erbij houden zijn kosten die ik graag betaal. De twee `esbuild`-gegenereerde bundles zijn het moderne pad; het legacy-bestand is het bestaande-gebruikers-niet-breken-pad.

De audit gebeurde alleen omdat de v1-test-suite me eigenlijk niet vertelde wanneer een indicator fout zat. Het is terecht om te vragen waarom dat zo lang duurde om aan het licht te komen, en het eerlijke antwoord is dat de suite groen bleef en ik die langer vertrouwde dan ik had moeten doen. Sommige van de indicators die de suite als correct certificeerde waren al fout sinds de eerste commit erop. Dat is het soort fout dat je niet ziet door alleen naar de test-runner-output te kijken, omdat de runner je al vertelt dat alles in orde is. Je vangt het door de indicators naast het leerboek te lezen, en dat is een aparte pass die pas in v2.0.0 plaatsvond.

## Waar het nu staat, en wat er volgt

`ta.js`, `ta.py` en `ta.go` zijn alle drie live op v2.0.0 en in onderhouds-modus. Ik plan op dit moment geen golf van nieuwe functies op een van de drie. Wat ik wel plan, over de komende maanden, is om door de open issues heen te werken die op de individuele repositories zijn opgehoopt en die het niet in v2.0.0 hebben gehaald. Het patroon wordt sequentieel: fix de library met de meest dringende stapel issues, lijn alle drie weer uit zodat de fixes de familie niet opnieuw uit elkaar laten drijven, ga naar de volgende library, herhaal. Dat is volgens mij de onderhouds-vorm die een multi-language familie daadwerkelijk gezond houdt zonder meer tijd aan alignment-werk dan aan de echte fixes te besteden.

De bench-harness komt mee in elke repo en is bedoeld om daar te blijven leven als forcing function, niet alleen als het artefact achter de v2.0.0-claims. Toekomstige performance-rondes draaien tegen deze. Toekomstige correctheids-fixes worden gevalideerd tegen dezelfde fixtures die de audit heeft opgeleverd. Als de volgende keer dat iemand een issue indient "deze indicator geeft een andere output op deze input" is, geven de regeneration-from-textbook-fixtures en de cross-library-bench me de mogelijkheid om de melding tegen meerdere andere library-implementaties van diezelfde functie te checken. Die triangulatie is wat de bench de moeite waard maakt om als onderdeel van het project mee te dragen in plaats van hem maar één keer voor de aankondiging te draaien.

Als je een van deze libraries op zijn v1-tijdperk-versie hebt gebruikt, dan is de migratie naar v2.0.0 op de formules die de audit heeft gefixt breaking. De output van de indicators die bugs hadden is veranderd, omdat de bugs weg zijn. Daar is geen migratie-script voor — iedereen wiens code de v1-tijdperk-output van die indicators consumeert moet kijken of zijn code afhing van het juiste of het verkeerde antwoord. De release notes in elke repo dragen de lijst. Was je gebruik op indicators die de audit niet heeft gemarkeerd, dan is v2.0.0 een drop-in.

Wat ik eigenlijk uit deze aankondiging wil halen, is dat iemand anders dan ik de bench draait. De cijfers zijn reproduceerbaar. De hardware staat gespecificeerd. De concurrent-versies zijn gepind. Als je een TA-library in een van deze drie talen beheert of gebruikt en je geeft erom dat de vergelijking eerlijk is, dan zit de bench al in de repository en is hij met één commando te draaien. Wat je ook vindt — eens met me, oneens met me, of iets aanstippen dat ik gemist heb — is de input die ik het meeste wil voor v2.0.x. Ik probeer niet de enige persoon te zijn die deze vergelijking met cijfers heeft vastgelegd. Ik probeer de eerste te zijn.


<!-- https://ninokroesen.nl/blog/twee-weken-agentic-coding-in-een-paywalled-saas-categorie -->

---
title: "Twee weken agentic coding in een paywalled SaaS-categorie"
date: 2026-05-06T18:18:00.000Z
updated: 2026-05-06T18:18:49.788Z
canonical: https://ninokroesen.nl/blog/twee-weken-agentic-coding-in-een-paywalled-saas-categorie
lang: nl
author: "Nino Kroesen"
---

# Twee weken agentic coding in een paywalled SaaS-categorie

[Hourly](/hourly) is vandaag, 6 mei 2026, live gegaan in de Mac App Store, naast de directe download vanaf deze site. Hij is gratis, draait volledig op je Mac, vraagt niet om een account, en heeft geen paywall achter een van zijn features. Ik heb hem in ongeveer twee weken gebouwd. Voor deze had ik in acht jaar niets meer geshipped naar een Apple-platform.

De hypothese die ik met de lancering wil testen is simpel. Elke gevestigde speler in de menubalk-tijdregistratie-categorie — WorkingHours, Toggl, Timery — zit achter een paywall in een of andere vorm. De reden dat een categorie als deze vandaag verdedigbaar is, is niet dat de software moeilijk te schrijven is; het is dat de kosten van het schrijven en onderhouden ervan hoog genoeg zijn dat wie hem heeft er ook geld voor kan vragen. Generatieve-AI-tooling heeft die kostenstructuur sneller veranderd dan de SaaS-verdienmodellen die bovenop die categorieën draaien hebben kunnen reageren. Hourly is de goedkoopste empirische test die ik kon draaien op de vraag of die verandering daadwerkelijk is aangekomen voor een kleine Mac-app, of dat hij nog verder weg ligt dan hij van binnenuit lijkt.

Ik heb over dit kader geschreven in [de introductiepost](/blog/introduction) toen het project nog op een roadmap stond. Dit is de empirische opvolger daarvan.

## De vorm

Hourly is een menubalk-tijdregistratie voor macOS. Je start een timer voor een project, de seconden tikken in de menubalk weg, je stopt hem. Eerdere entries worden opgesomd en zijn bewerkbaar. Date-range filters en CSV-export zitten erin. Facturatie is multi-currency. Er is een Pomodoro-modus met break overlays en configureerbare werkherinneringen. Calendar export naar Google Calendar en Apple Calendar. Vijf UI-talen — Engels, Nederlands, Duits, Spaans, Frans. Launch-at-login.

Opslag is lokaal. Alles staat in één JSON-file onder `~/Library/Application Support/Hourly/`. Geen account, geen sync, geen serverzijde, niets verlaat je Mac tenzij je het expliciet exporteert. Nul runtime-dependencies in de build zelf; de enige frameworks die worden aangeroepen zijn die van Apple zelf.

Die feature surface is geen toeval, en de volgende sectie gaat over hoe hij gekozen is.

## Hoe de feature surface gekozen is

Voordat ik de build aan het scopen was, ben ik door wat er daadwerkelijk achter de paywalls zat in de vergelijkbare apps in de Mac App Store gegaan. De Pomodoro-modus, de break overlays, de werkherinnering-pings, de calendar export — dat zijn allemaal features die ik in de betaalde apps zag worden ingezet als premium-tier lokkertjes. Het zijn geen features die ik op een vibes-driven feature list van "wat heeft een tijdregistratie nodig" had geprioriteerd. Het zijn features die ik erin heb gescoped omdat de probe een eerlijke test moet zijn. "Gratis tijdregistratie die minder doet dan de betaalde" is een andere bet dan "gratis tijdregistratie die op feature surface gelijk staat aan de betaalde." De bet die ik daadwerkelijk wil draaien is de tweede.

Dat onderzoek is ook de reden dat de app klein is. De laatst gepackagede build is 5,4 MB op disk. De concurrent-groottes die ik heb gecheckt — WorkingHours op 18,1 MB, Toggl op 16,2 MB, Timery op 98 MB — liggen hoger. Een deel van die kloof komt doordat de concurrenten hun account/sync-infrastructuur aan de clientkant meedragen en Hourly niet. Een deel ervan is dat er geen third-party Swift-dependencies in de build zitten. Hoe dan ook, de grootte is onderdeel van de lean-build bet, en het is een van de dingen waar ik op ga letten zodra installaties beginnen op te duiken in de App Store-rapportages.

## Hoe ik bij een Mac-build zonder Xcode terechtkwam

Dit is het deel van de build waar ik vooraf geen prior op had. Ik werk op een MacBook Air, ik zit op dit moment krap in mijn schijfruimte, en het vooruitzicht om de volledige Xcode-bundle te installeren om een kleine Swift-app te compileren was onaantrekkelijk. Ik had het gedaan als het had gemoeten, maar ik had het niet leuk gevonden.

De agentic coding tools waar ik tijdens de build op leunde, stelden een alternatief voor waarvan ik niet wist dat het haalbaar was: een Swift Package plus een paar honderd regels shellscripts, met alleen de Command Line Tools geïnstalleerd. Geen Xcode. Geen simulator. Geen Interface Builder. `swift build` en `swift test` vanuit de terminal, de rest is shell die `codesign` en `notarytool` aan elkaar knoopt. De dev-loop draait vanuit een teksteditor.

Het kostte wat debugwerk om het werkend te krijgen. Apple's tooling neemt op een paar plekken aan dat je in Xcode zit zonder dat te documenteren, en de test target moest het Command Line Tools framework-pad expliciet pinnen zodat `swift test` XCTest überhaupt kon vinden. Maar zodra het was bedraad, draait het hele ding — build, test, sign, notarize, package — end-to-end vanuit de terminal op een machine die nog nooit Xcode op zich heeft gehad. Die toolchain is het ding dat ik meeneem naar elk toekomstig Mac-project dat ik begin. Op een laptop die krap in zijn geheugen zit was hij de unlock die het bouwen van deze app op deze hardware überhaupt haalbaar maakte.

Ik was op eigen kracht niet bij die toolchain uitgekomen. Ik had gemopperd en Xcode geïnstalleerd. Het feit dat een agentic coding tool de no-Xcode-flow als eersteklas optie naar boven bracht is het soort ding dat niet opduikt in de headline-benchmarks van "heeft het model de code goed geschreven" maar wel opduikt in de daadwerkelijke productiviteit van een build als deze.

## De dual-ship was een midden-build-beslissing

Het oorspronkelijke plan was alleen directe download. Geen Apple Developer-account, geen $99 per jaar, geen App Store-reviewproces. Ik zou notarizen via Developer ID, de `.zip` op deze site hosten, en het daarbij laten.

Dat heb ik halverwege de build veranderd. De these die de lancering bedoeld is te testen, is of een gratis lokale app de naald kan verzetten in een categorie waar de gevestigde spelers in de Mac App Store leven. De App Store mijden zou hebben betekend dat de vergelijking plaatsvond op een surface waar de concurrenten niet zaten. Dus heb ik de $99 betaald, een Apple Developer-account geregistreerd, de App Store Connect-kant opgezet, en een tweede packaging-script naast het bestaande directe-download-script gezet. Dezelfde source, twee output-paden. De repository ship't nu vanuit hetzelfde Swift Package naar beide surfaces.

De directe download blijft in de lancering, en niet als dev-artefact of als fallback. App Store-installatie vereist een Apple ID; directe download niet. Er is een echte privacybewuste gebruiker — en een gebruiker op een account-loze machine — voor wie dat onderscheid uitmaakt. Dat pad had ik sowieso geshipped. De App Store is de toevoeging, niet de ruggengraat.

## Wat de review van Apple eruit haalde

Drie reviewrondes voordat hij werd goedgekeurd. Apple steekt echt moeite in het reviewen van apps, en daar mag ik ze van harte voor prijzen ook al zaten er afwijzingen in.

De eerste afwijzing was een echte. De build die ik had ingestuurd crashte bij opstarten op de machine van de reviewer, op een plek waar ik hem op de mijne niet had zien crashen. Het bewijs zat in de crash log:

```
_assertionFailure
static NSBundle.module.getter
AppStrings.bundle(for:)
PomodoroNotifier.requestAuthorizationIfNeeded()
AppModel.init
HourlyApp.init
```

`Bundle.module` is het Swift-package-mechanisme om bij runtime de resource bundle van een package te bereiken. Hij heeft een eenmalige lazy init die fataal foutgaat als hij de bundle niet kan vinden. Op een verse App Store-installatie kon hij hem niet vinden. Op `swift run` lokaal wel. De reden was een packaging-mismatch tussen wat `swift build -c release` produceert en wat Apple's signing-and-thinning pipeline accepteert: Swift Package Manager produceert een geneste resource bundle, en Apple's pipeline behandelt geneste resource bundles inconsistent genoeg dat de binnenste bij runtime niet betrouwbaar terug te laden is. Een vlakke layout — wat elke Mac-app al decennia ship't — overleeft de pipeline ongedeerd.

De fix was vier regels in het packaging-script die de SwiftPM-vormige resource bundle voor het code signen vlak in de `Contents/Resources/` van de app gooien. De bijbehorende verandering staat aan de leeskant: de bundle resolver probeert nu eerst de vlakke layout, en valt alleen terug op de geneste layout als de app onder `swift run` draait. Die divergentie tussen dev en ship is precies het soort ding dat ik lokaal niet had opgevangen, want de lokale pipeline is precies degene die de fout verbergt. De reviewer van Apple ving hem op omdat de reviewer van Apple de ship-pipeline draait. Ik ben blij dat hij op Apple's machine crashte en niet op die van een gebruiker.

De tweede afwijzing was de grappige. Apple liet me niet de zinnen "No paywall" of "No annoying IAP" gebruiken in de screenshot-tekst van de App Store-listing. Het platform dat zelf via paywalls en in-app purchases verdient, laat je op zijn store de afwezigheid daarvan niet adverteren. Ik schrijf dat als platte mededeling op omdat de ironie zelf de grap is; ik hoef hem niet aan te kleden. De metadata is zonder die tekst opnieuw ingestuurd, en de afwijzing zelf is grofweg de schoonste versie van de these die ik me had kunnen wensen, uitgespeeld als onderdeel van het lanceringsproces.

De derde was meer een verduidelijking dan een afwijzing — Apple wilde een onderbouwing voor een server entitlement waar de app om vroeg. Ik heb die opgeschreven, teruggestuurd, en die ronde was daarmee gesloten.

Het totale review-venster was ongeveer een week.

## Eerlijke caveats

De gebruikersbasis voor de lancering bestaat uit één persoon. Mijzelf. Ik heb de app gebruikt op een freelanceproject waarop ik declarabele uren bijhield — het gereedschap nodig hebben, in de Mac App Store kijken, niets gratis vinden dat het werk deed, en het ding zelf schrijven in plaats van de tol te betalen. Er is geen TestFlight-cohort, geen Hacker News-post, geen forumthread. De lancering is het begin van de feedback loop, niet het einde van een. Het plan vanaf hier is om hem naar een handvol vrienden te sturen waarvan ik weet dat ze hem een week zullen gebruiken en me echte feedback geven richting de volgende versie.

De acht jaar gat voor deze build is reëel. Het laatste Apple-platform-ding dat ik geshipped heb stond in een totaal andere context. Daar koud op terugkomen en in twee weken bij een werkende menubalk-app uitkomen is geen verhaal dat ik op een eerdere iteratie van de toolchain had kunnen vertellen. De agentic coding tools die ik tijdens de build heb gebruikt doen meer van het zware werk dan eerlijk is om weg te laten — vooral op de Apple-specifieke spreuken die je elk een dag of anderhalve dag blokkeren als je er uit oefening bent. Ik heb daar in algemenere zin over geschreven in [de adoption-gap post](/blog/the-adoption-gap); Hourly is daar het concrete voorbeeld van.

Ik ga me wat opgelaten voelen als blijkt dat Hourly een opvallende bug heeft die een echte gebruiker in de eerste week vindt. De repository heeft een test suite, de suite slaagt, maar een lancering met één gebruiker vooraf is precies het soort situatie waarin het ding waar je niet aan dacht om te testen het ding is waar de tweede gebruiker overheen struikelt. Ik hoor het liever wel dan niet.

De $99-per-jaar Apple Developer fee is de enige terugkerende kostenpost waar ik stilletjes baal van, en er is geen schone manier om die terug te verdienen terwijl de app gratis blijft. Een donatielink in de app zelf komt vermoedelijk niet langs Apple's regels. Ik laat dat waarschijnlijk verder met rust en behandel het als de kosten van het experiment.

## Waar het nu staat en wat er hierna komt

![1.00](https://media.ninokroesen.com/uploads/2026/05/d4ffd05d5e154953d7fb/_1280.jpeg)

[Hourly](/hourly) is live op [de Mac App Store](https://apps.apple.com/app/hourly-time-billing-tracker/id6762381291) en als directe download vanaf deze site. De bundle ID is `com.ninokroesen.hourly` als je wilt verifiëren dat het daadwerkelijk de app is waar ik het over heb en niet iemand anders zijn listing.

Wat ik nu ga doen is wachten en kijken. De twee aftakkingen die ik voor mezelf alvast heb getrokken:

* Als de installaties via de App Store wezenlijk bewegen — oftewel, als een gratis no-account lokale app gebruikers kan trekken in een categorie waar de gevestigde spelers geld vragen — landt de hypothese. In dat geval overweeg ik het project open-source te maken. De community zou welkom zijn om bij te dragen, de app is op dit moment oprecht kaal, en een open repo is de natuurlijke vorm voor een tool als deze. Er zit echt opschoonwerk tussen de huidige working copy en een publiceerbare repository, en dat bepaalt mede hoe snel het zou kunnen.

* Als de installaties stilvallen — oftewel, als het gemak van een betaalde app met account, sync en een gepolijste marketingsite zwaarder weegt dan het prijsvoordeel van een gratis lokale — landt de hypothese voor deze categorie niet. In dat geval zou ik de extra moeite van open-sourcen niet nemen. De app blijft gehost op deze site voor de mensen die hem vinden en draait stilletjes door op de App Store totdat Apple of ik hem afserveren. Geen actieve afschrijving; het artefact blijft gewoon staan.

Ben je een Mac-gebruiker die declarabele uren bijhoudt, dan is de installatie één klik vanaf [de projectpagina](/hourly). Vind je een bug of mis je een feature die de app niet heeft, dan is [de support-pagina](/hourly/support) de route. Vrienden waarvan ik weet dat ze hem voor mij gaan binnentrekken zijn niet de enige test set; lezers van deze post zijn nadrukkelijk onderdeel van de test set die de lancering komt verzamelen.

## Het deel dat zich generaliseert

De toolchain-bet is degene die ik meeneem naar elk toekomstig Mac-project dat ik start. Swift Package + Command Line Tools + een paar honderd regels shell — geen Xcode in de loop tenzij ik echt een SwiftUI-preview of een simulator-run wil hebben, en het grootste deel van de tijd wil ik dat niet. Het hele project is vanaf het begin tekstbestanden en versiebeheerbaar, de dev-loop zit in de editor die ik op dat moment toch al gebruik, en de build pipeline is end-to-end controleerbaar zonder de terminal te verlaten. De kost is dat je de paar dingen waar Xcode echt goed in is niet krijgt, en dat je er op de harde manier achter komt waar Apple's verstopte Xcode-veronderstelt-zichzelf-dependencies zitten. Maar zodra die zijn afgehandeld, past het resultaat in dezelfde vorm als een build voor wat dan ook.

Het andere ding dat ik meeneem is minder een toolchain en meer een discipline. Wanneer je een hypothese empirisch test, bepalen de kosten van het eerlijk uitvoeren van die test of je hem überhaupt uitvoert. Als Hourly als gepolijste SaaS had moeten shippen om de SaaS-versus-gratis-lokaal-vraag te testen, had ik mijn ogen gerold en de test niet gedraaid, en was de hypothese een mening gebleven. Twee weken bouwtijd, $99 aan kosten, geen marketing, geen groeiteam — dat is klein genoeg dat ik daadwerkelijk de knoop heb doorgehakt. De meeste van mijn meningen zijn nog steeds meningen omdat ik er geen goedkoop genoeg geworden versie van een test voor heb bedacht. De meningen die in projecten veranderen, zijn de meningen waar dat wel voor gelukt is.


<!-- https://ninokroesen.nl/blog/een-query-van-30-seconden-die-ik-zes-maanden-te-laat-draaide -->

---
title: "Een query van 30 seconden die ik zes maanden te laat draaide"
date: 2026-04-26T15:30:00.000Z
updated: 2026-04-27T20:35:57.759Z
canonical: https://ninokroesen.nl/blog/een-query-van-30-seconden-die-ik-zes-maanden-te-laat-draaide
lang: nl
author: "Nino Kroesen"
---

# Een query van 30 seconden die ik zes maanden te laat draaide

Meer dan zes maanden lang ging de WorkWear4All storefront elke nacht een paar minuten offline. Ik wist dat het gebeurde. Het bureau dat het platform had gebouwd wist het. Onze hosting provider wist het. Drie externe Magento integrators die we op verschillende momenten in die periode raadpleegden wisten het. Geen van hen kon me vertellen waarom, en ik kon de tijd om door te blijven graven niet rechtvaardigen — er stond altijd iets zichtbaarders op de queue, de outage was klein genoeg om op te vangen, en de gedeeltelijke fix die we al hadden draaien was net stabiel genoeg om de urgentie weg te nemen.

De daadwerkelijke oorzaak was een query van dertig seconden tegen `information_schema`. Ik had hem in de eerste maand moeten draaien.

Magento 2 is niet gebouwd voor een catalogus van de omvang die wij draaien. Met 800K+ producten, waarbij elk product dagelijks wordt aangeraakt voor voorraad- en prijssync vanuit leveranciers, kan de indexer de `_cl` changelog tabellen niet sneller leegmaken dan het platform erin schrijft, en de storefront betaalt uiteindelijk voor die mismatch — in ons geval met een korte outage elke nacht, op het moment dat iets in de indexing pipeline het opgaf, herstartte, en opnieuw inhaalde. Het platform zelf geeft geen signaal dat dit gebeurt. Er is geen waarschuwing in de admin UI, geen indexer status die rood kleurt voordat het symptoom op de storefront verschijnt, geen log line die naar de root cause wijst. En de fix — als je hem eenmaal hebt gevonden — staat op minstens drie publieke plekken gedocumenteerd, en geen daarvan komt naar boven als je een Magento expert vraagt om naar het symptoom te kijken.

Dat is het deel van het verhaal dat ik wil opschrijven. Niet "ik vond een slimme fix" — de fix is bekend als je vanuit de operationele kant gaat zoeken. Wat het waard is om te benoemen is dat het antwoord bestaat, dat geen enkele expert die ik vroeg het kon ophalen, en dat dat een failure mode is van het ecosysteem rond het platform die het waard is om eerlijk over te schrijven.

## De vorm van de install

Over de WorkWear4All stack heb ik geschreven in de introductiepost op deze site — multi-store Magento 2 over een half dozijn Europese domeinen (workwear4all.nl, workwear4all.be, workwear4all.de, workwear4all.com, workwear4all.pl en nog een aantal meer gespecialiseerde sub-stores), een gedeelde backend op Apache + Varnish + PHP-FPM + Redis. Het stuk dat voor dit verhaal van belang is, is de catalogus-schaal en het update-patroon.

De catalogus is 800K+ producten, een mix van simple en configurable, opgehaald via de dagelijkse exports van leveranciers. Elk product wordt één keer per dag aangeraakt voor voorraad- en prijssync vanuit de leveranciers-feeds. Dat zijn minstens 800K product updates per dag op het bronniveau, en omdat Magento's catalogus-indexers ingeschreven staan op productwijzigingen — price, category-product, catalogsearch\_fulltext, stock, de lijst gaat door — waaiert elk van die bron-updates uit naar een `_cl`-rij voor elke ingeschreven indexer. Het write-volume per dag in de changelog tabellen loopt op tot in de miljoenen.

De most-pinned indexer was altijd `catalogsearch_fulltext`. Hij was degene die als eerste achterop raakte, het hardst achterop raakte, en bovenaan de indexer status stond zodra er iets misging. Wij zitten op Magento 2.4.7, de minor release direct voor de 2.4.8 default-omschakeling naar Update by Schedule — dus het schedule-mode gedrag dat hieronder beschreven wordt, is iets dat we bewust hebben aangezet, niet iets dat we als default hebben geërfd.

## Wat we als eerste probeerden, en waarom de gedeeltelijke fix het slechtst mogelijke resultaat was

Voordat we bij de daadwerkelijke fix uitkwamen, probeerden we het voor de hand liggende. We installeerden [Advanced Index Manager by Magefine](https://magefine.com/magefine/advanced-index-manager), die het indexing-proces in batches verwerkt zodat hij niet probeert in één tick door de hele changelog heen te kauwen. De indexer werd er stabieler door. De outages werden korter en minder frequent. Ze stopten niet helemaal.

Die gedeeltelijke fix is het moment dat ik wil markeren. Zodra de storefront genoeg overeind stond om niet langer een dagelijkse brand te zijn, viel de druk om de daadwerkelijke oorzaak te vinden weg. De Magefine module leverde ons zes maanden op van "stabiel genoeg dat de outage niets urgents blokkeert" — wat klinkt als een goede uitkomst en achteraf het slechtst mogelijke resultaat is, omdat het wegnemen van de urgentie ook het tijdsbudget wegneemt voor het diepere onderzoek dat het probleem daadwerkelijk had opgelost. We zijn er niet mee gestopt. Het verloor het alleen steeds van de volgende brand.

Ik wist, na zes maanden, dat ik dit niet snel zou vinden. Ik werkte ongeveer net zo lang met Magento 2, en ik wist genoeg om te weten dat zoiets diagnosticeren, zo diep in de indexer pipeline, significant veel tijd zou gaan kosten die ik niet had. Het bureau dat het platform had gebouwd had het niet gevonden. Onze hosting provider, die zelf Magento ervaring heeft, had het niet gevonden. De drie externe integrators die we in die periode hebben aangeschreven hadden het ook niet gevonden. De gesprekken eindigden allemaal op dezelfde manier: iemand keek even, kon zijn vinger er niet op leggen, en ging door.

Achteraf gezien was de diagnose niets meer dan goed naar de database kijken voor een afwijking. Ik weet nog steeds niet zeker waarom niemand — ik zelf incluis, zes maanden lang — dat heeft gedaan.

## Wat er daadwerkelijk gebeurde

De fix is operationeel simpel zodra je hem ziet.

Magento 2's "Update by Schedule" indexing mode is gebouwd rondom materialised view changelogs. Elke indexer subscribet zich op een set source tables; zodra er een rij in een source table wijzigt, wordt er een entry weggeschreven naar een corresponderende `_cl` table voor elke ingeschreven indexer. De indexer cron leest op een tick de nieuwe entries uit elke `_cl` table, verwerkt ze, en ruimt ze op. Het geheel hoort zichzelf in evenwicht te houden: writes stromen de changelog in, de cron draint ze, en de indexes blijven actueel.

Het model gaat ervan uit dat de cron kan bijhouden. Met 800K+ producten die dagelijks worden geüpdatet, tegenover het half dozijn indexers dat ingeschreven staat op productwijzigingen, loopt het write-volume per dag in de changelog tabellen op tot in de miljoenen. De indexer cron, die entries sequentieel via PHP verwerkt, kan op de hardware waar hij op zit niet zo snel drainen. De tabellen groeien. Ze blijven groeien. Elke dagelijkse catalogus-import voegt een laag backlog toe die de cron niet meer gaat inhalen, omdat de import van morgen er al aankomt.

Wat er gebeurt zodra een `_cl` table voorbij de specifieke drempel groeit die de bijbehorende indexer niet meer aankan — te veel geheugen opgeslokt door de in-flight batch, een query timeout, een lock die nooit vrijkomt, een indexer-proces dat door de OOM killer wordt afgeschoten — is dat de indexer uiteindelijk faalt, herstart, en probeert in te halen vanaf waar hij was gebleven. Tijdens die inhaalslag is de storefront kort inconsistent of niet meer responsief, afhankelijk van welke indexer is omgevallen. In ons geval was de most-pinned altijd `catalogsearch_fulltext`, en dat is ook de indexer waarbij een stall het meest zichtbaar is voor een klant, omdat hij de productzoekfunctie van de storefront afsluit.

De diagnose die ik uiteindelijk draaide, was één enkele query tegen `information_schema` die alle `_cl` tables listte op rij-aantal, aflopend gesorteerd. De grootste changelog tabellen kwamen terug op zo'n 902 miljoen rijen — een getal uit mijn hoofd, want ik heb de originele output niet bewaard en de tabellen zijn allang getruncate. De vorm was onmiskenbaar: de indexer cron was niet aan het drainen; hij werd elke dag ingehaald door de catalogus-import van de volgende dag.

## De cron, en wat hij wel en niet oplost

De standaard `index` cron group draait niet op deze server. De schedule-mode incremental processing die hij zou doen — uit `_cl` tables lezen, ze drainen, ze opruimen — is precies het ding dat onze update-volume sowieso niet bijhoudt; de cron group is uitgeschakeld, en een nachtelijke full reindex from source doet het werk waarvan de incremental drain verondersteld werd het te doen. Die nachtelijke run is de cron die ik wil doorlopen.

Hij voert drie operaties uit, in deze volgorde:

1. **Full reindex** — `bin/magento indexer:reindex` herbouwt elke index direct vanuit de source tables, en omzeilt het changelog mechanisme volledig.
2. **Truncate elke** **`_cl`** **table** — zodra de reindex authoritative indexes heeft geproduceerd, zijn de opgehoopte changelog entries obsoleet en is de ruimte die ze innamen dead weight.
3. **Reset elke** **`mview_state`** **cursor** — `UPDATE mview_state SET version_id = 0` voor elke rij. Dit is precies de stap waar de waarschuwingspost van Max Chadwick over gaat; zonder die stap breekt post-truncate changelog tracking in stilte.

De volgorde doet ertoe. Door de reindex eerst te doen, blijven — als de reindex zelf faalt: out-of-memory, lock contention, een query timeout — de opgehoopte changelog entries op hun plek staan en heeft het schedule-mode mechanisme (voor zover het werkt) nog steeds zijn baseline state om op terug te vallen. Als we eerst zouden truncaten en de reindex zou falen, zouden we achterblijven met lege changelog tabellen en indexes in de kapotte staat van vóór de cron, wat strikt slechter is dan waar we begonnen. De destructieve operaties na de reindex sequencen, zet een gedeeltelijke failure om in een silent no-op in plaats van een outage.

Ontdaan van de interne wrapper waar ik hem doorheen draai, zien de operaties er zo uit:

```bash
#!/usr/bin/env bash
set -euo pipefail

# Run from the Magento root, with DB credentials configured (e.g. via
# ~/.my.cnf or environment) so the mysql calls below pick them up.

# 1. Full reindex — rebuild every index directly from source.
php bin/magento indexer:reindex

# 2. Truncate every changelog table; the freshly rebuilt indexes have
#    made the accumulated changelog entries irrelevant.
TABLES=$(mysql -N -e "
  SELECT TABLE_NAME
  FROM information_schema.tables
  WHERE table_schema = DATABASE()
    AND TABLE_NAME REGEXP '_cl\$';
")

for t in $TABLES; do
  mysql -e "TRUNCATE TABLE \`$t\`;"
done

# 3. Reset every mview_state cursor to zero. This is the step Chadwick's
#    warning is about — without it, post-truncate changelog tracking
#    silently breaks.
mysql -e "UPDATE mview_state SET version_id = 0;"
```

Dit draait elke nacht. De storefront is stabiel sinds we het hebben uitgerold, en zelfs na ongeveer een week normale operatie zit de grootste `_cl` table op zo'n 9 miljoen rijen — ruwweg een honderdste van de 902 miljoen die we vonden op het moment van ontdekking. Een paar neveneffecten klaarden in dezelfde periode ook op — het meest opvallend een terugkerend probleem dat we hadden met prijsupdates die niet doorkwamen naar de storefront, waarbij de price indexer in stilte achterop raakte en klanten oude prijzen te zien kregen. Dat is ook gestopt met gebeuren. Ik kan het niet volledig aan de cron toeschrijven — het kan het oorspronkelijke schedule-mode mechanisme zijn geweest dat achterop raakte, het kan gerelateerd zijn geweest aan de Chadwick failure mode voordat de `version_id`-reset op zijn plek stond, het kan een ongerelateerde coïncidentie zijn geweest met een server- of SQL-restart — maar het is niet teruggekomen sinds de huidige setup draait.

Ik wil eerlijk zijn over wat deze fix is. Het is geen root-cause fix. De root cause is dat de indexer-architectuur van Magento 2 niet ontworpen is voor een catalogus van deze omvang met dit update-patroon. De cron koopt tijd door elke nacht als schone lei te behandelen; de onderliggende mismatch tussen het indexing-model van het platform en onze operationele realiteit blijft hetzelfde. Als de catalogus blijft groeien of het dagelijkse update-volume nog verder oploopt, stopt ook dit met werken. De cron is een workaround.

Naast deze fix hoort ook een serieuze waarschuwing. Max Chadwick heeft [een post met de titel "Don't TRUNCATE the \_cl tables"](https://maxchadwick.xyz/blog/magento-enterprise-index-lesson-329) waarin hij — terecht — beargumenteert dat naïef truncaten van de changelog tabellen zonder de `version_id` in `mview_state` te resetten, de install in een staat brengt waarin changelog-based indexing in stilte breekt, en zich manifesteert als updates die nooit de storefront bereiken. De cron hierboven doet de `version_id`-reset expliciet, als stap drie; de reset is het stuk dat de specifieke failure mode van Chadwick afsluit. Een lezer die de truncate-stap kopieert zonder de reset, stelt zichzelf bloot aan precies de bug waarvoor Chadwick waarschuwt.

Er is nog één operationele tradeoff die het waard is om expliciet te benoemen, voorbij de "het is een workaround"-framing hierboven. Met de standaard incremental indexer cron group uitgeschakeld en een nachtelijke full reindex die al het werk doet, worden de indexes overdag niet actueel gehouden — ze halen 's nachts in. Dat betekent dat er een bekend staleness window is van tot vierentwintig uur voor elke catalogus-wijziging die tussen reindex runs in wordt gemaakt. Voor ons update-patroon, waar leveranciers-feeds op een dagelijkse cadans draaien en de storefront ruim tolerant is voor licht verouderde categorie- en zoekresultaten, zijn dat acceptabele kosten. Voor een shop waarbij de catalogus wijzigingen binnen minuten moet weerspiegelen — flash sales, time-limited inventory, alles waar intra-day freshness toe doet — werkt deze setup niet; je zou óf de incremental cron group moeten laten draaien en een andere manier moeten vinden om het changelog-volume af te handelen, óf vaker dan één keer per nacht moeten rebuilden.

De eerlijke conclusie: ik weet nog steeds niet zeker of dit precies de juiste manier is om het aan te pakken. Hij werkt en de uptime is drastisch verbeterd. Die zin is de echte rand van mijn begrip, en de post is met die zin op de pagina nuttiger dan zonder.

## Waarom geen van de experts hem vond

Ik wil terugkomen op het sociale deel van dit verhaal, want dat is het deel dat verder strekt dan deze specifieke bug.

Vijf aparte partijen hebben naar het probleem gekeken voordat ik het oploste. Het bureau dat het platform had gebouwd. Onze hosting provider. Drie externe Magento integrators. Geen van hen kwam met de changelog-table-invalshoek. De fix is niet obscuur — toen ik het achteraf nakeek, stond hij gewoon op de eerste pagina van de zoekresultaten voor "magento truncate \_cl tables." Max Chadwick heeft erover geschreven (er overigens tegen gewaarschuwd). De mgt-commerce knowledge base heeft [een stap-voor-stap tutorial](https://www.mgt-commerce.com/tutorial/magento-2-index-suspended/) die bijna exact de cron doorloopt die ik heb gebouwd. De Magento GitHub repository heeft [een open issue (#29789)](https://github.com/magento/magento2/issues/29789) waarin het probleem upstream wordt erkend. Er is zelfs [een Packagist module](https://packagist.org/packages/aligent/magento2-indexer-fix) die de fix in een extensie verpakt. De fix is gedocumenteerd.

Hij is alleen onbereikbaar vanaf de symptoomkant. Zoek op "magento storefront down at night" of "magento intermittent outage" of "magento indexer stuck" en de changelog-table-invalshoek komt niet naar boven. De expert die je om hulp vraagt komt er vanaf jouw symptoom ook niet, omdat hun mentale model vertrekt vanuit dezelfde set zoektermen als die van jou. De vindbaarheid stort in op de symptoomlaag, niet op de documentatielaag. Het antwoord ligt in het volle zicht onder een zoekterm waar je niet aan hebt gedacht om te proberen, en de experts hebben er niet aan gedacht om hem voor jou te proberen omdat het niet de term is die zij zouden associëren met wat je beschreef.

De les die ik hieruit haal — en wat ik anders had gedaan als ik die zes maanden over kon doen — is: minder tijd aan experts vragen besteden en meer tijd kijken naar wat het platform daadwerkelijk voor zich heeft staan. De query tegen `information_schema` was dertig seconden werk. De Magefine module, die ik in plaats daarvan installeerde, was een echte uitgave en een gedeeltelijke fix die zes maanden zelfgenoegzaamheid opleverde. Eerst naar de database kijken had het grootste deel van die tijd bespaard.

Dit gaat vaker voorkomen, niet minder. Magento 2.4.8 wordt geleverd met een default-wijziging die alle nieuwe indexers out-of-the-box op Update by Schedule zet, en dat is precies de modus waarin dit hele patroon toeslaat. Meer shops staan op het punt een versie van dit verhaal mee te maken.

## Waar dit nu staat

De cron is de operationele modus. Er is geen migratie-tijdlijn. De storefront is stabiel, de indexer houdt het bij, en de fix doet zijn werk.

Op de lange termijn denk ik dat het platform niet de juiste match is voor onze use case en gaan we er iets anders omheen ontwerpen. De vorm die ik in gedachten heb is een A/B-style cutover — het nieuwe systeem starten op een van de kleinere storefronts, bewijzen dat het onder live verkeer werkt, en pas daarna nadenken over de grotere migreren. Onze interne tooling heeft de catalogus-data al in een MongoDB backing store staan, dus de data layer voor het nieuwe systeem ligt er; de storefront en de operationele stukken eromheen niet. Er zijn nog geen vaste plannen.

De details van de vervangingsarchitectuur zijn niet iets dat ik nu al publiekelijk wil vastleggen. Wat ik publiekelijk wel zeg, is wat ik heb leren weg te ontwerpen: een indexer-patroon dat een generiek flexibility-first datamodel materialiseert in een set gedenormaliseerde indexes via een cron die een changelog moet drainen. Die hele vorm — de EAV-naar-indexer pipeline die Magento 2's catalogus-architectuur definieert — is het ding waar de cron in deze post omheen patcht, en het is precies wat ik niet wil meenemen in iets nieuws. Wat ik er wél in ontwerp, komt in een aparte post, zodra er iets draait om naar te wijzen, niet eerder. Ik schrijf de tweede poging liever op nadat hij contact met de realiteit heeft overleefd dan dat ik me van tevoren aan details commit.

## Het deel waar ik steeds op terugkom

Het principe waar ik op dit punt steeds op terugkom, is dat een gedeeltelijke fix die de urgentie wegneemt, slechter is dan helemaal geen fix. De Magefine module was echt een stuk engineering, hij deed echt werk, en hij maakte de storefront stabieler dan hij was geweest. Hij leverde ons ook zes maanden op van "this is fine," en tijdens die zes maanden stopte ik met kijken naar het echte probleem, omdat het echte probleem mij geen slaap meer kostte. De volgende brand wint altijd van de smeulende, en de gedeeltelijke fix is wat de brand tot smeulen terugbrengt.

Ik heb geen schone regel die dit in het volgende systeem voorkomt. Het dichtst dat ik bij iets kan komen is: als iets maandenlang te dragen is geweest maar je niet écht hebt begrepen wat het is, behandel dan de tolerantie zelf als het waarschuwingssignaal. De cron in deze post had vijf maanden eerder moeten bestaan dan hij deed. De reden dat hij dat niet deed, is dat er niets genoeg in brand stond om me ertoe aan te zetten hem te bouwen.


<!-- https://ninokroesen.nl/blog/honderd-technische-indicator-functies-in-javascript -->

---
title: "Honderd technische indicator-functies in JavaScript"
date: 2026-04-26T15:10:00.000Z
updated: 2026-04-27T19:53:41.217Z
canonical: https://ninokroesen.nl/blog/honderd-technische-indicator-functies-in-javascript
lang: nl
author: "Nino Kroesen"
---

# Honderd technische indicator-functies in JavaScript

Mijn eerste open-source project is een library voor technische analyse genaamd `ta.js` — ongeveer honderd indicator-functies in JavaScript, eerste commit op 2020-08-24, v1.17.0 eerder deze week uitgebracht. Ik ben ermee begonnen omdat ik de indicator-functies sowieso voor mijn eigen werk nodig had, en ze allemaal zelf uitschrijven bleek de schoonste manier om ze te leren. De commits van de eerste drie dagen voegden Money Flow Index, Rate of Change en On-Balance Volume toe; de RSI-fix landde vier dagen later; Stochastics twee weken erin. De library werd gebouwd parallel aan mijn werk door het studieboek heen. Ik heb hem gepubliceerd omdat als iemand het echt zou gebruiken, ze issues konden openen op de functies die ik fout had, en die feedback-loop van buitenaf was goedkoper dan wat ik voor mezelf had kunnen bouwen.

De eerlijke lezing van het ding vijfeneenhalf jaar later: ik heb mijn eerste open-source project in JavaScript gebouwd omdat ik toen nog niet wist hoeveel uitvoeringssnelheid uitmaakt in kwantitatieve systemen — de taal bleek verkeerd voor de backtest en goed voor de helft van het werk waar ik nog aan het uitvogelen was wat ik aan het bouwen was. Die tradeoff heb ik aan het begin niet bewust gekozen. Het is iets dat ik later heb geleerd, toen ik backtests op niet-triviale schaal had geprobeerd te draaien en zag dat ze lang genoeg duurden dat de enige eerlijke reactie was om het productiewerk naar een andere stack te verplaatsen. De library bleef waar hij zijn plek nog verdiende, en dat was alles rondom de backtest — data inladen, slicen, een indicator tegen een venster van OHLC plotten in een browsertabblad, itereren op een formule totdat die overeenkwam met wat het studieboek zei dat die moest zijn.

## De vorm

Een stuk of honderd standalone pure functies — moving averages, oscillators, bands, volatiliteits-indicatoren, statistiek, chart-transformaties, een PRNG — elk in zijn eigen bestand, elk kort genoeg om in één keer door te lezen. De kleinste moving-average implementatie is 9 regels JavaScript. RSI is 12. De hele library heeft één devDependency (`esbuild`, voor de bundles) en nul runtime dependencies.

Hij wordt op drie manieren gedistribueerd: het npm-package, een IIFE-bundle gehost op unpkg die je in een HTML-pagina kunt plakken met een `<script src="https://unpkg.com/ta.js/ta.iife.min.js">` en aan kunt roepen als `ta.sma(...)` tegen een browser global, en een ESM-bundle van dezelfde host voor named imports. De IIFE-route is degene die ik nog steeds het meest bruikbaar vind. Elk HTML-bestand wordt zonder build-stap een charting-harness voor een indicator-idee, en dat was de modus waar ik feitelijk het grootste deel van de tijd in zat.

Het enige stuk in de library dat geen pure JavaScript is, is een Monte Carlo `sim` geschreven bovenop Node's `worker_threads`. Die wordt tijdens runtime alleen geladen als Node ≥ 12 wordt gedetecteerd; browsers krijgen er in plaats daarvan een stub voor. De gate is een enkele `if` onderaan de entry-module, die de Node-versie afleest van `process.versions.node` en de worker wel of niet mount. Die voorwaarde is de enige omgevingscheck die de library heeft.

## Waarom JavaScript

JavaScript was de taal waar ik op dat moment het snelst in was, en het was de taal die me de visualisatie-helft van de workflow gratis gaf. Een HTML-pagina met een `<canvas>` en een `<script src="...">` is een charting-harness zonder build-stap, zonder virtuele omgeving, zonder toolchain. Ik kon een CSV in de browser laden, er een slice van doorgeven aan een indicator, en de output zichzelf zien tekenen op een canvas in hetzelfde tabblad waar ik de data open had. Voor het deel van het werk dat ik de meeste dagen feitelijk deed — "produceert deze formule een lijn die er hetzelfde uitziet als de studieboek-versie" — was die loop snel genoeg dat ik er nooit één keer aan heb gedacht om hem te vervangen. De CDN-distributie is op 2020-09-14 opgezet, drie weken na de start van het project. Visualisatie-vanaf-dag-één was de vroegste architecturale beslissing die de library nam. Er is ook een kleine React-companion op [github.com/Bitvested/ta.web](https://github.com/Bitvested/ta.web) die de library wrapt voor chart-gebruik in een React-app; het is niet de canonieke manier om `ta.js` voor visualisatie te gebruiken — de IIFE-drop-in is dat — maar hij bestaat als je al in een React-codebase zit en dezelfde indicator-output naar een charting-component wilt sluizen.

De alternatieven waar de library vandaag de dag tegen gebenchmarkt zou worden zijn Python met NumPy of pandas, een C++ of Rust backtester, of een gehost product dat de backtest voor je draait. Elk daarvan zou een betere keuze zijn geweest voor het productiewerk. Geen daarvan zou me de in-browser-visualisatie-route hebben gegeven zonder meer infrastructuur dan het waard was voor een eerste open-source project, en dat was het deel van het werk dat ik feitelijk aan het doen was. De prijs van het kiezen voor JavaScript was dat het backtest-verhaal tegen een plafond zou gaan lopen dat ik niet had voorzien. Ik liep ertegenaan, haalde mijn schouders op, en heb het productiewerk uit de library gehaald. De library bleef waar hij zijn plek nog verdiende.

## Array erin, array eruit

De API-vorm is over alle honderd-en-zoveel functies hetzelfde: pak een array, geef een array terug. `ta.sma(prices, 14)` eet een array van getallen en geeft een array van SMA's terug. Indicatoren die OHLC nodig hebben nemen een array van twee-element of vier-element arrays. Het hele contract is "geef me de slice van historie die je wilt, krijg het resultaat voor die slice terug."

Het alternatief dat ik niet heb gebouwd was een streaming-API — een indicator-instantie waar je één voor één prijzen in pusht en die op elke push de volgende waarde emit, met zijn interne state gecached. Dat zou het juiste design zijn geweest voor live-tick-verwerking, waar het dure ding het state-keep-alive over ticks heen is in plaats van de wiskunde zelf. Ik heb het overgeslagen omdat het niet aansloot bij hoe ik de library feitelijk gebruikte. Ik laadde een CSV, sliced 'm, gaf de slice aan een indicator door en plotte het resultaat. Een stateful API zou extra oppervlak zijn geweest voor een use-case die ik niet had.

De prijs van de array-in-vorm is dat de library structureel niet geschikt is voor live ticks. Elke call loopt het venster opnieuw door; er is geen incrementele berekening. Voor wie het in een live-loop probeert te gebruiken, is alles rond online updates en feed-integratie aan de aanroeper overgelaten. Dat is de prijs van een onderzoeks-API voor een onderzoeks-use-case.

## Plat voor vijfeneenhalf jaar

Voor bijna de hele levensduur van dit project was de broncode-layout één platte entry-module met elke indicator en elke hulpfunctie geregistreerd tegen één enkel object. Dat was een bewuste keuze. Plat is triviaal greppable. Plat is triviaal overrideable — `ta.ema = myEma` en elke andere indicator die intern `ta.ema` aanroept pakt de override op bij zijn volgende call. Plat is triviaal copy-pasteable in een `<script>`-tag wanneer je iets nieuws wilt prototypen zonder het eerst te publiceren. De platte layout paste beter bij hoe de library werd gebruikt dan een map-structuur dat zou doen.

Dat heeft standgehouden tot deze week. De laatste commit vóór die van deze week was 2024-07-22, dus het project was ongeveer 22 maanden inactief geweest voordat de refactor landde. De refactor zelf was één push van twee uur: de eerste PR splitste elk bestand onder een per-categorie map-structuur, de tweede verving de handgebouwde bundle door een `esbuild`-pipeline. De nieuwe layout is leesbaar op een manier waarop de platte versie dat niet was, maar het override-pattern was zo cruciaal dat het loslaten geen optie was. De fix is een shared indirection: een module van vier regels die een leeg object exporteert, dat de entry-module tijdens het laden vult en waar elk per-function bestand uit leest wanneer het een andere indicator moet aanroepen. De functie-bestanden zien er nu zo uit:

```js
const ta = require('../_registry.js');
function sma(data, length=14) {
  for(var i = length, sma = []; i <= data.length; i++) {
    var avg = ta.sum(data.slice(i-length,i));
    sma.push(avg / length);
  }
  return sma;
}
module.exports = sma;
```

De registry-module is:

```js
module.exports = {};
```

Consumer-overrides propageren nog steeds op dezelfde manier als altijd — de entry-module vult het registry-object tijdens het laden, dus een monkey-patch zoals `ta.sma = myOverride` wordt door elke afhankelijke indicator op zijn volgende call gelezen. De refactor was niet de moeite waard geweest om te shippen zonder dat stuk. v1.17.0 ging dezelfde middag de deur uit als beide PR's, zonder soak-window tussen de refactor en de release. Als er iets in de nieuwe layout fout is op een manier die ik nog niet heb gezien, gaat dat boven water komen via de mensen die het package gebruiken, niet via mij.

## Open source als externe kritische blik

Ik heb deze library niet gepubliceerd omdat ik dacht dat de wereld nog een TA-library nodig had. Ik heb hem gepubliceerd omdat ik wilde dat de functies die ik had geschreven werden bekeken door mensen die de wiskunde beter kenden dan ik. Als ik de definitie van MFI fout zou hebben of de standaardformule voor de stochastische K fout, hoorde ik dat liever via een issue op GitHub dan via een sim die zes maanden later stilletjes was afgedreven van de markt.

Die loop heeft zich daadwerkelijk gesloten. Issues zijn binnengekomen — geen vloedgolf, maar genoeg om implementaties te corrigeren die ik op eigen houtje niet zou hebben gecorrigeerd, en genoeg om me op dingen te wijzen die ik niet wist toen ik de eerste versie schreef. De open-source-houding heeft gedaan wat ik wilde dat het deed: het correctheidsverhaal van de library veranderd van "ik denk dat deze kloppen" naar "andere mensen hebben hier naar gekeken en hebben me verteld wanneer ze niet kloppen." De kostenkant hiervan is degene die de meeste open-source maintainers wel kennen — PR's om te triagen, verwachtingen van gebruikers waar ik niet voor getekend had — maar voor een indicator-library van honderd functies die nooit heeft geprobeerd voorbij zijn oorspronkelijke scope te groeien, is die kost beheersbaar gebleven.

## De tests zijn een regression guard, geen correctheidsverhaal

De tests zijn een platte `assert.deepEqual`-loop over een fixtures-bestand. Geen framework, geen assertion-library, geen setup. Drieëntwintig regels test-runner, één expected-output fixture per indicator, en een `try`/`catch` per fixture die bij een mismatch naar `console.error` logt en doorgaat. De belangrijkste regel ziet er zo uit:

```js
try { assert.deepEqual(ta[x].apply(null, parameters[x].in), parameters[x].out); } catch(e) { console.error('Test failed @ ' + x + '\n'); }
```

Wat dit checkt is "de output van deze indicator op deze fixture is niet veranderd sinds de laatste keer dat ik de fixture heb ingecheckt." Wat het niet checkt is "de output klopt." De fixture is berekend op basis van de implementatie op het moment dat ik hem schreef. Als de implementatie toen fout was, is de fixture nu fout, en de test asserteert dat de foute output stabiel fout is gebleven. Dat is een echte kanttekening. Adversarial test-design had een aantal van de bugs gevangen die in plaats daarvan als issues in mijn inbox landden.

De tweede eerlijke kanttekening over de test-setup is dat de runner exit 0 doet zelfs wanneer een fixture faalt. Fouten gaan naar `console.error` en het proces geeft nog steeds succes terug. CI kan de build niet falen op een regressie zonder stderr te greppen voor de failure-banner, en dat heb ik nooit ingericht. Dat is een bug in de runner, niet in de tests, maar het is een bug die ik niet heb gefixt omdat het me voor een library van deze vorm tot nu toe niets heeft gekost dat ik heb gemerkt.

## De rest van de eerlijke lijst

Dingen waarvan ik weet dat ze niet perfect zijn en die ik niet heb gefixt, in hetzelfde register:

* Er is een hand-onderhouden minified bundle die ouder is dan de `esbuild`-pipeline en die nog steeds met het package meegaat. Het is een derde source of truth naast de twee door `esbuild` gegenereerde bundles, zonder geautomatiseerde regenerator, en hij kan stilletjes uit de pas lopen met de broncode als ik vergeet hem bij een release opnieuw te genereren. Het werk van deze week heeft de andere twee bundles gemoderniseerd; deze ligt nog bij mij.
* Zowel de README als het EXAMPLES-bestand dragen de anchor-lijst van elke indicator in de library. Eén indicator toevoegen is drie gecoördineerde wijzigingen — het indicator-bestand, de README-entry, de EXAMPLES-entry. Dat is genoeg wrijving om bijdragen van mensen die er anders één hadden ingestuurd stilletjes te ontmoedigen.
* De Monte Carlo `sim`-worker roept terug in de main-module via naam in plaats van via referentie — `ta.sum`, `ta.sma`, `ta.std`, `ta.normsinv` — wat betekent dat een rename van een van die functies de simulatie stilletjes breekt. Er is geen type-contract dat dat opvangt. De tests draaien `sim` ook niet end-to-end, dus een gebroken call zou pas boven water komen wanneer een gebruiker een simulatie draait en een fout antwoord krijgt.
* JavaScript zelf is te traag voor een production-grade backtest op enige serieuze schaal. Ik heb dit hierboven al opgeschreven, maar het hoort ook thuis in de eerlijke lijst, omdat iedereen die de library op een niet-triviaal venster van historie gebruikt er tegenaan zal lopen, en het is niet iets dat de library kan fixen zonder op te houden een JavaScript-library te zijn.

Ik heb geen haast gehad om hier iets van op te ruimen. De release van deze week heeft de distributie-pipeline gemoderniseerd omdat dat het deel van het project is dat de mensen die het nog gebruiken daadwerkelijk aanraken. De ruwe randjes hierboven zijn randjes waar ik sinds 2020 mee leef en ze hebben me tot nu toe geen issue gekost die ik niet kon absorberen.

## Waar het nu staat

Ik gebruik deze library minder dan ik jaren geleden deed. Dat is het waard om vooraf te zeggen, omdat het de rest van het antwoord vormgeeft. Het productiewerk rond indicatoren leeft nu op een andere stack. `ta.js` is nog steeds het instrument dat ik pak wanneer ik een formule wil prototypen in een browsertabblad of iemand een `<script src="...">` wil geven om ze te laten zien wat een indicator eigenlijk is. Dat is een smallere rol dan waarmee het is begonnen, maar het is nog steeds een echte rol, en de mensen die het nog gebruiken, gebruiken het voor iets dat dicht bij dezelfde vorm van werk ligt.

De release van deze week ging er niet over om het project weer open te zetten voor actieve feature-development. Het ging erover om de internals up-to-date te brengen voor de mensen die het nog gebruiken — een schonere broncode-layout, een moderne bundle-pipeline, een override-mechanisme dat de refactor overleeft. Ik heb agentic coding tools die me helpen met het nakijken en aanscherpen van de stukken die ik op eigen kracht niet in een redelijke twee uur had kunnen aanscherpen. Waar ik me niet aan heb gecommitteerd is een lijst nieuwe functies om te schrijven. Ik weet nog niet of er veel over zijn die het waard zijn om aan een library op deze scope toe te voegen.

Als er een nieuwe ronde functie-werk op gaat komen, is het ding dat ik het meest wil behouden de oorspronkelijke houding: kleine, copy-pastable indicator-functies, één per bestand, kort genoeg om in één keer door te lezen. Toen ik in 2020 de eerste versie schreef kon ik geen library vinden die paste bij de use-case die ik had — het meeste wat er was voelde bloated, met meer oppervlak dan functie — en de minimalistische vorm van wat ik uiteindelijk heb gepubliceerd was een directe reactie daarop. Wat er ook komt, het moet nog steeds slagen voor de "kan ik dit in een `<script>`-tag plakken en is het op zichzelf logisch"-test. Zo niet, dan voeg ik het liever niet toe.


<!-- https://ninokroesen.nl/blog/een-diamond-painting-webshop-die-de-code-niet-kon-redden -->

---
title: "Een diamond-painting-webshop die de code niet kon redden"
date: 2026-04-26T04:19:00.000Z
updated: 2026-04-28T09:05:40.254Z
canonical: https://ninokroesen.nl/blog/een-diamond-painting-webshop-die-de-code-niet-kon-redden
lang: nl
author: "Nino Kroesen"
---

# Een diamond-painting-webshop die de code niet kon redden

Begin 2026 lanceerde ik een custom diamond-painting-webshop op mijndiamondpainting.nl, deed één verkoop en sloot de webshop binnen een maand weer. De reden dat het ding doodging zat nergens in de code.

De leverancier zat in China, het product was gepersonaliseerd (de klant uploadt een foto, wij printen die op een genummerd canvas dat ze daarna met de hand met diamantjes invullen) en er was geen versie van die combinatie waarin ik de order snel genoeg op een Nederlandse deurmat kreeg om de ene klant die ik had tevreden te stellen, zonder dat de verzendkosten de toch al dunne marge op een instapprijs van €22,95 op zouden vreten. De leverancier was ook niet bepaald goedkoop, en — dat kwam ik pas achter toen de webshop al live was — ze hadden gelogen over de verzendkosten waarop ik die instapprijs had gebaseerd. Ik had geprijsd tegen een fictie. Bij de echte cijfers kwam de rekensom niet uit, en dat ging ook nooit gebeuren.

Alles boven de supply chain was een tractable engineering-probleem. Het meeste daarvan heb ik gebouwd. De leverancier was niet tractable, en de leverancier was het enige onderdeel dat echt moest werken.

## De vorm van het ding

Een server-rendered Node.js-e-commerce-app, volledig Nederlandstalig. Express, EJS, Tailwind, Mongoose op één MongoDB, vanilla JS op de client met CDN-loaded Cropper.js voor het croppen en Chart.js voor de admin-dashboards. De topologie op de bak was Nginx voor TLS en static, Varnish voor Node voor page caching, PM2 met twee "frontend"-cluster-mode-workers voor publiek verkeer en een aparte "backend"-fork-process die de admin-UI en zes cron jobs droeg. Eén Mongo, één disk, één Varnish, één Nginx — maar met een role flag op elk proces zodat admin-routes en jobs niet op de publieke workers gemount werden.

De order-funnel was een state machine die in de server-side sessie van de gebruiker leefde, doorlopen via zes URLs: foto-upload, maatkeuze, een optionele AI-preview, cart, klantgegevens, payment service provider, bevestiging. Een middleware checkte op elke GET de cart-shape en redirectte je door naar de vroegste ontbrekende vereiste. Een tweede middleware migreerde legacy sessie-shapes zodat een een-jaar-oude verlaten sessie nog steeds kon hervatten waar hij gebleven was. Zes background jobs deden abandoned-cart-reminders, image cleanup, social-media scheduling, een AI-optimizer waar ik nog op terugkom, een bot-behaviour-detector en disk-space-monitoring. Eén gedeeld settings-document hield de complete business-config — maten per aspect ratio, quantity-discount-tiers, promotie-regels, engagement-tier-definities, de limieten van de AI-optimizer. Admin redigeerde het; elk ander subsysteem las eruit.

Het was, voor wat het was, een serieus complete webshop.

## Het ding waar ik niet omheen kon programmeren

Ik koos de niche uit een eerdere onderzoekspipeline die ik precies hiervoor had gebouwd — diezelfde die ik apart heb opgeschreven als de [niche-hunt-postmortem](/blog/een-research-pipeline-voor-wat-het-internet-wel-laat-zien). De V1-output van de pipeline zag er verdedigbaar uit: meetbaar zoekvolume, een categorie waar het Nederlandse online aanbod dunner was dan verwacht, een vorm waarin een solo operator met een zelfgebouwde stack een kans had. De pipeline deed zijn werk binnen zijn eigen kaders. Wat hij niet kon zien, was de operationele laag onder de categorie, want daar zat het probleem, en dat begreep ik pas nadat ik daadwerkelijk gelanceerd had.

Het concrete probleem: gepersonaliseerde producten die op aanvraag in het buitenland gemaakt worden. Elke order betekende een foto die in Nederland geüpload werd, omgezet werd naar een genummerd patroon, in China op een canvas geprint en weer terug verscheept. Zelfs in de meest optimistische lane die de leverancier kon quoten was het van deur tot deur weken, geen dagen — lang genoeg dat mijn eerste en enige klant al klaagde over de bezorging voordat iets anders in de flow überhaupt de kans kreeg om kapot te gaan. Elke verzendupgrade die er echt toe deed — betalen voor echte airfreight — vrat de marge op bij een instapprijs van €22,95, waar "marge" al de markup van de leverancier zelf, de fee van de payment processor, BTW en de vaste productiekost per canvas omvatte. De leverancier was om te beginnen niet bijzonder goedkoop; ze waren een van de professionelere opties die ik bekeken had, wat de nette manier is om te zeggen dat de bodem op de unitprijs gezet werd door de goedkoopste optie waarvan ik nog vertrouwde dat ze iets zouden afleveren dat een Nederlandse klant niet meteen retour zou sturen. Onder dat alles zat dan nog de communicatie-frictie van werken met een leverancier aan de andere kant van de wereld. "Kun je bevestigen dat het patroon correct geprint is voordat het verstuurd wordt" was geen vraag waar ik altijd binnen dezelfde week een schoon antwoord op kreeg. De leugen over de verzendkosten was de duidelijkste instantie van datzelfde patroon. Het bedrag dat ze hadden gequoot en waarop ik de retailprijs gebaseerd had, was niet het bedrag dat de leverancier in werkelijkheid in rekening bracht zodra er echte orders gingen lopen, en tegen de tijd dat ik dat doorhad was de retailprijs al live en ankerde hij een hele prijsladder eronder. Een live webshop in prijs naar boven bijstellen is geen zet waarmee je een klein bedrijf herstelt van een slechte uitgangspositie. Het is een zet waarmee je je vroege klanten vertelt dat ze een testronde waren.

En de Nederlandse marktverwachting is geen weken. De Nederlandse marktverwachting wordt gezet door bol.com en de baseline van PostNL-next-day op binnenlandse orders. Die mail over de bezorging kwam binnen weken voordat het product er was, en daar eindigt dat verhaal al. De klantenservice schaalde mee met het aantal orders, en "schaalt mee met het aantal orders" is de verkeerde richting voor een klantenservicekanaal waarvan de taak is de klant uit te leggen dat zijn gepersonaliseerde canvas op een trage boot zit.

Er waren de voor de hand liggende workarounds die ik overwogen heb. Een Nederlandse of Europese leverancier met een magazijn in de EU had de transittijd dramatisch verkort, maar de leveranciers die ik kon vinden printten óf geen gepersonaliseerde canvases óf wilden een unitprijs waardoor de retailprijs in een range terechtkwam waar de categorie niet meer verkoopt. Voorraad aanhouden was geen werkbare optie voor een gepersonaliseerd product — het hele punt is de eigen foto van de klant. Vooruitbetalen voor blanco canvases in bulk en de printstap lokaal doen was een fabrieksproject, geen webshop-project, en dat ging niet binnen hetzelfde kwartaal op het budget van een solo operator gebeuren.

Geen van die workarounds is iets dat code kan oplossen. Het zijn leverancierskeuze- en unit-economics-problemen, en de enige data die ik had die iets waard was, kwam uit het daadwerkelijk runnen van de webshop en kijken waar de eigenlijke dag heen ging. Dat stuk heeft me ruwweg een maand kalendertijd gekost en één canvas dat naar één klant verscheept is — goedkoop schoolgeld, voor wat je eruit leert.

## Tradeoffs die goed waren om de verkeerde redenen

Veel van de project-beslissingen die destijds goed leken, zien er los van elkaar nog steeds goed uit. Pas als je ze naast de supply-chain-realiteit zet, worden het "right tool, wrong problem".

### Alles zelf bouwen

Ik bouwde de webshop vanaf nul op Node in plaats van Shopify plus een configurator-app te pakken. Op de schaal van een solo operator, waar de kosten serverhuur en mijn eigen tijd waren, was dat op zichzelf redelijk. Auth is zes regels middleware die een sessie-boolean checken, gezet door een plaintext-vergelijking tegen een gebruikersnaam en wachtwoord die rechtstreeks uit env vars komen. De factuurgenerator is PDFKit in-process. Abandoned-cart-recovery is een cron job en vier EJS-templates. De zelfgebouwde versie leverde me ook het ene stuk van de funnel waar ik nog steeds van overtuigd ben dat het een echt categorievoordeel was — een live in-flow preview die de geüploade foto van de klant pakte, de pixellation- en palette-mapping-stap deed die het geprinte patroon zou worden, en hun liet zien wat ze daadwerkelijk kochten voordat ze betaalden. Geen van de configurator-apps die ik bekeken had, had me dat laten doen zonder de klant op een embedded iframe van iemand anders zijn tool te dumpen, wat het zicht op de sessie en de abandoned-cart-resume kapot zou hebben gemaakt. Niets in de rest van de stack is best-in-class, maar niets stuurt me een maandelijkse factuur om het te draaien, het hele control surface past in één repo die ik van boven tot beneden kan lezen, en de ene feature die voor de klant het meest uitmaakte was iets dat de zelfgebouwde versie kon shippen en de platformversie niet.

Wat die beslissing me gekost heeft, in de context van wat het project uiteindelijk doodde, is dat ik het tijdsbudget dat naar het upstream-probleem had kunnen gaan — een betere leverancier vinden, of eerder doorhebben dat de categorie er geen had — heb besteed aan het bouwen van een stack die downstream van een kapotte leverancier zat. De twee grootste controllers in de repo waren elk over de tweeduizend regels gegroeid. De codebase is niet klein. Niets ervan maakte de leverancier sneller. De eerlijke splitsing is dat de klantgerichte helft — de funnel, de live preview, de cart, de order flow — zijn waarde op zijn eigen merites verdiende, en dat stuk zou ik op dezelfde manier opnieuw bouwen. Wat ik overbouwd heb was de back office: een AI-prijsoptimizer voor verkeer dat ik niet had, een settings-document dat engagement-tiers en een promotie-ladder modelleerde voor nul betrokken klanten, een bot-behaviour-detector die wachtte op adversarial verkeer dat nooit kwam, een social-publishing-scheduler die posts in de wachtrij zette voor een publiek dat niet bestond. Niets daarvan was nodig om het idee te valideren. Een kale admin waarmee ik producten kon aanmaken, orders kon afhandelen en een lijst kon bekijken, had dezelfde vraag beantwoord — komt de supply chain uit op de prijs die de markt accepteert — voor een fractie van de kalendertijd. Voor een business waar de supply chain de bottleneck is, is het juiste antwoord om de minimale klantgerichte versie te shippen en de back office van een echte webshop pas te bouwen als de webshop er een verdiend heeft.

### Claude aan een leiband

Het interessantste stuk codebase, en het stuk dat ik in een ander project zou meenemen, is een AI-optimizer die op zijn eigen gezag naar het productie-settings-document mocht schrijven en promoties aan mocht maken — binnen een kader. Het kader zat in code, niet in prompts. Elke numerieke output die Claude produceerde, werd geclamped tegen expliciete limieten: een plafond op het engagement-discount-percentage, een plafond op het promotion-discount-percentage, een cap op hoeveel promoties tegelijk actief mochten zijn, een cap op hoe lang één promotie mocht lopen. Daarbovenop zat een minimum-tijd-tussen-veranderingen-cooldown, en de applier hield een md5-hash bij van elke toegepaste tier-config en weigerde een config opnieuw toe te passen die hij in de laatste drie runs al gezien had, omdat de eerste versie van het ding op elke cyclus tussen tiers heen-en-weer flipte. De anti-oscillatiecheck was de lelijkste zes regels in de repo, en de meest dragende.

De houding, op papier: de prompt is een suggestie; de code is het contract. De system prompt vertelde het model "verander niets dat te recent is". De applier ging er vanuit dat hij het toch zou proberen, en checkte de timestamps zelf. Dat is de leiband, en dat is het patroon dat ik overal opnieuw zou shippen waar ik een model productie-state laat aanraken.

De eerlijke beperking aan dit verhaal: ik heb de optimizer nooit in auto-apply mode gedraaid tegen echt klantverkeer op een volume dat het waard was om over te praten. De leiband was gebouwd. Het ding waar de leiband voor was, kwam nooit opdagen. In een ander project, met een echte bottleneck waar een LLM daadwerkelijk bij kan helpen, zou ik exact dit patroon shippen — harde caps, een cooldown, idempotency by hash, het uitgangspunt dat de prompt adviserend is en de clamps niet. Maar ik kan je niet vertellen "kijk hoe het me in productie gered heeft." Ik kan je alleen vertellen dat het patroon generaliseert, en het is het ene stuk van deze webshop dat ik in het volgende ding ga liften dat een model state mag laten aanraken.

### Checkout als server-side sessie

De andere beslissing die ik zonder voorbehoud zou herhalen, is de hele checkout server-rendered houden met de cart binnen de server-side sessie van de gebruiker. Geen cart-API, geen client-side cart-store, geen hydration-bundle die naar de browser gestuurd wordt. Omdat de sessie de waarheid is, was een stapel features die op een React-stack elk een project op zich zouden zijn geweest, allemaal vijf-regelige edits op één shape. Cart sharing — kopieer een link, de andere persoon landt in jouw cart met het item geconfigureerd — is een shared-cart-document dat aan de ontvangerskant terug-deserialiseert in een sessie. Abandoned-cart-recovery is een JWT-magic-link in een mail die de sessie opnieuw plant en de bezoeker twee stappen verder dropt dan waar hij gebleven was. Re-cropping ter plekke op een al-toegevoegd item is het item bewerken in de cart-array van de sessie en redirecten. Elke "feature" die ik bovenop een cart-API op een SPA had moeten bouwen, was een trivialiteit van een edit op de sessie-shape. Dat patroon — de server-side sessie is de app-state, en multi-step-flows horen daar te leven — neem ik mee naar elk toekomstig project met een hervatbare of deelbare multi-step-flow, e-commerce of niet.

## Eerlijke voorbehouden

Er zijn geen geautomatiseerde tests. Niet voor de prijsberekening, niet voor de webhook van de payment service provider, niet voor de abandoned-cart-scheduler, niet voor de apply-stap van de AI-optimizer. De cart-prijsberekening-functie is één procedure van 170 regels die per-maat-promoties, quantity-tiers, sitewide promoties, engagement-tiers, verzending en een BTW-reverse-charge-tak op elkaar stapelt, en er staat geen enkele assertion in de hele repo die ook maar iets daarvan checkt. De vervanging was dat ik vóór het live gaan met de hand door de funnel liep voor een handvol scenario's — verschillende maten, promotie-combinaties, abandoned-cart-resumes, BTW-aan- en BTW-uit-paden. De redenering destijds was dat zolang de webshop nog überhaupt geen verkoop gedaan had, een volledige Playwright- of Puppeteer-suite over de hele flow moeilijk te verdedigen was tegen de heel reële kans dat de webshop nooit een tweede order zou zien. Gegeven hoe die weddenschap is uitgedraaid was de keuze in elk geval intern consistent. Het is geen patroon dat ik als algemeen principe zou verdedigen, en bij een rewrite — of op het moment dat het volume het zou rechtvaardigen — is het het eerste dat ik zou toevoegen.

Admin-auth is de plaintext-env-var-vergelijking die ik hierboven beschreef. Prima voor één persoon, gênant in een verslag. Geen 2FA, geen audit trail, geen rotatie-verhaal anders dan SSH'en naar de bak en het env-bestand met de hand bewerken.

De "uitkomstmeting" van de AI-optimizer leest visit- en order-aantallen vanaf de timestamp van de run en stempelt before/after op het run-record. Geen holdout group, geen statistische test, geen correctie voor dag-van-de-week of voor veranderingen in advertentiebudget. Als ik dat in een post "data-driven" zou noemen, zou het woord "data" nogal wat te tillen hebben.

De meeste features op de webshop — de concurrent-scraper die op Puppeteer draait, de social-publishing-scheduler, de AI-image-generation-admintool, de optimizer zelf — hebben nooit adversarial verkeer gezien, want adversarial verkeer kwam nooit. Eén verkoop is geen load test. Ik kan je vertellen dat deze systemen op happy-path-dev werken. Ik kan je niet vertellen hoe ze zich gedragen onder welke versie van verkeer dan ook die ze interessant zou maken.

De pre-live-checklist had bij shutdown nog niet-aangevinkte items: HSTS-header, een Varnish-HIT-verificatieronde, een rate-limiter-stress-test, een 401-probe op de niet-geauthenticeerde admin-routes. Ik heb de webshop met die gaten gedraaid op de gok dat het verkeersvolume ze niet zou vinden voor ik de kans had om ze te dichten. Ik kwam ermee weg omdat het volume nooit kwam, wat niet hetzelfde is als dat de gok klopte.

En — dit is het ding dat ik eerder had moeten zien — de laatste week aan commits voordat de webshop stilviel zijn allemaal mobile-overflow-fixes en een "Vanaf €22,95"-pill op de homepage hero, voortgekomen uit een CRO-onderzoeksdocument over waar op de pagina je de prijs moet tonen voor een conversielift op een landingspagina. Die volgorde was precies omgekeerd. Ik was het stuk van de funnel aan het polijsten dat al werkte, omdat dat stuk binnen mijn controle lag, in plaats van te duwen op het stuk dat dat niet was.

## Waar het nu staat

Dicht. De repo is naar een archief-directory op disk verplaatst en er is geen plan om hem weer open te trekken. Ik heb hem niet verwijderd, omdat de code zelf herbruikbaar is — specifiek de checkout-state-machine, het cart-as-session-patroon en de LLM-on-a-leash-optimizer — en ik die liever in het volgende ding lift dan ze vanaf nul te herschrijven.

De beslissing om hem niet weer open te trekken gaat eigenlijk niet over de code. Het gaat erover dat ik een maand de winkel heb gerund en heb gekeken waar mijn dagen daadwerkelijk heen gingen. De meeste uren waren geen ontwikkeluren, het waren klantenservice-uren over verzending, het managen van de verwachtingen van een klant wiens order op een boot zat. Dat is de baan waar het runnen van deze webshop op enig betekenisvol orderniveau op uit zou komen, en die baan wil ik niet. De [nicheselectie-pipeline die ik apart heb opgeschreven](/blog/een-research-pipeline-voor-wat-het-internet-wel-laat-zien), had me naar een andere niche kunnen wijzen en de code die ik hier geschreven heb, had daarop aangepast kunnen worden; wat niet aan te passen is, is dat ik nu weet dat ik niet op de stoel van de e-commerce-operator wil zitten. Dat is een goedkopere les om uit een maand te halen dan uit zes, en dat de webshop zijn waarde daarmee heeft verdiend — als het ding dat me dat geleerd heeft — is waarschijnlijk de eerlijke opbrengst van het project.

Als je een D2C-webshop voor een gepersonaliseerd product aan het bouwen bent op een leverancier met lange lead times en de rekensom op de instapprijs duidelijk niet uitkomt — pauzeer voordat je een maand aan de frontend besteedt. De frontend is niet de bottleneck. De frontend is nooit de bottleneck op een webshop waar de supply chain een probleem van deze vorm heeft. De goedkoopste versie van het experiment is een gesprek met de leverancier, een ruwe verzendquote en een eerlijke blik op of de unit economics overleven op de prijs die de markt daadwerkelijk accepteert. Doen ze dat niet, dan gaan geen "Vanaf €22,95"-pills je redden.

## Wat ik meeneem naar het volgende project

Het leiband-patroon — harde caps, een cooldown, idempotency by hash, in code in plaats van in de prompt — voor elk toekomstig systeem dat een LLM productie-state laat aanraken. Dat is het ene stuk van de webshop waarvan ik het meest overtuigd ben dat het meereist.

De server-side sessie als app-state — voor elke multi-step-flow die hervatbaarheid, delen of recovery nodig heeft. Het feit dat de sessie autoritatief is, verandert een stapel "features" in one-liner-edits op de shape, en hoe langer ik aan webprojecten werk, hoe vaker ik mezelf betrap op een grijp naar een client-side store waar een server-side sessie de hele klus al gedaan zou hebben.

De volgorde van de checklist — supply chain eerst, frontend laatst — op alles wat eigenlijk een fysiek-product-business is verkleed als webproject. De code is bijna nooit het ding. De code was hier niet het ding, en ik heb een maand gedaan alsof.


<!-- https://ninokroesen.nl/blog/agentic-coding-vergroot-de-kloof-voordat-hij-krimpt -->

---
title: "Agentic coding vergroot de kloof voordat hij krimpt"
date: 2026-04-25T14:10:00.000Z
updated: 2026-04-28T09:05:40.097Z
canonical: https://ninokroesen.nl/blog/agentic-coding-vergroot-de-kloof-voordat-hij-krimpt
lang: nl
author: "Nino Kroesen"
---

# Agentic coding vergroot de kloof voordat hij krimpt

Ik was sceptisch tijdens GPT-3.5 en GPT-4. Chat in een zijbalk was autocomplete met extra stappen — handig voor een alinea hier of een snelle lookup, niet handig voor het echte werk van software bouwen en draaien. Ik bleef wachten op het ding waarvan iedereen behalve ik volhield dat het al waar was, en het kwam niet. Wat er ongeveer een jaar later wel kwam was een ander primitive: agentic coding loops, waarbij het model een kleine set tools aanstuurt — lees een file, bewerk een file, draai een test, lees de error — in plaats van alleen tekst produceren. Dat is de versie waar ik op ben omgedraaid, en het is de versie waar de rest van deze post over gaat.

Agentic coding is een voordeel dat zich opstapelt voor developers die de vorm van het werk al kennen, en een information overload voor degenen die dat nog niet doen — en de kloof die dat creëert gaat groter worden voordat hij krimpt. Ik denk niet dat mijn eigen werk net zo efficiënt zou zijn als ik nu pas met coderen begon. De tool is een force multiplier op een bestaand mental model; het mental model is wat je vertelt wanneer de agent vol vertrouwen verkeerd zit, en het mental model is het dure ingrediënt, niet het model.

## De algehele vorm

Bijna alles wat op dit moment op deze blog staat is gebouwd met een agent die naast me zat. Het WorkWear4All Magento 2 cluster is het hoofdbaan-stuk — een multi-store backend oud genoeg om een long tail aan operationele randen te hebben gekregen, waar agentic coding tools de manier zijn waarop ik door een codebase heen beweeg waarvan noch ik noch een van de juniors het meeste hebben geschreven. [Hourly](/hourly) is een menubalk-macOS time tracker in SwiftUI, en SwiftUI is een stack waar ik voor dat project fris in stapte. [`mijndiamondpainting.nl`](/blog/een-diamond-painting-webshop-die-de-code-niet-kon-redden) was een Nederlandse webshop die ik heb gelanceerd en heb stopgezet, en de hele frontend van die shop — de Cropper.js upload flow, admin dashboards, de state-machine order funnel — is werk dat ik in dat tempo nooit zelf had geproduceerd. De [AI-agent experimenten die ik aan het herwerken ben](/blog/een-agent-gebouwd-rond-het-niet-aanroepen-van-de-llm) zitten daarnaast; de [niche-hunt pipeline waar ik apart over heb geschreven](/blog/een-research-pipeline-voor-wat-het-internet-wel-laat-zien) is er nog eentje. De site die je nu leest is zelf een Express/EJS/Tailwind app op dezelfde manier gebouwd.

In geen van die gevallen produceert de agent in zijn eentje een voltooid systeem. Hij produceert het scaffold, de eerste eerlijke draft, de onderdelen waar ik anders de meeste tijd in had gestoken en het minst van had genoten. Wat hij niet produceert is het oordeel over of het scaffold überhaupt de juiste vorm heeft, of dat de eerste draft op een stille bug zit. Dat oordeel is van mij, en dat is wat beter moet worden naarmate de agent sneller wordt.

## Waarom de scepticus omdraaide

Het GPT-3.5- en GPT-4-chattijdperk faalde voor mij op een specifieke as: het kon plausibel ogende code produceren, maar het kon niet het werk doen van die code daadwerkelijk draaien, de error lezen en het opnieuw proberen. Elke iteratie vroeg om mij als de handen — paste in de editor, run, paste de error terug in de chat, lees, paste. Het model was snel maar de loop was traag, en de loop is het ding dat ertoe doet bij echt werk. Wat er aan agentic loops anders aanvoelde was dat de tool layer naar binnen in de loop verschoof. Het model bewerkt een file, draait de test, leest de stack trace, bewerkt opnieuw. Ik ben nog steeds de reviewer, maar ik ben niet ook de koerier.

De caveat waar ik steeds op terugkom is dat de huidige agent-abonnementen vrijwel zeker gesubsidieerd zijn tegen de echte inference cost van de frontier-modellen die erachter zitten. Die rekening ligt érgens — de vraag is of de prijs die de individuele developer ziet de prijs is waar de economics van het ding uiteindelijk op uitkomt. Ik denk van niet. De enige versie van dit verhaal die structureel gezond blijft, is er één waarin kleine, lokaal draaiende modellen genoeg van de capability gap dichten om de hot path goedkoop te draaien, en de recente vooruitgang aan de kleine-model kant is genoeg geweest dat ik die bet serieus neem. Ik heb [de vorm van die bet al op een ander project](/blog/een-agent-gebouwd-rond-het-niet-aanroepen-van-de-llm) opgeschreven. De korte versie is: behandel het model als één aanroeper in een systeem, bouw er goede tools omheen die hij kan gebruiken, en het verschil tussen een frontier-scale model en een kleiner model krimpt sneller dan je zou verwachten.

## Waar de agent zijn brood verdient

Frontend design is de eerste plek. Ik ben er niet goed in, ik ben nooit tevreden met het resultaat, en de tijd die ik er vroeger in stak om iets presentabel te krijgen was enorm. Op `mijndiamondpainting.nl` is de volledige publieke shop — de order funnel over zes URL's, de foto-upload met Cropper.js, de admin met Chart.js dashboards, een Tailwind-laag die ik niet hand-tuned hoefde te maken, abandoned-cart e-mail templates — werk dat ik op eigen kracht of had overgeslagen of op een zichtbaar lagere kwaliteitslat had geleverd. Niet omdat een van die onderdelen op zichzelf moeilijk is, maar omdat ik bij iteratie vier op zou hebben gegeven en iets lelijks zou hebben geshipped. Met een agent en een duidelijke richting van wat ik probeerde te bereiken, plus een paar voorbeelden om de esthetiek te ankeren, heeft de frontend design me echt honderden uren bespaard. Dat getal is een schatting, geen meting, maar het is de juiste orde van grootte voor een jaar bouwen op de manier waarop ik aan het bouwen ben.

Een nieuw project scaffolden is de tweede. Ik heb nooit eigen boilerplate templates gemaakt, en ik kies bewust om de zoveel tijd een ander framework omdat de constraint interessant is en ik niet in één stack wil verkalken. Die combinatie betekende vroeger een lange, saaie eerste week van elk project waarin er niets gebeurde behalve copy-pasten van het vorige ding. Nu komt het scaffold in een middag binnen, correct genoeg om er meningen over te kunnen vormen. Die meningen zijn juist het deel waar ik mijn tijd aan wilde besteden.

Nieuwe dingen leren is de derde, en Hourly is het geval waar dit het meeste uitmaakt. SwiftUI, AppKit menubalk-glue, de Mac App Store build pipeline, code signing — de hele klif die voor iedereen ligt die nieuw is in Apple-platform development. Ik heb genoeg software in genoeg talen geshipped dat de concepten zich laten vertalen, maar de specifieke spreuken niet, en het Apple-ecosysteem is het soort plek waar de specifieke spreuk het ding is dat je anderhalve dag blokkeert. Direct werkende code kunnen genereren — vaak in één keer goed, soms na een ronde correctie — is wat het lanceren van Hourly daadwerkelijk heeft laten gebeuren op een tijdlijn die ik bij een side project zou overwegen. Zonder dat had ik vermoedelijk nog steeds vastgezeten in een of ander signing-configuration dialoogvenster.

Bij elk daarvan staat er een kostenpost naast de besparing. Gegenereerde frontend is zelden rigoureus op het vlak van accessibility of performance tenzij ik terugga en hem audit, en ik moet eraan denken om terug te gaan. Scaffolden in een framework dat ik weinig heb gebruikt is snel, maar het kan me stilletjes vastleggen op keuzes waarvan ik niet doorhad dat het keuzes waren — de meest recente die ik heb opgemerkt was een packaging-conventie die ik anders zou hebben opgelost als ik hem eerder had gezien, en die ik überhaupt niet had opgemerkt als de agent er niet voor de tweede keer tegenaan was gelopen en het naar boven had gebracht. Learning-while-shipping betekent dat ik code aan het opbouwen ben die ik minder goed begrijp dan code die ik zelf heb geschreven, wat prima is tot het dat niet meer is.

## Waarom achtergrond nu juist meer uitmaakt, niet minder

De ongelijkheidsclaim is degene die ik daadwerkelijk wil verdedigen. De agent is een force multiplier, en force multipliers vermenigvuldigen waar ze ook maar op gericht worden. Als je weet hoe "goed" eruitziet in de stack — de conventies, de idiomen van het framework, de vorm van een gezonde codebase, het soort error dat meestal betekent wat hij zegt te betekenen en het soort dat meestal iets anders betekent — versnelt de agent je omdat hij genereert, en jij opvangt en corrigeert. De feedback loop is snel omdat jij snel bent.

Als je nog niet weet hoe "goed" eruitziet — omdat je net begint, of omdat de stack echt nieuw voor je is en je de smaak ervoor nog niet hebt opgebouwd — is dezelfde tool een information overload. Hij produceert vrolijk twintig regels code die naar vier conventies verwijzen die je niet herkent, drie utilities aanroepen waar je nog nooit van hebt gehoord, en op een architectuurbeslissing zitten waar jij nog niet klaar voor bent om mee in discussie te gaan. Je kunt de hallucinaties niet opvangen omdat je ze nog niet kunt ruiken, en je kunt niet in discussie gaan met de structurele keuzes omdat je niet de ervaring hebt die je zou vertellen om in discussie te gaan. Wat je wel kunt doen is het ding shippen, en dat is het probleem. Vol vertrouwen verkeerde code, geshipped door iemand die nog niet doorheeft dat hij vol vertrouwen verkeerd is, is de failure mode, en het is de failure mode die de tool makkelijker maakt, niet moeilijker.

Ik schrijf dit niet om afwijzend te zijn over mensen die net beginnen. Ik schrijf het omdat ik me herinner hoe het was om niet te weten hoe "goed" eruitziet, en ik weet hoe het zou hebben gevoeld om een tool aangereikt te krijgen die plausibel ogende code sneller produceerde dan ik er een mening over kon vormen. De eerlijke lezing is dat dit nu juist moeilijker is om op te leren, niet makkelijker, en de kloof tussen mensen die het op de langzame manier hebben geleerd en mensen die het op de snelle manier gaan proberen te leren gaat een tijd duren voordat hij dichtgaat — als hij überhaupt dichtgaat. De force multiplier op achtergrond werkt sterker bovenin de curve dan onderin.

## De eerlijke caveats

Ik heb wat mentale vermoeidheid ervaren die ik niet had verwacht. De agent gaat snel genoeg dat hij me dwingt om beslissingen over de volgende stap sneller te nemen dan ik gewend ben, en het cumulatieve effect over een dag dichte werk heen is reëel. Het is een ander soort moe dan code met de hand schrijven — minder typen, meer oordeel per minuut, en oordeel is de dure resource. Het is vooral erg aan het begin van een project met veel onbekenden, of op een bestaande codebase met een hoop dependencies die in de vorm ervan zijn ingebakken.

Ik heb de agent prima werkende code zien breken in precies het soort plek waar de context rond WorkWear4All voor waarschuwde. Magento 2 is geen codebase waar een module netjes in isolatie bewerkt kan worden; de issues waar je tegenaan loopt zijn vaak het soort dat lastig te onderzoeken is zonder in aangrenzende componenten van de stack te duiken om ze uit te sluiten. Een agent die vol vertrouwen een module bewerkt die hij half heeft begrepen, zonder de indexers te draaien of te kijken wat de cache layer doet, is heel goed in het introduceren van een stille downstream break die pas opduikt wanneer een admin-user twee dagen later opmerkt dat een productprijs niet klopt. Dat is mij overkomen. De diagnose was een nachtmerrie want de voor de hand liggende plek om te kijken was niet de plek waar het probleem vandaan was gekomen, en op het moment dat het symptoom aan de oppervlakte kwam was ik mijn aandacht voor de oorspronkelijke wijziging al lang kwijt.

Hallucinaties zijn nog steeds reëel. Ik denk dat dit deels een skill issue is, in de zin dat als je de agent een vage taak met slechte context geeft, je vage output met slechte accuracy krijgt, en hetzelfde zou gelden voor een junior developer aan wie hetzelfde ticket wordt overhandigd. De fix daarop is prompting en context, en dat is het deel van het werk waar ik nog actief beter in word. Het deel dat geen skill issue is, is de failure mode waarbij de agent vol vertrouwen verkeerd zit over iets specifieks — de vorm van een library API, het gedrag van een framework in een corner case, een syntax-detail — omdat het ding waar hij vol vertrouwen in zit is wat hij heel vaak heeft gezien tijdens training, niet wat de library daadwerkelijk doet in de versie waar ik op zit. Dat zijn de gevallen die je moet opvangen met je eigen kennis van de stack, wat het argument terugbrengt naar de hoofdthese.

De failure mode waar ik het minst trots op ben is blind vertrouwen aan het einde van een vermoeide dag. Wanneer ik al een hoop features heb geproduceerd, ze heb verfijnd, en gewoon het laatste ding wil afronden voordat ik stop, ben ik geneigd om eerder te accepteren wat de agent heeft geproduceerd zonder het zorgvuldig genoeg te lezen. Dat is het tegenovergestelde van wat ik zou moeten doen — dat is juist het moment waarop ik het voorzichtigst zou moeten zijn — maar het is wat er in de praktijk gebeurt. Ik zit te denken aan een workflow waarbij de agent standaard verificatie inbouwt in de code die hij produceert, in plaats van als iets dat ik moet onthouden om te vragen. Hij doet dat de meeste tijd al voor de voor de hand liggende surfaces, maar in een complexe applicatie zijn er een hoop dingen die een drift in een ander deel van de applicatie kunnen triggeren waar het model niet altijd voor test. Die workflow bestaat nog niet. Het is een echte kloof.

## Waar de bet naartoe gaat

De richting waar ik denk dat dit op gaat, en de richting waar mijn eigen werk al naartoe draait, is kleine lokale modellen die op de hot path draaien met goede tools eromheen — de operator die de agent gebruikt als één aanroeper tussen vele, in plaats van als een autonome redeneerder die de hele taak probeert te dragen. Dat herformuleert het probleem van "hoe kies ik een slimmer model" naar "wat moet het model zien, vanwaar, en in welke vorm" — wat een software-engineering probleem is, en een veel hanteerbaarder probleem dan het scaling probleem. Ik heb over die herformulering geschreven in de context van [een AI-project dat ik op precies die bet heb gebouwd](/blog/een-agent-gebouwd-rond-het-niet-aanroepen-van-de-llm); dezelfde bet is van toepassing op de eigen workflow van de operator, niet alleen op agents die hij voor andere mensen bouwt.

De concrete volgende stap aan mijn kant is de verificatieworkflow. Iets dat licht genoeg is om automatisch te draaien op elke betekenisvolle wijziging die de agent voorstelt, mechanisch genoeg dat ik het aan het einde van een lange dag vertrouw, zelfs op het moment dat ik mezelf niet zou vertrouwen om de diff zorgvuldig te lezen. Dat is het ding dat ik tussen mij en de "om 23:00 alles accepteren"-failure-mode wil zetten.

## Het deel dat zich generaliseert

Het principe waar ik hier steeds op terugkom, over de agents heen die ik bouw en de agents die ik gebruik om dingen te bouwen, is dat de tools de design surface zijn, niet het model. Zodra het model vastligt — je hebt je provider gekozen, je hebt de grootte gekozen, je gaat hem niet in een weekend fine-tunen — is alles wat er nog te ontwerpen valt de set affordances die het model ziet wanneer het gaat zitten om de taak te doen. Hetzelfde geldt wanneer de "agent" degene is die in jouw eigen codebase bewerkt. De ontwerpvraag is welke context je hem geeft, tot welke verificatie hij toegang heeft, wat hij op eigen autoriteit mag aanraken, en wat hij aan jou moet teruggeven. Het model is de constante in die vergelijking. Al het andere is het werk.

De kloof die ik eerder beschreef — tussen mensen die de vorm van het werk al kennen en mensen die dat nog niet doen — is oncomfortabel om eerlijk over te schrijven, omdat geen van beide kanten ervan vleiend is om hardop te zeggen. Maar het werk dat ik dit jaar daadwerkelijk heb gedaan is het bewijs ervoor, en het bewijs is sterk genoeg dat ik er liever eerlijk over schrijf dan te doen alsof de tool iedereen even hard optilt. Dat doet hij niet. Hij tilt de mensen op die al dicht bij het plafond zaten, en hij laat de mensen die nog aan hun eigen ladder timmerden achter met een tool die sneller beweegt dan de ladder zelf.


<!-- https://ninokroesen.nl/blog/een-research-pipeline-voor-wat-het-internet-wel-laat-zien -->

---
title: "Een research pipeline voor wat het internet wel laat zien"
date: 2026-04-20T21:52:00.000Z
updated: 2026-04-28T18:37:21.970Z
canonical: https://ninokroesen.nl/blog/een-research-pipeline-voor-wat-het-internet-wel-laat-zien
lang: nl
author: "Nino Kroesen"
---

# Een research pipeline voor wat het internet wel laat zien

Ik heb een research pipeline gebouwd om een Nederlandse e-commerce niche te kiezen om in te lanceren. Versie 1 wees me er één aan. Ik heb daar een webshop op gelanceerd, één verkoop gedaan, en de shop weer dichtgegooid om redenen die de pipeline op geen enkele manier kon zien. Versie 2 is strikter opgezet en ik vertrouwde hem minder, omdat ik tegen die tijd had geleerd welke laag van het probleem een pipeline als deze niet raakt.

Het is een 5-staps pipeline — crawl, classify, embed, cluster, analyze — die ongeveer 177.000 Nederlandse e-commerce domeinen verwerkt en een gerankte lijst van niches oplevert die eruitzien als blinde vlekken: veel zoekvolume of bekende categorie-omzet, schaars online aanbod. Dat is wat ik hem heb gevraagd te vinden, en op zijn eigen termen heeft hij die gevonden. De niches waren echt en er viel een werkende shop op te bouwen op basis van de output — de pipeline deed precies de klus die ik hem had gegeven. Wat de pipeline op geen enkele manier kon laten zien, was de operationele laag onder de niche, en dat is waar het eerlijke verhaal van dit project ligt: e-commerce- en dropshipping-werk rond zo'n niche is ellendig, de marge relatief klein, en zodra ik een echte shop had gelanceerd en van dichtbij had gezien wat voor soort service ik aan een klant zou leveren, had ik geen zin meer om hem te draaien — hoe schoon de ranking ook was geweest.

## De grote lijn

![1.00](https://media.ninokroesen.com/uploads/2026/04/b7f3068fb28dc317bc3a/_1280.jpeg)

De bron is niet het open web. Het is de output van twee eerdere projecten van mij — eentje die de Nederlandse domeinruimte in kaart bracht voor onderzoek, en eentje daar bovenop die de lijst terugfilterde tot de domeinen waar waarschijnlijk een e-commerce store op draait. Ongeveer 177K daarvan, die in MongoDB stonden tegen de tijd dat deze pipeline begint te lezen. De pipeline crawlt niet vanaf nul — hij verwerkt een gecureerde lijst.

De classifier is Claude Haiku, één call per domein, met async concurrency gecapt op ongeveer tien in-flight calls. De kosten per call op die schaal waren laag genoeg dat het opnieuw draaien van het hele corpus over verschillende versies van de pipeline nooit een budget-discussie werd.

De embeddings zijn OpenAI's `text-embedding-3-small`, 1536-dimensionaal, toegepast op de *classification text* (industry + niche + products + keywords + USPs) in plaats van de ruwe HTML van elke crawl. De embedding-dataset kwam uit op ongeveer 141K × 1536 op float32.

Clustering is HDBSCAN op een 20-dimensionale PCA-projectie. Ik begon het lokaal op CPU te draaien, en op de volledige corpus-grootte was de run zo traag dat hij onbruikbaar werd — de CPU stond uren te thrashen en gaf me nog steeds geen clustering waar ik in één sessie op door kon werken. Dus de run die nu echt telt, draait op Google Colab via cuML RAPIDS GPU. De lokale CPU-clustering-code staat nog in de codebase, maar ik draai die feitelijk nooit op volledige corpus-grootte — die wordt alleen aangeroepen voor kleine test-subsets. Het echte pad is een `.npz` round-trip via een Colab-notebook, wat betekent dat de pipeline eigenlijk geen single end-to-end command is — de clustering-stap gebeurt off-machine, en de rest van de pipeline moet daarnaartoe overdragen en het resultaat weer oppikken.

Tot slot, kansen-scoring op cluster-niveau. Cluster-keywords worden gematcht tegen Nederlandse SBI-codes, en daarna gejoind aan de CBS (Centraal Bureau voor de Statistiek) OData API voor een omzetindex per sector en jaar-op-jaar groei. De output is een CSV met gerankte "dropshipping opportunities", gesorteerd op een gap-score. Een getal, gezaghebbend ogend, en ik kom nog terug op wat het wel en niet waard is — niet in de laatste plaats omdat ik de SBI/CBS-helft uiteindelijk helemaal niet gebruikt heb om een niche te kiezen. In de praktijk behandelde ik de clustering-output als ideegeneratie en hield ik daar op met de pipeline. Ik liep elke kandidaat-niche met de hand af en checkte adverteerdersactiviteit op Meta en Google; of er iets serieus op een van beide platforms draaide, was wat mij vertelde dat een niche echt gewicht achter zich had, naast het voor de hand liggende filter of het iets was waar ik echt mee aan de slag wilde.

## Waar V1 me naartoe stuurde, en wat er gebeurde

V1 van de pipeline was een kleinere setup — lokale MiniLM embeddings op ruwe pagina-content, CPU-clustering op kleinere schaal, geen CBS-overlay. Hij leverde een gerankte shortlist op, ik koos daar een niche uit, en ik bouwde er een echte webshop omheen. De shop deed één verkoop en ik trok hem binnen een maand offline.

De reden dat hij eraan ging, zat in de operatie, niet in de niche-keuze. Het was een dropshipping-business op gepersonaliseerde items die in China gemaakt werden, wat betekende dat de verzendtijden lang genoeg waren dat mijn eerste en enige klant al klaagde over de levering voordat iets anders überhaupt de kans kreeg om mis te gaan. De vorm van de daaropvolgende maanden was vanaf dat moment duidelijk: het meeste van mijn tijd zou opgaan aan klantenservice-mails over verzending, en bijna niets aan het daadwerkelijk doorontwikkelen van de shop. Ik schrijf [dat project apart op als zijn eigen post-mortem](/blog/een-diamond-painting-webshop-die-de-code-niet-kon-redden); voor deze post is het verhaal gewoon: *de output van de pipeline was bruikbaar, en ik heb erop gehandeld*. De pipeline heeft me niet de verkeerde niche aangewezen. Hij wees me een niche aan waarbij het ding dat me zou opvreten — de operationele laag onder de website zelf — niet iets was wat een pipeline van deze vorm kon meten. Dat bleek een nuttiger stuk leerwerk dan wat de CSV me ooit had kunnen geven. Lang genoeg een echte shop draaien om te zien waar mijn dagen écht aan opgingen, deed het inzicht inklikken dat ik niet in e-commerce wilde zitten — niet de markt, maar de dagelijkse praktijk van het draaien van een shop. Welke marge een goede niche ook maar zou kunnen opleveren, het werk dat bij het runnen van het ding hoorde, ging me ongelukkig maken, en ongeveer een maand het echt doen was de goedkoopste eerlijke manier om daarachter te komen.

Dat is de dragende zet waar de rest van deze post op rust. De pipeline was niet stil vanwege een bug. Hij was stil omdat het ding waar hij naar keek — wat er op het internet staat, geaggregeerd, in het Nederlands — een ander object is dan het ding dat bepaalt of een specifieke operator een specifieke shop winstgevend kan draaien. Fulfillment, unit economics, de dagelijkse praktijk van het draaien van een bepaalde categorie — niets daarvan komt naar boven in een embedding van een gecrawlde homepage.

## Waarom V2 strikter was en ik hem minder vertrouwde

V2 was, technisch gezien, beter op elke dimensie waarop ik hem beter wilde maken. Meer domeinen in het corpus. OpenAI-embeddings op classification text in plaats van lokale MiniLM op ruwe HTML, wat een hoop footer-boilerplate-ruis wegsneed en clusters opleverde die ik daadwerkelijk kon lezen. HDBSCAN op cuML GPU in plaats van een CPU die uren stond te thrashen. Een CBS-overlay die elk cluster scoorde tegen publieke omzet- en groeicijfers — al weet ik nog steeds niet zeker of dat laatste de output echt verbeterde of er gewoon gezaghebbender uit liet zien. Op elke metric die ik voor de rewrite had gezet, was V2 de versie die de pipeline had moeten zijn.

En de hoofdbevinding van V2 was dat V1 op meerdere plekken zelfverzekerd fout had gezeten. Het duidelijkste voorbeeld is Pokemon TCG. V1 was teruggekomen met 2 concurrenten in het cluster — een gat, een wijd open niche, nú gaan. V2 kwam terug met 149, inclusief feitelijk elke gevestigde kaartwinkel in het land. Dezelfde markt, dezelfde pipeline-vorm, andere embedding en andere schaal, een totaal ander concurrent-aantal.

Die correctie had het moment moeten zijn waarop de pipeline méér van mijn vertrouwen verdiende, niet minder. V2 was het instrument dat zichzelf corrigeerde, en dat is precies het gedrag dat je uit een onderzoekstool wilt. Het probleem was dat ik al sceptisch was voordat V2 het me vertelde. Een vriend van mij zit toevallig in de Nederlandse TCG-markt, en hij had me eerder al — op de meest low-tech manier denkbaar, een gesprek — verteld dat die markt een stuk groter was dan V1's output suggereerde. Dus toen V2 terugkwam met 149, was dat geen openbaring. Het was de pipeline die alsnog inhaalde wat ik weken eerder al wist uit een gesprek met één iemand die de categorie kende.

Dat is geen vleiend datapunt voor 141K × 1536-dimensionale embeddings. Eén gesprek met één vriend leverde een accuratere lezing van de Pokemon TCG-concurrentie op dan V1 deed, en V2's overeenstemming met die vriend bekrachtigde alleen maar een beeld dat ik al had. De rol van de pipeline in die specifieke niche was retrospectief: hij kwam uiteindelijk op het juiste antwoord uit, lang nadat ik het juiste antwoord ergens goedkoper al had.

Ik wil niet hard generaliseren vanuit één datapunt. Maar ik heb in de output van V2 nooit een niche gevonden waar ik onafhankelijke ground truth op had en waar de pipeline vóór die ground truth zat. Tegen de tijd dat ik echt iets geloofde over een niche, kwam dat ergens anders vandaan — een vriend, een forum, een markt waar ik al naast leefde — en zat de pipeline daar dan mee in te stemmen of het tegen te spreken tegenover een beeld dat voor mij leesbaarder was dan dat van de pipeline. De eerlijke voetnoot bij dit hele project, de voetnoot die de codebase je niet zal vertellen, is dat ik geen bewust protocol heb opgezet om een kandidaat-niche te valideren tegen een mens in de markt. Ik had één toevallig datapunt, en dat landde laat genoeg om de toon voor de rest van de runs te zetten in plaats van vroeg genoeg om het ontwerp van de pipeline zelf om te buigen.

## Dingen die ik bij een rewrite eruit zou snijden

Er zijn een paar concrete dingen in de repo die ik zou weghalen als ik er met frisse ogen op terug zou komen.

Drie parallelle embedding-pipelines — OpenAI op classification text, lokale MiniLM op ruwe HTML, en een derde die alleen op domeinnamen draaide — zijn naast elkaar blijven bestaan, elk geïntroduceerd om een ander probleem met de vorige op te lappen. Alleen het OpenAI-pad is daadwerkelijk dragend voor de rest van de pipeline. De domeinnaam-pipeline produceerde zijn eigen retro-document waarin werd toegegeven dat het tokeniseren van Nederlandse second-level domains met een Nederlandstalig BERT-model de clusters slechter maakte in plaats van beter (de top-cluster-keywords waren dingen als "dam", "ster", "min", "mijn", "van" — dus substrings van domeinnamen, geen onderwerpen). Bij een rewrite zou ik één embedding-pad kiezen en de andere twee weghalen.

De CBS SBI keyword-match-scoring — de laatste stap van de pipeline, degene die de top-keywords van een cluster pakt, probeert die te koppelen aan een Nederlandse SBI-code, en die code vervolgens joint tegen CBS-omzet- en groeicijfers om tot de uiteindelijke kansen-ranking te komen — doet minder werk dan het lijkt. Die keyword-naar-SBI-match is zelf een keyword-overlap-heuristiek, en die heuristiek is onnauwkeurig genoeg om tandartspraktijken aan hotels te koppelen als je hem zijn gang laat gaan. Er staat een `match_score >= 3`-filter overheen om de ergste gevallen weg te knippen, maar er is geen evaluatie van hoe vaak dat filter goede matches op de grond laat vallen. De kansen-score zelf is een gewogen combinatie van vijf subscores — concurrentie, kwaliteit, e-commerce-ratio, fysieke-goederen-ratio, dropship-vriendelijkheid — met wegingen van `0.25 / 0.20 / 0.20 / 0.15 / 0.20`. De gap-score tussen cluster-vraag en cluster-aanbod is `(revenue_index * growth_factor) / sqrt(cluster_size)`. Beide formules ogen gezaghebbend. De wegingen in de eerste zijn nergens in de repo onderbouwd. Het zijn vibes. De tweede is een plausibel ogend onderbuikgevoel met een vierkantswortel erin. Wat in de praktijk allemaal niet veel meer uitmaakte, want ik ben gestopt met op deze stap te leunen om een keuze te maken zodra het duidelijk werd hoe onnauwkeurig hij was — de tandartspraktijk-naar-hotel-mismatch is het soort ding dat bleef opduiken, en vanaf dat moment behandelde ik de output als achtergrondruis in plaats van signaal en maakte ik de feitelijke keuzes op basis van de clustering-output plus de handmatige adverteerderscheck die ik hierboven beschreef.

De hybride embedding waarvan ik al wist dat ik die zou moeten gebruiken, heeft het nooit gehaald. Een `0.5 * raw_page + 0.5 * classification`-blend was de voor de hand liggende fix geweest voor het probleem dat "classification-text-only gegijzeld is door de classifier" — ik had voor mezelf een notitie liggen waar precies dat in stond, en ben er vervolgens nooit op teruggekomen om het te implementeren. Tussen aanpakken die ik al had besloten beter te zijn en aanpakken die ik daadwerkelijk had gedraaid, is de ratio van de eerste tot de tweede in deze codebase hoger dan waar ik comfortabel mee ben.

Er zijn ook nul tests. De correctheid van de pipeline werd gevalideerd door de output-CSVs te lezen en "ja, dat ziet er goed uit" te denken. Dat is precies de manier waarop V1 me dingen had laten geloven die V2 later weer terugnam — hij produceerde output die er *goed uitzag*, en er stond niets tussen die output en het mij geloven dan mijn eigen pattern-matching.

## Wat ik mee zou nemen naar het volgende

Eerlijk gezegd niet zo heel veel dat generaliseert. Haiku was het juiste model voor dit soort structured-extraction-over-een-groot-corpus-werk — goedkoop per call, nauwkeurig genoeg op het classification-schema om de downstream clustering iets schoons te geven om mee te werken, en vergevingsgezind voor het feit dat elke input een rommelige gecrawlde homepage was in plaats van een netjes voorbereide prompt. Als ik in de nabije toekomst tegen een ander large-batch-classification-probleem aanloop, zou ik bij Haiku beginnen, en ik zou ook een tier eronder willen testen om te zien waar de accuracy cliff feitelijk zit — voor dit soort werk is het plausibel dat iets goedkopers dan Haiku al goed genoeg is, en dat experiment heb ik nooit gedraaid. De richting die ik wel heb geprobeerd en die niet werkte, was de andere kant op: ik heb een Runpod-instance opgezet met DeepSeek R1 tegen dezelfde classification prompt, en die was slechter op elke as die ik belangrijk vond — langzamer per call, merkbaar duurder om te draaien, en de extra reasoning tokens leverden geen extra nauwkeurigheid op voor een taak die feitelijk gestructureerde extractie uit een gecrawlde homepage is. Voor dit soort probleem wordt het plafond niet bepaald door hoe slim het model is. Het wordt bepaald door hoe schoon de input is en hoe strak het output-schema is afgebakend. Daarbuiten is de rest van de pipeline te zeer verbonden met *déze* niche-hunt in *deze* markt om netjes mee te nemen naar iets anders.

## Waar het nu staat

Het project staat geparkeerd. De laatste echte run is van half maart, en er zijn sindsdien geen betekenisvolle commits geweest. Het is niet dood — ik heb de repo niet verwijderd, en er ligt geen specifiek besluit om hem te killen — maar er wordt ook niet actief aan gewerkt, en ik heb geen directe plannen om hem weer open te trekken.

Als ik hem wel weer zou openen, is het enige eerlijke pad om hem te shippen als een Nederlandse market-intelligence SaaS voor andere operators — iets dat de clustering-output, de classifier-pipeline, en een opgeschoonde versie van de CBS-overlay pakt en die in een UI wikkelt waar iemand anders dan ik voor wil betalen. De insteek zou ideegeneratie zijn in plaats van een gerankte kansen-lijst: hier zijn leesbare clusters van de Nederlandse markt, hier is ruwe omzet- en groei-context op sectorniveau, doe nu zelf je validatie — want een niche moet bij de specifieke operator passen voordat iets ervan werkt, en CBS-data is breed genoeg dat een goed verdienende sector nog steeds hoge opstartkosten of een operationele puinhoop kan verbergen die de cijfers niet laten zien. De keyword-naar-SBI-mapping zoals die er nu staat, zou niet de versie zijn die de deur uit gaat; het idee erachter klopt, de manier waarop ik het heb geïmplementeerd niet. Ik ben dat pad niet ingeslagen omdat er nog geen klant voor is, en de enige klant die de CSVs nu hebben ben ik, en ik koop het niet.

Als jij iets bouwt dat hiernaast ligt — een market-intelligence-pipeline, een large-batch LLM-classification-job over een rommelig corpus, of een retrospectief op een onderzoekstool die uiteindelijk meer goede vragen dan antwoorden produceerde — wissel ik graag notes uit.


<!-- https://ninokroesen.nl/blog/een-agent-gebouwd-rond-het-niet-aanroepen-van-de-llm -->

---
title: "Een agent gebouwd rond het niet aanroepen van de LLM"
date: 2026-04-19T14:10:00.000Z
updated: 2026-10-10T11:50:06.041Z
canonical: https://ninokroesen.nl/blog/een-agent-gebouwd-rond-het-niet-aanroepen-van-de-llm
lang: nl
author: "Nino Kroesen"
---

# Een agent gebouwd rond het niet aanroepen van de LLM

De standaard van de meeste agent frameworks is *roep het model nog een keer aan.* Wil je elk uur een webpagina checken? Draai de agent elk uur. Wil je in de gaten houden of er iets verandert? Vraag de LLM of er iets is veranderd. Wil je een field uit een tool result halen? Nog een round trip. De doorlopende rekening voor een agent die zo gebouwd is, is ruwweg de kosten van het model maal het aantal keer dat de agent wakker werd, en voor elk nuttig systeem is dat *veel*.

Het persoonlijke agent-project waar deze post over gaat is gebouwd om een andere standaard te beantwoorden — *moeten we het model deze keer eigenlijk wel aanroepen?* — en om elk onderdeel van het systeem zo te structureren dat het antwoord meestal nee is. Het doel dat ik vanaf dag één had was een agent die extreem kosteneffectief is om te draaien, en elke architecturele keuze die uit dat doel volgt is waar de rest van deze post over gaat.

## De algehele vorm

Het project is een agent runtime rond vier onderdelen die op elkaar leunen:

* Een main loop die met een pluggable model provider praat en een kleine registry aan tools aanstuurt die het model kan aanroepen.

* Een scheduler die gewone Python jobs op een timer draait, hun output alleen met een LLM evalueert zodra er iets verandert, en je een mail stuurt als dat gebeurt.

* Een provider layer die de loop ofwel met een goedkope remote endpoint ofwel met een lokaal model laat praten — uitwisselbaar.

* Een zelf te hosten setup flow — installatiewizard, authenticatie, mail- en runtime-configuratie — zodat het pad van "clone deze repo" naar "er draait iets voor me" niet via een README en een `.env`-file loopt.

Er zijn drie runtime profiles waar de gebruiker uit kan kiezen: goedkope remote, lokaal, of goedkope remote met een lokaal model dat alleen voor preprocessing wordt gebruikt. Dat zijn drie punten op de cost/capability curve, en de hele reden dat de provider layer bestaat is zodat de keuze ertussen een dropdown is en geen herschrijving.

## Waarom de goedkope remote het hoofdmodel is

Het hoofdmodel is een goedkoop remote model om een saaie reden: op het moment dat ik dit bouwde, was het de goedkoopste remote optie die zich daadwerkelijk staande hield in een agent loop. Een frontier model had hetzelfde werk betrouwbaarder gedaan en zou me genoeg per run hebben gefactureerd om de "kosteneffectieve agent"-premisse binnen een week om zeep te helpen. Een agent loop is geen one-shot — het is een langlopend ding waarin elke aanroep er één van vele is, en de kosten schalen lineair met het aantal aanroepen.

De interessantere tradeoff is waarom niet lokaal. Daar ben ik wel begonnen — de eerste versie van de agent laadde direct een klein lokaal model, met grammar constraints die boolean-shaped outputs afdwongen zodat tool calls te parsen waren, en viel terug op een download URL als er geen weights op disk stonden. Wat ik bleef tegenkomen was dat kleine lokale modellen zowel te traag waren als niet accuraat genoeg voor de hot path. Inference was traag genoeg om de debug loop pijnlijk te maken, en de outputs waren inconsistent genoeg dat ik meer prompt scaffolding aan het schrijven was dan daadwerkelijke agent-logica. Het moment waarop ik tegen mijn eigen eerlijkheid aanliep was een note die ik uiteindelijk heb verwijderd — *het model krijgt een aparte prompt die zegt: gebruik alleen tool results als bewijs, negeer je eigen eerdere redeneerwerk en wereldkennis.* Dat is het punt waarop ik het al had opgegeven dat het lokale model zich naar het antwoord toe zou redeneren. De overstap naar een goedkope remote was alleen nog de erkenning.

Ik denk nog steeds dat lokaal draaiende modellen de toekomst zijn. De rekenkosten van frontier LLMs zijn geen houdbare basis om software op te bouwen, en het vermogen van kleine modellen verbetert snel genoeg dat het plaatje over een jaar er waarschijnlijk anders uitziet dan vandaag. De architectuur waar ik op uitkwam is gebouwd om die verschuiving op te vangen wanneer hij komt — de provider layer bestaat juist zodat de volgende keer dat een lokaal model bruikbaar is voor de hot path, hem inswappen goedkoop is. Vandaag was hij niet bruikbaar.

## Tool design is het deel waar ik het meeste van genoot

De houding waar ik op dit project steeds op terugkwam, en die ik in vrijwel alles wat ik verder bouw met een LLM in de loop zou meenemen, is dat *de tools het design surface zijn, niet het model.* Zodra je accepteert dat het model vaststaat — je hebt je provider gekozen, je hebt je size gekozen, je gaat hem niet in een weekend fine-tunen — is alles wat er nog te ontwerpen valt de set affordances die het model ziet wanneer het aan een taak begint. Wat kan het fetchen. In welke vorm. Wat kan het produceren. Waar kijkt het zelf naar versus wat geeft het door.

Dat andere perspectief bleek nuttiger dan welke scaffolding-trick ik ook eerst probeerde. Je stelt niet meer de vraag "hoe krijg ik het model zover dat het zich naar X toe redeneert" en begint te vragen "wat zou ik een redelijk slimme intern in handen geven die X moest produceren, en welke tools zouden er op zijn bureau liggen?" Als het model worstelt, is de eerlijke diagnose meestal niet "het model is slecht" maar "ik heb hem geen tool gegeven die past bij de vorm van de taak." De prompt herschrijven is de verleidelijke shortcut; een betere tool schrijven is meestal de juiste zet.

Een concreet voorbeeld. Een generieke "fetch een webpagina"-tool returnt de volledige HTML van de pagina, wat zowel duur in tokens is als rommelig genoeg dat het model uiteindelijk in zijn hoofd DOM parsing zit te doen. De fix is niet om het model te zeggen "negeer alsjeblieft de nav en footer." De fix is een tweede tool — een targeted extractor die een CSS selector of een semantische omschrijving meekrijgt en alleen het deel van de pagina returnt waar het model daadwerkelijk om vroeg. Zelfde web, radicaal andere vorm, en het model verzuipt niet meer.

Het andere stuk tool design dat ik pas waardeerde toen ik er middenin zat, is dat *de tool description zelf onderdeel is van de prompt.* De description van elke tool komt mee in de context van het model zodra tools worden aangeboden, en die description is waar je niet alleen kunt communiceren wat de tool doet maar ook wanneer het model er wel of juist niet naar moet grijpen. Degene waar ik het meest trots op ben is de escalation tool:

De tool die hierin wordt beschreven stuurt een enkele zelfstandige vraag naar een capabeler (en duurder) model en returnt het antwoord. Het patroon waar ik op mikte is *goedkoop model voor het grootste deel van de loop, slimmer model alleen wanneer het goedkope model echt vastloopt* — een escape hatch die de gemiddelde kosten per aanroep laag houdt maar een vangnet overlaat voor de zeldzame vraag die daadwerkelijk meer rekenkracht nodig heeft. Het idee is geboren toen het hoofdmodel een klein lokaal model was — kleine lokale modellen missen het soort complexer redeneerwerk dat je nodig hebt voor zwaardere taken, en hen op aanvraag een escape hatch geven naar een capabeler model is goedkoper dan ofwel het lokale model permanent upgraden ofwel alles routen door een frontier API.

Eerlijke kanttekening: ik ben overgestapt vanaf het lokale hoofdmodel voordat ik kon bevestigen dat een lokaal model daadwerkelijk correct naar deze escape hatch grijpt op het moment dat het zou moeten. De tool zit er nog steeds in en het patroon klopt in principe nog steeds, maar zijn beoogde pairing is met het lokale runtime profile, en die pairing is ongetest. Met een goedkope remote als hoofdmodel is de escalation minder load-bearing, omdat de remote het meeste afhandelt wat anders de escalation zou triggeren. Wanneer ik het project weer opensla en een nieuwer klein lokaal model in de hot path zet, is kijken of dit patroon in de praktijk werkt een van de eerste dingen waar ik naar wil kijken.

Andere tools die ik om dezelfde design-surface reden ben gaan waarderen: een persistent key-value memory zodat state niet elke turn opnieuw gefabriceerd wordt; een structured page-change checker die de agent direct kan aanroepen in plaats van een pagina opnieuw de loop in te lezen; en een tool waarmee de agent een nieuwe scheduled job in het project kan schrijven die op de volgende scheduler tick wordt opgepakt — wat het onderwerp is van de volgende sectie.

## De scheduler is de thesis in uitvoerbare vorm

De architecturele keuze waar ik op dit project het meest aan gehecht ben is het scheduled background-job systeem. De realisatie erachter is simpel: een hoop nuttig agent-werk — *check of deze pagina is veranderd, laat het me weten wanneer deze release uitkomt, kijk naar deze feed voor een nieuw item* — heeft duidelijk geen metered LLM-aanroep per uur nodig. Een LLM is meer dan capabel om de check zelf te schrijven, één keer. Een cron kan die check vervolgens eindeloos draaien zonder het model nog een keer aan te raken. De LLM hoeft pas weer terug te komen in de loop wanneer de check iets meldt dat evalueren waard is.

Zo werkt het systeem. De agent heeft een tool die een nieuwe Python module in een jobs directory laat vallen. De scheduler ontdekt de module automatisch op de volgende tick, draait hem op zijn eigen interval, houdt een persistent state file bij zodat hij tussen runs weet wat "changed" betekent, en roept de LLM alleen aan om een gedetecteerde verandering te evalueren voordat hij de gebruiker een email callback stuurt. De eerste job die ik ermee schreef houdt de homepage van een model provider in de gaten voor release-gerelateerde taal, omdat ik hem handmatig zat te checken en dat precies het soort taak is waarbij elk uur voor een LLM betalen absurd zou zijn.

Het bredere patroon is echter niet "bouw een website watcher." Het patroon is *de meeste herhaalbare automatiseringen hebben de LLM alleen nodig op het moment van bouwen, niet bij elke tick,* en de taak van het systeem is om die vorm tot standaard te maken in plaats van tot workaround. Als er één feature is die dit project onderscheidt van elke andere "hier is mijn local LLM wrapper"-weekendbuild, dan is het deze. De meeste agent frameworks beantwoorden "hoe draai ik deze automatisering elk uur?" met "draai de agent elk uur." Het antwoord van dit project is "laat de agent een cron voor je schrijven."

## Lokale modellen in een nauwere rol

Naast de scheduler zit een webpage-compression preprocessor. Hij draait een klein lokaal model op gefetchte HTML met een strikte structured-output prompt die precies deze vorm produceert:

```
TITLE: ...
SUMMARY: - ...
SECTIONS: [Heading] - ...
ENTITIES: - ...
KEY FACTS: - ...
OPEN QUESTIONS: - ... or 'None'
```

De web-fetch tool stuurt HTML optioneel door deze preprocessor voordat hij überhaupt het hoofdmodel bereikt. De oorspronkelijke reden was local-on-local: toen de main loop een klein lokaal model was, hoefde hij eigenlijk niet de HTML te lezen — hij had de *content* van de pagina nodig, en specifiek de content in een vorm die compact genoeg was om in zijn krappe context window te passen en gestructureerd genoeg om over te kunnen redeneren. Ruwe HTML faalde op beide punten. Een tweede motivatie kwam boven zodra een ander klein lokaal model dat ik bij de hand had, oprecht goed bleek in het schrijven van deze samenvattingen: hem voor de pipeline plaatsen verlaagde de token count op elke downstream call die naar het resultaat moest kijken. Voor een project waarvan het hele punt is om metered model-aanroepen te minimaliseren is een tokenbesparing op elke web fetch geen kleine winst.

Beide motivaties zijn vandaag nog steeds van toepassing, en ze passen netjes samen met het derde runtime profile: goedkope remote main loop, met een lokale preprocessor ervoor. Dezelfde preprocessor-rol, andere begunstigde. Het remote model ziet de ruwe pagina nooit. Zijn context window blijft schoon, zijn per-call token count blijft begrensd, en het kleine lokale model verdient zijn brood in een rol waar zijn plafond er niet toe doet — hij probeert niet te redeneren, hij probeert een compacte, voorspelbare samenvatting van iets ondoorzichtigs te produceren. Hij faalt netjes. En hij is bovendien ongeveer gratis om op dezelfde box als al het andere te draaien.

De generalisatie voorbij web scraping is wat ik in elk toekomstig project ook daadwerkelijk zou meenemen. Vrijwel elke tool die ondoorzichtige, in size onbegrensde output teruggeeft — lange file reads, verbose API responses, transcripts, scraped content — is een kandidaat voor een small-local-model compressiestap voor de main loop. De besparingen zijn groter dan ze lijken omdat ze stapelen over elke tool call in een lang gesprek, niet alleen de ergste. Ik heb dit systeem niet gebouwd als een "local vs. remote"-verhaal, en ik denk niet dat dat kader standhoudt. Ik heb hem gebouwd als *een goedkoop model dat de saaie preprocessing job opvangt zodat het dure model minder ziet en er meer mee doet,* en dat is een verhaal dat overleeft welke verschuiving dan ook in welk model op welke dag duur is.

## De provider layer is de wegbereider

Alles hierboven — de runtime profiles, de preprocessor-rol, de uiteindelijke local-main gok — hangt ervan af dat het de agent loop niet uitmaakt met welk model hij praat. Die ontkoppeling is het stuk plumbing waar ik het minst opgewonden over ben om over te praten en het stuk dat de rest van de architectuur mogelijk maakt. Een kleine interface zit tussen de loop en welke client er ook actief is, de loop praat alleen tegen die interface, en de interface doet de rest. De payoff is dat een toekomstig klein lokaal model dat zich staande houdt in een agent loop slechts een one-file swap verwijderd is van bruikbaar zijn voor de hot path. Geen ander deel van het systeem hoeft het te weten.

Het bredere punt voorbij dit project: elk agent-project waar ik aan gewerkt heb wil uiteindelijk zo'n abstractie, en hoe eerder hij er is hoe minder pijnlijk de uiteindelijke providerwissel is. Er is altijd een uiteindelijke providerwissel.

## De setup flow is een first-class surface

De beoogde gebruiker van dit project is iedereen die hem wil draaien — niet "ik en misschien een collaborator." Dat is de reden dat de web layer zo substantieel is als hij is. De installatiewizard, de authenticatie, de mail-configuratie, de runtime-profile picker, het gebruikersbeheer — alles bestaat zodat het pad van "clone de repo" naar "je background job draait en mailt je" niet via het met de hand bewerken van config files loopt. Als de waardepropositie is "deploy dit en het stopt jou LLM tokens te kosten op routinewerk," dan moet de setup-ervaring daadwerkelijk werken, anders valt de hele propositie om bij eerste contact met de gebruiker.

Dat argument zou ik breder trekken voor elke zelf te hosten tool. Setup is een first-class surface die het waard is om als feature te behandelen, niet als een klusje waarover je proza schrijft in een README.

## Wat ik heb meegenomen uit het bouwen hiervan

Hoe meer tijd ik besteedde aan het ontwerpen van tools waar het model naar kan grijpen in plaats van te proberen het model zelf slimmer te maken, hoe meer het werk begon te lijken op de vorm van de gok die ik op LLMs in het algemeen wil maken.

Mijn lezing, nu ik dit gedaan heb: de as die er vooruitkijkend toe doet is niet hoeveel informatie een model in zijn weights heeft gepropt, maar hoe goed hij de juiste informatie kan ophalen uit een betrouwbare bron en een mening kan vormen over wat hij net gelezen heeft. Een model dat een beetje minder kennis heeft maar weet hoe het naar de juiste bron moet grijpen, hem zorgvuldig moet lezen, en je moet vertellen wat hij daadwerkelijk betekent is nuttiger dan een groter model dat met overtuiging iets herhaalt wat het zich half herinnert uit pretraining. Het eerste soort model is een probleem dat je oplost met tools. Het tweede soort is een probleem dat je oplost met parameter count, en parameter count is wat inference duur maakt.

Dit is geen nieuw patroon. Het is hetzelfde wat al lang voor LLMs bestonden gold voor mijn eigen werk. Het lastige deel van vrijwel elke taak waar ik daadwerkelijk voor ben betaald is niet handelen op basis van de informatie — het is om te beginnen de juiste informatie vinden om naar te handelen. Handelen op slechte of onjuiste informatie is erger dan niet handelen, omdat alles wat erop volgt al gecompromitteerd is; je shipt uiteindelijk iets dat met overtuiging fout is, en de kosten van met overtuiging fout zitten zijn vrijwel altijd groter dan de kosten van trager zijn. Als de input slecht is, kan de output niet goed zijn, en geen enkele hoeveelheid afwerking verderop in de pipeline fixt het probleem stroomopwaarts.

De LLM-versie is hetzelfde patroon. Pretraining data is statisch en uiteindelijk stale, en het eerlijke antwoord van het model op "wat weet je over X" is een gewogen gemiddelde van wat er over X waar was op een vast punt in het verleden. Een tool die de huidige versie van X gaat lezen, gestructureerd zodat het model hem kan consumeren, geeft het model een kans om vandaag gelijk te hebben. De ontwerpvraag is niet langer *hoe kies ik een slimmer model* maar wordt *wat moet het model lezen, vanwaar, en in welke vorm* — wat precies de ontwerpvraag is waar de tools layer van dit project omheen is gebouwd.

Dat is de gok waar de architectuur voor gebouwd is, en het is de gok die ik in de volgende versie wil blijven maken.

## Waar het nu staat, en wat er hierna komt

Het project staat momenteel op de plank. Niet dood — ik ben van plan ernaar terug te keren, en de reden dat ik van plan ben terug te keren is de reden dat ik eraan begonnen ben. LLM-gebruik optimaliseren is de weg vooruit, niet hem negeren, en rekenefficiënte automatisering waarbij de LLM op het moment van bouwen wordt geraadpleegd en daarna uit de loop blijft is een betere standaard dan het "draai de agent elk uur"-patroon dat de meeste frameworks aanmoedigen. Kleine lokaal draaiende modellen gaan goed genoeg worden om op de hot path te zitten, en een architectuur die al rond die gok gebouwd is is een veel korter pad naar een werkend systeem dan het achteraf aanpassen van een remote-first stack.

Wanneer ik hem weer opensla, zijn de dingen die de volgende iteratie overleven de scheduler, het preprocessor-patroon, en de provider-abstractie. Het ding dat ik het liefst daadwerkelijk wil testen is het escalation pattern in zijn beoogde pairing — een klein lokaal model als de main loop, dat alleen escaleert naar een grotere remote als het echt vastzit. Die test is de eerste keer nooit gedraaid omdat de lokale main loop nooit ver genoeg kwam om hem nodig te hebben. Een deel van de omliggende machinerie — de installatie-flow in het bijzonder — is waarschijnlijk te zwaar opgetuigd voor waar het project op dit moment staat, en is een kandidaat voor agressieve vereenvoudiging voordat er iets nieuws bovenop komt.

Als iets hiervan overeenkomt met een probleem dat jij ook probeert te vermijden door er tokens op te verbranden, dan zou ik graag notities vergelijken.


<!-- https://ninokroesen.nl/blog/introductie -->

---
title: "Introductie"
date: 2026-04-17T23:18:00.000Z
updated: 2026-04-28T18:36:03.356Z
canonical: https://ninokroesen.nl/blog/introductie
lang: nl
author: "Nino Kroesen"
---

# Introductie

Dit is de eerste post op ninokroesen.com en ninokroesen.nl, en het is de enige plek op de site waar ik de zaak uitleg in plaats van hem gewoon te doen. Volgende posts duiken meteen in het probleem zelf — een productiesysteem dat zich misdraagt, een onderzoeksrun die met iets interessants terugkwam, of een onafhankelijk project dat een eerlijk verslag verdient. Deze post is de index: wie er schrijft, waar ik daadwerkelijk aan werk, en wat de blog gaat behandelen zodra de inhoudelijke posts beginnen te landen.

De invalshoek is operator-developer. Ik bouw software, ik houd de infrastructuur eromheen draaiende, daarnaast doe ik langerlopend onderzoek, en ik ship kleine onafhankelijke experimenten van mezelf. Die hybride positie is de reden dat de posts hier anders lezen dan pure engineering-blogs of pure foundercontent. De tradeoffs in elke post komen voort uit het feit dat ik meer dan één van die dingen tegelijk moet doen, niet uit een focus op slechts één ervan.

Eerlijk gezegd is de andere reden dat deze site bestaat dat het schrijven van posts als deze het meest nuttige reflectie-instrument is dat ik voor mijn eigen werk heb gevonden. Het schrijven van deze introductie heeft me al gedwongen om opnieuw te graven in wat er op elk van deze projecten daadwerkelijk heeft gewerkt, wat niet, en waar ik me als volgende op zou moeten richten — het soort eerlijke evaluatie dat makkelijk over te slaan is als je met je neus diep in het volgende ding op de stapel zit. Daar is deze blog deels voor. Veel van de posts die nog komen lezen meer als hardop nadenken op papier dan als een afgeronde mening, en dat is bewust en niet per ongeluk.

## Wie dit schrijft

![1.00](https://media.ninokroesen.com/uploads/2026/04/fa90829a078eac47b7ba/_1280.jpeg)

Ik ben Nino Kroesen. Ik woon in de Achterhoek, Nederlands is mijn moedertaal, en ik schrijf in beide talen. Posts op deze site worden eerst in het Engels geschreven en daarna naar het Nederlands vertaald, zodat de `.com`- en `.nl`-versies van de site synchroon blijven in plaats van twee gescheiden redactionele stromen te draaien.

Mijn rol in mijn hoofdbaan is Lead Developer bij WorkWear4All B.V., een landelijk Nederlands werkkledingbedrijf dat een multi-store Magento 2 stack draait over meerdere Europese markten. Het systematische tradingwerk op deze blog staat los van die hoofdbaan — persoonlijk onderzoek dat ik in mijn eigen tijd doe, buiten WorkWear4All om, en de posts erover worden vanuit die hoek geschreven.

Ik werk voornamelijk op een MacBook Air, en voor de dagelijkse ontwikkeling op elk hieronder genoemd project leun ik zwaar op agentic coding tools. Ik probeer wisselend uit wat er op dat moment beschikbaar is in plaats van me aan één tool vast te leggen, en ik kijk actief uit naar nieuwe tools die de workflow daadwerkelijk verbeteren in plaats van in de weg zitten. Voor alles wat rekenintensief is — en een flink deel van het AI-onderzoek plus een flink stuk van het tradingwerk valt in die categorie — is de laptop het verkeerde gereedschap, dus huur ik rekenkracht in de cloud in plaats van te proberen de zware runs lokaal te draaien. Mijn leveranciers op dit moment zijn Netcup voor algemeen VPS- en serverwerk, Runpod voor on-demand GPU-huur als een AI-experiment een kaart nodig heeft die groter is dan wat er in mijn eigen machine zit, en Google Colab voor Jupyter notebooks die een rekenintensieve kernel nodig hebben zonder dat ik er een hele omgeving omheen wil opzetten. Die splitsing — lokaal voor ontwikkeling, cloud voor de rekenintensieve runs — is hoe de opstelling eruitziet, en hij gaat de posts kleuren waar rekenkracht zelf de bottleneck is.

## Waar ik op dit moment aan werk

Een paar dingen parallel. Ik lijst ze hier op zodat latere posts kunnen terugverwijzen naar "de stack van het tradingonderzoek" of "het Magento-cluster van WorkWear4All" zonder elk project elke keer opnieuw te hoeven introduceren.

### WorkWear4All

WorkWear4All is een multi-store Magento 2 e-commercebedrijf — meerdere storefronts (workwear4all.nl, workwear4all.be, workwear4all.de, workwear4all.com, workwear4all.pl en nog een aantal meer gespecialiseerde sub-stores) die één backend delen, draaiend op Apache + Varnish + PHP-FPM + Redis. De keuze voor Apache is een vroege beslissing die door een externe developer is gemaakt voordat ik in beeld kwam, en achteraf is het er een waar ik spijt van heb — we lopen tegen genoeg wrijving op de performance aan dat een migratie naar Nginx al op de roadmap staat. Ik ben lead developer op het platform, en ik coach ook de juniors en stagiairs aan de engineeringkant.

De interessante delen, vanuit schrijfperspectief, zijn de operationele. De `_cl` changelogtabellen die in de achtergrond stilletjes opzwellen totdat er iets in de indexeringspipeline kapotgaat. De indexer cron groups waarvan het gedocumenteerde gedrag en het echte gedrag op subtiele manieren verschillen. De meerlandige `MAGE_RUN_CODE` plus locale plus Varnish VCL-coördinatie die over al deze storefronts heen correct moet blijven zonder dat er iemand op een willekeurige dag bewust over nadenkt. Breder gezien past het Magento-ecosysteem niet goed bij moderne webontwikkeling, en dat kleurt een hoop van de operationele inhoud op deze blog. De problemen waar we tegenaan lopen zijn vaak het soort dat lastig te diagnosticeren is zonder in aangrenzende componenten van de stack te duiken om ze uit te sluiten, en één ding fixen betekent vaak begrijpen wat de drie andere dingen aan het doen waren die allemaal dachten dat zij verantwoordelijk waren voor hetzelfde gedrag. De posts die uit dit deel van het werk voortkomen, komen vanuit deze stoel — niet uit het lezen van de documentatie, maar uit tegen de randen ervan aanlopen in productie. Als een module de moeite van het installeren waard is, zal ik dat zeggen en waarom; als hij dat niet is, zeg ik dat ook.

### Hourly

Hourly is een gratis menubalk-tijdregistratie voor macOS die ik in SwiftUI aan het bouwen ben. De projectpagina staat op `/hourly`, met ondersteuning op `/hourly/support`. De bewuste positionering is: geen paywall, geen in-app purchases, geen abonnement, geen account, geen cloud — opslag is lokaal op je Mac en blijft daar. De marktreferenties zijn WorkingHours, Toggl, en Timery, en al die drie zitten op de Mac App Store achter een of andere vorm van paywall. Het punt waarop Hourly afwijkt is dat hij geen verdienmodel heeft dat je uiteindelijk om je creditcard vraagt.

De minder voor de hand liggende reden dat Hourly bestaat, is dat ik hem als experiment gebruik. Generatieve AI heeft het oprecht triviaal gemaakt om het soort functieset te shippen waar een kleine SaaS vroeger een maandelijks abonnement voor vroeg, en ik wil — empirisch — uitvinden hoeveel van een bedreiging dat daadwerkelijk is voor de SaaS-aanbieders die op dit moment een categorie als deze in handen hebben. Dus ik lanceer Hourly zo minimaal als maar kan: geen marketingbudget, geen groeiteam, geen retentiemachinerie, alleen een gratis app die het werk goed doet en een schone projectpagina op deze site. Wat ik daadwerkelijk meet, is of een fatsoenlijke gratis tool, gebouwd in een fractie van de tijd die het twee jaar geleden zou hebben gekost, een merkbaar effect kan hebben op installaties en aandacht in een categorie waarin elke gevestigde speler geld vraagt. Wat er over Hourly in schrijfwerk uitkomt, gaat over het experiment zelf — de productbeslissingen achter het gratis en lokaal blijven, wat ik bewust niet heb gebouwd en waarom, en de adoptiecijfers zodra die er zijn en de moeite waard zijn om over te praten.

### Systematisch tradingonderzoek

Naast mijn hoofdbaan draai ik systematisch tradingonderzoek als persoonlijk project in mijn eigen tijd. De huidige iteratie is een systematische forex-strategie die via een Node.js broker bridge met MetaTrader 5 praat. Hij zit in paper-tradingvalidatie, niet in live capital. Er zit zinnige paper-trading-risicobeheersing in — een circuit breaker die gekalibreerd is tegen de backtested drawdown zodat live volatiliteit een hard plafond heeft voordat de strategie zichzelf op pauze zet voor evaluatie. Verder houd ik de inhoud over dit systeem zwaar geredigeerd: geen gepubliceerde performance-cijfers, geen parameterwaarden, geen specifieke instrumentlijsten, niks waarmee een lezer de strategie kan reverse-engineeren uit wat ik op deze blog schrijf. Dat is een bewuste redactionele regel, geen bescheidenheid.

De grootste uitdaging op dit project is niet het tradingdeel — het is het onderzoeksdeel. De pipeline is rekenintensief, en een betekenisvolle dataset genereren op één enkele strategievariant duurt ongeveer een week voordat hij terugkomt. Dat is een lange feedback loop vergeleken met elk ander softwarewerk dat ik doe, waar ik gewend ben iets te veranderen en het effect in seconden of hooguit minuten te zien. Een week tussen hypothese en resultaat zitten is de moeilijkste aanpassing van het hele project geweest, en het bepaalt mede welke experimenten ik überhaupt bereid ben te draaien — dure runs krijgen minder pogingen, en er is een serieuze discipline nodig om niet halverwege een run dingen te blijven bijstellen terwijl de data nog binnenkomt. Wat er uit dit deel van het werk in schrijfwerk komt, is engineering-eerst: het ontwerp van de onderzoeksharness, de broker-integratie, en het statistische denkwerk dat het echte werk doet om een echt voordeel te onderscheiden van een geluks-backtest. Ik schrijf geen "ik heb $X verdiend vorige maand"-posts, ik publiceer geen live P\&L, ik verkoop geen signalen, en ik geef geen financieel advies.

### AI-agent-experimenten

Ik besteed ook tijd aan routed-model agentic systems, met gemengde gevoelens over de resultaten tot nu toe. De architectuur waar ik op aan het itereren ben, gebruikt een klein redeneermodel (Nanbeige4-3B) als orchestrator die afhankelijk van de taakcomplexiteit doorschakelt naar grotere modellen — DeepSeek V3.2 voor zwaarder redeneerwerk, een lokale R1-32B voor werklasten die ik privé wil houden, en Claude Sonnet voor Nederlandstalige klanttekst.

De eerlijke conclusie is dat ik mezelf tijdens het bouwen van het framework keer op keer betrapte op het curve-fitten van de scaffolding om een specifiek antwoord te produceren in plaats van het hardere werk te doen om het systeem daadwerkelijk door de taak heen te laten redeneren. Dat is geen prettige plek om te landen. Daarnaast was de operationele wrijving reëel — `<think>`-block-bloat die context windows opvreet op lange sessies, routinglatency op de kleine orchestrator als die in het hot path zat, en de fragiele context-engineering die nodig was om de stack coherent te houden over een taak met meerdere stappen. En de kosten hielpen ook geen van beide kanten van de opstelling. Voor gevoelige werklasten viel ik terug op commerciële LLM-API's die per miljoen tokens werden afgerekend en direct werden betaald; voor middelgrote self-hosted modellen probeerde ik te huren op Runpod en de rekening liep sneller op dan de onderzoeksopbrengst rechtvaardigde. Geen van beide uiteinden van het spectrum was houdbaar, en het project staat als gevolg daarvan op het tweede plan.

Ik denk nog steeds dat dit ecosysteem uiteindelijk naar kleine modellen toe moet. De rekenkosten van de huidige frontier-LLM's zijn geen houdbare basis om software op te bouwen, en de recente verbeteringen in de capaciteit van kleine modellen zijn genoeg geweest dat ik van plan ben het project te herstarten. Als ik dat doe, verschuift de focus: minder "een model dat op eigen houtje redeneert," meer "goede tools bouwen die een LLM kan gebruiken." Dat is een ander probleem dan orchestratie — het zit dichter bij traditionele software engineering met een LLM als één van de aanroepers — en uit wat ik tot nu toe gezien heb, is het een veel productiever kader dan proberen een routed stack zelfstandig een lange taak te laten dragen. Wat er uit dit project in schrijfwerk komt, gaat precies over die verschuiving — wat ik probeerde, wat niet werkte, en waar de tweede poging op gebouwd is.

## Waar ik hier over ga schrijven

Drie inhoudelijke pijlers. Alles op deze site wordt eerst in het Engels geschreven en daarna naar het Nederlands vertaald, dus elke post die op `.com` landt krijgt een gekoppelde Nederlandse versie op `.nl`. Er is geen aparte Nederlandstalige redactionele stroom en geen onderwerp dat op één van de twee domeinen leeft en op het andere niet.

De pijlers gaan niet over specifieke projecten, want projecten komen en gaan op een site als deze. Ze beschrijven de drie werkmodi die daadwerkelijk inhoud opleveren die het opschrijven waard is.

De eerste pijler is **het onderhouden en uitbouwen van productiesystemen**. De vorm van mijn hoofdbaan: een draaiend platform met echte gebruikers, echte data, en een lange lijst operationele randgevallen die pas opduiken zodra het systeem een tijdje in gebruik is. Posts in deze pijler gaan over de realiteit op infrastructuurniveau van zoiets in leven houden en laten doorgroeien — achtergrondmigraties, index- en cache-valkuilen, performance-schuld die je hebt geërfd van eerdere beslissingen, evaluaties van extensies of dependencies met eerlijke tradeoffs, en de architectuurkeuzes die je vandaag anders zou maken als je vanaf nul zou beginnen. Op dit moment wordt deze pijler voornamelijk gevoed door de Magento-stack bij WorkWear4All, maar het kader is algemener; elk draaiend systeem met echte gebruikers is geldig terrein.

De tweede pijler is **ideeën onderzoeken met data-science-methoden**. Trager werk, langere feedback loops, meer geduld. Het tradingonderzoek is het huidige voorbeeld, maar de pijler dekt elk project waarin de loop is: een hypothese vormen, een harness bouwen om hem te testen, het experiment draaien, en de output eerlijk interpreteren. Posts hier gaan over de engineering van onderzoek — hoe je een harness bouwt die niet stilletjes tegen je liegt, hoe je nadenkt over steekproefgroottes en statistische significantie, hoe je experimenten ontwerpt als één enkele run dagen nodig heeft om terug te komen, en hoe je een signaal van een fit onderscheidt. Geen rijk-worden-verhalen. Geen signalen verkopen. Waar het onderliggende werk commercieel gevoelig is, worden de posts zwaar geredigeerd op alles waarmee een lezer een specifieke strategie kan reverse-engineeren.

De derde pijler is **het shippen en evalueren van onafhankelijke software-experimenten**. Kleine producten gelanceerd op een bewuste hypothese, met eerlijke verslagen van wat er is gebeurd — inclusief de producten die niets zijn geworden. Op dit moment wordt deze pijler gevoed door Hourly (zelf opgezet als experiment op wat generatieve AI doet met een paywalled SaaS-categorie), een geplande post-mortem op de webshop die ik heb gelanceerd en heb stopgezet, en waar de herstart van de AI-agent ook in uitmondt. De rode draad: ship het ding, meet het resultaat, schrijf het zonder opsmuk op, en ga door. Geen lanceerdag-hype op iets wat in werkelijkheid nog niet is gebruikt.

Bewust buiten scope voor deze site: algemene AI- en LLM-opiniestukken, persoonlijk financieel advies voor niet-ondernemers, consumentenproductreviews, politieke commentaren, en meta-posts over bloggen zelf. Dat is een bewuste scope-keuze, zodat de site niet wegzakt in wat er op enig moment populair is. Als een onderwerp hier staat, dan is dat omdat ik het doe, niet omdat ik er een mening over heb.

## Hoe je dit kunt volgen

![1.00](https://media.ninokroesen.com/uploads/2026/04/d0c43653888860d81d12/_1280.jpeg)

De site draait op twee domeinen: ninokroesen.com voor Engels, ninokroesen.nl voor Nederlands — dezelfde auteur, dezelfde backend, gekoppeld via hreflang. Posts worden in het Engels geschreven en naar het Nederlands vertaald, dus de twee domeinen blijven synchroon; wat op het ene domein verschijnt, heeft een tegenhanger op het andere. Mijn code staat op github.com/vultwo, dat is waar een deel van de tooling en libraries waar ik in posts naar verwijs gepubliceerd worden. RSS-autodiscovery zit in de layout ingebouwd, dus elke moderne reader pikt de feed op zonder extra werk aan jouw kant. Ik voeg later misschien ook een opt-in e-mailnieuwsbrief toe voor lezers die liever e-mail dan RSS hebben; als ik dat doe, wordt hij laagfrequent, en er komt geen modal omhoog die om je adres vraagt voordat je überhaupt iets gelezen hebt.

Als één van de hierboven beschreven dingen overlapt met iets dat jij aan het bouwen bent, of als er een interessant project of vraag is waar het de moeite waard is om over te sparren, dan staan mijn contactgegevens op de about-pagina. Ik lees wat er binnenkomt.

```widget
type: newsletter
variant: inline
```