Lige nu er alle vilde med agenter, der kører af sig selv. Du sover, og om morgenen ligger der tre pull requests, et opdateret dashboard og en log over alt det, maskinen nåede, mens du var væk.
Og nu bliver det først rigtig vildt. Agenter, der skriver deres egne loops, retter deres egen kode og bliver klogere undervejs. Skalerer uden flere mennesker. Forbedrer sig selv.
Hvad er der ikke at kunne lide?
Én ting. Et loop er kun så meget værd som din evne til at tjekke, hvad det lavede. Kan du ikke det, render maskinen bare hurtigere og hurtigere i en retning, du ikke kan se er forkert. Og ingen opdager det, før det er for sent.
Hvad et loop egentlig er
Skræl marketingen af, så er et loop ikke mystisk.
Noget kører på et tidspunkt eller en hændelse. I midten sidder en beslutning, der ikke er skrevet i sten. Maskinen kigger på tilstanden, vælger hvad der skal ske, gør det, tjekker resultatet og starter forfra.
Det spændende er ikke modellen i midten. Den kan du skifte ud i morgen. Det spændende er rammen omkring den. At noget sker af sig selv. At et valg bliver truffet uden et menneske, der siger ja. Og at valget får konsekvenser ude i verden.
Derfor står og falder det hele med ét spørgsmål.
Kan du bagefter vide, om den gjorde det rigtigt?
Forskellen på et loop og et cron job
Et cron job er en tro hund. Det gør det samme hver gang, præcis når du har sagt det, uanset hvad der ellers foregår. Skemaet bestemmer hvornår. Du bestemte for længst hvad.
Backup klokken to hver nat. År efter år. Uden at kny.
Et loop kan også køre på et skema eller en trigger. Men hvad det laver, bliver først afgjort, når det kører. Den lille forskel, beslutningen i midten, er hele pointen. Cron jobbet udfører noget, du har låst fast. Loopet kigger sig omkring og vælger. Og det kan godt vælge noget andet i dag end i går.
Det ændrer alt for verifikationen.
Et cron jobs handling er fast. Du tjekkede den én gang, dengang du skrev koden. Et loops handling skifter fra gang til gang, så tjekket skal ske hver gang, mod det der faktisk kom ud.
I et cron job bor korrektheden i koden. I et loop skal korrektheden måles, mens det kører, fordi koden ikke på forhånd bestemte, hvad der ville ske.
Et konkret eksempel lige nu er loop i Claude Code. Du giver den et interval og en opgave, og den sætter en tilbagevendende prompt op, som fyrer af sig selv, oversat til et cron udtryk bag kulisserne.
Det, der skiller den fra et almindeligt cron job, er igen beslutningen i midten. Den kører en prompt eller en skill, og agenten finder selv ud af, hvad der skal ske.
Det gør det pinligt nemt at starte et loop. Et interval, en linje, så kører det.
Og præcis dér bliver verifikation vigtigere end før.
Det loop tager af dine skuldre, er besværet med at planlægge. Om svaret er rigtigt, blander den sig ikke i. Kig på de opgaver, folk faktisk sætter den til. Holde øje med en pull request og rebase den. Banke på et staging deploy og melde statuskoden tilbage. Råbe op, hvis CI skifter farve.
De har alle en billig facitliste indbygget. Testen er grøn eller rød. Deployet svarer eller er dødt. CI passerer eller fejler.
De rigtigt svære opgaver, dem uden facitliste, er mærkværdigt fraværende fra eksemplerne.
Det er ikke et tilfælde.
Det egentlige spørgsmål
De fleste starter med at spørge, om agenten kan klare opgaven.
Begynd et andet sted.
Findes der et objektivt mål, jeg kan holde resultatet op imod?
Kan du formulere det mål, har du noget at bygge på. Kan du ikke, så byg facitlisten først. Eller lad være med at bygge loopet endnu.
Et loop uden et mål, du kan tjekke imod, er bare en automatiseret måde at lave fejl på, som du opdager for sent.
Og facitlisten behøver ikke ligge hos dig. Tværtimod er hele pointen, at den helst ikke gør. I samme sekund et menneske skal godkende hvert resultat, er skaleringen væk.
Der skal bare være et system, gerne ikke dig, der kan afgøre, om målet blev ramt. Helst noget hårdt og firkantet. En test der går igennem eller falder. Et schema der validerer. Et tal der faldt eller ikke faldt.
Når tjekket er så håndfast, kan loopet selv læse, om det lykkedes, og handle på det.
Lader du i stedet en sprogmodel bedømme en anden sprogmodels svar, er du ude på tynd is. Det ligner verifikation, men det er en model, der gætter på, om en anden model gættede rigtigt.
Nogle gange er det det bedste, du har. Fint nok. Men byg ikke et selvforbedrende system oven på det og regn med, at det trækker i den rigtige retning.
Et dyrt tjek kan være det rigtige tjek
Mange tror, at et loop kun egner sig, hvis tjekket er nemt.
Det er forkert.
Det vigtige er ikke, om tjekket er billigt. Det vigtige er, om det er objektivt.
Tag en sprogmodel, der forsøger at presse loss ned i en machine learning algoritme. Den læser nye papers, implementerer idéer og prøver dem af.
Tjekket er dyrt. Du er nødt til at træne for at vide, om loss faldt.
Men det er knivskarpt objektivt. Tallet falder, eller det gør ikke. Det er præcis sådan et loop, der kan være værd at bygge, fordi tjekket holder, dyrt eller ej. Systemet kan optimere uden, at nogen behøver vurdere hvert skridt, for der er ingen tvivl om, hvad bedre betyder.
Hold det op mod et loop, der skal skrive god tekst eller træffe gode forretningsbeslutninger.
Dér er tjekket nemt at lade som om, man har, og svært at have for alvor. Der er ikke ét tal. Ikke én facitliste. Ikke ét schema, der fortæller dig, om beslutningen var god.
Bygger du selvforbedring oven på den slags, optimerer systemet mod din proxy for kvalitet. Og afstanden mellem proxyen og den ægte vare bliver kun større, jo mere frihed du giver det.
Hvor selvforbedringen bliver konkret
Det stærkeste argument for verifikation er et loop, der skriver sin egen kode.
Forestil dig et system, der selv henter ny lovgivning og maser den ind i et struktureret format. Det meste glider lige igennem. Men ny lovgivning ligner ikke altid gammel lovgivning, og en dag dukker der et dokument op, som parseren ikke kan finde ud af.
Et naivt system fejler i stilhed eller spytter noget forkert ud.
Et loop med et tjek opdager, at outputtet ikke validerer mod schemaet. Så retter det sin egen kode, prøver igen og kan selv se, om ændringen virkede.
Det er her, pointen bliver konkret.
Schema valideringen er ankeret. Det er den, der gør det forsvarligt overhovedet at lade systemet pille ved sin egen kode. Systemet kan se, hvornår ændringen virkede, og hvornår den ikke gjorde.
Tag valideringen væk, og du har en agent, der skriver sig selv om på fornemmelse.
Det er præcis den slags, du aldrig vil have kørende uden opsyn.
Det er samme princip som i loss eksemplet, bare med struktur i stedet for et tal. Begge steder findes der et objektivt signal. Og det signal er det eneste, der skiller selvforbedring fra rent held.
At loope loopet
Når du først har et par verificerbare loops i luften, åbner der sig et interessant trick. Et loop, hvis eneste job er at gøre de andre loops bedre.
Hver kørsel efterlader et trace. En logbog over hvilke trin der kørte, hvad der blev besluttet, om målet blev ramt, hvor tit det gik godt, og hvor det gik galt.
Et meta loop kan læse de logbøger og skrue på de underliggende loops. Stramme en tærskel. Skrive en prompt om. Lappe en parser, der bliver ved med at snuble over samme slags input.
Men det fungerer kun, fordi de underliggende loops kan verificeres.
Deres traces bærer et objektivt signal. Ramte loopet sit mål eller ej? Uden det signal er trace’et bare en logbog over en maskine, der erklærede sig selv færdig.
Så sidder meta loopet og finpudser støj.
Meta loopet arver altså kravet om verifikation. Det skal også have et mål, der kan måles. Ramte loop X sit mål oftere i ugerne efter ændringen end før? Faldt fejlratens gennemsnit? Blev færre kørsler rullet tilbage?
Det kan man kun måle, fordi loop X selv kan verificeres.
Det er her, den ægte sneboldeffekt opstår. Hvert verificerbart loop spytter troværdige traces ud, og meta loopet laver dem om til forbedringer.
Men hele systemet hviler på, at signalet i trace’et er ægte.
Sætter du et meta loop oven på loops, du ikke kan verificere, har du bare løftet problemet én etage op. Nu har du en model, der læser logbøger, foreslår ændringer og ingen sikker måde har at vide, om ændringerne hjalp.
Og så er der en forudsætning, som er nem at glemme. Loopene skal faktisk efterlade traces.
Skriver du ikke kørselshistorik ned, trin for trin, har meta loopet ingenting at læse. Observabilitet er hele fødegrundlaget. Uden den er der ikke noget at optimere på.
Sådan beslutter du, om du skal bygge loopet
Reglen falder næsten ud af sig selv.
Inden du bygger et loop, så skriv det tjek ned, der afgør, om en kørsel gik godt.
Skriv det først. Som om det er det vigtigste i hele systemet.
For det er det.
Kan du formulere et hårdt, objektivt tjek, så byg løs. Det er den slags loops, der kan køre uden mennesker og blive bedre med tiden. Det er dér, gevinsten ligger.
Kan du kun formulere et tjek, hvor en model skal bedømme en anden model, så ved du, at du bygger noget skrøbeligt. Det kan stadig være nyttigt. Bare hold et menneske tæt på, og lad være med at sætte forbedringen på autopilot.
Kan du slet ikke formulere et tjek, er opgaven ikke moden til et loop endnu. En agent kan sagtens hjælpe dig med den. Den skal bare ikke køre alene.
Det, du sidder tilbage med om morgenen, er kun noget værd, hvis du tør stole på, at det maskinen lavede klokken tre om natten, var rigtigt.
Den tillid bygger du ind fra starten.
Ellers bygger du den aldrig.