Karpathy's AutoResearch: wat er gebeurt als AI 's nachts het onderzoek doet

In maart 2026 publiceerde Andrej Karpathy, mede-oprichter van OpenAI en voormalig hoofd AI bij Tesla, een framework genaamd AutoResearch. De gedachte is eenvoudig: u beschrijft wat u wilt onderzoeken in een tekstbestand, start het systeem voordat u gaat slapen en wordt wakker met zo'n 100 voltooide machine learning-experimenten, gerangschikt op prestatie. In drie weken bereikte het 65.000 GitHub-sterren. Die adoptiesnelheid weerspiegelt iets echts over wat het project vertegenwoordigt, niet alleen wat het doet.

Wat AutoResearch daadwerkelijk doet

AutoResearch zet een AI-codeeragent in op één trainingsscript. De agent past het script aan, voert een experiment van vijf minuten uit, meet het resultaat via een validatiemeetwaarde genaamd val_bpb (bits per byte, een maat voor de efficiëntie van taalmodellen) en beslist vervolgens of de wijziging behouden of verworpen wordt. Verbetert de wijziging de score, dan wordt ze de nieuwe baseline. Zo niet, dan draait de agent de wijziging terug en probeert iets anders. Deze cyclus loopt continu en levert ruwweg 12 experimenten per uur, oftewel zo'n 100 per nacht.

Het vaste tijdsbudget van vijf minuten per experiment is een bewuste ontwerpkeuze. Het maakt resultaten vergelijkbaar over uitvoeringen heen, voorkomt dat de agent onevenredig veel tijd besteedt aan één hypothese en past binnen het kostenprofiel van één H100-GPU die een nacht draait. De beperking dwingt het systeem efficiënt te werken in plaats van uitputtend.

De drie-bestandsarchitectuur

Het systeem is opgebouwd rond drie bestanden, elk met een duidelijke rol:

• prepare.py ligt vast. Het verzorgt de datavoorbereiding en verandert nooit. Zo blijft het experimentele substraat stabiel, zodat variaties in resultaten echte modelverschillen weerspiegelen en geen wijzigingen in de datapipeline.
• train.py is het canvas van de agent. Het begint als een standaard trainingsscript en wordt door de agent over honderden iteraties aangepast, uitgebreid en verfijnd. 's Ochtends kan het er wezenlijk anders uitzien dan bij de start.
• program.md wordt door de mens geschreven. Hier beschrijft u uw onderzoeksstrategie: welke benaderingen u wilt verkennen, welke beperkingen gelden, welke hypothesen u wilt toetsen. Het enige wat de mens hoeft te schrijven.

De eenvoud is bewust. Doordat wijzigingen beperkt blijven tot één bestand (train.py), is elke verandering te beoordelen. U kunt de diff tussen de ochtendversie en het startpunt bekijken en begrijpen wat de agent werkelijk heeft gedaan. Dat is moeilijker te bereiken wanneer agenten tegelijkertijd meerdere bestanden aanraken.

U schrijft de onderzoeksstrategie, niet de code

Karpathy's omschrijving van de menselijke rol is het waard direct te citeren. Hij beschrijft het als volgt: "You are not writing the code directly 99% of the time. You are orchestrating agents." De taak van de mens is het schrijven van program.md, dat hij de "research org code" noemt: de strategie op hoog niveau die bepaalt wat de agent nastreeft.

Dit is een betekenisvolle verschuiving ten opzichte van hoe de meeste mensen nu denken over AI-codeertools. De gangbare opvatting positioneert AI als een assistent die u helpt sneller code te schrijven. AutoResearch keert dit om: de agent schrijft de code, voert de experimenten uit en beoordeelt de resultaten. De mens schrijft de onderzoeksrichting. Het werkproduct van de mens is het strategiedocument, niet de implementatie.

Of deze opvatting verder reikt dan ML-onderzoek is een open vraag. Maar binnen het domein van iteratieve experimenten, waarbij het doel is een grote ruimte van mogelijke benaderingen te doorzoeken en te bepalen wat werkt, past het naadloos. De agent kan die ruimte veel sneller doorzoeken dan welk menselijk team dan ook.

De cijfers op een rij

Karpathy draaide AutoResearch twee dagen op een persoonlijk project en rapporteerde ongeveer 700 autonome codewijzigingen. Daarvan leidden zo'n 20 tot additieve verbeteringen die zich opstapelden tot betekenisvolle vooruitgang. Het cumulatieve effect was een efficiëntiewinst van 11% op de Time to GPT-2-leaderboard, een benchmark die meet hoe efficiënt een model GPT-2-niveau kan bereiken.

Een slagingspercentage van ruwweg 3% klinkt laag. Bedenk echter het alternatief: een menselijke onderzoeker die 700 experimenten handmatig uitvoert, is maanden bezig. De agent doet het in één nacht. De economie verandert volledig wanneer de kosten van een mislukt experiment dalen tot vijf minuten GPU-tijd in plaats van dagen menselijke inspanning.

Een eerlijk vergelijkingsmechanisme

Het vaste tijdsbudget van vijf minuten lost ook een subtiel probleem in ML-onderzoek op: hoe vergelijkt u benaderingen die in rekencomplexiteit variëren? Als een techniek tweemaal zoveel rekenkracht vereist, zou een langere trainingsrun haar beter doen lijken dan ze is. Door de tijd constant te houden garandeert AutoResearch dat verbeteringen echte algoritmische winsten weerspiegelen en geen strategie van simpelweg meer rekenkracht inzetten.

