Hvorfor jeg stoppede med at prompt'e AI-agenter — og begyndte at bygge loops

For et par uger siden.postede Peter Steinberger noget på Twitter, der fik otte millioner visninger: "Du skal ikke længere prompte coding-agenter. Du skal designe loops, der prompter dine agenter." Cirka samtidig sagde Boris Cherny — manden bag Claude Code — noget lignende på Acquired Unplugged: "Jeg prompter ikke Claude mere. Jeg har loops kørende. De prompter Claude."

Og så skete det, som altid sker på internettet: alle diskuterede, ingen så et loop, og samtalen druknede i abstraktion.

Jeg har faktisk kørt loops de sidste par måneder. Ikke fordi jeg er på forkant — jeg var bare træt af manuel sorteringsarbejde og automatiserede det. Det, jeg opdagede, overraskede mig: loop-tankegangen er ikke en avanceret teknik til AI-superbrugere. Det er en naturlig udvikling, der sker, når du holder op med at behandle AI-agenter som avancerede copy-paste-værktøjer og begynder at se dem som systemer, der kan overvåge, beslutte og handle på dine vegne.

De tre slags "loop" ingen kan blive enige om

Her er hvorfor denne samtale ender i kaos: når folk siger "loop," mener de én af tre ting, og forskellene betyder noget.

Først er der den autonome opgaveløkke — grundlæggende "bliv ved indtil det er færdigt." Tænk Geoffrey Huntleys Ralph-script (while :; do cat PROMPT.md | claude-code; done), eller /goal-kommandoen som Codex og Claude Code nu har indbygget. Det er "sæt den i gang og glem den"-tilstand.

Dernæst er der den planlagte eller hændelsesdrevne løkke — arbejde der kører, mens du ikke sidder ved tastaturet. Peter Steinbergeres eget HEARTBEAT.md i OpenClaw er det klassiske eksempel: en tjekliste agenten genovervejer hvert 30. minut. Descendenter af dette mønster inkluderer Codex-automatiseringer og Claude Codes planlagte rutiner.

For det tredje er der orkestrering fan-out — dynamiske arbejdsgange med flere agenter, der kører samtidig. Claude Codes map/reduce-lignende operationer hører hjemme her. Det ligner mere actor-modellen end noget simpelt loop.

Min vurdering? Steinberger og Cherny beskriver den anden type, forbundet med den første. De loops, jeg kører, er planlagte og hændelsesdrevne på overfladen, og flere af dem udfører eksperimentagtige indre loops, når de udløses. Den kombination er der, hvor den virkelige værdi ligger.

PR-babysitteren: min indgang til loop-design

Jeg havde allerede AI-kodegennemgang på alle pull requests. Claude gennemgik først, derefter Codex' indbyggede review, og så en custom GitHub Action, hvor jeg kontrollerede præcis hvad modellen så — inklusive hele samtalekonteksten plus patch-diff.

Min faktiske arbejdsgang var absurd: send en PR, vent på at anmeldelserne kommer ind, og kopier så review-kommentarer ind i agenten. Nogle gange indsatte jeg screenshots. Det var manuelt, repetitivt og sjælenedbrydende.

En dag spurgte jeg min agent: "Kan du ikke bare bruge gh-klienten og tjekke review-status selv?" Det kunne den. Så naturligvis spurgte jeg: "Kan du ikke bare blive ved med at tjekke og fortælle mig, når det er færdigt?"

Den ene forespørgsel transformerede min arbejdsgang. Nu overvåger agenten ændringer i review-status, henter ny kontekst, analyserer feedback og gør det faktiske arbejde med at adressere den. Løkken slutter, når den når en sorteringsbeslutning: accepter feedback, skub tilbage på den, eller eskaler til mig.

Mønsteret generaliserer smukt: hold øje med tilstandsændringer i eksterne systemer, vågn op når de sker, hent frisk kontekst, analyser, handl og sorter. Når du først ser denne form, begynder du at spotte den alle vegne. Codex-holdet sender deres egen babysit-pr-færdighed, og Claude Codes dokumentation nævner nu PR-babysitting som et hovedanvendelsesområde for deres /loop-kommando.

