Een gids voor Andrej Karpathy’s AutoResearch: ML automatiseren met AI-agents

Andrej Karpathy's AutoResearch is een open-sourcetool dat ML-experimenten in een lus draait en alleen de wijzigingen behoudt die het huidige beste resultaat verslaan. Je beschrijft onderzoekslijnen in een markdownbestand, wijst een AI-codeagent naar de repo en loopt weg. ’s Ochtends heb je een git-geschiedenis met gevalideerde verbeteringen en een logboek van alles wat de agent heeft geprobeerd.

Uitgebracht op 7 maart 2026, verzamelde het project binnen enkele dagen 21.000+ GitHub-sterren en 8,6 miljoen weergaven op Karpathy's aankondiging. Dit artikel behandelt hoe de drie-bestandenarchitectuur werkt, wat de ratchet-loop doet tijdens die nachtruns, welke resultaten AutoResearch tot nu toe heeft opgeleverd en waar de aanpak zijn grenzen bereikt.

Wat is AutoResearch?

AutoResearch is een open-source Python-tool waarmee een AI-agent ML-experimenten op een enkele GPU kan draaien zonder menselijke tussenkomst. Het doorloopt cycli van voorstellen-trainen-evalueren en behoudt alleen wijzigingen die de validatieverlies verbeteren. Het project wordt geleverd onder een MIT-licentie.

Dit is geen hyperparametertuning. Tools als Optuna of Ray Tune zoeken in een vooraf gedefinieerde parameterspace. AutoResearch geeft de agent de vrijheid om willekeurige code te wijzigen. De zoekruimte is alles wat de LLM kan bedenken, en dat maakt het een andere categorie tool dan wat er nu beschikbaar is.

AutoML- en NAS-frameworks (Neural Architecture Search) zoeken over architecturen of hyperparameters met gestructureerde algoritmen: precies, maar beperkt tot hun gedefinieerde zoekruimte.

AlphaEvolve (Google DeepMind) gaat verder met een evolutionaire aanpak en Gemini-modellen voor algoritmeontdekking, maar het is closed-source en voor de meeste teams niet toegankelijk. Algemene codeagents zoals SWE-Agent, OpenHands en Aider kunnen willekeurige code schrijven, maar zijn niet gebouwd voor de experimenteer-evalueer-behoud/rollback-cyclus die ML-onderzoek daadwerkelijk vereist.

AutoResearch gokt op de algemene kennis van de LLM om goede experimenten voor te stellen, in plaats van de zoekruimte te begrenzen voor wiskundige garanties.

Van vibe coding naar onderzoeksadviseur

Karpathy schetst dit als een natuurlijke evolutie in hoe engineers met AI werken. In februari 2026 introduceerde hij de term "agentic engineering": "Je schrijft 99% van de tijd niet zelf de code. Je orkestreert agents die dat doen en fungeert als toezicht." AutoResearch zet de volgende stap. De mens orkestreert niet eens meer. Je beschrijft in een markdownbestand hoe goed onderzoek eruitziet en loopt weg.

De voortgang loopt van vibe coding (mens promt, AI schrijft code, mens beoordeelt) naar agentic engineering (mens orkestreert agents in real time) naar volledig zelfstandig onderzoek (mens bepaalt richting, agent draait autonoom). 

Elke stap verkleint de rol van de mens van schrijver naar regisseur naar, in Karpathy's bewoording, onderzoeksadviseur.

In een vervolgpost beschreef hij de volgende stap: "Het doel is niet om één PhD-student te emuleren, maar een onderzoeksgemeenschap van hen", met verwijzing naar een SETI@home-achtige gedistribueerde agentensamenwerking.

Hoe het systeem die visie implementeert, komt neer op drie bestanden.

De drie-bestandenarchitectuur van AutoResearch

Het ontwerp van AutoResearch draait om een contract tussen drie bestanden, elk met strikte regels over wie eraan mag zitten.

prepare.py

prepare.py verzorgt datapreparatie en evaluatie. Het bouwt een BPE-tokenizer (Byte Pair Encoding) met een vocabulaire van 8.192 tokens, verwerkt het trainingscorpus en definieert de validatiemetriek: val_bpb (validation bits-per-byte). 

Dit bestand is onveranderlijk: noch de mens noch de agent wijzigt het, wat garandeert dat elk experiment met dezelfde maatstaf wordt gemeten.

