Claude Code voor prestatieonderzoek: een meetbare workflow

Waarom prestatiewerk fout gaat zonder meten

Prestatiebugs nodigen uit tot giswerk. Iemand merkt dat een pagina traag aanvoelt of dat een API time-outs geeft, en de snelste stap is om code te "schoonmaken", caching toe te voegen of een lus te herschrijven. Het probleem is dat "voelt traag" geen metric is en "netter" niet per se sneller betekent.

Zonder meten verslijten teams uren aan het veranderen van de verkeerde dingen. Het hot path kan in de database, het netwerk of een onverwachte allocatie zitten, terwijl het team code oppoetst die nauwelijks invloed heeft. Erger nog: een wijziging die slim lijkt kan de prestaties verslechteren: extra logging in een strakke lus, een cache die druk op geheugen verhoogt, of parallel werk dat lock-contentie creëert.

Giswerk brengt ook risico's voor correcte werking met zich mee. Als je code verandert om het sneller te maken, kun je resultaten, foutafhandeling, ordering of retries veranderen. Als je correctheid en snelheid niet samen controleert, kun je een benchmark "winnen" en tegelijk een bug deployen.

Behandel prestatie als een experiment, niet als een debat. De cyclus is eenvoudig en herhaalbaar:

• Kies één metric die de pijn representeert (latentie, throughput, CPU, geheugen, DB-tijd).
• Leg een baseline vast onder gelijke condities.
• Verander één klein ding.
• Meet opnieuw en vergelijk.

Veel overwinningen zijn bescheiden: 8% van p95-latentie weghalen, piekgeheugen met 50 MB verlagen of één databasequery schrappen. Die overwinningen tellen nog steeds, maar alleen als ze gemeten, geverifieerd en reproduceerbaar zijn.

De workflow: meten, hypothese, veranderen, her-meten

Dit werkt het beste als een lus, niet als een eenmalig "maak het sneller"-verzoek. De lus houdt je eerlijk omdat elke actie terug te voeren is op bewijs en een cijfer dat je kunt volgen.

Een duidelijke sequence:

• Meten: kies één metric en leg een baseline vast.
• Hypothese: leg uit wat je denkt dat traag is en waarom.
• Veranderen: maak de kleinst mogelijke wijziging die de hypothese test.
• Her-meten: voer dezelfde meting opnieuw uit en vergelijk.

Elke stap beschermt je tegen een ander soort zelf-bedrog. Eerst meten stopt je ervan iets te "fixen" dat geen echt probleem was. Een opgeschreven hypothese voorkomt dat je vijf dingen tegelijk verandert en vervolgens raadt welk ding effect had. Minimale wijzigingen verkleinen het risico op het breken van gedrag of het toevoegen van nieuwe bottlenecks. Her-meten vangt placebo-wins (zoals snellere runs door een warme cache) en onthult regressies.

"Klaar" is geen gevoel. Het is een resultaat: de doelmetric bewoog in de juiste richting en de wijziging veroorzaakte geen duidelijke regressies (fouten, hoger geheugen, slechtere p95-latentie of tragere endpoints in de buurt).

Weten wanneer te stoppen hoort ook bij de workflow. Stop wanneer winst afvlakt, wanneer de metric goed genoeg is voor gebruikers, of wanneer de volgende stap grote refactors vereist voor kleine winst. Prestatiewerk heeft altijd opportunity cost; de lus helpt je tijd te besteden waar het rendeert.

Kies de metric en vergrendel een baseline

Als je vijf dingen tegelijk meet, weet je niet wat verbeterde. Kies één primaire metric voor dit onderzoek en behandel alles anders als ondersteunende signalen. Voor veel gebruikersgerichte problemen is die metric latentie. Voor batchwerk kan het throughput, CPU-tijd, geheugenverbruik of zelfs kosten per run zijn.

Wees specifiek over het scenario. "De API is traag" is te vaag. "POST /checkout met een typische winkelwagen van 3 items" is meetbaar. Houd inputs stabiel zodat de cijfers iets betekenen.

