Nyheden først. Ifølge en gennemgang udgav Andrej Karpathy 7. marts 2026 et lille, skarpt repo kaldet autoresearch under MIT‑licens. Pointen er enkel: I stedet for at tweake hyperparametre manuelt defineres et mål, en verifikator og en stop‑betingelse. Agenten planlægger, handler, tjekker og gentager – indtil målet er nået, eller budgettet stopper løbet [kilde]. Gennemgangen bemærker også, at repoet består af cirka 630 linjer fordelt på tre filer og nåede i nærheden af 90.000 GitHub‑stjerner kort efter udgivelsen [kilde].
Guiden sætter det i ramme: Loop engineering ser AI‑arbejdet som et målstyret loop – ikke en enkelt prompt‑svar‑udveksling. Mange bruger stadig AI som en slags søgeboks, men loop‑mønstret automatiserer iterationen mod et mål, når det kan måles [kilde]. Guiden understreger samtidig, at de rapporterede eksperimenter kører som små, hurtige iterationer; generalisering til større modeller og produktion er et åbent spørgsmål, som forbliver et forbehold i materialet [kilde].
Hvad loop engineering dækker over
To tilstande beskrives i kilden: En prompt er ét skub, hvorefter et menneske vælger næste skridt. Et loop er en intention pakket ind i plan, handling, kontrol og gentagelse. Maskinen får lov at bevæge sig mod målet trin for trin uden konstant mellemkomst – men kun når arbejdet kan måles [kilde].
Guiden peger på tre ufravigelige byggeklodser for et pålideligt loop: En verifikator, som bedømmer hvert forsøg. En state, som husker hvad der blev prøvet og hvad der virker. Og en stop‑betingelse, som forhindrer runaway‑omkostninger. Uden verifikator: bare gentagelse. Uden state: glemsomhed. Uden stop: ukontrolleret forbrug [kilde].
Karpathys autoresearch indefra
Autoresearch fremhæves som et konkret, læsbart eksempel. Ifølge guiden består det af tre filer og omkring 630 linjer kode og udgives under MIT‑licens. Designvalget, som kilden lægger vægt på, er adskillelsen mellem det agenten må ændre – og det, den ikke må. Agenten må redigere i train.py, hvor model, optimeringer (bl.a. Muon og AdamW) og træningsløkke bor. prepare.py, der håndterer evaluering, er read‑only. Det skal hindre, at agenten “forbedrer” metrikken ved at gøre testen lettere i stedet for at forbedre modellen [kilde].
Hvert loop‑skridt kører ét eksperiment: læs kode, foreslå ændring, træn i fem minutter, evaluer, og behold eller rollback ændringen. Scoringen, som beskrives i guiden, er validation bits per byte (val_bpb), hvor lavere er bedre [kilde]. Det er også her, guiden betoner stop‑betingelser for at holde budgettet under kontrol.
Resultater og forbehold
Guiden nævner en anekdote fra Shopify, hvor CEO Tobi Lütke beskriver 19 procent forbedring efter 37 eksperimenter. Kilden markerer ikke en fuld dokumenteret baseline og kontrol for opsætningen, så eksemplet bør ses som illustrativt – ikke som reproduceret evidens i sig selv [kilde].
De åbne spørgsmål, som guiden selv lister, omfatter bl.a. reproducerbarhed, generalisering til større modeller hvor fem minutters kørsel kan være utilstrækkeligt signal, samt skaleringsøkonomi. Kilden peger på, at de viste fremskridt er for små, hurtige loop‑kørsler og ikke i sig selv dækker alle domæner eller produktionsscenarier [kilde].
Bilevel Autoresearch kort fortalt
Ifølge guiden peger Bilevel Autoresearch på en indre og en ydre agent – et loop oven på loopet – der arbejder mod samme metrik men på to beslutningsniveauer. Guiden henviser til det oprindelige paper for den dybere matematik og eksperimentopstilling og opfordrer implicit til validering i eget domæne, før man skalerer [kilde].
Guiden omtaler rapporterede forbedringer i val_bpb i nogle opsætninger, men uden at udfolde hele metodikken i selve guiden. Derfor peger den læseren videre til de oprindelige artefakter for detaljer og reproduktion [kilde].
Hvad det kræver i praksis
De tre kerneelementer går igen i den praktiske gennemgang: en automatisk verifikator med en klart defineret målmetrik, en state‑mekanisme, så næste run ikke starter forfra, og en stop‑betingelse for at undgå, at omkostninger løber løbsk. Kilden beskriver specifikt, at en hård adskillelse mellem træning og evaluering – f.eks. read‑only evaluering i prepare.py – hjælper mod metrik‑gaming [kilde].
Guiden peger også på fem generelle byggeklodser i en agent‑opsætning: automation; en “skill” som projektviden i markdown (program.md); sub‑agenter, der adskiller forfatter og anmelder; connectors til værktøjer; og verifikatoren som portvagt. Den præsenteres som et mønster eller en arkitektur, ikke som krav om en bestemt platform [kilde].
Når loops fejler
Et velkendt problem, som kilden adresserer, er metrik‑gaming: en agent kan maksimere metrikken uden at løse det egentlige problem. Beskyttelsen i guiden starter med adskilt træning og evaluering, så evalueringen ikke kan forvrides af agentens ændringer. Eksemplet med train.py kontra prepare.py illustrerer denne beskyttelse [kilde].
Stop‑betingelser er et andet værn, som guiden fremhæver. Uden dem risikerer man mange iterationer uden reel forbedring og med stigende omkostning. Kilden beskriver stop‑kriterier som antal forsøg eller tidsgrænser som konkrete måder at rammesætte et loop på [kilde].
Sammenligning med en anden vej
Som kontrast fremhæver en separat artikel fra VentureBeat Google Researchs TabFM: en foundation‑model til tabulære data, der kan levere forudsigelser for en uset tabel i et enkelt forward pass. Ifølge artiklen kan det reducere time‑to‑production fra uger med pipelines til et API‑kald i nogle scenarier [kilde].
Forskellen i tilgang er tydelig i kilderne: TabFM bytter per‑dataset træning ud med in‑context læring for tabulære opgaver, mens autoresearch automatiserer selve forbedringsprocessen i eksisterende træningskode via målstyrede loops. De to retninger kan eksistere side om side, men de adresserer forskellige problemer, sådan som artiklerne beskriver det [kilde] [kilde].
Konkrete skridt fra kilderne
Hvis man vil prøve mønstret af, peger guiden på de samme byggesten hver gang: Definér et klart mål, sæt en verifikator på, hold styr på state, og indfør en stop‑betingelse. Hold evalueringen uden for agentens rækkevidde. I autoresearch er det eksemplificeret med train.py som det redigerbare og prepare.py som read‑only. Kilden beskriver derudover fem‑minutters træningsklip i hvert eksperiment samt keep/rollback‑mekanikken, som gør forløbet kontrollerbart fra skridt til skridt [kilde].
Guiden afrunder med, at loop engineering først giver mening, når arbejdet kan måles. Her bliver verifikator, state og stop‑betingelse ikke bare teknik, men de egentlige gelændere, der gør mønstret anvendeligt i praksis – med de nævnte forbehold om skala, reproduktion og omkostninger, som kilderne selv gør opmærksom på [kilde].
