Loop Engineering for AI Coding Agents

Loop engineering turns an AI coding agent from a chat partner into a repeatable worker with a trigger, goal, execution mode, verifier, review gate, state log, and stop rule.

Most weak agent workflows fail in the same place: the first prompt sounds clear, but the second and third pass have no control system. The agent edits before reproducing, weakens the test to make the suite green, opens a bigger scope than the ticket asked for, or keeps polishing because nobody defined the stop condition.

The useful unit is not the prompt. The useful unit is the loop.

Define the loop before you run the agent

A loop is a repeatable workflow that starts from a clear trigger and goal, performs work through one or more execution modes, verifies the result, and repeats or refactors until the result is accepted.

That sounds simple, but each word does work.

The verifier matters most. If the loop can only say "the agent thinks it is done," the loop is not useful yet.

Choose the trigger by the kind of work

Bad loops often start from the wrong trigger. A goal-driven loop and a scheduled loop are different tools.

Manual loops are best for product slices, refactors, and bugs where the human still owns priority. Scheduled loops are best for sweeps: docs drift, aging pull requests, stale incidents, dependency reviews, release baselines. Action-based loops are best when the signal is already in the system: failed CI, a Sentry spike, a ticket status change, a PR review, or a deploy event.

The trigger should not decide the whole task. It should open the loop with enough context to run the next safe step.

Separate verifiable gates from LLM judgment

There are two kinds of finish lines.

The first is deterministic: test coverage reaches 100%, a benchmark is below 50 ms, CI is green, a migration runs, a log query shows the error family has a regression test. These are strong loop targets because the agent cannot argue with the check.

The second is judgment-based: "docs are complete," "architecture is simpler," "the UI matches the design," "the release brief is useful." These can still be looped, but the judge must be constrained. Give the large language model (LLM) a rubric, examples, out-of-scope rules, and a maximum number of passes. When the work affects product taste, architecture, security, pricing, customer data, or deployment risk, keep a human gate.

The behavior should be explicit:

1. Start from the trigger.
2. Compare the current state to the goal.
3. Execute the smallest useful pass.
4. Verify the output.
5. Send the result through the judge.
6. Stop and report evidence if the judge accepts the result.
7. Refactor the smallest failing part and run the loop again if the judge rejects the result.
8. Stop with evidence, attempts, and the next decision needed if the loop is blocked.

This is why "refactor until satisfied" is weak by itself. It can work only when "satisfied" is backed by rules: public API unchanged, tests pass, no new dependency, no file outside the target module, review finds no P0/P1 issue, max three passes.

Use nested loops to build a product from scratch

Do not ask an agent to "build the whole product." That gives the loop no stable goal. Use an outer product loop to choose the next slice, then inner loops to build and verify that slice.

The first slice must be small enough to prove:

A private-beta user can request an invite, see the saved pending state,
and see a clear duplicate-request error.

Now the loops have real jobs.

The product loop is not one giant run. It is a queue of small loops. Each loop produces evidence that the next loop can read.

/goal Ship the private-beta invite request slice.
 
Trigger:
- Manual product request approved for this sprint.
 
Goal:
- A visitor can submit an invite request.
- Duplicate requests show a clear existing-request state.
- The route has a regression test.
 
