Loop Engineering: Write the Loop, Not the Prompt
What a loop is made of, how Claude Code and Codex run one, and the problems a loop makes worse instead of better.
Last updated · By Adel Ahmadyan
Loop engineering is designing the system that prompts your coding agents for you. A loop finds the work, hands each task to an agent in an isolated workspace, checks the result with something other than the agent that produced it, writes down what happened, and decides what runs next. You stop typing every turn. You write the loop, watch what it does, and fix it when it drifts.
The idea took off in June 2026, when Boris Cherny, who leads Claude Code at Anthropic, described his own workflow: "I don't prompt Claude anymore. I have loops running." By then the parts of a loop had started shipping inside the tools themselves, so a loop no longer means a pile of bash only one person understands.
This guide covers where the term came from, the parts every loop needs, the loop primitives Claude Code and Codex ship today, three loops worth copying, and what loops cost. We checked every product claim against first-party documentation on October 9, 2026.
Loop engineering at a glance#
| Part of the loop | Its job | Claude Code | Codex | Agentastic |
|---|---|---|---|---|
| Trigger | Start a run on a schedule or an event | /loop, Desktop scheduled tasks, cloud routines, hooks, GitHub Actions | Automations | Scheduled agents; Linear, Sentry, and Slack intake |
| Workspace | Keep parallel runs from colliding | --worktree, worktree isolation for subagents | A worktree per thread | A worktree, container, SSH host, or cloud VM per task |
| Instructions | Write down what the agent would otherwise guess | CLAUDE.md, skills | AGENTS.md, skills | Each agent reads its own instruction files |
| Checker | Judge "done" separately from the maker | /goal evaluator, subagents, hooks | /goal, subagents | Review passes by Claude, Codex, CodeRabbit, or Greptile |
| Memory | Track what's done and what's next outside the context window | Markdown files, Linear through MCP | Markdown files, connectors | Task memory documents, a Manager Agent's wiki |
| Exit | Decide when to stop | /goal condition, or you stop the /loop | /goal condition or budget | Objectives with verification on Manager Agents |
Where the term came from#
The phrase is a label other people put on something Cherny said. In a June 2, 2026 interview he described running loops that prompt Claude and decide what to do, and summed up his job as writing loops. Peter Steinberger made the same point as advice: stop prompting coding agents and design the loops that prompt them.
Addy Osmani named and unpacked the practice a few days later in Loop Engineering, describing a loop as five building blocks plus a place to remember things, and placing it "one floor above the harness." By July, The Pragmatic Engineer and IBM had published definitions. IBM's version: loops "that iteratively guide AI agents toward completing user-defined goals with minimal human intervention."
Loop engineering sits on top of two older ideas. Context engineering is about what a model sees. Harness engineering is about the environment one agent works in. A loop runs many harnessed agents over time, and a software factory runs many loops.
The anatomy of a loop#
Every loop that holds up in practice has six parts. Most loops that fail are missing the fourth or the fifth.
- A trigger. Time (every 30 minutes, every night at 4:00) or an event (a new issue, a failing CI run, a Sentry alert, a review comment).
- A queue with state. A markdown file, a Linear board, or an issue label that records what was tried, what passed, and what is still open. It lives outside the conversation, because the agent forgets between runs and the repository doesn't.
- A worker in an isolated workspace. One task, one git worktree or container, so two runs can't write over each other.
- A checker that isn't the worker. Tests, linters, a type checker, a second agent with different instructions or a different model, or the separate evaluator behind
/goal. The model that wrote the code is too generous grading its own work. - A stop rule. A condition a machine can verify, plus a budget in turns, tokens, or wall-clock time.
- A report. What changed, what's blocked, and what needs a person, delivered somewhere you will actually look.
Inner loops: /loop and /goal#
Both major coding agents now ship loop primitives that run inside a single session.
Claude Code /loop re-runs a prompt on an interval while the session stays open. /loop 5m check the deploy runs on a fixed schedule; with a prompt and no interval, Claude picks the interval each time; a bare /loop runs a built-in maintenance prompt or your own loop.md. You can pass a skill as the prompt, such as /loop 20m /review-pr 1234. Recurring tasks expire seven days after you create them, and they fire between your turns, never in the middle of one (docs).
Claude Code /goal sets a completion condition. After every turn, a small, fast model checks whether the condition holds; if not, Claude starts another turn instead of handing control back. The goal clears when the condition is met, when the evaluator judges it impossible, or when a turn fails on an error you have to fix. A goal doesn't change your permission mode, so run it in auto mode if you want it unattended (docs).
Codex /goal gives Codex one durable objective that can run for hours. /goal shows the current goal, and /goal pause, /goal resume, and /goal clear control it; if the command is missing, enable features.goals in config.toml. A goal stops on success, pause, clear, interruption, a budget limit, or a blocker that needs you (Codex docs). OpenAI's cookbook suggests the pattern desired end state, verified by specific evidence, while preserving constraints.
/goal all tests in test/auth pass and npm run lint exits 0, without editing any test file
/loop 30m check my open PRs, fix failing CI, answer review comments, and pushWe compare the two /goal commands in detail in Claude Code /goal vs Codex /goal.
Outer loops: schedules, triggers, and managers#
An in-session loop ends when the session does. For loops that must outlive your terminal, move the trigger out of the conversation.
- Claude Code offers Desktop scheduled tasks, which run on your machine at intervals as short as one minute while it's on, and cloud routines on Anthropic-managed infrastructure that run with your machine off, start from a fresh clone, and repeat at most hourly. GitHub Actions works for anything that should run in CI.
- Codex has Automations: you pick a project, a prompt, a cadence, and whether it runs on your local checkout or a background worktree, and runs that find something land in a triage inbox. Codex Cloud keeps tasks running after you close the laptop.
- Agentastic schedules any agent, not just one vendor's. A scheduled agent freezes a launch snapshot (repository, base branch, agent, environment, prompt, attachments, and any linked Linear or Sentry issue) and keeps memory documents outside the repository, so tonight's run knows what last night's already triaged. Manager Agents run for days or weeks, start and steer worker agents through the dev CLI, keep a git-backed wiki, and report on a live dashboard.
A loop can also start workers from a script. This creates a worktree from main and starts Codex in it:
dev agent create --agent codex --name fix-flaky-tests --from main \
--prompt "Find the three flakiest tests, fix them, and list what you changed in FLAKY.md"Three loops worth stealing#
The PR babysitter. Every 30 minutes, check open pull requests for failing CI or unanswered review comments, fix them in that PR's own worktree, and push. The checker is CI itself. The loop stops on a PR when everything is green, or when a comment needs a decision only a person can make, and it says so in the PR.
The nightly bug hunt with memory. A scheduled agent reads its memory document of findings it already triaged, looks for new crash patterns or risky code, opens a draft PR or an issue for each real finding, and appends what it did. Without the memory, it re-reports the same twelve findings every night. Agentastic ships this as a preset ("Find critical bugs", daily at 4:00) that you bind to a repository before it runs.
The goal-driven migration. One worktree, one /goal with an end state a machine can check ("the new client passes the contract tests and the old path still builds"), and a second agent that reviews the diff against your conventions before anyone merges. Run Claude Code and Codex on the same goal in separate worktrees, and keep the better diff.
What loops cost#
Loops spend tokens while nobody watches. Each iteration re-reads context, each verifier is another model call, and parallel workers multiply both. Anthropic warns that Claude Code's dynamic workflows "can consume substantially more tokens" than a normal session (announcement). At the far end, StrongDM's software factory guidance says that if you haven't spent at least $1,000 on tokens per engineer per day, the factory has room to grow (StrongDM).
Most teams should start well below that:
- Give every loop a budget: maximum iterations, maximum tokens, maximum wall-clock time.
- Send triage and summarization to cheaper models, and save frontier models for the change itself.
- Keep stable instructions at the top of prompts so cache reads stay cheap.
- Measure cost per merged change, not cost per run. Agentastic's Usage & Cost view reads Claude Code and Codex logs already on your disk.
When a loop makes things worse#
A loop makes three problems bigger, not smaller.
- Verification is still yours. A loop that runs unattended also makes mistakes unattended. "Done" from a loop is a claim until a test, a check, or a person confirms it.
- Comprehension rots faster. The more code ships without anyone reading it, the wider the gap between what exists and what your team understands. Read what your loops merge, at least by sampling.
- Review is the ceiling. If finished diffs already wait for you, another loop lowers throughput. Fix review first: smaller tasks, machine checks before human ones, and a parallel workflow that survives review.
Don't loop a task you can't check mechanically. Write the check first, then the loop.
Sources#
- Addy Osmani, Loop Engineering (June 7, 2026) and Software Factories, Light and Dark
- IBM, What is loop engineering?; The Pragmatic Engineer, What is "loop engineering?"
- Claude Code docs: scheduled tasks and /loop, /goal, dynamic workflows
- Codex: follow a goal, using goals in Codex
- StrongDM, Software Factories and the Agentic Moment
- Agentastic docs: scheduled agents, Manager Agents, dev CLI, Usage & Cost
- On this site: harness engineering, agent orchestration, what is an AI software factory?
Frequently asked questions#
What is loop engineering?#
Loop engineering is designing the system that prompts your coding agents for you. A loop finds work, hands each task to an agent in an isolated workspace, checks the result with something other than that agent, records what happened, and decides what runs next. Your job moves from typing prompts to writing and tuning loops.
Who coined the term loop engineering?#
The idea comes from Boris Cherny, who leads Claude Code at Anthropic and said in June 2026 that he no longer prompts Claude directly because his loops do it. Commentators including Peter Steinberger and Addy Osmani gave the practice its name, and IBM and The Pragmatic Engineer published definitions in July 2026.
What is the difference between loop engineering and harness engineering?#
Harness engineering shapes the environment one agent runs inside: its instructions, tools, tests, and sandbox. Loop engineering sits a level above it and decides when agents run, on what work, how their output is checked, and when to stop. A good loop depends on a good harness, because the checker can only trust what the harness can verify.
What is the difference between loop engineering and context engineering?#
Context engineering decides what a model sees in a single session: instructions, files, examples, and memory. Loop engineering decides what happens across many sessions over time: triggers, work queues, verification, budgets, and stop conditions. See our comparison of context, harness, and loop engineering for a side-by-side view.
How do you do loop engineering in Claude Code?#
Use /loop to re-run a prompt or skill on an interval, /goal to keep working until a condition you wrote is verified by a separate model, hooks for lifecycle checks, and Desktop scheduled tasks, cloud routines, or GitHub Actions for loops that must outlive your terminal session.
Does Codex support loop engineering?#
Yes. Codex has Automations that run a prompt on a cadence and send findings to a triage inbox, a /goal command with pause, resume, and clear, a worktree per thread, skills, and subagents defined in .codex/agents. The same loop design carries over between Codex and Claude Code.
Is loop engineering expensive?#
It can be. Every iteration re-reads context and every verifier is another model call, so cost grows with cadence and parallelism. Cap iterations and budgets, send triage to cheaper models, and track spend per merged change before you add another loop.
Run your loops across every agent you use
Agentastic is free on macOS. Schedule agents with memory, run Claude Code and Codex side by side in isolated worktrees, and let Manager Agents keep the loop going.
Try Agentastic on macOS