Slutt å prompt, start å bygge loops

For et par uker siden tweeta Peter Steinberger noe som fikk åtte millioner visninger: «Du bør ikke lenger prompt kodingsagenter. Du bør designe loops som prompt agentene dine.» Rundt samme tid sa Boris Cherny—skaperen av Claude Code—noe lignende på Acquired Unplugged: «Jeg promoter ikke Claude lenger. Jeg har loops som kjører. Det er de som promoter Claude.»

Og så gjorde internett som internett gjør: alle diskuterte, ingen så et konkret eksempel, og diskursen druknet i abstraksjon.

Jeg har kjørt faktiske loops de siste månedene. Ikke fordi jeg ligger foran kurven—jeg ble bare irritert nok over manuelt sorteringsarbeid til å automatisere det. Det jeg fant overrasket meg: loop-tenkningen er ikke en avansert teknikk for AI-powerusere. Det er en naturlig evolusjon som skjer når du slutter å behandle AI-agenter som avanserte kopieringsverktøy og begynner å behandle dem som systemer som kan overvåke, bestemme og handle på dine vegne.

De tre typene «loop» ingen er enige om

Her er hvorfor denne samtalen blir rotete: når folk sier «loop», kan de sikte til én av tre ting, og forskjellene betyr noe.

Først: den autonome oppgaveløkka. Tenk «fortsett til du er ferdig». Geoffrey Huntleys Ralph-script er et eksempel (while :; do cat PROMPT.md | claude-code; done), eller /goal-kommandoen som Codex og Claude Code nå har innebygd. Dette er «sett i gang og glem det»-modus.

Andre: den planlagte eller hendelsesstyrte løkka. Arbeid som kjører mens du ikke sitter ved maskinen. Peter Steinbergers egen HEARTEBEAT.md i OpenClaw er det klassiske eksempelet: en sjekkliste agenten vurderer på nytt hvert 30. minutt. Arvtakere av dette mønsteret inkluderer Codex-automatiseringer og Claude Codes planlagte rutiner.

Tredje: orkestrering med fan-out. Dynamiske arbeidsflyter der flere agenter kjører samtidig. Claude Codes operasjoner i map/reduce-stil faller hit. Dette er nærmere aktørmodellen enn noe som ligner en enkel loop.

Min tolkning? Steinberger og Cherny beskriver den andre typen, koblet sammen med den første. Loopsene jeg kjører er planlagte og hendelsesstyrte på utsida, og flere av dem kjører eksperimentelle indre løkker når de trigges. Den kombinasjonen er der den virkelige gevinsten ligger.

PR-babysitteren: min inngang til loop-design

Jeg hadde allerede AI-kodegjennomgang på alle pull requests. Claude gjennomgikk først, deretter Codex sin innebygde gjennomgang, deretter en egen GitHub Action der jeg kontrollerte akkurat hva modellen fikk se—full samtalekontekst pluss patch-differensialet.

Den faktiske arbeidsflyten min var absurd: send inn en PR, vent på tilbakemeldinger, kopier deretter inn kommentarene i agenten. Noen ganger limte jeg inn skjermbilder. Det var manuelt, repetitivt og sjeleparende.

Én dag spurte jeg agenten: «Kan du ikke bare bruke gh-klienten og sjekke statusen selv?» Den kunne det. Så naturlig spurte jeg: «Kan du ikke bare fortsette å sjekke og si fra når det er klart?»

Den ene forespørselen transformerte arbeidsflyten. Agenten overvåker nå statusendringer på reviews, henter ny kontekst, analyserer tilbakemeldingene, og gjør det faktiske arbeidet med å adressere dem. Løkka avsluttes når den når en sorteringsbeslutning: aksepter tilbakemeldingen, skyv tilbake på den, eller eskaler til meg.

Mønsteret lar seg generalisere pent: se etter tilstandsendringer i eksterne systemer, våkn opp når de skjer, hent inn fersk kontekst, analyser, handle, og sorter. Når du ser denne forma, begynner du å finne den overalt. Codex-teamet sender nå sin egen babysit-pr-skill, og Claude Codes dokumentasjon nevner PR-babysitting som et hovedbruk for /loop-kommandoen.

