# What Is Loop Engineering for AI Coding Agents?

Learn loop engineering for AI coding agents through Addy Osmani's workflow context, a budget calculator, stop rules, and a downloadable proof-of-done JSON contract.

## Quick Answer

Loop engineering for AI coding agents means designing the repeatable control loop around the agent, not writing one better prompt. Addy Osmani's loop engineering approach is useful context, but the practical repo loop is Plan → Act → Observe → Verify → Stop, a stricter version of the act → observe → reason cycle: give the agent a bounded goal, inspect tests or diffs, retry only with a changed strategy, and stop on token or cost caps, repeated failure, risky permission changes, or a required human checkpoint.

## Best for

Developers, staff engineers, and platform teams adopting agentic coding workflows in Cursor, Claude Code, Codex, or custom CI agents.

## Use this guide to

Developers want to move from prompting agents task-by-task to designing durable loops that plan, change code, verify results, and stop safely.

## Recommended play

1. Start with one real repository task and a single plan-execute-verify loop before adding schedules or parallel agents.
2. Write the done signal as a command or artifact, not a vibe: passing tests, green build, opened PR, or filed ticket.
3. Cap iterations per item and escalate when the same failure repeats twice with the same root cause.
4. Separate exploration from implementation so read-only passes cannot mutate production paths.
5. Budget tokens and concurrency before running unattended cloud or scheduled loops.

## When to prompt vs when to loop

Use this table to decide whether a task needs a durable loop or a single supervised agent session.

| Area | Prompt once when | Design a loop when | Stop rule to add |
| --- | --- | --- | --- |
| Task shape | The steps are predictable and fit one focused session | The agent must read errors, revise, and re-run verification | Name the verification command and maximum iterations |
| Duration | You can stay at the keyboard for the whole task | Work should continue while you review other items or close the laptop | Set a schedule or queue with a summary artifact per run |
| Risk | Changes are reversible and confined to a local branch | The loop touches shared files, CI, production config, or permissions | Require a human checkpoint before merge or deploy |
| Cost | Token use is small and visible in one sitting | Retries, parallel agents, or long horizons can compound quickly | Set per-run and per-day budgets with automatic stop |
| Team workflow | One engineer needs a quick answer or small patch | A team wants repeatable triage, review, or hygiene across repos | Publish run logs without secrets and name an owner for loop drift |

## Execution steps

1. **Name the goal and done signal** — Write what finished means in observable terms: command output, PR state, ticket link, or report section. Avoid fuzzy goals like 'make it better' that let the loop run without a verdict.
2. **Choose the first pattern** — Default to plan-execute-verify for code changes. Add evaluator-optimizer only when review criteria are explicit. Reserve scheduled wake-up loops for recurring triage after the single-task loop works once.
3. **Wire observation before speed** — Give the agent tests, linters, build commands, diff review, or MCP tools that return ground truth. A loop without observation is just expensive repetition.
4. **Set termination and escalation** — Cap attempts per file or task, stop when the same error repeats, and name who approves production or permission changes. Document what the loop should do when blocked.
5. **Write the loop into repository instructions** — Record the verification command, retry cap, forbidden paths, and human checkpoint in AGENTS.md, CLAUDE.md, Copilot instructions, or the workflow file that launches the loop.
6. **Pilot, measure, then parallelize** — Run the loop on one repo task, record review time, token use, and human interventions actually observed. Add parallel agents or cloud handoff only when single-threaded loops are trustworthy.

## Common pitfalls

- **Fuzzy goals with no done signal**: Translate goals into a verification command, required artifact, or explicit human acceptance step before the first unattended run.
- **Unbounded retries on the same mistake**: Cap iterations per item and change strategy after repeated failures instead of paying for identical attempts.
- **Cron without an agent decision-maker**: Ensure each run observes current state and chooses the next action; a fixed script on a timer is scheduling, not loop engineering.
- **Parallel agents on shared files**: Isolate branches or assign disjoint ownership; merge results deliberately instead of letting agents overwrite each other.

## Implementation checklist

- [ ] Write the goal and done signal in observable terms.
- [ ] Pick plan-execute-verify as the default loop pattern.
- [ ] Attach tests, linters, or builds as loop observation.
- [ ] Cap iterations and name escalation for repeated failures.
- [ ] Add human checkpoints before production or destructive actions.
- [ ] Budget tokens and parallel agents before unattended runs.
- [ ] Log outcomes without secrets and assign a loop owner.