Schrijf de baseline en de omgevingsdetails op voordat je code aanraakt: datasetgrootte, machinetype, build-mode, feature flags, concurrency en warmup. Deze baseline is je anker. Zonder die anchor kan elke verandering als vooruitgang lijken.

Voor latentie vertrouw je op percentielen, niet alleen op een gemiddelde. p50 toont de typische ervaring, terwijl p95 en p99 de pijnlijke staart blootleggen waar gebruikers over klagen. Een wijziging die p50 verbetert maar p99 verslechtert kan nog steeds als trager aanvoelen.

Bepaal vooraf wat "betekenisvol" is zodat je geen ruis viert:

• Latentie: minstens 10% verbetering in p95 (of een vaste drempel zoals 50 ms)
• Throughput: minstens 5% meer requests per seconde bij hetzelfde foutpercentage
• CPU of geheugen: voldoende reductie om schalen of crashes te voorkomen
• Kosten: een meetbare daling per run of per 1.000 requests

Als deze regels zijn vastgesteld, kun je ideeën testen zonder het doel te verplaatsen.

Verzamel bewijs met profilering en eenvoudige metrics

Begin met het eenvoudigste signaal dat je vertrouwt. Eén enkele timing rond een request kan je vertellen of je een echt probleem hebt en grofweg hoe groot het is. Diepere profilering bewaar je voor wanneer je moet uitleggen waarom het traag is.

Goed bewijs komt meestal uit een mix van bronnen:

• App-logs (requestduur, foutpercentage, traagste endpoints)
• APM-traces (waar tijd wordt besteed over services)
• Profiler-output of flame graphs (hot functions en call stacks)
• Database-statistieken (trage queries, lock-waits, cache hit rate)
• Infrastructuurmetrics (CPU, geheugen, netwerk, container-restarts)

Gebruik simpele metrics voor de vraag "is het trager, en hoeveel?" Gebruik profilering wanneer de vraag is "waar gaat de tijd heen?" Als p95-latentie verdubbelde na een deploy, begin met timings en logs om de regressie te bevestigen en af te bakenen. Als timings laten zien dat het merendeel van de vertraging in je app-code zit (niet de DB), dan kan een CPU-profiler of flame graph naar de exacte functie wijzen die gegroeid is.

Houd metingen veilig. Verzamel wat je nodig hebt om prestatie te debuggen, niet user content. Geef de voorkeur aan aggregaten (duur, aantallen, groottes) boven ruwe payloads en redacteer identifiers standaard.

Ruis is echt, dus neem meerdere samples en noteer outliers. Voer hetzelfde request 10 tot 30 keer uit en registreer mediaan en p95 in plaats van één beste run.

Schrijf het exacte testrecept op zodat je het na wijzigingen kunt herhalen: omgeving, dataset, endpoint, request-bodygrootte, concurrency-niveau en hoe je resultaten hebt vastgelegd.

Zet bewijs om in een heldere hypothese

Begin met een symptoom dat je kunt benoemen: "p95-latentie stijgt van 220 ms naar 900 ms tijdens verkeerspieken", "CPU staat op 95% op twee cores" of "geheugen groeit met 200 MB per uur." Vage symptomen zoals "het voelt traag" leiden tot willekeurige wijzigingen.

Vertaal vervolgens wat je hebt gemeten naar een verdachte zone. Een flame graph kan laten zien dat de meeste tijd in JSON-encodering zit, een trace kan een traag call path tonen of database-statistieken kunnen één query aanwijzen die de meeste tijd opslokt. Kies het kleinste gebied dat het grootste deel van de kosten verklaart: een functie, één SQL-query of één externe aanroep.

Een goede hypothese is één zin, toetsbaar en gekoppeld aan een voorspelling. Je vraagt hulp om een idee te testen, niet om een tool alles sneller te laten maken.

Een eenvoudige hypothese-template

Gebruik dit format:

• Omdat (bewijs), (verdachte) veroorzaakt (symptoom).
• Als we (specifiek gedrag) veranderen, dan zou (metric) verbeteren met (ruwe hoeveelheid).
• We weten dat het werkte als (her-meetresultaat).