train.py

train.py is de sandbox van de agent: 630 regels met de GPT-modelarchitectuur, de Muon+AdamW optimizer en de volledige trainingslus. De agent kan hier alles herschrijven (activatiefuncties wisselen, attention heads herstructureren, leerschema’s wijzigen, gewichtinitialisatie aanpassen) zolang de gewijzigde code nog traint en een val_bpb-score oplevert.

program.md

program.md is in platte markdown geschreven en is het enige bestand dat de menselijke auteur aanraakt. Het vertelt de agent welke onderzoekslijnen te volgen, wat te vermijden en hoe experimenten aan te pakken.

Wat program.md aanstuurt

Het bestand is specifieker dan de meesten verwachten. Het hardcodet baselinestatistieken zodat de agent weet wat er te verslaan is (val_bpb: 0.997900, piek-VRAM (videogeheugen): 45 GB). 

Het specificeert exacte commando’s voor het uitvoeren van experimenten en het extraheren van resultaten. Het vertelt de agent hoe om te gaan met falen: typfouten fixen en opnieuw draaien, ideeën overslaan die fundamenteel kapot zijn, alles killen dat langer dan 10 minuten draait. 

En het bevat de instructie die het hele systeem laat werken: "NOOIT STOPPEN. Zodra de experimentlus is gestart, PAUZEER NIET om de mens te vragen of je moet doorgaan."

Er is ook een ontwerpbeperking die elk experiment vormt: "Alles gelijk, eenvoud is beter. Een kleine verbetering die lelijke complexiteit toevoegt, is het niet waard." Dit stuurt de agent weg van over-engineering en richting nette wijzigingen die een menselijke reviewer zou goedkeuren.

De taakverdeling is helder. De mens bepaalt de onderzoekslijn via program.md, de agent voert uit door train.py te wijzigen, en prepare.py fungeert als neutrale scheidsrechter waar geen van beiden aan mag komen. Met dat contract op zijn plek draait de agent de experimentlus continu door zonder te stoppen.

AutoResearch Ratchet-loop

De kern van AutoResearch is een experimentcyclus die zonder menselijke input draait. Zo werkt één iteratie, volgens de 9-stappenlus gedefinieerd in program.md:

1. De agent leest program.md om de huidige onderzoekprioriteiten en -beperkingen te begrijpen.
2. Hij bekijkt de huidige train.py en recente resultaten in results.tsv.
3. Hij stelt een hypothese voor: een architectuurwijziging, een optimizer-aanpassing of een trainingmodificatie.
4. Hij wijzigt train.py om de voorgestelde wijziging te implementeren.
5. Hij commit de wijziging naar een git-branch.
6. Hij draait training exact 5 minuten (vaste wallclock-budget).
7. Als de training crasht, logt hij de fout, maakt de commit ongedaan en probeert opnieuw.
8. Hij evalueert het resultaat met val_bpb en legt de uitkomst vast in results.tsv.
9. Als val_bpb verbeterde: blijft de commit. Zo niet: git reset HEAD~1 zet terug naar de vorige versie.

Daarna begint hij weer bij stap 1.

Elk experiment krijgt hetzelfde wallclock-budget van 5 minuten, waardoor resultaten direct vergelijkbaar zijn. Een wijziging die sneller traint en een wijziging die lager convergeert, worden op gelijke voet beoordeeld. 

Met 5 minuten per experiment draait het systeem ongeveer 12 experimenten per uur.

De naam "ratchet" komt van de git-geschiedenis. Elk geslaagd experiment voegt een commit toe; elke mislukking wordt teruggedraaid. De codebase kan alleen vooruit, nooit achteruit, en bouwt zo stap voor stap gevalideerde verbeteringen op.

Git als onderzoekgeheugen

Dit lijkt qua structuur op evolutionaire algoritmen, maar AutoResearch houdt één afstammingslijn in plaats van een populatie. In plaats van crossover en mutatie over kandidaten fungeert de LLM zowel als mutatie-operator (voorstellen van wijzigingen) als als selectiedruk (kiezen wat te proberen op basis van eerdere resultaten). 

Hij leest zijn eigen git-geschiedenis en results.tsv om voort te bouwen op wat veelbelovend bleek.