Read first:
- AGENTS.md
- docs/product/private-beta.md
- app/invite/**
- lib/db/**
- current diff
 
Scope:
- Allowed: invite page, invite API, invite tests, seed fixture.
- Forbidden: auth rewrite, billing, email deliverability, admin dashboard.
 
Verifier:
- npm test
- npm run lint
- npm run build
- browser check for happy path and duplicate-request state
 
State:
- Update docs/agent-runs/private-beta-invite-loop.md after each pass.
 
Stop when:
- The verifier passes.
- The browser check proves both states.
- A fresh review finds no P0/P1 issue.
 
Escalate when:
- The task requires production email, account roles, payment logic, or schema deletion.
- The same failure repeats twice.

Run backlog loops like a repair shop

Backlog loops are valuable because they turn stale issues into one of four outcomes: reproduced and fixed, reproduced and assigned, duplicate, or blocked with evidence.

Do not let the agent browse a backlog and "clean it up." Give it a batch rule and a closure rule.

Goal:
Reduce the P0/P1 backlog by handling the top reproducible issues.
 
Trigger:
- Scheduled daily sweep, or manual run before planning.
 
Batch rule:
- Sort by severity, customer impact, age, linked production signal, and owner.
- Pick one issue at a time.
 
Execution:
1. Read the issue, linked PRs, logs, and related files.
2. Reproduce with a failing test, script, log query, or explicit non-repro note.
3. Patch only the root cause.
4. Add or update the regression check.
5. Run the verifier.
6. Update the issue with changed files, commands, output, remaining risk, and owner.
 
Verifier:
- Original reproduction fails before the fix.
- Regression check passes after the fix.
- Relevant test/lint/build command passes.
 
Do not:
- Close from a summary alone.
- Delete or weaken tests.
- Silence logs.
- Broaden catch blocks.
- Combine unrelated refactors with the patch.
 
Stop when:
- The batch is handled, or the next issue requires missing credentials, unclear product decision, or high-risk owner approval.

The repair loop should leave a reviewer with less work, not more prose. The issue update should name the cause, the evidence, and what still needs a human.

Start production-error loops read-only

Production loops should not begin by editing code. They should begin by finding the error family and proving that it is actionable.

The safe shape is:

Read-only pass:
- Query the top error families by count, severity, customer impact, and first-seen time.
- Link each family to deploy history, likely owner, code path, and reproduction path.
- Pick one actionable family.
- Stop if the signal points to infrastructure, missing credentials, third-party outage, or unclear ownership.
 
Write pass:
- Patch only the root cause for the selected family.
- Add a regression check.
- Run the verifier.
- Prepare deploy note with risk, rollback condition, and post-deploy query.

A production-error loop should never reward hiding the signal. "No more errors" is not enough if the fix was to suppress logging or catch everything.

Use this gate:

Use manager loops to remove status fog

Engineering managers should use loops for discovery and decision support, not only code changes. The best manager loop does not "summarize status." It finds missing proof.

The manager loop should usually start read-only. It can open issues, draft Slack messages, or prepare PRs only if your permissions and review policy allow that.

The output format should be boring:

## Aging PR loop result
 
PR: #812
Owner: Maya
Age: 31 hours
Current blocker: required e2e check is failing
Evidence: CI job app-e2e failed at checkout duplicate-request path
Next action: assign repair loop to checkout owner
Escalate if: no movement by 15:00

That is useful because it changes the meeting. You stop asking "what is blocked?" and start deciding "who owns the next observable action?"

Pick the smallest orchestration layer that controls the risk

Loops get expensive when the control system is bigger than the task.

The rule is simple: add a layer only when it controls a real failure mode. Worktrees control file collisions. Hooks control forgotten checks. Subagents control context pollution and self-review. Schedules control recurring discovery. A goal controls repeated execution against one finish line.

Build your own loop

Use the guide workbench instead of duplicating it here:

• Open the Codex loop workbench for /goal, automations, AGENTS.md, skills, sandbox profiles, subagents, review gates, and unattended sweeps.
• Open the Claude Code loop workbench for /goal, /loop, routines, hooks, subagents, state files, worktrees, and production gates.

Watch for these failure modes

The loop should make the agent more useful, not less accountable.

Read the implementation guides

This post gives the operating model. The implementation details live in the two AI Hub guides:

• Claude Code Loop Engineering covers /goal, /loop, routines, hooks, subagents, state files, worktrees, and production gates.
• Codex Loop Engineering covers /goal, automations, codex exec, AGENTS.md, skills, sandbox profiles, subagents, review gates, and unattended sweeps.