Andrej Karpathy’s autoresearch bewees dat een goed geschreven Markdown-bestand AI-agenten kan aansturen om’s nachts echte wetenschappelijke ontdekkingen te doen. Maar niet alle program.md-bestanden zijn gelijk.

De kwaliteit van je Markdown-instructies bepaalt direct de kwaliteit van de uitvoer van de AI-agent. Een vaag program.md produceert willekeurige, ongerichte experimenten. Een precieze produceert gerichte verbeteringen die compounderen.

Hier is hoe je een program.md schrijft die echt werkt.

De Structuur van een Goede program.md

Elke effectieve program.md heeft vijf secties nodig, of je nu ML-onderzoek doet of ander agent-gestuurd werk.

1. Context: Wat Moet de Agent Weten?

De agent begint met nul begrip van je project. Je eerste taak is het genoeg context geven om intelligente beslissingen te nemen.

Wat op te nemen:

Wat het project doet
Hoe de codebase eruitziet
Sleutelbestanden en hun doelen
Domein-specifieke terminologie
Huidige staat en bekende problemen

Wat over te slaan:

Vanzelfsprekende informatie die de LLM al weet
Implementatiedetails die het uit de code kan lezen
Geschiedenis die huidige beslissingen niet beïnvloedt

2. Doelen: Wat Moet de Agent Optimaliseren?

Dit is de meest kritieke sectie. De agent heeft een duidelijk, meetbaar doel nodig.

In autoresearch is het doel eenvoudig: verminder val_bpb (validatie bits per byte). De agent kan dit meten na elke 5-minuten durende trainingsrun.

Definieer voor je eigen projecten succes in termen die de agent kan evalueren:

“Verminder paginalaadtijd onder 2 seconden”
“Verhoog testdekking boven 80%”
“Verklein bundle-grootte met minimaal 15%”

Vage doelen zoals “maak de code beter” produceren vage resultaten. Meetbare doelen produceren gerichte verbeteringen.

3. Beperkingen: Wat Mag de Agent Nooit Doen?

Beperkingen zijn net zo belangrijk als doelen. Zonder hen kan de agent creatieve oplossingen vinden die je niet wilt --- zoals alle tests verwijderen om de bouwsnelheid te “verbeteren.”

Veelvoorkomende beperkingen:

Pas testbestanden of evaluatiecode niet aan
Verander de publieke API niet
Introduceer geen nieuwe afhankelijkheden
Overschrijd een geheugenbudget niet
Houd de code leesbaar en onderhoudbaar

In autoresearch is de kernbeperking dat alleen train.py kan worden aangepast. De datapijplijn, evaluatiecode en testset zijn vergrendeld. Dit voorkomt dat de agent de statistieken manipuleert.

4. Strategie: Hoe Moet de Agent het Probleem Aanpakken?

Dit is waar je domeinexpertise schittert. Je weet dingen die de agent niet weet --- welke richtingen veelbelovend zijn en welke doodlopende wegen zijn.

Goede strategische instructies:

“Begin met hyperparameter-tuning vóór architecturele wijzigingen”
“Focus op het aandachtsmechanisme --- de huidige implementatie is mogelijk suboptimaal”
“Probeer eerst regularisatietechnieken: dropout, gewichtsverval, laagnorm”
“Vermijd wijzigingen die de trainingstijd met meer dan 10% verhogen”

Slechte strategische instructies:

“Probeer alles” (te vaag)
“Verander de leersnelheid naar 0.001” (te specifiek --- je micromanaget)

Het juiste midden is richtinggevende begeleiding die de agent binnen productieve grenzen laat verkennen.

5. Evaluatie: Hoe Moet de Agent Succes Beoordelen?

De agent moet weten hoe te meten of zijn wijzigingen hielpen. In autoresearch zit dit in de lus ingebakken: als val_bpb verbetert, behoud de wijziging. Als niet, terugzetten.

Definieer voor andere contexten je evaluatiecriteria:

Welke statistieken zijn belangrijk?
Welke drempel telt als een verbetering?
Hoe moet de agent omgaan met dubbelzinnige resultaten?
Wanneer moet de agent stoppen en terugrapporteren?

Veelvoorkomende Fouten

Te Vaag Zijn

“Maak het model beter” geeft de agent geen richting. Wees specifiek over wat “beter” betekent, hoe het te meten, en welke benaderingen eerst te proberen.

Te Specifiek Zijn

“Verander regel 47 naar een leersnelheid van 3e-4” verslaat het doel van agentische engineering. Je moet richting aangeven, niet implementatie dicteren. Laat de agent verkennen.

Beperkingen Vergeten

Zonder beperkingen zullen agenten de weg van de minste weerstand vinden --- wat vaak niet is wat je wilt. Een agent die “trainingstijd te verminderen” als opdracht heeft, kan de helft van de trainingsdata overslaan als je dat niet verbiedt.

Niet Itereren

Je eerste program.md zal niet perfect zijn. Kijk wat de agent doet, zie waar het misgaat, en werk je instructies bij. De beste program.md-bestanden evolueren over tientallen iteraties.

De Iteratielus

program.md schrijven is geen eenmalig proces. Het is een lus:

Schrijf je initiële program.md
Voer de agent uit
Beoordeel wat de agent deed
Werk je instructies bij op basis van wat werkte en wat niet
Herhaal

Elke iteratie maakt je instructies preciezer. Na een paar rondes heb je een program.md die consequent goede resultaten produceert.

Dit is de kernvaardigheid van agentische engineering: niet code schrijven, maar steeds effectievere agentinstructies schrijven door iteratie.

Je Referentiebibliotheek Bouwen

De beste program.md-bestanden komen niet uit het niets. Ze zijn gebouwd op diepgaande kennis van het domein --- documentatie, papers, best practices en voorbeelden.

Wanneer je nuttig referentiemateriaal op het web tegenkomt, sla het op als Markdown. Dan kun je bij het schrijven van je program.md relevante context inbrengen, specifieke technieken citeren en de agent de achtergronddkennis geven die het nodig heeft.

De onderzoekers die de beste resultaten behalen uit autoresearch zijn niet alleen goede schrijvers. Het zijn domeinexperts met goed georganiseerd referentiemateriaal dat ze kunnen samenvatten tot duidelijke agentinstructies.

Save converteert elke webpagina naar schone Markdown --- perfect voor het bouwen van de referentiebibliotheek die effectieve program.md-bestanden aandrijft. Probeer Save gratis.