Het bestand results.tsv houdt elk experiment bij: commit-hash, val_bpb-score, GPU-geheugengebruik, pass/fail-status en een beschrijving van wat de agent heeft geprobeerd. 

Je krijgt een duidelijk controlespoor om ’s ochtends te bekijken, en de agent gebruikt hetzelfde log om af te stemmen wat hij daarna probeert. Vroege experimenten zijn vaak breed (verschillende optimizerconfiguraties testen), terwijl latere inzoomen op de richting die de data valideerden.

Aan de slag met AutoResearch

AutoResearch draaien vereist een machine met een NVIDIA GPU (de standaardconfig richt zich op moderne GPU’s met 20+ GB VRAM), Python 3.10+, uv en een codeagent (Claude Code, Cursor of vergelijkbaar).

Clone de repo, installeer afhankelijkheden en bereid de dataset voor:

git clone https://github.com/karpathy/autoresearch.git
cd autoresearch
uv sync
uv run prepare.pyMogelijk gemaakt door

Er is geen orkestratiescript. Geen run.py, geen pipeline, geen framework. 

De README zegt om "gewoon je Claude/Codex of wat je maar wilt in deze repo op te starten." 

Je opent een codeagent in de projectmap, vraagt hem program.md te lezen, en de agent draait de experimentlus vervolgens zelfstandig. 

De LLM is de automatiseringslaag. Volg de voortgang door results.tsv te tailen of de git-log te checken op nieuwe commits.

De standaardconfiguratie traint een GPT-model op de FineWeb-Edu-dataset, wat een behoorlijke GPU en enkele uren vereist om resultaat te tonen. Voor een eerste test op kleinere hardware raadt Karpathy aan over te schakelen naar de TinyStories-dataset en het model te verkleinen door de vocabulaire te reduceren naar 256 en de diepte naar 4. 

Deze wijzigingen verlagen de VRAM-eisen en verkorten elk experiment genoeg om de ratchet binnen een paar uur in actie te zien.

Je eerste run configureren

Lees de standaard-program.md voordat je een nachtrun start. Het definieert de onderzoeksagenda die de agent volgt, en door het te bewerken stuur je de experimenten. 

Wil je dat de agent focust op attention-mechanismen, zet dat in program.md. 

Wil je dat hij de optimizer met rust laat, voeg die beperking toe. De agent zal niet afwijken van wat daar staat.

Voor een eerste nachtrun kun je rekenen op 80-100 experimenten met misschien 15-20 behouden verbeteringen. Een paar praktische dingen om te weten:

• API-kosten schalen met het aantal experimenten. Eén nachtrun is beheersbaar voor individuele onderzoekers, maar meerdaagse runs vragen om budgettering.
• Sommige experimenten crashen. De lus herstelt automatisch, dus ze onderbreken een nachtrun niet.
• Check results.tsv in de ochtend in plaats van naar de terminal te staren. Het trapjespatroon van verbeterende val_bpb-scores vertelt het verhaal beter dan losse logs.

AutoResearch-resultaten en het creativiteitsplafond

AutoResearch is getest in meerdere runs, van Karpathy's eigen experimenten tot communityreproducties en productie-adoptie.

De agent vond dingen die een methodische mens uiteindelijk ook zou vinden. QKnorm miste een schaalvermenigvuldiger voor het aanscherpen van attention, Value Embeddings profiteren van regularisatie, en er waren winstjes in banded attention-tuning, AdamW-betaparameters en weight-decay-schema’s. 

Dit zijn structurele codewijzigingen, geen willekeurige hyperparametersweeps, en het handmatig testen van elk zou dagen hebben gekost.

Shopify-CEO Tobi Lutke paste AutoResearch aan voor een intern query-expansionmodel en behaalde een verbetering van 19% in validatiescore uit 37 experimenten op een model met 0,8B parameters, en rapporteerde resultaten de dag nadat hij begon.

De trapjesgrafiek is echt, maar elke stap is klein. De agent vindt echte verbeteringen: hier een betaparameter bijstellen, daar regularisatie toevoegen. Niemand heeft gemeld dat hij een nieuw attention-mechanisme uitvindt of een architectuuridee voorstelt waar een menselijke onderzoeker niet uiteindelijk ook op zou komen.

Het creativiteitsplafond

