Automatisch Onderzoek Met Claude Code: De Karpathy Loop Die Draait Terwijl Je Slaapt
Andrej Karpathy pushte op 7 maart 2026 een Python-script van 630 regels naar GitHub. Hij ging naar bed. Toen hij wakker werd, had zijn AI-agent meer dan 100 machine learning-experimenten uitgevoerd, 20 optimalisaties ontdekt die daadwerkelijk werkten, en de resultaten samengevat in een overzichtelijk logboek — allemaal zonder een enkele menselijke toetsaanslag gedurende de nacht. De repo bereikte binnen vijf dagen 25.000 sterren. Shopify-CEO Tobi Lutke richtte het op hun templating-engine en kreeg 53% snellere rendering uit 93 geautomatiseerde commits. En plotseling had een concept dat al een tijdje rondging in AI-onderzoekskringen — de autonome verbeterloop — een naam die iedereen kon onthouden: auto research. Ik volg dit vanuit mijn Claude Code terminal. En wat mij het meest enthousiast maakt, zijn niet de ML-experimenten. Het is wat er gebeurt als je hetzelfde patroon — verander een ding, meet het resultaat, behoud of verwerp, herhaal — richt op bedrijfsproblemen. Landingspagina-conversies. E-mail onderwerpregels. Advertentieteksten. Prijspagina-indelingen. Alles waar een getal aan hangt. Dat is de versie die Jack Roberts onlangs in detail heeft uitgelegd, en het is de versie die ik de afgelopen twee weken heb getest. De resultaten zijn niet zo spectaculair als die van Karpathy — ik train geen taalmodellen 's nachts. Maar ik kijk wel toe hoe Claude autonoom mijn conversieteksten verbetert via een gestructureerde loop die wekelijks draait zonder dat ik er iets aan doe. En de samengestelde wiskunde daarvan is werkelijk verbijsterend. Hier lees je hoe het hele systeem werkt, hoe ik het heb opgezet, en welke specifieke fouten ik heb gemaakt zodat jij ze niet herhaalt.
Het Mentale Model: Waarom 1% Samengesteld 37x Wordt
Voordat je ook maar een regel code aanraakt, moet je begrijpen waarom deze aanpak werkt — want het instinct dat de meeste mensen hebben, is verkeerd. De meeste optimalisatie gebeurt in pieken. Je herontwerpt een landingspagina elke zes maanden. Je herschrijft e-mailsequenties eens per kwartaal. Je werkt advertentieteksten bij wanneer de prestaties kelderen. Tussen die pieken door? Er verandert niets. Je draait dezelfde teksten, dezelfde indeling, dezelfde koppen weken- of maandenlang. Auto research draait dat model om. In plaats van grote incidentele veranderingen maak je kleine continue aanpassingen. En de wiskunde van continue verbetering is contra-intuïtief. Een verbetering van 1% per dag — samengesteld over een jaar — levert geen winst van 365% op. Het levert een winst van 37x op. Dat is 1,01 tot de macht 365. James Clear maakte dit populair in Atomic Habits, maar Karpathy maakte er een technisch patroon van. De auto research loop is het mechanisme dat samengestelde verbetering mechanisch maakt in plaats van ambitieus. Het omgekeerde is even meedogenloos. Een dagelijkse achteruitgang van 1% resulteert samengesteld in een verlies van 97%. Stilstand is niet neutraal — het is langzame erosie terwijl concurrenten om je heen itereren. Het getal van 37x is theoretisch. Je zult niet voor altijd dagelijkse verbeteringen van 1% op een enkele metriek volhouden. Afnemende meeropbrengsten zijn reëel. Maar het patroon van continue geautomatiseerde iteratie? Dat is de doorbraak. Zelfs een gemiddelde verbetering van 0,1% per iteratie, twee keer per week, levert zinvolle winst op over een kwartaal. En het cruciale deel: de AI handelt de iteratie af, niet jij. Het WD-40-verhaal illustreert dit perfect. Het product dankt zijn naam aan het feit dat er 40 pogingen nodig waren om de juiste waterverdringsformule te vinden. Veertig iteraties. De meeste mensen zouden na vijf zijn gestopt. Auto research neemt de menselijke neiging om vroeg op te geven weg door elke iteratie nagenoeg gratis te maken. Dat is de theorie. Hier is hoe het daadwerkelijke systeem eruitziet.
Drie Componenten, Een Loop: De Auto Research Architectuur
Het auto research framework — of je het nu toepast op ML-training zoals Karpathy of op bedrijfsmetrieken zoals ik — reduceert altijd tot drie componenten: Een ding om te veranderen. Een enkele variabele of element dat je Claude wilt laten aanpassen. Een kop. De tekst van een CTA-knop. Een e-mail ondwerpregel. De volgorde van voordelen op een prijspagina. Niet vijf dingen tegelijk — een ding. Isolatie is belangrijk, want als je drie variabelen wijzigt en de prestaties verbeteren, weet je niet welke verandering het veroorzaakte. Een metriek om te meten. Een objectief, kwantitatief getal dat je vertelt of de verandering hielp of schaadde. Conversieratio. Doorklikratio. Bouncepercentage. Openingspercentage. Geen "gevoel." Geen "voelt beter." Een getal. Een methode om de resultaten te lezen. Een manier waarop Claude daadwerkelijk toegang heeft tot de prestatiegegevens zonder dat je ze handmatig in een prompt kopieert. Dit is waar de meeste mensen vastlopen, en ik laat je de oplossing zien die ik vond in het implementatiegedeelte. De loop zelf is doodeenvoudig:
1. Claude leest huidige prestatiegegevens (de "controle")
2. Claude genereert een variant (de "uitdager")
3. Je implementeert de uitdager
4. Wacht tot er genoeg data is verzameld
5. Claude leest de nieuwe prestatiegegevens
6. Als uitdager > controle → uitdager wordt de nieuwe basislijn
7. Als controle > uitdager → terugdraaien, andere aanpak proberen
8. Herhaal vanaf stap 1
Dit is A/B testing-logica, maar dan met de AI die stappen 1, 2, 5, 6, 7 en 8 autonoom afhandelt. Jouw taak krimpt tot stap 3 (de verandering doorvoeren) en stap 4 (wachten). En met de juiste tooling — bijvoorbeeld de browserautomatisering van Claude Co-work — kan zelfs de implementatie geautomatiseerd worden. Karpathy's originele repo implementeert dit voor ML-training. Zijn drie bestanden komen direct overeen met dit framework:
prepare.py— Vaste datavoorbereiding en hulpprogramma's. De agent raakt dit nooit aan. Het is de stabiele basis.train.py— Het enige bestand dat de agent bewerkt. Bevat de modelarchitectuur, hyperparameters, optimizer en trainingsloop. Alles mag aangepast worden.program.md— Het instructiebestand. Vertelt de agent wat te optimaliseren, hoe succes te meten en welke beperkingen te respecteren. De agent wijzigttrain.py, voert een trainingscyclus van 5 minuten uit, controleert of het validatieverlies is verbeterd, behoudt of verwerpt de wijziging, en herhaalt. In twee dagen voerde Karpathy's agent 700 experimenten uit en vond 20 echte optimalisaties. Toen die 20 aanpassingen werden toegepast op een groter model, verbeterde de trainingssnelheid met 11%. De bedrijfsversie volgt dezelfde structuur — andere bestanden, hetzelfde patroon. Laat me je laten zien hoe ik het heb aangepast.
Je Auto Research Omgeving Opzetten
Ik ga de opzet beschrijven die ik daadwerkelijk gebruik, niet een theoretisch ideaal. Sommige dingen zijn provisorisch. Het werkt.
Stap 1: Definieer Je Metriek en Maak een Bedrijfscontextbestand
Kies een metriek. Ik koos de doorklikratio op een landingspagina CTA-knop omdat de feedbackloop snel is (ik heb genoeg verkeer voor wekelijkse metingen) en de variabele geïsoleerd is (knoptekst en omringende context).
Maak vervolgens een business.md-bestand dat Claude de context geeft die het nodig heeft om intelligente beslissingen te nemen. Dit is het onderdeel dat de meeste mensen overslaan, en het is het onderdeel dat er het meest toe doet. Zonder bedrijfscontext genereert Claude generieke marketingteksten. Met context genereert Claude teksten die daadwerkelijk bij je doelgroep passen.
Hier is een vereenvoudigde versie van de mijne:
# Business Context
## Who We Are
Ramlit Limited — software development agency serving B2B clients.
Primary service: custom web application development.
Average project size: $15K-$50K.
## Target Audience
- CTOs and engineering leads at mid-size companies (50-500 employees)
- Evaluating build-vs-buy for internal tools
- Pain points: slow development cycles, technical debt, unreliable freelancers
## Current Landing Page Performance
- Monthly visitors: ~2,400
- Current CTA click-through rate: 3.2%
- Primary CTA: "Get a Free Quote"
- Traffic sources: 60% organic, 25% referral, 15% direct
## Brand Voice
Professional but direct. No buzzwords. Results-focused.
Reference tone: ramlit.com existing copy.
## Constraints
- Do not change the core value proposition
- Do not use urgency tactics ("limited time", "act now")
- Keep CTA under 6 words
- All changes must maintain professional tone
Hoe specifieker je contextbestand, hoe slimmer Claude's suggesties worden. Ik leerde dit van mijn werk aan zelfverbeterende AI-systemen — de kwaliteit van het contextdocument bepaalt direct de kwaliteit van de AI-output. Generieke context levert generieke resultaten op.
Stap 2: Zet Je Datapijplijn Op
Hier wordt het serieus — en hier gaan de meeste auto research-opstellingen mis. Karpathy's versie heeft het makkelijk. De metriek (validatieverlies) wordt berekend door het trainingsscript zelf. De agent voert het script uit, leest de output en weet onmiddellijk of de prestaties zijn verbeterd. Schoon, afgebakend, geen externe afhankelijkheden. Bedrijfsmetrieken zijn niet zo netjes. Je conversiegegevens zitten in Google Analytics. Of Stripe. Of een platformdashboard zonder API. Die gegevens in een formaat krijgen dat Claude kan lezen is de eerste echte technische uitdaging. Ik heb drie benaderingen getest: Optie A: Directe API-integratie. Als je analyticsplatform een API heeft (Google Analytics 4, Mixpanel, Amplitude), kun je een script schrijven dat de relevante metriek ophaalt en in een bestand dumpt dat Claude kan lezen. Dit is de schoonste aanpak maar vereist enige opzet.
# Example: Pull GA4 data into a metrics file
from google.analytics.data_v1beta import BetaAnalyticsDataClient
from google.analytics.data_v1beta.types import RunReportRequest
import json
from datetime import datetime
client = BetaAnalyticsDataClient()
request = RunReportRequest(
property=f"properties/YOUR_PROPERTY_ID",
dimensions=[{"name": "pagePath"}],
metrics=[
{"name": "screenPageViews"},
{"name": "conversions"},
],
date_ranges=[{"start_date": "7daysAgo", "end_date": "today"}],
)
response = client.run_report(request)
# Format for Claude consumption
metrics = {
"date_pulled": datetime.now().isoformat(),
"period": "last_7_days",
"landing_page": "/services",
"pageviews": int(response.rows[0].metric_values[0].value),
"conversions": int(response.rows[0].metric_values[1].value),
"conversion_rate": round(
int(response.rows[0].metric_values[1].value)
/ int(response.rows[0].metric_values[0].value) * 100, 2
)
}
with open("metrics/current_performance.json", "w") as f:
json.dump(metrics, f, indent=2)
Optie B: Browserautomatisering met Claude Co-work. Wanneer API's niet beschikbaar zijn — en voor een verrassend aantal platformen zijn ze dat niet — kan Claude Co-work dashboardgegevens direct scrapen. Dit heb ik behandeld in mijn bericht over geplande taken met Claude Co-work. Je stelt een geplande taak in die je analytics-dashboard opent, de relevante cijfers leest en ze naar een bestand of Notion-pagina schrijft.
Optie C: Handmatig ondersteund (de eerlijke versie). De eerste twee weken kopieerde ik de cijfers gewoon elke maandagochtend in een metrics.json-bestand. Kostte 90 seconden. Niet glamoureus. Maar het liet me de loop zelf valideren voordat ik tijd investeerde in automatisering. Laat perfecte infrastructuur je er niet van weerhouden om te beginnen.
Ik begon met Optie C en schakelde over naar Optie B na de eerste maand toen ik bevestigde dat de loop echte winst opleverde. Als je net begint, doe hetzelfde. Automatiseer de datapijplijn nadat je hebt bewezen dat de optimalisatieloop werkt.
Stap 3: Maak Je Programmabestand
Dit is je program.md — de instructieset die Claude vertelt hoe de loop moet draaien. Hier is de structuur die ik gebruik:
# Auto Research: Landing Page CTA Optimization
## Objective
Improve the click-through rate on the /services landing page CTA.
## Current Baseline
- Control CTA: "Get a Free Quote"
- Control CTR: 3.2% (last 7 days, from metrics/current_performance.json)
## Rules
1. Read the current metrics from metrics/current_performance.json
2. Read the business context from business.md
3. Analyze why the current CTR might be underperforming
4. Generate ONE challenger variant — a new CTA copy and 2-3 sentences
of surrounding context
5. Explain WHY you expect the challenger to outperform (hypothesis)
6. Write the challenger to variants/challenger_[date].md
7. After deployment and data collection, compare challenger vs control
8. If challenger wins: update baseline in this file
9. If control wins: log the failed hypothesis and try a different approach
## Change Constraints
- CTA must be under 6 words
- Surrounding copy changes limited to the 3 sentences nearest the CTA
- No urgency language, no discount offers
- Maintain professional B2B tone
## Experiment Log
| Date | Variant | Hypothesis | Result | CTR |
|------|---------|-----------|--------|-----|
| Baseline | "Get a Free Quote" | — | Control | 3.2% |
Het experimentlogboek onderaan is cruciaal. Het geeft Claude geheugen over iteraties heen. Zonder dit logboek zou de agent dezelfde verandering twee keer kunnen voorstellen of niet leren van eerdere mislukkingen. Elke keer dat de loop draait, leest Claude het logboek, ziet wat er is geprobeerd, wat werkte en wat niet — en genereert dan een variant die voortbouwt op die opgebouwde kennis.
Stap 4: Configureer de Loopfrequentie
Hoe vaak moet de loop draaien? Dat hangt af van je verkeer en feedbacksnelheid. Voor mijn landingspagina met ~2.400 maandelijkse bezoekers geven wekelijkse iteraties me genoeg data om zinvolle verschillen te meten. Sites met veel verkeer (10.000+ dagelijkse bezoekers) zouden dagelijks kunnen draaien. E-mailcampagnes zouden per verzending kunnen draaien. De belangrijkste beperking: je hebt genoeg data nodig tussen iteraties om signaal van ruis te onderscheiden. Als je een CTA-verandering test en slechts 50 mensen zien hem voordat de volgende iteratie start, zijn je gegevens betekenisloos. Wacht op statistische significantie — of op zijn minst praktische significantie. Ik heb het mijne ingesteld als een wekelijkse geplande taak in Claude Co-work. Elke maandag om 8:00 uur leest Claude de laatste metrieken, vergelijkt met de controle van de vorige week en genereert de volgende uitdager als de data overtuigend is. Als je nieuwsgierig bent naar de planningmechanismen, loop ik door de exacte Claude Co-work-configuratie in mijn gids voor automatisering van geplande taken. De korte versie: je maakt een geplande taak aan in het Co-work-paneel, wijst het naar je projectmap en stelt de herhaling in.
Wat Er Werkelijk Gebeurde Toen Ik Dit Twee Weken Draaide
Hier stop ik met praten over theorie en laat ik je de realiteit zien. Inclusief de gênante delen. Week 1: De Basislijn Startmetrieken: 3,2% CTR op "Get a Free Quote." 587 paginaweergaven. 19 CTA-klikken. Claude las de bedrijfscontext, analyseerde de basislijn en genereerde zijn eerste uitdager:
Uitdager CTA: "See What We'd Build For You" Hypothese: De huidige CTA impliceert een transactionele verkoopinteractie ("offerte"). De doelgroep (CTO's, technische leiders) zit in de evaluatiefase, niet in de aankoopfase. De CTA herformuleren als een uitnodiging om een oplossing op maat te bekijken vermindert de waargenomen verplichting en vergroot de nieuwsgierigheid. Ik wisselde de CTA-tekst maandagmiddag. Kostte twee minuten in het CMS. Week 1 Resultaten: 612 paginaweergaven. 27 klikken. 4,4% CTR. Een verbetering van 37,5% ten opzichte van de basislijn. Mijn eerste reactie was argwaan. Een stijging van 37,5% door vijf woorden te veranderen? Dat voelde te hoog. Kan ruis zijn. Kan een andere verkeermix die week zijn geweest. Ik noteerde het en ging verder. Week 2: De Overmoedige Uitdager Claude las de resultaten van Week 1, noteerde de verbetering en werd — ik ga hier even vermenselijken — ambitieus. De volgende suggestie: Uitdager CTA: "Your Custom Build Starts Here" Hypothese: Voortbouwend op het succes van de personalisatieframing ("What We'd Build For You"), voegt deze variant voorwaartse dynamiek toe ("Starts Here") met behoud van lage drempel. Het bezittelijke "Your" vergroot de eigenaarschapspsychologie. Redelijke hypothese. Ik rolde hem uit. Week 2 Resultaten: 591 paginaweergaven. 22 klikken. 3,7% CTR. Beter dan de oorspronkelijke basislijn, maar slechter dan de uitdager van Week 1. Dus Claude keerde terug naar de winnaar van Week 1 ("See What We'd Build For You") als nieuwe basislijn, logde het mislukte experiment en noteerde in het experimentlogboek: "Bezittelijke framing + actietaal presteerde slechter dan nieuwsgierigheidsframing. Volgende iteratie moet variaties op de nieuwsgierigheidsaanpak verkennen in plaats van over te schakelen naar actietaal." Die notitie — die zelfcorrigerende analyse — is wat auto research anders maakt dan een mens die A/B-tests uitvoert. Ik zou die synthese niet hebben geschreven. Ik zou naar het getal hebben gekeken, gedacht "dat werkte niet," en zijn verdergegaan zonder de les eruit te halen. Claude legt systematisch vast waarom iets mislukte en gebruikt dat om de volgende poging te sturen. De Lopende Resultaten Na Twee Weken: | Week | CTA | CTR | vs. Basislijn | |------|-----|-----|-------------| | 0 (Controle) | "Get a Free Quote" | 3,2% | — | | 1 | "See What We'd Build For You" | 4,4% | +37,5% | | 2 | "Your Custom Build Starts Here" | 3,7% | +15,6% | | 3 (huidig) | "See What We'd Build For You" (teruggedraaid) | Lopend | — | Twee iteraties. Een winnaar, een verliezer. Het systeem leerde van beide. En mijn nieuwe basislijn ligt 37,5% boven waar ik begon. Stel je nu voor dat dit 26 weken draait — een half jaar — met het samengestelde effect waarbij elke winnende variant de nieuwe bodem wordt. Dat is auto research.
De Karpathy Repo: ML-Experimenten Vertalen naar Bedrijfsgebruik
Laat me de kloof overbruggen tussen wat Karpathy heeft gebouwd en wat jij daadwerkelijk gaat gebruiken, want de implementaties zien er anders uit ook al is het patroon identiek.
Karpathy's autoresearch-repo richt zich op optimalisatie van neurale netwerktraining. De agent past architectuurbeslissingen, hyperparameters en optimizerconfiguraties aan — technische keuzes die een enkele metriek beïnvloeden: validatieverlies. De volledige feedbackloop is zelfstandig. train.py draait 5 minuten, geeft een verlieswaarde uit, en de agent beslist of de verandering behouden wordt.
De repo ging viraal (49.800+ GitHub-sterren op het moment van schrijven) omdat het iets demonstreerde waar mensen over hadden getheöretiseerd maar nog niet schoon hadden zien werken: een AI-agent die een systeem daadwerkelijk verbetert door autonome experimenten, niet alleen door prompting.
Maar tenzij je neurale netwerken traint, moet je het patroon aanpassen. Hier is de vertaaltabel:
| Karpathy's ML-Versie | Jouw Bedrijfsversie |
|---|---|
train.py (modelcode) |
Jouw landingspagina / e-mail / advertentietekst |
prepare.py (datahulpprogramma's) |
Jouw analytics-pijplijn (API of scraping) |
program.md (agentinstructies) |
Jouw program.md (optimalisatiedoel + beperkingen) |
| Validatieverlies | Conversieratio / CTR / openingspercentage |
| 5 minuten trainingsrun | 1 week verkeersaccumulatie |
| Automatische code-executie | Handmatige implementatie of Claude Co-work-automatisering |
| GPU-rekenkracht | Menselijk geduld |
| Het grootste verschil: snelheid. Karpathy's agent voerde 700 experimenten uit in 2 dagen omdat elk experiment minuten duurde. Bedrijfsoptimalisatieloops draaien wekelijks of dagelijks omdat je echte mensen nodig hebt om de data te genereren. Dit betekent dat je experimentlogboek nog belangrijker wordt — je kunt het je niet veroorloven een iteratie te verspillen aan een slecht onderbouwde hypothese. | |
Protip: Karpathy's repo bevat een program.md-bestand dat de moeite waard is om te lezen, zelfs als je nooit een model traint. De manier waarop hij beperkingen, succescriteria en agentinstructies structureert is een meesterlijke les in prompt engineering voor autonome systemen. Ik heb zijn format direct overgenomen voor mijn bedrijfsoptimalisatieversie. |
Het Dataprobleem Waar Niemand Over Praat (En Mijn Oplossing)
Hier is de ongemakkelijke waarheid over het toepassen van auto research op bedrijfsmetrieken: het merendeel van je belangrijke data zit achter dashboards die niet ontworpen zijn voor programmatische toegang. Google Analytics heeft een API. Stripe heeft een API. Maar Skool? De gedetailleerde engagementdata van ConvertKit? Je WordPress-dashboard? Je Shopify-thema-editor? De helft van de tools die founders daadwerkelijk gebruiken, stelt de metrieken die je nodig hebt niet beschikbaar via schone API's. Jack Roberts benadrukte precies dit probleem in zijn walkthrough, en zijn oplossing is de juiste: browserautomatisering. De browsermogelijkheden van Claude Co-work kunnen naar een dashboard navigeren, de cijfers lezen en ze naar een bestand schrijven. Het is niet elegant. Het is geen fatsoenlijke integratie. Maar het werkt betrouwbaar voor de "lees de metriek"-stap van de loop. De opzet ziet er zo uit:
- Maak een Co-work-taak die naar je analytics-dashboard navigeert
- Log in met opgeslagen inloggegevens (of, beter, een sessie die ingelogd blijft)
- Lees de specifieke metriek van de pagina — Claude kan cijfers uit dashboard-UI's identificeren en extraheren
- Schrijf de metriek naar een JSON-bestand of Notion-pagina die je hoofd auto research loop leest Ik testte dit met een Google Analytics-dashboard en een Notion-database. Claude Co-work opende de GA-pagina, vond de conversieratio voor mijn doelpagina, extraheerde het getal en schreef het naar een Notion-tabel. Duurde ongeveer 45 seconden per keer. Niet snel, maar voor een wekelijks ritme? Prima. Voor platformen die complexere navigatie vereisen — meerdere klikken, dropdown-filters, datumbereiksselecties — moet je explicieter zijn in je Co-work-taakinstructies. Beschrijf elke klik. Specificeer met welk element interactie moet plaatsvinden. Hoe preciezer je instructies, hoe betrouwbaarder de automatisering. Als je liever iemand hebt die deze volledige datapijplijn en auto research loop vanaf nul opbouwt, neem ik precies dit soort AI-automatiseringsprojecten aan. Je kunt zien wat ik heb gebouwd op fiverr.com/s/EgxYmWD. Een alternatief dat het vermelden waard is: Google Sheets als tussenlaag. Je kunt een Google Sheet opzetten die data importeert uit verschillende bronnen (met ingebouwde connectors, Zapier of handmatige invoer), en vervolgens Claude het werkblad laten lezen via de Google Sheets API. Het is een universele adapter. Rommelig, maar universeel compatibel.
De Juiste Metriek Kiezen: Waar Auto Research Werkt (en Waar Niet)
Niet elke metriek is een goede kandidaat voor auto research. Ik leerde dit door eerst het verkeerde te proberen te optimaliseren. Waardevolle kandidaten:
- Conversieratio's van landingspagina's — Snelle feedback, duidelijke metriek, geïsoleerde variabele. Mijn topaanbeveling voor je eerste auto research loop.
- Openingspercentages van e-mail onderwerpregels — Elke verzending is een nieuw experiment. Hoog datavolume als je lijst 1.000+ is.
- Doorklikratio's van advertentieteksten — Platformen zoals Google Ads en Meta bieden de metriek al aan. Je hoeft alleen Claude varianten te laten genereren en resultaten te laten lezen.
- Voltooiingspercentages van afrekenpagina's — Hoge bedrijfsimpact, meetbaar, en kleine tekst-/indelingswijzigingen kunnen de naald aanzienlijk verplaatsen.
- Feature-adoptiepercentages in SaaS — Als je kunt meten hoeveel gebruikers een feature activeren, kun je de onboarding-tekst of UI die ernaartoe leidt optimaliseren. Minder waardevolle kandidaten (vermijd deze voor auto research):
- SEO-rankings — Feedbackcyclus is te traag (weken tot maanden). Te veel verstorende variabelen. Je kunt niet isoleren wat een rankingverandering veroorzaakte.
- Merkbekendheid — Niet op een zinvolle manier kwantificeerbaar voor iteratieloops.
- NPS-scores — Te subjectief en te zeldzaam voor snelle iteratie.
- Omzet — Te hoog niveau. Omzet is een output van veel inputs. Optimaliseer de inputs afzonderlijk.
- Social media-engagement — Te veel ruis. Algoritmewijzigingen, virale willekeur en stemming van het publiek verstoren allemaal de data. De ideale auto research-metriek heeft vier eigenschappen:
- Hoog volume — Genoeg evenementen per cyclus om verschillen te meten
- Snelle feedback — Resultaten beschikbaar binnen dagen, niet maanden
- Geïsoleerde variabele — Je kunt een ding veranderen en de impact meten
- Toegankelijke data — Je kunt de metriek programmatisch lezen (of via browserautomatisering) Als je gekozen metriek niet aan alle vier criteria voldoet, kies dan een andere. De loop werkt alleen als de data schoon, snel en toerekenbaar is.
De Kwaliteit van Vragen Is Belangrijker Dan de Kwaliteit van Antwoorden
Dit is iets dat Jack Roberts benadrukte en dat een eigen sectie verdient, want het is het meest onderschatte inzicht in het hele auto research framework.
Wanneer je je program.md schrijft, geef je Claude niet alleen instructies. Je definieert de probleemruimte. En de kwaliteit van die probleemdefinitie bepaalt het plafond van wat Claude kan ontdekken.
Slechte probleemdefinitie:
"Verbeter de conversieratio van onze website." Goede probleemdefinitie: "Verbeter de doorklikratio op de /services-pagina CTA. De doelgroep is CTO's die build-vs-buy-beslissingen evalueren. Huidige CTR is 3,2% met 600 wekelijkse paginaweergaven. De CTA verschijnt onder een voordelensectie en boven een testimonialblok. Het verkeer is voor 60% organisch zoekverkeer." Het verschil? De tweede versie geeft Claude genoeg context om intelligente hypotheses te vormen. Het kent de mindset van de doelgroep. Het kent de paginastructuur. Het kent de verkeersbron, wat hints geeft over zoekintentie. Elk van die details vormt de suggesties die Claude genereert. Ik heb ontdekt dat 30 minuten besteden aan het schrijven van een grondig
business.mdenprogram.mdbetere resultaten oplevert over 10 iteraties dan 5 minuten besteden aan een vaag briefing en 50 iteraties draaien. Context is hefboomwerking. Dit sluit aan bij een breder principe dat ik heb gezien in al mijn Claude Code-werk: het knelpunt is bijna nooit de capaciteit van de AI. Het is het vermogen van de mens om het probleem precies te definiëren. Auto research versterkt elk signaal dat je het geeft — dus als het signaal vaag is, krijg je vage optimalisatie. Als het signaal precies is, krijg je precieze winst.
Opschalen Voorbij een Enkele Metriek: De Multi-Loop Architectuur
Zodra je eerste auto research loop werkt en winst oplevert, is de natuurlijke vraag: kan ik meerdere loops tegelijkertijd draaien? Ja. Maar voorzichtig. Het risico bij meerdere gelijktijdige optimalisatieloops zijn interactie-effecten. Als je tegelijkertijd je landingspagina CTA en je hero-kop en je testimonialsectie optimaliseert, kan een verandering in het ene de prestaties van het andere beïnvloeden. Je CTA-verbetering kan eruitzien als een achteruitgang omdat de kopwijziging erboven de aandacht van gebruikers heeft verlegd. Mijn aanpak: sequentieel, niet parallel. Draai een loop totdat deze stabiliseert (wat betekent dat de verbeteringen afvlakken en uitdagers de controle niet consistent meer verslaan). Vergrendel dan die variabele, stel de winnende versie in als permanent en start een nieuwe loop op de volgende variabele. Voor mijn landingspagina ziet de volgorde er zo uit:
- CTA-tekst (draait nu)
- Hero-kop (volgende)
- Sociaal bewijs-sectie (nadat de kop stabiliseert)
- Volgorde van het voordelenblok (als laatste) Elke loop draait 4-8 weken voordat ik overstap naar de volgende variabele. Geduldig? Ja. Maar het behoudt de causale helderheid die de data betrouwbaar maakt. Als je absoluut parallelle loops moet draaien, doe het dan op verschillende pagina's of verschillende kanalen. Optimaliseer je landingspagina CTA en je e-mail onderwerpregels tegelijkertijd — dat zijn onafhankelijke systemen met onafhankelijke metrieken. Optimaliseer alleen niet twee elementen op dezelfde pagina tegelijkertijd.
Wat De Meeste Mensen Fout Zullen Doen
Ik test dit al twee weken en heb met drie andere bouwers gesproken die hetzelfde doen. Hier zijn de patronen die ik zie falen:
Te veel variabelen per iteratie veranderen. De verleiding om het "beter te maken" door vijf dingen tegelijk te veranderen is sterk. Weersta het. Je hebt isolatie nodig om te leren wat werkt. Een verandering. Een meting. Een beslissing.
Statistische significantie negeren. Als 50 mensen je nieuwe CTA zagen en 3 erop klikten (6% CTR) versus 2 die op de oude klikten (4% CTR), is dat geen zinvol verschil. Je hebt genoeg datavolume per iteratie nodig om het resultaat te vertrouwen. Voor sites met weinig verkeer betekent dit langere iteratiecycli — minimaal wekelijks, tweewekelijks voor zeer weinig verkeer.
Subjectieve metrieken gebruiken. "De pagina voelt beter" is geen metriek. "De nieuwe tekst is meer on-brand" is geen metriek. De auto research loop vereist een getal. Als je je doel niet als een getal kunt uitdrukken, kan de loop er niet voor optimaliseren.
De bedrijfscontext overslaan. Auto research draaien zonder een business.md-bestand is alsof je een copywriter inhuurt en niet vertelt wie je klanten zijn. Claude zal iets genereren. Het zal niets bijzonder nuttigs genereren.
Opgeven na de eerste mislukte iteratie. De Week 2-uitdager in mijn test presteerde slechter dan de winnaar van Week 1. Als ik daar was gestopt, had ik het inzicht gemist dat de aanpak van Week 3 vormgaf. Mislukte experimenten zijn geen mislukkingen — het zijn datapunten die de zoekruimte verkleinen voor de volgende iteratie. Karpathy's agent voerde 700 experimenten uit. Veel ervan maakten dingen slechter. Dat is het proces.
Het Grotere Plaatje: Waarom Dit Mijn Kijk op Optimalisatie Verandert
Voor auto research zag mijn optimalisatieproces er zo uit: een idee hebben, het implementeren, resultaten controleren over twee weken, vergeten te controleren, een maand later controleren, niet meer weten wat ik had veranderd, opnieuw beginnen. Na auto research ziet mijn optimalisatieproces er zo uit: definieer de metriek, definieer de beperkingen, laat Claude de loop draaien, bekijk het experimentlogboek wekelijks, grijp alleen in als iets er niet goed uitziet. Het verschil in cognitieve belasting is enorm. Ik besteed geen mentale energie meer aan "wat moet ik als volgende testen?" Dat is Claude's taak. Ik besteed mentale energie aan "is het framework correct gedefinieerd?" — wat een veel krachtigere vraag is. En het samengestelde effect is reëel. Niet de theoretische 37x. Maar een verbetering van 37,5% in twee weken op een enkele metriek, met een systeem dat blijft itereren? Projecteer dat zes maanden vooruit. Zelfs met afnemende meeropbrengsten is de cumulatieve impact op een bedrijfsmetriek die ertoe doet — conversies, klikken, inschrijvingen — aanzienlijk. Het auto research-patroon is niet ingewikkeld. Drie bestanden. Een metriek. Een loop. Het moeilijke deel is niet het bouwen ervan. Het moeilijke deel is de juiste metriek kiezen, precieze context schrijven en geduldig genoeg zijn om het samengestelde effect zijn werk te laten doen. Karpathy liet zien dat dit werkt voor ML-onderzoek op een schaal die de industrie versteld deed staan. De bedrijfsversie is langzamer, rommeliger en minder spectaculair. Het is ook toegankelijk voor iedereen met een Claude-abonnement en een metriek waar ze om geven. Begin met een metriek. Schrijf vanavond je contextbestand. Zet het systeem dit weekend op. En laat het draaien terwijl je slaapt. Over zes maanden wens je ofwel dat je vandaag was begonnen — of ben je blij dat je het deed.
Veelgestelde Vragen
Wat is auto research in Claude Code?
Auto research is een autonome optimalisatieloop waarbij Claude Code iteratief veranderingen test tegen een meetbare metriek, verbeteringen behoudt, mislukkingen verwerpt en herhaalt. Andrej Karpathy populariseerde het patroon in maart 2026 met zijn autoresearch GitHub-repo, die 700 ML-experimenten uitvoerde in twee dagen. Voor zakelijke toepassingen optimaliseert hetzelfde patroon conversieratio's, doorklikratio's en andere kwantificeerbare metrieken.
Heb ik programmeerervaring nodig om een auto research loop op te zetten?
Basaal bestandsbeheer en gemak met een teksteditor zijn voldoende voor een handmatig ondersteunde opzet waarbij je wekelijks metrieken kopieert naar een JSON-bestand. Voor volledige automatisering — API-integraties, browser-scraping, geplande taken — heb je intermediaire Python-vaardigheden nodig of bekendheid met de browserautomatiseringsfuncties van Claude Co-work. De program.md- en business.md-bestanden zijn gewoon Markdown.
Hoeveel verkeer heb ik nodig om auto research te laten werken?
Je hebt genoeg evenementen per iteratiecyclus nodig om signaal van ruis te onderscheiden. Voor landingspagina-optimalisatie met wekelijkse cycli is 500+ paginaweergaven per week een redelijk minimum. E-mailoptimalisatie vereist 1.000+ ontvangers per verzending. Advertentietekst-testen werkt met kleinere volumes omdat advertentieplatformen robuuste meting bieden. Sites met weinig verkeer moeten tweewekelijkse of maandelijkse cycli gebruiken.
Kan ik auto research op meerdere metrieken tegelijk draaien?
Draai parallelle loops op onafhankelijke systemen — optimaliseer je landingspagina en je e-mail onderwerpregels tegelijkertijd. Vermijd parallelle loops op dezelfde pagina of funnel, want veranderingen aan het ene element kunnen de prestaties van het andere beïnvloeden, waardoor het onmogelijk wordt resultaten toe te schrijven. Sequentiële optimalisatie met een variabele tegelijk levert schonere, betrouwbaardere data op.
Hoe verhoudt Karpathy's autoresearch-repo zich tot bedrijfsoptimalisatie?
Karpathy's repo optimaliseert de training van neurale netwerken door een AI-agent train.py te laten aanpassen, een trainingscyclus uit te voeren, het validatieverlies te meten en veranderingen te behouden of te verwerpen. De bedrijfsversie gebruikt hetzelfde controle-vs-uitdager-patroon maar vervangt ML-training door bedrijfsteksten, validatieverlies door conversieratio en 5-minuten trainingsruns door wekelijkse dataverzameling. Het kernframework — veranderen, meten, beslissen, herhalen — is identiek.
Laten We Samenwerken
Op zoek naar het bouwen van AI-systemen, het automatiseren van workflows of het opschalen van je tech-infrastructuur? Ik help graag.
- Fiverr (maatwerk & integraties): fiverr.com/s/EgxYmWD
- Portfolio: mejba.me
- Ramlit Limited (enterprise-oplossingen): ramlit.com
- ColorPark (design & branding): colorpark.io
- xCyberSecurity (beveiligingsdiensten): xcybersecurity.io