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

In maart 2026 bracht Andrej Karpathy, medeoprichter van OpenAI en voormalig hoofd AI bij Tesla, een framework uit genaamd AutoResearch. Het uitgangspunt is eenvoudig: je beschrijft wat je wilt onderzoeken in een tekstbestand, start het systeem op voordat je gaat slapen en wordt wakker met zo'n 100 voltooide machine learning-experimenten, gerangschikt op prestaties. In drie weken bereikte het 65.000 GitHub-sterren. De snelheid van adoptie weerspiegelt iets echts over wat het project vertegenwoordigt, niet alleen wat het doet.

Wat AutoResearch werkelijk doet

AutoResearch zet een AI-coderagent in op één trainingsscript. De agent past het script aan, voert een trainingsexperiment van vijf minuten uit, meet het resultaat met behulp van een validatiemetric genaamd val_bpb (bits per byte, een maatstaf voor de efficiëntie van taalmodellen) en beslist dan of de wijziging bewaard of verworpen wordt. Als de wijziging de score verbetert, wordt het de nieuwe baseline. Als dat niet het geval is, draait de agent de wijziging terug en probeert iets anders. Deze lus draait continu en produceert ongeveer 12 experimenten per uur, zo'n 100 gedurende een nacht.

Het vaste budget van vijf minuten per experiment is een bewuste ontwerpkeuze. Het maakt resultaten vergelijkbaar over runs 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-bestandenarchitectuur

Het systeem is georganiseerd rond drie bestanden, elk met een eigen rol:

• prepare.py is vast. Het verzorgt de datavoorbereiding en verandert nooit. Dit houdt het experimentele substraat stabiel, zodat variaties in resultaten echte modelverschillen weerspiegelen in plaats van wijzigingen in de datapipeline.
• train.py is het canvas van de agent. Het begint als een baseline trainingsscript en wordt door de agent over honderden iteraties gewijzigd, uitgebreid en verfijnd. 's Ochtends kan het er substantieel anders uitzien dan waar je mee begon.
• program.md wordt door de mens geschreven. Hier beschrijf je je onderzoeksstrategie: welke benaderingen te verkennen, welke beperkingen te respecteren, welke hypothesen te testen. Het is het enige dat de mens hoeft te schrijven.

De eenvoud is opzettelijk. Door wijzigingen te beperken tot één bestand (train.py) is elke wijziging controleerbaar. Je kunt de diff bekijken tussen de ochtendversie en het startpunt en begrijpen wat de agent daadwerkelijk heeft gedaan. Dit is moeilijker te bereiken wanneer agenten tegelijkertijd veel bestanden aanraken.

Je schrijft de onderzoeksstrategie, niet de code

Karpathy's formulering van de menselijke rol is het waard direct te citeren. Hij beschrijft het zo: "Je schrijft de code 99% van de tijd niet direct. Je orkestreert agenten." De taak van de mens is program.md schrijven, wat hij de "research org code" noemt, de strategie op hoog niveau die bepaalt wat de agent moet nastreven.

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

Of dit perspectief zich generaliseert buiten ML-onderzoek is een open vraag. Maar binnen het domein van iteratieve experimentatie, waar het doel is een grote ruimte van mogelijke benaderingen te doorzoeken en te identificeren wat werkt, past het uitstekend. De agent kan die ruimte veel sneller doorzoeken dan welk menselijk team dan ook.

Wat de cijfers laten zien

Karpathy draaide AutoResearch twee dagen op een persoonlijk project en rapporteerde ongeveer 700 autonome codewijzigingen. Van deze resulteerden er ongeveer 20 in additieve verbeteringen die samengesteld tot betekenisvolle vooruitgang. Het cumulatieve effect was een efficiëntiewinst van 11% op het Time to GPT-2 leaderboard, een benchmark die meet hoe efficiënt een model GPT-2-niveau prestaties kan bereiken.

Het slagingspercentage van ongeveer 3% klinkt misschien laag. Maar overweeg het alternatief: een menselijke onderzoeker die 700 experimenten handmatig uitvoert zou maanden nodig hebben. De agent voert ze in één nacht uit. De economie verandert volledig wanneer de kosten van een mislukt experiment dalen naar vijf minuten GPU-tijd in plaats van dagen menselijke inspanning.

Een eerlijk vergelijkingsmechanisme

Het vaste budget van vijf minuten lost ook een subtiel probleem in ML-onderzoek op: hoe vergelijk je eerlijk benaderingen die variëren in computationele complexiteit? Als een techniek twee keer zoveel rekenkracht vereist, zou een langere trainingsrun het er beter uit laten zien dan het is. Door de tijd constant te houden, zorgt AutoResearch ervoor dat verbeteringen echte algoritmische winsten weerspiegelen in plaats van simpelweg "meer rekenkracht uitgeven"-strategieën.