Indre loops: få agenten til at køre sine egne eksperimenter

Der er et andet loop-mønster, som tog mig længere tid at sætte pris på: eksperimentløkken. Andrej Karparthys autoresearch-koncept fik mig til at tænke over dette — kør mange iterationer, mål resultater, behold det der virker. Jeg rettede det mod en langsom Python-sti og kørte 49 eksperimenter på en time, og pressede p95-latency fra 339ms ned til 34ms for omkring 200 kroner.

Samme mønster gælder for sværere problemer: debugging af agentadfærd i produktion. Når noget går galt — en underlig trace i Braintrust, brugerfeedback i Slack, eller noget jeg selv rammer — spinner jeg en worktree op, indsætter trace'en og kalder testløkken.

Her er hvad der gør dette loop anderledes: det tvinger en disciplin, som modellens naive intuition kæmper imod. Overladt til sig selv vil en model hardkode "aldrig gør X, Y, Z" ind i system-prompten og overfitte til den ene trace, du viste den. Færdighedens referencer destillerer forskningen i, hvorfor den tilgang fejler, og loop-kontrakten kræver en hypotese og en testmatrix.

Jeg skal bruge tre cases: den originale fejlende case, en tilstødende positiv case der burde tage samme vej, og et modeksempel der burde tage en anden vej. Tre eller fire probes kører samtidigt mod lokal dev og genskaber præcis brugerkonteksten fra trace'en. Hver kørsel scores på tool-kald, latency, input-token-delta og korrekthed. Modellen kan ikke snyde ved at huske — den er nødt til faktisk at forstå.

Hvad der faktisk ændrer sig, når du bygger loops

Det største skift er ikke teknisk — det er konceptuelt. Når du prompter en agent, er du stadig den, der styrer. Du er gassen, navigatoren, kvalitetstjekkeren. Loops inverterer det. Du bliver arkitekten bag systemer, der styrer sig selv.

Det betyder ikke, at fuld autonomi er målet. Jeg står stadig ved sorteringsporten for alt vigtigt. Loops håndterer kedeligheden, overvågningen, repetitionerne. Jeg håndterer de vurderingskald, der faktisk betyder noget.

Det andet skift er, at loops tvinger dig til at være eksplicit om succeskriterier. Et godt loop har klare exit-betingelser, klare beslutningspunkter, klare eskaleringsstier. Du kan ikke bygge et loop uden at definere, hvad "færdig" ser ud. Den disciplin siver ud i alt andet.

For det tredje: loops er sammensatte. PR-babysitteren arbejder side om side med eksperimentløkken. Planlagte tjek udløser on-call-respons. Du begynder at bygge et bibliotek af adfærd, der arbejder sammen, i stedet for en bunke one-off-prompts.

Det praktiske udgangspunkt

Hvis du vil eksperimentere med loops, så start med noget du allerede har automatiseret dårligt. Du har sandsynligvis en GitHub Action, der gør noget på en plan, eller en Claude Code-session du manuelt kører igen, eller en review-proces der involverer copy-paste af outputs mellem værktøjer.

Vælg den mest irriterende. Spørg dig selv: hvilken tilstandsændring venter jeg egentlig på? Hvilken kontekst har agenten brug for, når den ændring sker? Hvilken beslutning skal den tage?

Og så byg loopet. Det behøver ikke være elegant. Det skal virke, og det skal sætte dig tilbage i kontrol over din egen tid.

De fulde konfigurationer, færdigheder og CI-workflow bag de loops, jeg kører, ligger i et offentligt snapshot-repo: camwest/agent-skills. Det er ikke et poleret produkt — det er et fungerende system, der udvikler sig, mens jeg lærer. Det er pointen. Loops er ikke en destination; de er en praksis.

Diskursen omkring AI-agenter drukner i abstraktion. Her er den konkrete version: stop med at prompte, begynd at bygge loops, og se hvad der sker, når du lader maskinen håndtere overvågningen, mens du håndterer betydningen.