GitHub Issue #22 legt het structurele probleem vast. Een gebruiker merkte op dat de agent door kleine variaties draait van wat het laatst werkte, vast in een lokaal zoekpatroon. 

De ratchet accepteert alleen wijzigingen die val_bpb meteen verbeteren, dus de agent kan nooit een stap terug doen om een grotere winst voor te bereiden. 

Menselijke onderzoekers redeneren regelmatig: "het wordt eerst slechter voordat het beter wordt." Daar is in de ratchet geen ruimte voor.

Karpathy erkende een gerelateerd probleem op Hacker News: de agent voelt zich "schichtig en bang" bij open problemen. 

Hij wijt dit aan RLHF (Reinforcement Learning from Human Feedback), dat veilige, conservatieve outputs beloont boven gedurfde experimenten. De agent kan creatieve wijzigingen voorstellen, maar is gebouwd om op veilig te spelen.

Het vaste trainingsvenster van 5 minuten voegt nog een beperking toe. 

Wijzigingen die hun waarde snel tonen, worden gevonden; wijzigingen die zich pas over langere runs bewijzen, blijven onzichtbaar. En 100 experimenten tegen dezelfde validatieset draaien brengt een overfitrisico met zich mee: sommige verbeteringen kunnen specifiek zijn voor die evaluatie in plaats van echte winst te vertegenwoordigen. De onveranderlijkheid van prepare.py, de eerlijkheidsgarantie van het systeem, is ook zijn blinde vlek.

De community discussieert of het plafond uit het framework komt of uit het onderliggende model. Voorstellen omvatten meta-promptoptimalisatie (een tweede agent herschrijft program.md op basis van resultaten), diversiteitsinstructies die nieuwigheid belonen naast verbetering, en periodieke "reset"-experimenten die vanuit een eerder checkpoint starten om lokale optima te ontsnappen.

Op dit moment is AutoResearch een tool die het methodische deel van ML-onderzoek automatiseert: honderden kleine experimenten draaien en evalueren. Het vervangt niet het creatieve deel, het formuleren van nieuwe onderzoekslijnen; dat blijft mensenwerk. Die taakverdeling is ook het duidelijkste signaal of deze tool in je workflow past.

Wanneer AutoResearch gebruiken

Het driebestandencontract (onveranderlijke evaluator, door de agent aanpasbare implementatie, door de mens geschreven richting) is breder toepasbaar dan LLM-training: voor elk domein waar je een automatische scorefunctie kunt definiëren. 

Zoekrangschikking optimaliseren, productcategorisatie, klinische named entity recognition, fraudedetectiescores, intentclassificatie: deze taken hebben de juiste eigenschappen. Kleine modellen die in minuten trainen, duidelijke scorefuncties en verbeteringen die overdragen als je opschaalt.

Als experimenten 100x sneller lopen dan een mens kan bijbenen, wordt de eval-pijplijn de bottleneck. Statische benchmarks raken snel verzadigd. Teams die dit patroon adopteren, hebben evalsets nodig die meebewegen met productie-data en zwaardere randgevallen.

Karpathy zelf draait een "grotere neef" van AutoResearch op 8x H100 GPU’s met zijn productie-nanochat-framework, wat suggereert dat het patroon verder schaalt dan speelexperimenten. De community heeft het al geforkt voor macOS/Apple Silicon en integraties voorgesteld voor oudere GPU’s. De CPU vs GPU-gids legt uit waarom GPU-hardware onmisbaar is voor dit soort iteratieve training.

Als je doel is om incrementele verbeteringen uit een goed begrepen trainingpijplijn te persen, is AutoResearch een goede match. Het creativiteitsplafond betekent dat je nog steeds menselijke onderzoekers nodig hebt voor problemen die echte vernieuwing vragen, en de tool werkt het best op het merendeel van het onderzoek dat methodische iteratie is.

Conclusie

Een goede program.md schrijven vereist dat je het onderzoek zelf hebt gedaan. Je moet weten welke richtingen het proberen waard zijn, wat "beter" betekent voor jouw probleem, en wanneer incrementele winst is uitgeput. De agent verzorgt de uitvoering, maar het oordeel achter de onderzoeksagenda blijft menselijk. Als de volgende generatie engineers dat vormende werk overslaat omdat agents het nu doen, heeft het veld plenty compute en niemand met de ervaring om het de juiste kant op te sturen.