## FAQ

**Q: What is loop engineering for AI coding agents?**

Loop engineering means designing the operating loop around the agent instead of writing one better prompt. For coding agents, the practical loop is Plan → Act → Observe → Verify → Stop: give the agent a bounded goal, inspect tests or diffs, retry only with a changed strategy, and stop on token caps, repeated failure, or a required human checkpoint.

**Q: When should an AI coding agent stop the loop?**

Stop when verification passes, when an iteration cap is reached, when the same failure repeats, when the next action needs wider permissions, when cost crosses the budget, or when the agent can no longer tie its next action to observed evidence. Document stop rules in AGENTS.md, CLAUDE.md, Copilot instructions, or the workflow file that launches the loop.

**Q: How is loop engineering different from prompt engineering?**

Prompt engineering improves a single instruction. Loop engineering designs the repeated system around that instruction: context loading, tool access, action, observation, verification, retry limits, and stop conditions. A strong prompt can still fail inside a weak loop if the agent cannot read test output or does not know when to stop.

**Q: What belongs on an AI coding agent workflow checklist?**

Name the goal and done signal, pick plan-execute-verify as the default pattern, attach tests or linters as observation, cap iterations, add human checkpoints before production or destructive actions, budget tokens before unattended runs, and assign a loop owner who reviews logs without secrets.

**Q: What counts as proof that an AI coding agent loop is done?**

An agent's DONE message is a claim, not proof. Require fresh evidence tied to the exact source revision: passing commands, required artifacts, an independently checked diff, and any named human approval. Record an explicit terminal state such as verified, review-required, blocked, or stopped-by-budget. A passed gate proves the named check under its trust model, not semantic correctness of the whole program.

## Evidence sources

- [Loop Engineering](https://addyosmani.com/blog/loop-engineering/) — Addy Osmani. Practitioner overview of moving from prompting agents to designing autonomous loops.
- [Building effective AI agents](https://www.anthropic.com/research/building-effective-agents) — Anthropic. Official guidance on agent workflows, evaluator-optimizer loops, and when to add complexity.
- [What is loop engineering?](https://kilo.ai/articles/what-is-loop-engineering) — Kilo. Defines the plan-search-modify-verify-repair cycle for AI-assisted software work.
- [Claude Code overview](https://docs.anthropic.com/en/docs/claude-code/overview) — Anthropic. Places scheduling, hooks, subagents, and headless runs in the Claude Code workflow.
- [Proof-or-Stop: Don't Trust the Agent, Trust the Evidence](https://arxiv.org/abs/2607.14890) — arXiv. July 2026 preprint proposing fresh, source-state-bound evidence gates for lifecycle transitions; proof is operational rather than semantic correctness, and the evaluation states material limits.
- [Stop Hand-Holding Your Coding Agent: Engineering the Loops that Replace Step-by-Step Prompting](https://arxiv.org/abs/2607.00038) — arXiv. June 2026 preprint defining bounded loop specifications with verification, stopping rules, memory, and named terminal states, based partly on a descriptive 50-loop corpus.

## Related guides

- [Claude Code subagents workflow examples](/guides/claude-code-subagents-examples) — Subagents are a common way to split explore, implement, and verify inside a loop.
- [Claude Code hooks and MCP setup](/guides/claude-code-hooks-mcp-setup) — Hooks and MCP supply the observation and tool access loops need to act on real systems.
- [agent mode vs chat mode in IDE](/guides/agent-mode-vs-chat-mode-in-ide) — Loops usually run in agent mode; chat mode stays better for one-off questions.
- [local vs cloud AI coding agent](/guides/local-vs-cloud-ai-coding-agent) — Long-running loops often move to cloud agents once local proof is complete.
- [agent governance checklist](/guides/agent-governance-checklist-for-software-teams) — Unattended loops need permissions, logs, and approval rules before team-wide rollout.
- [AI coding agent instruction files](/guides/agents-md-vs-claude-md-cursorrules-copilot-instructions) — Loops inherit verification commands and boundaries from repository instruction adapters.
- [Codex vs Claude Code](/guides/codex-vs-claude-code) — Pick the tool surface first, then design the loop around where your team already works.
- [MCP security checklist](/guides/secure-mcp-servers-ai-coding-agents) — Observation tools inside loops often use MCP; scope permissions before unattended runs.

---
Canonical: https://www.kyenai.com/guides/loop-engineering-ai-coding-agents