Mechanism: Termination Condition

Part of Mechanisms of Vibe Coding · Core · Read first: Loop.

One-sentence definition

A termination condition is an explicit, checkable rule that tells a loop or agent run to stop — tests green, max iterations, diff limit, or human approval — so repetition ends by design, not by accident or exhaustion.

The problem

You tell the agent to “keep going until it works.” It refactors a file you did not want touched, loops on the same type error, or stops early because it believes it succeeded. Without a stop rule, you babysit forever or trust a completion message you cannot audit.

An unbounded loop is an over-automation trap: energy applied to a poorly defined problem. No termination condition is hope with extra API calls.

Symptoms:

• Agent runs until you interrupt manually
• Same failure on pass 4 and pass 8
• “Done” means the model stopped talking, not that your check passed
• You cannot say which rule ended the run

How it works

Pick stop rules before the first pass. Good conditions are objective (script, counter, file state) or bounded (max N tries, then escalate).

Common patterns:

• Verify — pnpm test -- health.test.ts exits 0
• Lint / typecheck — zero errors in touched files
• Diff budget — stop if more than 3 files change
• Iteration cap — max 5 passes, then stop and report
• Human gate — stop after proposed diff; human merges or rejects

When automating, use two layers: a success condition (tests pass) and a safety cap (max iterations). Success alone fails if the agent never reaches it; cap alone fails if the agent “succeeds” on the wrong metric.

  Loop running
       │
       ▼
  Success condition true? ──yes──► STOP (win)
       │
      no
       ▼
  Safety cap hit? ──yes──► STOP (escalate)
       │
      no
       ▼
  Next pass

Put termination in the same block as goal and constraints — not a footnote.

When to use it

• Every loop — manual or automated
• Long agent runs, background jobs, scheduled automations
• Before “run until done” in any tool
• Team workflows where others must know when to intervene

When not to use it

• Single-shot edit with immediate human review — review is the stop
• Production-only checks with no local proxy — use human gate or local substitute
• Model self-assessment (“I believe this is correct”) — that is completion bias, not termination

Failure modes

Subjective stop — “When it looks clean.” Fix: Command, test name, or diff rule.

Only a cap — Five passes, still failing, no escalation. Fix: Cap plus “list hypotheses and stop.”

Wrong success signal — Lint green, user bug remains. Fix: Tie to the goal’s verify line.

No cap on automation — Overnight quota burn. Fix: Max iterations + optional file limits.

Silent stop — No log of which condition fired. Fix: Log stopped: test_pass or stopped: max_iterations.

Minimal example

Context: Loop on health.test.ts with bounded retry.

Steps:

1. Extend the loop block:

   Termination (success): pnpm test -- health.test.ts exits 0
   Termination (safety): max 5 passes
   On safety cap: stop editing; output last test log + one suggested next step

1. If pass 3 goes green, stop — no “cleanup” in the same loop.

1. If pass 5 still fails, read the safety report — no pass 6.

Done when: You can name the ending condition: success or safety cap.

Tool instances (optional deep-dive)

Portable idea above; tool-specific. Date: June 2026.

Cursor

• Termination in the first message of agent or loop sessions.
• Loop commands: Stop on shell exit code 0 from your test command + max iterations when exposed.
• Rules: “After max passes, summarize blockers; do not keep editing.”
• Hooks: Test hook exit code enforces termination machine-side.

Other tools

CI timeout-minutes, Ralph wrappers (while ! npm test; do ...), n8n stop nodes.

Related mechanisms

• Loop — repetition that needs a stop rule
• Verify loop — often supplies the success signal; read next in Core
• Over-automation trap — loops without clear stops

Try it yourself

Exercise: Add two lines to your loop block: success command and safety cap. Run once; record stopped because: [test_pass | max_passes | human_stop].

Done when: Your note is explicit — not “it seemed done.”