Ontwerpkeuzes die ertoe doen

Verschillende ontwerpen in AutoResearch komen voort uit productie-ML-systemen:

Deze beperkingen maken het systeem begrijpelijk. Een krachtigere agent met minder restricties zou snellere resultaten kunnen opleveren, maar moeilijker te doorgronden. AutoResearch ruilt enige pure capaciteit in voor interpreteerbaarheid, wat telt als u daadwerkelijk wilt leren van wat de agent ontdekt.

Het bredere signaal: zichzelf verbeterende AI

Karpathy's beschrijving van wat AutoResearch vertegenwoordigt is belangrijker dan het instrument zelf. Hij noemt het het begin van het "self-improvement loopy era of AI": systemen waarbij AI-agenten het onderzoek uitvoeren dat toekomstige AI-systemen beter maakt. De cyclus luidt: betere agenten voeren betere experimenten uit, vinden betere trainingstechnieken, produceren betere modellen, die op hun beurt betere agenten worden.

Onderzoekers theoretiseren al decennialang over recursieve zelfverbetering. Het nieuwe is infrastructuur die op één GPU past en in een middag opgezet kan worden, althans in een beperkt domein. AutoResearch toont één concreet onderdeel van die cyclus: AI-gestuurde experimentele zoektocht die meetbare verbeteringen in AI-trainingsefficiëntie oplevert.

De implicaties reiken verder dan ML-onderzoek. Elk domein met een heldere evaluatiemeetwaarde, een aanpasbaar artefact en een grote zoekruimte van mogelijke benaderingen is een kandidaat voor dit patroon: softwareoptimalisatie, medicijnontwikkeling, materiaalwetenschap, financiële modellering. In elk geval vormen de kosten van experimenten de bottleneck; lagere kosten veranderen wat haalbaar is.

Uitbreidingen door de community

Binnen dagen na de release had de community AutoResearch uitgebreid naar hardware die niet in het oorspronkelijke ontwerp was voorzien:

• macOS met Apple Silicon via MLX, waardoor het toegankelijk is zonder cloud-GPU-kosten voor gebruikers met M-serie Macs
• Windows met RTX-GPU's via community-forks die de trainingspipeline aanpassen voor CUDA op consumenten-hardware
• AMD-GPU's via ROCm-gebaseerde aanpassingen voor gebruikers buiten het NVIDIA-ecosysteem

De breedte van de community-aanpassing weerspiegelt oprechte interesse buiten de ML-onderzoeksgemeenschap. Ontwikkelaars buiten ML-onderzoek hebben nu een toegangsweg tot trainingsoptimalisatie-experimenten op hardware die ze al bezitten.

Criteria voor teamimplementatie

AutoResearch is een onderzoeksinstrument. Teams kunnen de cyclus hergebruiken: genereer een kandidaat, test die, leg mislukkingen vast en voer de volgende iteratie uit op basis van die mislukkingen.

De menselijke rol verschuift

Als de agent de experimenten uitvoert, ligt de menselijke waarde in het stellen van de juiste vragen. Een goede program.md vereist inzicht in welke benaderingen het verkennen waard zijn, welke beperkingen tellen en hoe succes er daadwerkelijk uitziet. Dat is werk op een hoger niveau dan code schrijven, en het vraagt domeinkennis en oordeelsvermogen. De werkzaamheden verschuiven van implementatie naar richting geven.

Nachtelijke rekencapaciteit wordt onderbenut

De meeste teams met cloudinfrastructuur beschikken 's nachts over onbenutte GPU-capaciteit. AutoResearch maakt duidelijk dat die capaciteit productief experimenteel werk zou kunnen verrichten in plaats van ongebruikt te blijven. De vraag voor elk team met een helder optimalisatiedoel en een toetsbare meetwaarde is of hetzelfde patroon van toepassing is op hun probleem.

Begrijpelijkheid moet bewust worden ontworpen

De beperking tot één bestand in AutoResearch is een begrijpelijkheidsmaatregel. Wanneer agenten alles kunnen aanraken, vergt begrijpen wat ze deden aanzienlijk reverse engineering. Systemen ontwerpen waarbij agentacties begrensd en auditeerbaar zijn, wordt steeds belangrijker naarmate de autonomie toeneemt. Teams die agent-geproduceerd werk kunnen vertrouwen en doorontwikkelen, zijn diegenen die interpreteerbaarheid van meet af aan hebben ingebouwd.

Aan de slag

AutoResearch is beschikbaar op github.com/karpathy/autoresearch. De repository bevat installatie-instructies, voorbeelden van program.md-bestanden en documentatie over aanpassing aan verschillende trainingstaken. Met toegang tot een H100 of een door de community ondersteunde GPU is de drempel voor het eerste nachtelijke experiment laag.

De interessantere vraag is wat u zou willen onderzoeken. AutoResearch biedt het mechanisme. De onderzoeksrichting, zoals altijd, komt voort uit inzicht in welke problemen het oplossen waard zijn.

webvise werkt samen met teams die AI integreren in hun ontwikkel- en onderzoeksworkflows. Overweegt u hoe autonome agenten passen in uw processen, neem dan contact op voor een praktische beoordeling van wat zinvol is in uw context.