Sluta prompta. Börja bygga loopar.

Förra månaden fick Peter Steinberger en tweet att explodera – åtta miljoner visningar. Budskapet: "Sluta prompta kodningsagenter. Börja designa loopar som promptar agenterna åt dig." Ungefär samtidigt sa Boris Cherny, skaparen bakom Claude Code, något snarlikt i Acquired Unplugged: "Jag promptar inte Claude längre. Jag har loopar igång. De promptar Claude."

Och så gjorde internet vad internet alltid gör: alla diskuterade, ingen förstod vad en loop faktiskt var, och diskursen försvann in i ett dimmigt landskap av abstraktion.

Jag har kört riktiga loopar i några månader nu. Inte för att jag ligger före kurvan – jag var bara så trött på manuell triagering att jag automatiserade den. Det jag upptäckte förvånade mig: loop-tänket är ingen avancerad teknik för AI-nördar. Det är en naturlig evolution som händer när du slutar behandla AI-agenter som sofistikerade copy-pasteverktyg och börjar behandla dem som system som kan övervaka, besluta och agera på dina vägnar.

De tre sorters "loopar" som ingen är överens om

Här blir diskussionen rörig: när folk säger "loop" kan de mena tre helt olika saker, och skillnaderna spelar roll.

Först har vi den autonoma uppgiftsloopen – i grunden "fortsätt tills det är klart". Tänk Geoffrey Huntleys Ralph-skript (while :; do cat PROMPT.md | claude-code; done), eller /goal-kommandot som Codex och Claude Code nu erbjuder native. Det här är "ställ in och glöm"-läge.

Sedan finns den schemalagda eller händelsestyrda loopen – arbete som kör medan du inte sitter vid datorn. Peter Steinbergers egen HEARTEBEAT.md i OpenClaw är det klassiska exemplet: en checklista som agenten omprövar var 30:e minut. Avkommor av detta mönster inkluderar Codex automations och Claude Codes schemalagda rutiner.

Tredje har vi orkestrerings-fan-out – dynamiska arbetsflöden med flera agenter som körs parallellt. Claude Codes map/reduce-liknande operationer hamnar här. Det här ligger närmare aktörsmodellen än något som liknar en enkel loop.

Min tolkning? Steinberger och Cherny beskriver den andra typen, kopplad till den första. De loopar jag kör är schemalagda och händelsestyrda på utsidan, och flera av dem kör experiment-stil inner loops när de väl triggas. Den kombinationen är där den verkliga hävstången finns.

PR-babysittaren: Min inkörsport till loopdesign

Jag hade redan AI-kodgranskning på varje pull request. Claude granskade först, sedan Codex inbyggda granskning, sedan en egen GitHub Action där jag kontrollerade exakt vad modellen såg – full konversationskontext plus patch-differensen.

Min faktiska workflow var absurd: skicka in en PR, vänta på granskningar, kopiera och klistra in kommentarerna i agenten. Ibland klistrade jag in skärmdumpar. Manuellt, repetitivt, självdödande.

En dag frågade jag min agent: "Kan du inte använda gh-klienten själv och kolla granskningsstatus?" Det kunde den. Såklart frågade jag: "Kan du inte bara fortsätta kolla och säga till när det är klart?"

Den enskilda förfrågan förändrade hela min workflow. Agenten övervakar nu granskningsstatus, hämtar ny kontext, analyserar feedback och gör det faktiska arbetet med att adressera den. Loopen slutar när den når ett triage-beslut: acceptera feedback, pusha tillbaka på den, eller eskalera till mig.

Mönstret generaliserar perfekt: bevaka tillståndsförändringar i externa system, vakna när de inträffar, hämta färsk kontext, analysera, agera och triagera. När du ser den här formen börjar du upptäcka den överallt. Codex-teamet levererar sitt eget babysit-pr-skill, och Claude Codes dokumentation nämner nu PR-babysittning som ett av huvud användningsfallen för deras /loop-kommando.