Voorbeeld: "Omdat het profiel 38% van de CPU in SerializeResponse laat zien, veroorzaakt het aanmaken van een nieuwe buffer per request CPU-spikes. Als we een buffer hergebruiken, zou p95-latentie met ongeveer 10–20% moeten dalen en CPU onder gelijke load met 15% moeten afnemen."

Houd jezelf eerlijk door alternatieven te benoemen voordat je code aanraakt. Misschien is het trage deel juist een upstream dependency, lock-contentie, een hogere cache-missrate of een rollout die payload-grootte heeft verhoogd.

Schrijf 2 tot 3 alternatieve verklaringen op en kies de verklaring die het beste door je bewijs wordt ondersteund. Als je wijziging de metric niet beweegt, heb je meteen de volgende hypothese klaar.

Hoe je Claude Code gebruikt zonder in giswerk te vervallen

Claude is het meest nuttig in prestatiewerk wanneer je het behandelt als een zorgvuldige analist, niet als een orakel. Houd elk voorstel gekoppeld aan wat je hebt gemeten en zorg dat elke stap weerlegbaar is.

Geef het echte inputs, geen vage omschrijving. Plak klein, gefocust bewijs: een profileringssamenvatting, enkele logregels rond de trage request, een queryplan en het specifieke codepad. Voeg "voor"-cijfers toe (p95-latentie, CPU-tijd, DB-tijd) zodat het je baseline kent.

Vraag het uit te leggen wat de data suggereert en wat het niet ondersteunt. Forceer concurrerende verklaringen. Een bruikbare prompt eindigt met: "Geef me 2–3 hypothesen, en voor elk, vertel wat het zou falsificeren." Dat voorkomt verankering op het eerste plausibele verhaal.

Voordat je iets verandert, vraag om het kleinst mogelijke experiment dat de leidende hypothese kan valideren. Houd het snel en omkeerbaar: voeg één timer rond een functie toe, zet één profiler-flag aan of voer één DB-query met EXPLAIN uit.

Als je een strakke structuur voor de output wil, vraag dan om:

• Wat het bewijs aangeeft (en de zekerheid)
• 2–3 hypothesen met een falsificatietest
• De kleinste code- of configwijziging om de top-hypothese te testen
• Exact welke metric je opnieuw moet meten en de verwachte richting

Als het geen specifieke metric, locatie en her-testplan kan noemen, ga je terug naar giswerk.

Maak minimale, omkeerbare wijzigingen

Nadat je bewijs en een hypothese hebt, weersta de drang om "alles schoon te maken." Prestatiewerk is het makkelijkst te vertrouwen wanneer de codewijziging klein en eenvoudig te herstellen is.

Verander één ding tegelijk. Als je in één commit een query tweak, caching en refactor doet, weet je niet wat hielp (of schade aanrichtte). Single-variable-wijzigingen maken de volgende meting betekenisvol.

Schrijf vooraf op wat je numeriek verwacht. Voorbeeld: "p95-latentie zou moeten dalen van 420 ms naar onder de 300 ms en DB-tijd met ongeveer 100 ms verminderen." Als het resultaat die doelstelling mist, leer je snel dat de hypothese zwak of onvolledig was.

Houd wijzigingen omkeerbaar:

• Geef de voorkeur aan een kleine diff die je makkelijk kunt revert-en.
• Zet de wijziging achter een simpele flag zodat je hem snel kunt uitzetten.
• Vermijd drive-by refactors die namen, format en logica tegelijk veranderen.
• Houd scope strak: één endpoint, één hot path, één dure aanroep.
• Voeg een korte notitie toe in het commitbericht met de verwachte before/after metrics.

"Minimaal" betekent niet "triviaal." Het betekent gefocust: cache één dure functie, verwijder één herhaalde allocatie in een strakke lus of stop met werk voor requests die het niet nodig hebben.

Voeg lichte timing toe rond het vermoedelijke bottleneck zodat je kunt zien wat er bewoog. Eén timestamp voor en na een aanroep (gelogd of als metric vastgelegd) kan bevestigen of je wijziging het trage deel raakte of dat je tijd elders verschuift.

