Zes commits in één zaterdag

Zaterdag 16 mei 2026. Tussen 09:00 en 17:00 NL pushte ik zes productie commits naar mijn algo trading repo. Allemaal getest, allemaal geslaagd door CI, allemaal automatisch gedeployed naar Render. Niet één regel code zelf getypt.

Dat klinkt als een marketing claim. Het was geen marketing. Het was zaterdag.

De zes commits

Voor de transparantie, hier waar de dag over ging:

Commit 1 (5e49fce3): factory pattern voor IBKR account ID. Drie scripts fixed, één nieuwe file ibkr_client_factory.py. Plus tests.

Commit 2 (b1da1112): fill sync lookback window. Removed 24h filter, replaced with 30-day maximum. Tests + constant definitie.

Commit 3 (29471a0f): migratie van ib.fills() naar reqExecutions(ExecutionFilter). Plus SMART/AEB ticker mapping fix.

Commit 4 (ad2d92fe): diagnostic probe script probe_reqexecutions.py om drie time format varianten te testen.

Commit 5 (9d609b77): standalone sync_positions.py met IBKRClient method en 4× daily Render cron config.

Commit 6 (handover docs): twee onderzoeksdocumenten gecommit, SYNC_FILLS_INVESTIGATION.md en SYNC_FILLS_INVESTIGATION_PART2.md.

Drie code-changes, twee infra-changes, één pure documentatie commit. 506 tests groen aan eind van de dag.

Wat ik wel deed

Ik dacht. Specifiek: ik formuleerde wat het probleem was. Voor elke commit was er eerst een diagnose-fase waar ik probeerde te begrijpen waarom iets niet werkte. Voor commit 1 was dat: "waarom toont dashboard nul terwijl IBKR veertien laat zien." Drie hypothesen opgeschreven, één gevalideerd via Render Shell probe.

Daarna schreef ik een prompt voor Cursor. Geen één-regel "fix the bug". Een spec van anderhalve A4 met:

• Wat het probleem is in mijn eigen woorden
• Welk pad ik wil dat gevolgd wordt (factory pattern in plaats van direct hardcode)
• Welke files aangeraakt mogen worden en welke niet
• Welke tests minimaal moeten worden toegevoegd
• Wat ik niet wil zien (geen defensive code dat het IBKR account silently masked)
• Commit message format

Cursor implementeerde. Ik reviewde de diff. Soms accepteerde ik direct, soms had ik comments. Op één punt vroeg Cursor wat overcomplexe defensieve code in te bouwen die masking-gedrag op zou leveren. Ik wees dat af en vroeg om een specifiekere uitwerking. Tweede iteratie was raak.

Wat mijn AI-assistent deed

Tussen Cursor en mij zit nog een laag: Harry de hulp, mijn Claude-gebaseerde sparringpartner. Niet om code te genereren, daar is Cursor voor. Harry helpt me met:

Strategische beslissingen: voor commit 5 (sync_positions) was de vraag of we het als evening cron of als 4× per dag moesten draaien. Harry's analyse van mogelijke race conditions met fill_sync hielp me 4× per dag te kiezen, met clientId 12 die overlap met clientId 11 voorkomt.

Diagnostic-driven approach: bij commit 4 (probe script) was de keuze om eerst rauwe data op te halen voordat ik een fix zou bouwen. Harry pushte me daartoe in plaats van direct nog een fix te proberen. Goed dat hij dat deed, want anders had ik commit 3 mogelijk opnieuw gewoon herschreven zonder echt te begrijpen waarom het niet werkte.

Pushback op risk-gerelateerde acties: ik was vrijdag 26 uur achter mijn laptop geweest. Harry had op een moment specifiek gezegd: "Erik, deze fix raakt live trading state. Niet doen onder vermoeidheid. Wacht tot morgen." Dat hielp me commit 5 pas zaterdag te doen in plaats van vrijdagavond.

De cognitieve verdeling

Drie rollen, drie soorten werk:

Erik denkt: wat is het probleem, welk pad volgen, wanneer wel of niet implementeren, wanneer accepteren of afwijzen.

Harry sparrt: bouwt geen code, helpt met strategische keuzes, dwingt me hypotheses op te schrijven voor ik fixt, pusht terug op risk-gerelateerde acties onder vermoeidheid.

Cursor bouwt: leest mijn prompt, schrijft code, draait tests, doet commit, push. Geen strategische keuzes, alleen uitvoering van een specifieke spec.

Het werkt omdat geen van de drie te veel taken op zich neemt. Cursor wordt niet gevraagd "wat moet ik doen", die vraag staat al opgelost als de prompt geschreven wordt. Harry wordt niet gevraagd om code te schrijven, die rol is bij Cursor. Ik word niet gevraagd om elke regel code zelf te typen, want dat is precies wat de hele setup ontwerpt om te voorkomen.

Wat lastig is aan deze workflow

Eerlijke check: dit klinkt schoon, maar in de praktijk is het rommelig.

Cursor implementeert sneller dan ik kan reviewen. Bij commit 1 had ik een diff van 200 regels. Cursor had die in twee minuten klaar. Ik had vijftien minuten nodig om elk stuk te begrijpen en te checken of het deed wat ik bedoelde. Die asymmetrie is structureel. Hoe sneller AI bouwt, hoe disciplineerder ik moet reviewen.

Soms wil Cursor te ver gaan. Bij commit 3 (reqExecutions migratie) wilde Cursor naast de migratie ook een retry mechanism met exponential backoff toevoegen. Niet gevraagd, mogelijk nuttig, maar verbreedt de scope van de commit. Ik wees dat af en hield het bij wat in de spec stond.

Soms ben ik te snel met goedkeuren. Bij commit 5 had ik eigenlijk de IBKR sync_positions_from_ibkr method eerder moeten reviewen, voordat de cron config werd toegevoegd. Door beide in één commit te accepteren werd de reviewbare unit te groot. Niet kapot, maar wel een tactische les voor volgende keer.

De take-away

Geen regel code typen klinkt als marketing tot je ziet wat het werkelijk vereist. Een spec die zo specifiek is dat Cursor niet kan dwalen. Een review-discipline die niet inzakt onder snelheid. Een sparringpartner die je vraagt te denken voordat je vraagt te bouwen. Een set van rules en handover docs die elke sessie consistent maken.

Zes commits in één zaterdag is niet snel. Het is het resultaat van twee jaar opgebouwde workflow. Het systeem is sneller dan ik alleen had kunnen zijn, niet omdat AI magisch is, maar omdat de drie rollen elkaar versterken zonder elkaar in de weg te zitten.

Vrijdag had de marathon zes commits geblokkeerd op één bug. Zaterdag werden zes commits gepushed. Niet omdat ik beter was. Omdat de juiste persoon op het juiste moment het juiste werk deed.