Inner loops: Låt agenten köra sina egna experiment

Det finns ett annat loop-mönster som tog längre tid för mig att uppskatta: experimentloopen. Andrej Karpathys autoresearch-koncept fick mig att tänka på det här – köra många iterationer, mäta resultat, behålla det som fungerar. Jag riktade det mot en långsam Python-sökväg och körde 49 experiment på en timme, och pushade p95-latensen från 339ms ner till 34ms för omkring 24 dollar.

Samma mönster fungerar på svårare problem: felsöka agentbeteende i produktion. När något går fel – en konstig trace i Braintrust, användarfeedback i Slack, eller något jag stöter på själv – snurrar jag upp en worktree, klistrar in trace, och anropar testloopen.

Det som gör den här loopen annorlunda är att den tvingar fram en disciplin som modellens naiva intuition kämpar emot. Utan tillsyn kommer en modell att hårdkoda "aldrig gör X, Y, Z" i systemprompten och överanpassa till just den trace du visade den. Skillets referenser destillerar forskningen om varför det tillvägagångssättet misslyckas, och loop-kontraktet kräver en hypotes och en testmatris.

Jag behöver tre fall: det ursprungliga misslyckandet, ett angränsande positivt som borde ta samma väg, och ett motexempel som borde ta en annan. Tre eller fyra probers körs parallellt mot lokal dev, och rekonstruerar exakt användarkontexten från trace. Varje körning poängsätts på verktygsanrop, latens, input-token-delta och korrekthet. Modellen kan inte fuska genom att memorera – den måste faktiskt förstå.

Vad som faktiskt förändras när du bygger loopar

Den största förskjutningen är inte teknisk – den är konceptuell. När du promptar en agent är du fortfarande den som kör. Du är gasen, navigatorn, kvalitetskontrollanten. Loopar inverterar det. Du blir arkitekten av system som styr sig själva.

Det betyder inte att full autonomi är målet. Jag finns fortfarande vid triage-grinden för allt viktigt. Looparna tar hand om tristessen, övervakningen, repetitionen. Jag tar hand om bedömningarna som faktiskt spelar roll.

Den andra förskjutningen är att loopar tvingar dig att vara explicit om framgångskriterier. En bra loop har tydliga avslutsvillkor, tydliga beslutspunkter, tydliga eskaleringsvägar. Du kan inte bygga en loop utan att definiera vad "klart" betyder. Den disciplinen sipprar över i allt annat.

Tredje: loopar är kompositionsbara. PR-babysittaren fungerar tillsammans med experimentloopen. Schemalagda kontroller triggar on-call-svar. Du börjar bygga ett bibliotek av beteenden som arbetar tillsammans istället för en hög med engångspromptar.

Den praktiska startpunkten

Om du vill experimentera med loopar, börja med något du redan automatiserat dåligt. Du har förmodligen en GitHub Action som gör något på schedule, eller en Claude Code-session du manuellt kör om, eller en granskningsprocess som involverar att kopiera och klistra output mellan verktyg.

Välj den mest irriterande. Fråga dig själv: vilken tillståndsförändring väntar jag egentligen på? Vilken kontext behöver agenten när den förändringen sker? Vilket beslut behöver den fatta?

Bygg sedan loopen. Den behöver inte vara elegant. Den behöver fungera, och den behöver ge dig tillbaka kontrollen över din egen tid.

De fullständiga konfigurationerna, skillsen och CI-arbetsflödet bakom looparna jag kör finns i en publik snapshot-repo: camwest/agent-skills. Det är ingen polerad produkt – det är ett fungerande system som utvecklas när jag lär mig. Det är poängen. Loopar är inte ett mål; de är en praktik.

Diskursen kring AI-agenter drunknar i abstraktion. Här är den konkreta versionen: sluta prompta, börja bygga loopar, och se vad som händer när du låter maskinen ta hand om övervakningen medan du tar hand om betydelsen.