Her-meten en beslissen wat je daarna doet

Na een wijziging voer je exact hetzelfde scenario uit dat je voor de baseline gebruikte: dezelfde inputs, omgeving en load shape. Als je test van caches of warm-up afhangt, maak dat expliciet (bijvoorbeeld: "eerste run koud, volgende 5 runs warm"). Anders "vind" je verbeteringen die puur geluk waren.

Vergelijk resultaten met dezelfde metric en percentielen. Gemiddelden kunnen pijn verbergen, dus houd p95 en p99 in de gaten, plus throughput en CPU-tijd. Voer genoeg herhalingen uit om te bepalen of de cijfers zich stabiliseren.

Controleer voor je juicht op regressies die niet in één kopnummer verschijnen:

• Correctheid: responses nog steeds volgens verwachting
• Foutpercentage: timeouts, 5xx, retries
• Geheugen: hogere piek of steady growth over runs
• Staartlatentie: p99 slechter geworden ondanks verbetering in p50
• Resourcekosten: CPU of DB-belasting is omhoog gegaan

Beslis vervolgens op basis van bewijs, niet hoop. Als de verbetering echt is en je geen regressies hebt geïntroduceerd, houd de wijziging. Als de resultaten gemengd of rumoerig zijn, revert en vorm een nieuwe hypothese of isoleer de wijziging verder.

Als je op een platform werkt zoals Koder.ai, kan het nemen van een snapshot vóór experimenten rollback tot één stap maken, wat het veiliger maakt om gedurfde ideeën te testen.

Schrijf tenslotte op wat je geleerd hebt: de baseline, de wijziging, de nieuwe cijfers en de conclusie. Dit korte verslag voorkomt dat de volgende ronde dezelfde doodlopende paden betreedt.

Veelgemaakte fouten die tijd verspillen

Prestatiewerk ontspoort vaak wanneer de lijn tussen wat je mat en wat je veranderde verloren raakt. Houd een schone bewijsketen zodat je met vertrouwen kunt zeggen wat het verschil maakte.

De herhalende fouten:

• Het verkeerde doel fixen: je viert een snellere mediaan (p50), maar de staartlatentie (p95 of p99) is nog steeds slecht.
• Een heleboel dingen tegelijk veranderen: refactors, caching en query-tweaks in één commit maken onduidelijk wat hielp.
• Geloven in één rumoerige run: een lokale benchmark die 20% heen en weer schommelt is geen bewijs.
• Eén profiel behandelen als de ultieme waarheid: een flame graph wijst naar JSON-parsing, maar requests stapelen op tijdens DB-tragerheid.
• Appels met peren vergelijken: verschillende datasets, feature flags, hardware of concurrency-niveaus en toch conclusies trekken.

Een klein voorbeeld: een endpoint lijkt traag, dus je tuneert de serializer omdat die hot is in een profiel. Je test daarna met een kleinere dataset en het lijkt sneller. In productie wordt p99 slechter omdat de database nog steeds de bottleneck is en je wijziging de payloadgrootte verhoogde.

Als je Claude Code gebruikt om fixes voor te stellen, houd het kort en concreet. Vraag om 1–2 minimale wijzigingen die bij het verzamelde bewijs passen, en eis een her-meetplan voordat je een patch accepteert.

Een korte checklist voordat je het ‘sneller’ noemt

Snelheidsclaims vallen uit elkaar als de test vaag is. Voordat je viert, zorg dat je kunt uitleggen wat je mat, hoe je het mat en wat je veranderde.

Begin met het noemen van één metric en het opschrijven van de baseline. Voeg details toe die cijfers beïnvloeden: machinetype, CPU-load, datasetgrootte, build-mode (debug vs release), feature flags, cache-state en concurrency. Als je de setup morgen niet kunt reproduceren, heb je geen betrouwbare baseline.

Checklist:

