Jag har börjat behandla AI-kodningsagenter mindre som chattfönster och mer som arbetare med kontrakt. Skillnaden ligger inte i modellen. Skillnaden är om agenten vet vad den ska fortsätta göra, hur den ska bevisa framsteg och när den ska stoppa.
Det är här /loop och /goal blir viktiga.
Claude Code exponerar nu båda idéerna direkt: /goal för ett slutförandevillkor, och /loop för upprepade uppmaningar medan en session hålls öppen. OpenAI Codex har /goal som ett dokumenterat kommando, och OpenAI dokumenterar också eval-drivna förbättringsloopar som ett arbetsflöde. Den viktiga detaljen: Jag skulle inte beskriva OpenAI Codex som att ha samma officiella /loop snedstreckscommando om det inte dyker upp i din installerade kommandolista. I de aktuella dokument jag kontrollerade är /goal officiellt; "loop" är mönstret.
Den distinktionen är viktig eftersom dessa verktyg ser likadana ut utifrån, men jag använder dem för olika jobb.
Snabbt svar
Använd /goal när agenten ska sträva efter ett bestående resultat tills ett tydligt villkor är uppfyllt.
Använd /loop när agenten ska upprepa en uppmaning med ett visst intervall eller i eget tempo medan sessionen förblir öppen.
Använd en eval-driven loop när utdata kan poängsättas och förbättras upprepade gånger: kodkvalitet, visuell kvalitet, prestanda, SEO, migreringar, tester eller vilken uppgift som helst där varje genomgång kan mätas.
Den praktiska regeln är enkel: ett mål behöver en mållinje; en loop behöver en rytm; båda behöver verifiering.
Vad Claude Code /goal gör
Claudes kommandoreferens beskriver /goal [condition|clear] som ett sätt att ställa in ett villkor så att Claude fortsätter arbeta över flera omgångar tills det villkoret är uppfyllt. Hook-dokumenten lägger till en användbar implementeringsdetalj: /goal fungerar som en inbyggd genväg för ett sessionsomfattande stoppvillkor.
På ren svenska säger /goal till Claude:
Det är kraftfullt, men bara om villkoret är konkret.
Svagt:
text /goal Gör appen bättre
Användbart:
text /goal Fixa checkout-buggen, behåll allt befintligt betalningsbeteende intakt, och stoppa endast när pnpm test, pnpm build och Playwright-checkoutvägen alla klarar sig.
Den andra versionen ger Claude ett mål, gränser och bevis. Den kan besluta om vägen, men inte omdefiniera framgång mitt i processen.
Jag använder /goal för arbete som:
I det ögonblick en uppgift har flera orelaterade resultat använder jag inte ett stort mål. Jag delar upp det. Ett mål per resultat är renare och lätta att lita på.
Vad Claude Code /loop gör
Claudes kommandoreferens listar /loop [interval] [prompt] som en paketerad färdighet. Den kör en uppmaning upprepade gånger medan sessionen är öppen. Du kan ge den ett intervall, låta Claude själv bestämma tempot, eller utelämna uppmaningen och låta den använda en konfigurerad underhållsuppmaning där det är tillgängligt.
Det gör att /loop känns mer operativt än /goal.
Exempel:
text /loop 5m kontrollera om Vercel-förhandsgranskningsdistributionen är klar, verifiera sedan /blog och /api/health
text /loop ta nästa okontrollerade objekt i PRODUCTION_READINESS.md, fixa det, kör relevanta testet, uppdatera sedan checklistan
text /loop var 10:e minut kontrollera CI, sammanfatta misslyckanden, och sluta eskalera först efter att den senaste körningen är grön
Det bästa användningsfallet är upprepad kontroll eller upprepade små arbetsenheter. I min hybrid AI-kodgranskningsloop→ var det användbara mönstret inte "skriv för alltid". Det var: ta ett checklistobjekt, implementera det, be en annan modell granska, kör bygget, bocka av rutan, upprepa.
Det är vad som gör /loop farligt om du skriver en lat uppmaning. Om uppmaningen inte säger vad som ska verifieras kan agenten fortsätta göra trovärdigt arbete som ingen borde lita på.
Vad OpenAI Codex /goal gör
OpenAI dokumenterar /goal för Codex i både appen och CLI. Codex-guiden beskriver det som ett bestående mål för långkörande arbete, särskilt när uppgiften har ett tydligt framgångsvillkor och en valideringsloop.
Codex CLI-kommandoreferensen listar /goal som kommandot för att ställa in, pausa, återuppta, visa eller rensa ett uppgiftsmål. App-dokumenten säger samma sak i produkttermer: ett mål är bestående, synligt och kan pausas eller återupptas.
Ett bra Codex-mål ser nästan identiskt ut som ett bra Claude-mål:
text /goal Slutför Next.js 16-migreringen utan att ändra publika rutter. Stoppa endast när pnpm build klarar sig, hemsidan laddas, /blog laddas och de ändrade rutterna returnerar 200.
För Codex gillar jag mål som namnger:
OpenAIs egna riktlinjer för svåra problem ligger nära hur jag redan arbetar: ge Codex ett utvärderingssystem, gör fokuserade förbättringar, kör poängen igen, inspektera artefakter och fortsätt tills poängen är tillräckligt bra.
Det är kärnan i agentiskt arbete. Inte autonomi för autonomins skull. Autonomi kopplad till mätning.
Har OpenAI /loop?
Här kan folk bli slarviga med formuleringarna.
Claude Code har ett dokumenterat /loop-kommando. OpenAI Codex har dokumenterade loop-liknande arbetsflöden: eval-loopar, reparationsloopar, målläge med validering, hooks och automatiseringar. Men i den aktuella Codex snedstreckscommandoreferensen jag kontrollerade hittade jag /goal, /plan, /review, /status, /mcp och många andra, men inte ett officiellt /loop-kommando motsvarande Claudes.
Så min formulering är:
Det är inte en svaghet. Det ändrar bara hur jag ställer in det. I Codex uttrycker jag vanligtvis loopen inuti målet eller uppmaningen:
text /goal Förbättra denna komponent tills den visuella regressionsscoren är över 95%. Gör en fokuserad ändring i taget, kör skärmdumpjämförelsen efter varje ändring, för en poänglogg och stoppa när målet håller två gånger i rad.
Det ger Codex samma operativa rytm utan att låtsas att det finns ett separat /loop snedstreckscommando.
Min praktiska setup
För seriöst arbete använder jag ett femskiktsmönster.
1. Ett skrivet mål
Jag börjar med en kort plan eller checklista. Det kan vara `PLAN.md`, `PRODUCTION_READINESS.md`, ett GitHub-issue eller en vanlig uppmaning. Formatet är mindre viktigt än kontrollerbarheten.
En svag uppgift säger "förbättra artikelsystemet".
En stark uppgift säger "förhindra publicering när externa URL:er returnerar 404, mjuk 404, felaktig content-type eller omdirigerar till fel mål; tillåt sparande av utkast; bevisa med build och ett fokuserat valideringsfall".
Det är den typ av instruktion som en agent kan fortsätta agera på.
2. En ägarmodell
Välj vem som driver. Claude kan vara implementeraren. Codex kan vara implementeraren. Låt inte båda redigera samma filer samtidigt om du inte har worktrees eller en strikt överlämning. Autonomi utan ägarskap blir teater kring merge-konflikter.
3. En andra åsikt
För arbete med högre risk gillar jag fortfarande modell-till-modell-granskning. Jag har skrivit om min AI-peer-review-brygga→ eftersom den fångar andra failure modes än att en ensam modell kontrollerar sig själv.
Granskaren kan vara read-only. Den behöver inte skrivåtkomst för att vara användbar. Den behöver diffen, målet, de riskfyllda filerna och behörighet att säga "detta är fel".
4. En hård validerare
Tester slår självförtroende. Byggen slår sammanfattningar. Skärmdumpar från webbläsare slår "det borde renderas". Loggar slår känslor.
För webbarbete betyder det vanligtvis:
bash pnpm build pnpm lint pnpm test
plus rutt-kontroller, skärmdumpar eller Playwright-flöden när uppgiften är användarvänd.
För innehållsflöden är min preferens URL-QA före publicering: inte bara "returnerade länken 200", utan "nådde den sidan som artikeln påstod?". Det är samma princip. Valideraren bör verifiera det som läsaren faktiskt upplever.
5. En stoppregel
Detta är delen folk hoppar över.
En loop utan stoppregel blir dyr. Ett mål utan stoppregel blir vagt. En stoppregel ska vara tråkig och bokstavlig:
Den sista raden är viktig. Bra agenter döljer inte osäkerhet. De lyfter fram den.
När jag använder varje en
| Situation | Bästa verktyg | Varför |
|---|---|---|
| --- | ---: | --- |
| En stor uppgift med en tydlig definition av klart | /goal | Agenten kan fortsätta röra sig mot ett bestående slutläge |
| Kontrollera distributionsstatus var few minutes | Claude /loop | Samma kontroll behöver köras upprepade gånger |
| Förbättra en genererad artefakt mot en poäng | Eval loop | Poängen talar om för agenten om den senaste genomgången förbättrade något |
| Rensa en checklista objekt för objekt | /loop eller /goal | Använd /loop för upprepade objekt, /goal för det slutliga resultatet |
| Forskning med osäker riktning | Normal uppmaning eller plan-läge | Starta inte autonomi innan målet är tydligt |
| Känslig produktionsåtgärd | Godkännandegate för människa | Agenter kan förbereda åtgärden, men bör inte tyst utföra den |
Kopiera-klistra uppmaningar
Claude Code /goal
text /goal Slutför denna buggfix utan att ändra orelaterat beteende. Läs först AGENTS.md och de relevanta rutt-/komponentfilerna. Gör små commits endast i logiken, kör pnpm build och den fokuserade regressionsvägen, och stoppa endast när den ursprungliga buggen inte längre reproduceras och all verifiering klarar sig.
Claude Code /loop
text /loop ta nästa okontrollerade objekt i TODO.md, inspektera de verkliga filerna först, gör en fokuserad fix, kör det relevanta valideringskommandot, uppdatera kryssrutan först efter verifiering, och rapportera alla blockeringar istället för att hoppa över dem
OpenAI Codex /goal
text /goal Slutför migreringen som beskrivs i PLAN.md. Bevara publikt beteende, håll orelaterade filer oförändrade, kör de listade valideringskommandona efter varje milstolpe, för en kort framstegslogg och stoppa endast när varje milstolpe är klar och det slutliga bygget klarar sig.
Codex eval-driven loop uppmaning
text Jag vill ha detta som en eval-driven förbättringsloop. Hitta eller skapa kommandot som poängsätter utdata. Gör en fokuserad förbättring i taget, kör poängen igen efter varje ändring, inspektera alla genererade artefakter direkt, logga poängförändringar och fortsätt iterera tills målpouängen nåtts två gånger i rad. Om poängen slutar förbättras, förklara flaskhalsen och stoppa.
Vanliga misstag
Det första misstaget är att använda /goal som en motivationsmening. "Gör detta produktionsredo" är inte ett mål. Det är ett humör.
Det andra misstaget är att använda /loop utan en validerare. Om varje iteration slutar med ett okontrollerat påstående är loopen bara upprepning.
Det tredje misstaget är att bunta ihop orelaterat arbete. "Fixa auth, redesigna dashboarden, uppdatera prissättningen och städa SEO" borde vara fyra uppgifter, inte en heroisk autonom körning.
Det fjärde misstaget är att ge agenten skrivåtkomst innan den förstår repo-reglerna. I mina egna projekt vill jag att agenter ska läsa `AGENTS.md`, respektera distributionsregler, undvika hemligheter och verifiera innan de hävdar framgång. Kontrollskiktet runt modellen är lika viktigt som modellen. Det är därför jag fortsätter komma tillbaka till MCP-utvecklararbetsflöden→: verktyg, behörigheter, bevis och replaybara åtgärder är vad som förvandlar en smart chatt till ett operativt system.
Den verkliga poängen
Det intressanta med /loop och /goal är inte syntaxen för snedstreckscommandon. Det intressanta är förskjutningen i ansvar.
En normal uppmaning säger: svara mig.
Ett mål säger: avsluta detta, och vet vad avslutat betyder.
En loop säger: fortsätt kontrollera eller förbättra tills villkoret ändras.
Så vill jag att AI-kodningsagenter ska arbeta. Inte som magi. Inte som oövervakat kaos. Som arbetare med ett kontrakt, en validerare och en ren stoppregel.
Om du använder Claude Code är /loop det snabbaste sättet att förvandla en upprepad operativ kontroll till något agenten kan hantera medan du fortsätter arbeta. /goal är det bättre verktyget när arbetet har ett bestående slutläge.
Om du använder OpenAI Codex ger /goal dig det bestående målet, och loopen hör hemma i valideringsdesignen: tester, evals, artefakter, hooks, framstegsloggar och ett stoppvillkor som agenten inte tyst kan omdefiniera.
Det är mönstret jag litar på: inte "låt AI:n köra", utan "låt AI:n köra inuti ett system som kan säga nej till den".