Andrej Karpathys autoresearch beviste, at en velskrevet Markdown-fil kan dirigere AI-agenter til at gøre rigtige videnskabelige opdagelser hen over natten. Men ikke alle program.md-filer er ens.

Kvaliteten af dine Markdown-instruktioner bestemmer direkte kvaliteten af AI-agentens output. En vag program.md producerer tilfældige, urettede eksperimenter. En præcis én producerer fokuserede forbedringer, der akkumulerer.

Her er, hvordan du skriver en program.md, der faktisk virker.

Strukturen af en god program.md

Enhver effektiv program.md har brug for fem sektioner, uanset om du laver ML-forskning eller andet agentstyret arbejde.

1. Kontekst: Hvad har agenten brug for at vide?

Agenten starter med nul forståelse af dit projekt. Din første opgave er at give den nok kontekst til at træffe intelligente beslutninger.

Hvad der skal inkluderes:

Hvad projektet gør
Hvordan kodebasen ser ud
Nøglefiler og deres formål
Domænespecifik terminologi
Nuværende tilstand og kendte problemer

Hvad der kan udelades:

Åbenlys information, som LLM allerede kender
Implementeringsdetaljer, den kan læse fra koden
Historie, der ikke påvirker nuværende beslutninger

2. Mål: Hvad skal agenten optimere?

Dette er den mest kritiske sektion. Agenten har brug for et klart, målbart mål.

I autoresearch er målet ligetil: reducer val_bpb (validerings bits per byte). Agenten kan måle dette efter hvert 5-minutters træningskørsel.

For dine egne projekter, definer succes i termer, agenten kan evaluere:

“Reducer sideindlæsningstid under 2 sekunder”
“Øg testdækning over 80%”
“Reducer bundle-størrelse med mindst 15%”

Vage mål som “gør koden bedre” producerer vage resultater. Målbare mål producerer fokuserede forbedringer.

3. Begrænsninger: Hvad må agenten aldrig gøre?

Begrænsninger er ligeså vigtige som mål. Uden dem kan agenten finde kreative løsninger, du ikke ønsker — som at slette alle test for at “forbedre” byggehastighed.

Almindelige begrænsninger:

Modificer ikke testfiler eller evalueringskode
Ændr ikke den offentlige API
Introducer ikke nye afhængigheder
Overskrid ikke et hukommelsesbudget
Hold koden læsbar og vedligeholdelig

I autoresearch er den vigtigste begrænsning, at kun train.py kan modificeres. Datapipeline, evalueringskode og testsæt er låst. Dette forhindrer agenten i at gamble med metrikker.

4. Strategi: Hvordan skal agenten tilgå problemet?

Her skinner din domæneekspertise. Du ved ting, agenten ikke gør — hvilke retninger der er lovende, og hvilke der er blindgyder.

Gode strategiinstruktioner:

“Start med hyperparameter-tuning før arkitektoniske ændringer”
“Fokuser på attention-mekanismen — den nuværende implementering kan være suboptimal”
“Prøv regulariseringsteknikker først: dropout, weight decay, layer norm”
“Undgå ændringer, der øger træningstiden med mere end 10%”

Dårlige strategiinstruktioner:

“Prøv alt” (for vagt)
“Skift learning rate til 0.001” (for specifikt — du micromanager)

Det søde punkt er retningsgivende vejledning, der lader agenten udforske inden for produktive grænser.

5. Evaluering: Hvordan skal agenten bedømme succes?

Agenten skal vide, hvordan den måler, om dens ændringer hjalp. I autoresearch er dette indbygget i løkken: hvis val_bpb forbedres, behold ændringen. Hvis ikke, reverter.

For andre kontekster, definer dine evalueringskriterier:

Hvilke metrikker betyder noget?
Hvilken tærskel tæller som en forbedring?
Hvordan skal agenten håndtere tvetydige resultater?
Hvornår skal agenten stoppe og rapportere tilbage?

Almindelige fejl

At være for vag

“Gør modellen bedre” giver agenten ingen retning. Vær specifik om, hvad “bedre” betyder, hvordan man måler det, og hvilke tilgange man skal prøve først.

At være for specifik

“Skift linje 47 til at bruge en learning rate på 3e-4” modvirker formålet med agentic engineering. Du er meningen at sætte retning, ikke diktere implementering. Lad agenten udforske.

At glemme begrænsninger

Uden begrænsninger finder agenter mindste-modstands-vejen — som ofte ikke er det, du ønsker. En agent, der er bedt om at “reducere træningstid”, springer måske halvdelen af træningsdataene over, hvis du ikke siger andet.

Ikke at iterere

Din første program.md vil ikke være perfekt. Se hvad agenten gør, se hvor det går galt, og opdater dine instruktioner. De bedste program.md-filer udvikler sig over snesevis af iterationer.

Iterationsløkken

At skrive program.md er ikke en engangsproces. Det er en løkke:

Skriv din indledende program.md
Kør agenten
Gennemgå hvad agenten gjorde
Opdater dine instruktioner baseret på hvad der virkede, og hvad der ikke gjorde
Gentag

Hver iteration gør dine instruktioner mere præcise. Efter et par runder har du en program.md, der konsekvent producerer gode resultater.

Dette er kernekompetencen i agentic engineering: ikke at skrive kode, men at skrive stadigt mere effektive agentinstruktioner gennem iteration.

Opbyg dit referencebibliotek

De bedste program.md-filer kommer ikke ud af ingenting. De er bygget på dyb viden om domænet — dokumentation, artikler, bedste praksisser og eksempler.

Når du støder på nyttigt referencemateriale på nettet, gem det som Markdown. Så når du skriver din program.md, kan du trække relevant kontekst ind, citere specifikke teknikker og give agenten den baggrundsviden, den har brug for.

De forskere, der får de bedste resultater fra autoresearch, er ikke bare gode skribenter. De er domæneeksperter med velorganiseret referencemateriale, som de kan syntetisere til klare agentinstruktioner.

Save konverterer enhver webside til ren Markdown — perfekt til at bygge det referencebibliotek, der driver effektive program.md-filer. Prøv Save gratis.