Loop engineering: skaperen av Claude Code skriver ikke prompts lenger, han skriver løkker

«Jeg prompter ikke Claude lenger. Jeg har løkker som prompter Claude og finner ut hva som skal gjøres. Jobben min er å skrive løkker.» — Boris Cherny, skaperen av Claude Code

Uttalelsen falt på Anthropics utviklerkonferanse, og den er en av tre i rask rekkefølge som gjorde loop engineering til månedens trendord. Peter Steinberger, mannen bak OpenClaw, forkynte løkkedesign i et innlegg. Addy Osmani, tidligere i Google, definerte begrepet slik: loop engineering er å erstatte deg selv som den som prompter agenten, og heller designe systemet som gjør det. Gergely Orosz i The Pragmatic Engineer gikk begrepet etter i sømmene og spurte leserne sine hva de faktisk gjør.

Bakgrunn

Ideen er ikke ny. For nøyaktig ett år siden publiserte Geoffrey Huntley «Ralph Wiggum as a software engineer», oppkalt etter Simpsons-figuren som alltid er ivrig etter å hjelpe. I sin reneste form er Ralph en Bash-løkke: while :; do cat PROMPT.md | claude-code ; done. Agenten får en plan med suksesskriterier, tar ett punkt per runde, og starter på nytt med friskt kontekstvindu til målet er nådd.

«Det er skjønnheten i Ralph. Teknikken er deterministisk dårlig i en ikke-deterministisk verden.» — Geoffrey Huntley

Ralph var i praksis en omgåelse av kontekstvinduet. Midt i 2025 lå taket rundt 200 000 tokens, for lite til ambisiøse oppgaver, så løsningen var å dele opp kjøringen og lagre fremdriften komprimert på filsystemet. Huntley var tydelig på at det fortsatt krever en senior utvikler som styrer.

Så bygget verktøyene det inn. Codex fikk /goal i april, Hermes tre dager senere, og Claude Code den 12. mai. Alle gjør det samme: du oppgir en sluttilstand, en liten modell sjekker etter hver runde om den holder, og agenten fortsetter til den gjør det. Claude Code hadde allerede /loop fra mars for å repetere en oppgave med et gitt intervall. Løkken du måtte skrive selv i fjor, er nå én kommando.

Det er her regningen kommer. Av rundt 210 svar Orosz fikk, handler de vanligste bruksområdene om triggere (en agent starter når en feil logges eller en sak opprettes) og cron-jobber (agenten kjører på et fast intervall). Nyttig, men gjenkjennelig. Flere utviklere har prøvd og gitt opp: agentene driver av kurs, mennesket i løkken gir bedre resultater, og på selskaper som betaler API-pris blir «tokenmaxxing» dyrt fort.

Utviklingsdirektør Oded Messer sier det slik: noen ganger føles det som om KI-entusiaster har glemt at automatisering fantes før språkmodellene. Max Kanat-Alexander, distinguished engineer, mener løkken kanskje bare var en midlertidig omgåelse mens verktøyene tok igjen, og at /goal beviser det. For deg som bygger, betyr det at tiden er bedre brukt på kontekstvinduet og på stoppbetingelsene enn på å lære et nytt buzzord: en løkke uten en presis definisjon av «ferdig» er bare en dyr måte å brenne tokens på.