Ontwerpbeslissingen die ertoe doen

Verschillende keuzes in het ontwerp van AutoResearch weerspiegelen lessen uit ML-systemen in productie die het vermelden waard zijn:

Deze beperkingen maken het systeem begrijpelijk. Een krachtigere agent met minder beperkingen zou snellere maar moeilijker te begrijpen resultaten kunnen produceren. AutoResearch ruilt wat ruwe capaciteit in voor interpreteerbaarheid, wat belangrijk is als je daadwerkelijk wilt leren van wat de agent ontdekt.

Het bredere signaal: zichzelf verbeterende AI

Karpathy's beschrijving van wat AutoResearch vertegenwoordigt is betekenisvoller dan de tool zelf. Hij noemt het het begin van het "zichzelf verbeterende loop-tijdperk van AI": systemen waarbij AI-agenten het onderzoek uitvoeren dat toekomstige AI-systemen beter maakt. De lus is: betere agenten voeren betere experimenten uit, vinden betere trainingstechnieken, produceren betere modellen, die betere agenten worden.

Dit is niet nieuw als concept. Onderzoekers theoretiseren al decennia over recursieve zelfverbetering. Wat nieuw is, is dat de infrastructuur om dit te doen, tenminste in een beperkt domein, nu op één GPU past en in een middag opgezet kan worden. AutoResearch is niet de volledige zelfverbeteringslus. Maar het demonstreert een concreet stuk ervan: AI-gestuurde experimentele zoektocht die echte, meetbare verbeteringen oplevert in de efficiëntie van AI-training.

De implicaties reiken verder dan ML-onderzoek. Elk domein met een duidelijke evaluatiemetric, een aanpasbaar artefact en een grote zoekruimte van mogelijke benaderingen is een kandidaat voor dit patroon. Softwareoptimalisatie, geneesmiddelenontdekking, materiaalwetenschap, financiële modellering. Het knelpunt in elk geval zijn de kosten van het uitvoeren van experimenten; het verlagen van die kosten verandert wat haalbaar is.

Community-uitbreidingen

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

• macOS met Apple Silicon via MLX, waardoor het toegankelijk is zonder cloud-GPU-kosten voor gebruikers op Macs met M-chips
• Windows met RTX-GPU's via community-forks die de trainingspipeline aanpassen aan CUDA op consumentenhardware
• 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 die geen ML-specialisten zijn maar willen experimenteren met trainingsoptimalisatie hebben nu een toegangspad, op hardware die ze al bezitten.

Wat dit betekent voor teams die met AI werken

AutoResearch is een onderzoekstool, geen productieplatform. Maar het patroon dat het demonstreert is direct relevant voor hoe teams bredere AI-ondersteunde werkzaamheden zouden moeten beschouwen.

De menselijke rol verandert

Als de agent de experimenten uitvoert, ligt de waarde van de mens in het stellen van de juiste vragen. Een goede program.md schrijven vereist begrip van welke benaderingen de moeite waard zijn om te verkennen, welke beperkingen er toe doen en hoe succes er daadwerkelijk uitziet. Dit is werk op een hoger niveau dan code schrijven, maar het is niet makkelijker. Het vereist domeinkennis en oordeelsvermogen.

Nachtelijke rekencapaciteit is onderbenutt

De meeste teams die cloudinfrastructuur draaien hebben 's nachts inactieve GPU-capaciteit. AutoResearch maakt het argument dat deze capaciteit productief experimenteel werk zou kunnen doen in plaats van ongebruikt te blijven. De vraag voor elk team met een duidelijk optimalisatiedoel en een testbare metric is of hetzelfde patroon van toepassing is op hun probleem.

Leesbaarheid moet worden ingebouwd

De enkelvoudige bestandsbeperking in AutoResearch is niet alleen een technische beperking; het is een leesbaarheidsfeature. Als agenten alles kunnen aanraken, vereist begrijpen wat ze deden aanzienlijk reverse engineering. Systemen ontwerpen waarbij agentacties afgebakend en controleerbaar zijn, wordt steeds belangrijker naarmate de autonomie toeneemt.

Hoe te beginnen

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

De interessantere vraag is wat je zou onderzoeken. AutoResearch geeft je het mechanisme. De onderzoeksrichting komt, zoals altijd, voort uit begrip van welke problemen de moeite waard zijn om op te lossen.

Bij webvise werken we met teams die AI integreren in hun ontwikkel- en onderzoeksworkflows. Als je nadenkt over hoe autonome agenten in jouw processen passen, neem contact op en we bespreken wat er echt zinvol is voor jouw context.