23.125 historische scores in één middag

In klassieke softwareontwikkeling zou wat ik laatst deed een sprint van twee weken zijn geweest. Misschien drie. Een team van vier mensen, dagelijkse standups, code reviews, sprint retrospective. Aan het einde een feature gepubliceerd, met een changelog item.

Wat ik heb gedaan: één middag. In mijn eentje. Tweeëntwintigduizend honderd vijfentwintig historische score punten gegenereerd, getoetst en in een database gezet. Vier verschillende factor implementaties, ieder met een ander berekeningsmodel, allemaal werkend.

Niet omdat AI tools tien keer meer code per minuut typen. Het is iets anders, en het heeft te maken met leren van fouten.

Wat is er gebeurd

Mijn handelssysteem berekent vier factoren: Value, Quality, Momentum en Catalyst. Elk daarvan is een aparte module die voor 552 aandelen op een gegeven datum een score uitrekent.

Voor de backtest had ik historische scores nodig. Niet alleen vandaag, maar voor elke maand sinds juni 2022. Dat is 51 maanden. Vier factoren keer 552 aandelen keer 51 datums = 23.125 score berekeningen, plus alle bijhorende fundamentele data.

In één middag was alles berekend en in de database opgeslagen. Niet door magie. Door iets specifieker.

De eerste keer was hard

Mijn Momentum factor, de eerste die ik bouwde, kostte mij drie iteraties. Drie pijnlijke iteraties.

Iteratie 1: Cursor schreef code die werkte voor één datum. Ik draaide het op meerdere datums. Crash.

Iteratie 2: Probleem gevonden, namelijk dat ik over verschillende handelsdagen aan het rekenen was alsof het allemaal dezelfde lijst was. Cursor herschreef. Werkte voor de meeste datums maar gaf rare scores voor een paar.

Iteratie 3: Bug zat in hoe ik de prijsgeschiedenis ophaalde. Voor elk aandeel apart moest ik de meest recente N handelsdagen pakken, in plaats van een vast aantal kalenderdagen. Cursor herschreef. Werkte.

Tussen iteratie 1 en 3 zat ongeveer vijf uur van mijn dag. Twee uur Cursor laten coderen, twee uur testen, één uur debuggen. Een hele middag.

En toen kwam de tweede

Op het moment dat Momentum werkte, dacht ik: nu moet ik nog drie keer dit doen voor Value, Quality en Catalyst. Vijf uur per stuk. Vijftien uur extra.

Maar voor ik aan Value begon, deed ik iets dat ik tot dan toe nooit had gedaan. Ik schreef op wat ik geleerd had.

Niet als blog, niet als documentatie voor anderen. Als een lijst van principes die voor mijn factor implementaties moesten gelden. Drie regels:

1. Geen vaste vensters in scripts. Altijd parameterizable.
2. Gebruik per-ticker groepering voor cross-period berekeningen.
3. Voor fundamentele data: 60 dagen buffer voor look-ahead bias.

Drie regels. Niets baanbrekend. Standaard kennis voor wie data analyse heeft gedaan. Maar drie regels die mij vijf uur debuggen hadden gekost om te ontdekken.

Ik nam die drie regels en plakte ze als requirements bovenaan mijn volgende prompt voor Cursor. "Bouw de Value factor. Houd rekening met deze drie principes."

Value was af in vijftien minuten.

Daarna ging het hard

• Quality factor: vijftien minuten. Cursor wist al wat hij niet moest doen.
• Catalyst factor: vijftien minuten. Zelfde verhaal.

Tussen Momentum (vijf uur) en de andere drie (samen 45 minuten) zat een factor 20 in tempo. Niet omdat ik beter ben geworden in coderen. Niet omdat Cursor sneller is geworden in tikken. Omdat ik geleerd had wat de valkuilen waren en die expliciet naar Cursor had gecommuniceerd.

Lessons-driven prompts, noem ik het nu. Het idee: na elke pijnlijke debugging sessie, schrijf de drie tot vijf principes op die je ervan geleerd hebt. Hergebruik die lijst als requirements in je volgende prompt. Cursor doet wat hij moet doen, met de constraints die je vorige keer met pijn ontdekt hebt.

Waarom dit werkt

Klassieke softwareontwikkeling kent dit patroon ook, maar dan informeel. Senior engineers leren wat junior engineers niet leren. Iemand die tien jaar Java doet, weet welke patterns werken en welke niet, en past ze impliciet toe. Een nieuwe engineer maakt dezelfde fouten, leert ze opnieuw, en wordt langzaam senior.

Met AI is die kennis niet ingebakken. Cursor weet veel, maar niet wat specifiek voor mijn project geldt. Mijn database structuur, mijn data sources, mijn conventies. Dat moet ik hem vertellen. Iedere keer.

Maar ik hoef niet vanaf nul te beginnen. Ik kan een lijst bijhouden van wat ik geleerd heb. Vergelijkbaar met een persoonlijk codeboek. Voor elk type taak: hier zijn de fouten die ik in het verleden heb gemaakt, hier zijn de aannames die niet bleken te kloppen, hier zijn de patronen die wel werken.

Voor mijn factor refactors: drie regels op één briefje. Vijf uur naar vijftien minuten. Voor andere taken zou de lijst anders zijn.

Wat dit betekent voor anderen

Ik bouw een handelssysteem omdat ik dat leuk vind, en omdat ik wil zien hoever je kunt komen met AI als je een specifiek doel hebt. Maar dit lessons-driven patroon werkt niet alleen voor handelssystemen. Het werkt voor elk complex software project waar je AI laat coderen.

Drie tips voor wie dit zelf wil proberen:

Tip één: na elke debugging sessie, schrijf op wat je geleerd hebt. Niet als roman, als bullet points. Drie tot vijf zinnen.

Tip twee: bewaar die lessen ergens centraal in je project. Een LESSONS_LEARNED.md file werkt goed. Voor mij is het een levend document dat ik bij elke prompt kan raadplegen.

Tip drie: gebruik die lessen actief als requirements in nieuwe prompts. Niet "lees mijn LESSONS_LEARNED.md", want dat doet de AI niet vanzelf. Specifiek copy-paste de drie regels die voor deze taak relevant zijn, bovenaan de prompt.

De rode draad

Wat een programmeur vroeger deed: zelf de oplossing bedenken en de code typen. Wat ik nu doe: ik bedenk de oplossing, formuleer de requirements, en laat de code typen door iemand anders. Dat anders is in dit geval Cursor.

Het resultaat: meer tijd om na te denken over wat de juiste oplossing is, minder tijd in syntax. Maar ook: een nieuw soort werk, namelijk het cureren van mijn eigen lessen. Wat heb ik geleerd dat ik volgende keer moet meegeven?

Die kennis kan in je hoofd zitten, maar dat is fragiel. Bij mij ligt het in een file. Een file die ik letterlijk naar Cursor kopieer wanneer dat relevant is. Het verschil tussen impliciet en expliciet wordt dan ineens belangrijk.

Voor mijn 23.125 score punten op één middag betekende het: vijf uur fouten maken, daarna 45 minuten profiteren van die fouten. Niet snel coderen, maar slim coderen. Het tempo is niet de winst. De discipline om bij te houden wat je leert, dat is de winst.