• Metric en baseline zijn vastgelegd met omgevingsnotities (hardware, config, data, warm of koud cache).
• Teststappen zijn opgeschreven en reproduceerbaar.
• Je hebt één hypothese met een voorspelling (bijvoorbeeld: "Als we N+1-queries verwijderen, zou p95 ~30% dalen").
• Je maakte één kleine, omkeerbare wijziging en documenteerde precies wat bewoog (bestand, functie, query, instelling).
• Je her-meten met meerdere samples en vergeleek gelijk met gelijk (zelfde inputs, zelfde load).

Als de cijfers beter lijken, doe dan snel een regressiecheck: controleer correctheid (zelfde outputs), foutpercentage en timeouts. Let op bijwerkingen zoals hoger geheugen, CPU-spikes, tragere startup of meer DB-belasting. Een wijziging die p95 verbetert maar geheugen verdubbelt kan een verkeerde trade-off zijn.

Voorbeeld: stap-voor-stap onderzoek naar een traag API-endpoint

Een team meldt dat GET /orders in dev prima voelt, maar in staging traag wordt bij matige load. Gebruikers klagen over time-outs, maar gemiddelde latentie lijkt nog "ok", wat een klassieke val is.

Eerst: leg een baseline vast. Onder een stabiele load-test (zelfde dataset, dezelfde concurrency, dezelfde duur) registreer je:

• p95-latentie: 1.8s (doel is < 600ms)
• API-CPU: ~70% met af en toe spikes
• DB: één query duurt 900–1100ms en totale querytijd per request is ~1.3s

Verzamel bewijs. Een snelle trace toont dat het endpoint een hoofdquery uitvoert voor orders en vervolgens per order gerelateerde items ophaalt in een lus. Je merkt ook dat de JSON-respons groot is, maar DB-tijd domineert.

Zet dat om in een hypotheselijst die je kunt testen:

• Een trage query heeft een ontbrekende index.
• N+1-queries vermenigvuldigen DB-tijd.
• Serialisatie is traag door een enorme payload.
• Lock-contentie blokkeert reads tijdens writes.

Vraag om een minimale wijziging die bij het sterkste bewijs past: haal één duidelijke N+1-call weg door items in één query op te halen keyed op order-IDs (of voeg de ontbrekende index toe als het queryplan een full scan toont). Houd het omkeerbaar en in een gefocuste commit.

Her-meten met dezelfde load-test. Resultaten:

• p95-latentie: 1.8s -> 720ms
• Totale DB-tijd: ~1.3s -> ~420ms
• CPU: iets lager, maar nog steeds met spikes

Beslissing: deploy de fix (duidelijke winst), en start vervolgens een tweede cyclus gericht op de resterende kloof en CPU-spikes, aangezien DB nu niet langer de limiter is.

Volgende stappen: maak deze workflow routine

De snelste manier om beter te worden in prestatieonderzoek is elke run te behandelen als een klein experiment dat je kunt herhalen. Als het proces consistent is, worden resultaten makkelijker te vertrouwen, vergelijken en delen.

Een simpele één-pagina template helpt:

• Metric + hoe die gemeten wordt (tool, command, dataset)
• Baseline (cijfers, omgeving en wanneer vastgelegd)
• Hypothese (één zin, toetsbaar)
• Wijziging (kleine diff, wat je aanraakte)
• Resultaat (voor/na, plus beslissing)

Bepaal waar deze notities leven zodat ze niet verdwijnen. Een gedeelde plek is belangrijker dan het perfecte hulpmiddel: een map in de repo naast de service, een team-doc of ticket-notities. Het belangrijkste is vindbaarheid. Iemand moet later "p95-latentie spike na caching-wijziging" kunnen vinden.

Maak veilige experimenten tot gewoonte. Gebruik snapshots en makkelijke rollback zodat je een idee kunt proberen zonder angst. Als je met Koder.ai bouwt, kan Planning Mode een handige plek zijn om het meetplan te schetsen, de hypothese te definiëren en de wijziging te begrenzen voordat je een strakke diff genereert en her-meet.

Stel een cadence in. Wacht niet op incidenten. Voeg kleine prestatiechecks toe na wijzigingen zoals nieuwe queries, nieuwe endpoints, grotere payloads of dependency-upgrades. Een 10-minuten baseline-check nu kan een dag giswerk later besparen.