Indre løkker: få agenten til å kjøre sine egne eksperimenter

Det er et annet loop-mønster som tok meg lenger tid å sette pris på: eksperimentløkka. Andrej Karpathys autoresearch-begrep fikk meg til å tenke på dette—kjøre mange iterasoner, måle resultater, beholde det som funker. Jeg pekte det mot en treg Python-vei og kjørte 49 eksperimenter på en time, og presset p95-latens fra 339ms ned til 34ms for omtrent 24 dollar.

Samme mønster funker på hardere problemer: feilsøking av agentatferd i produksjon. Når noe går galt—en rar trace i Braintrust, bruker tilbakemelding i Slack, eller noe jeg støter på selv—spin-up en worktree, lim inn trace-en, og kall opp testløkka.

Her er hva som gjør denne løkka annerledes: den påtvinger en disiplin som modellens naive intuisjon kjemper mot. Overlatt til seg selv vil en modell hardkode «aldri gjør X, Y, Z» i system-prompten og overtilpasse til den ene trace-en du viste den. Skillens referanser destillerer forskningen på hvorfor den tilnærmingen feiler, og loop-kontrakten krever en hypotese og en testmatrise.

Jeg trenger tre tilfeller: den originale feilende saken, et nærliggende positivt tilfelle som skal ta samme vei, og et moteksempel som skal ta en annen. Tre eller fire prober kjører samtidig mot lokal dev, og rekonstruerer nøyaktig brukerkonteksten fra trace-en. Hver kjøring scores på verktøykall, latens, input-token-delta og korrekthet. Modellen kan ikke jukse ved å huske—den må faktisk forstå.

Hva som faktisk endrer seg når du bygger loops

Det største skiftet er ikke teknisk—det er konseptuelt. Når du prompter en agent, er du fremdeles den som styrer. Du er gasspedalen, navigatoren, kvalitetssikreren. Loops snur det. Du blir arkitekten av systemer som styrer seg selv.

Det betyr ikke at full autonomi er målet. Jeg er fremdeles ved sorteringsporten på alt som betyr noe. Loopsene tar seg av kjedsomheten, overvåkingen, repetisjonen. Jeg tar de viktige skjønnsbeslutningene.

Det andre skiftet er at loops tvinger deg til å være eksplisitt på suksesskriterier. En god loop har klare avslutningsbetingelser, klare beslutningspunkter, klare eskaleringsveier. Du kan ikke bygge en loop uten å definere hva «ferdig» ser ut som. Den disiplinjen siver over i alt annet.

Tredje: loops er komponible. PR-babysitteren fungerer sammen med eksperimentløkka. Planlagte sjekker trigger på-vakt-respons. Du begynner å bygge et bibliotek av atferder som fungerer sammen, istedenfor en haug med engangs-prompts.

Det praktiske startpunktet

Hvis du vil eksperimentere med loops, start med noe du allerede har automatisert dårlig. Du har sannsynligvis en GitHub Action som gjør noe på en plan, eller en Claude Code-session du kjører manuelt om og om igjen, eller en gjennomgangsprosess som involverer å kopiere utdata mellom verktøy.

Velg den mest irriterende. Spør deg selv: hvilken tilstandsendring venter jeg egentlig på? Hvilken kontekst trenger agenten når den endringen skjer? Hvilken beslutning trenger den å ta?

Deretter bygger du loop-en. Den trenger ikke være elegant. Den må fungere, og den må gi deg kontrollen over din egen tid tilbake.

De fulle konfigurasjonene, skillene og CI-flyten bak loopsene jeg kjører ligger i et offentlig repo: camwest/agent-skills. Det er ikke et polert produkt—det er et fungerende system som utvikler seg etter hvert som jeg lærer. Det er poenget. Loops er ikke et mål; de er en praksis.

Diskursen rundt AI-agenter drukner i abstraksjon. Her er den konkrete versjonen: slutt å prompt, start å bygge loops, og se hva som skjer når du lar maskinen ta seg av overvåkingen mens du tar deg av meningen.