TL;DR
Stop rules end or pause an AI coding loop when budgets expire, evidence contradicts the target, progress stalls, risk changes, or a named human decision is required. Inspect budget boundary, failed evidence, non-convergence signal, and human escalation on one recent change. If another qualified reviewer cannot reach the same decision from the stored evidence, pause and repair the earliest missing handoff before increasing automation or output. The goal is dependable delivery that the team can explain, challenge, and maintain.
In this article
Last updated October 14, 2026
7 min read
Stop rules end or pause an AI coding loop when budgets expire, evidence contradicts the target, progress stalls, risk changes, or a named human decision is required. This question matters because faster generation moves work into decisions that still require evidence and ownership.
Persistent agents are appealing because they do not give up after one failed test.
They inspect the failure, change the code, and run again.
Persistence becomes a problem when the loop has no honest reason to stop.
“Continue until it works” leaves three questions unanswered:
What counts as working? How much effort is justified? Which decisions is the loop authorised to make?
Define six stop categories
Success stop
The approved behaviour is implemented, required evidence passes, documentation is current, open findings are resolved or accepted by the right owner, and the final verdict is available.
Success should reference a specification version and evidence requirements. “Agent reports done” is not a success condition.
Failure stop
A required deterministic check fails beyond the allowed retry policy, an artifact is invalid, or a mandatory condition cannot be met.
The workflow should preserve the failure, last valid state, and recovery options.
Uncertainty stop
Evidence is missing, contradictory, or outside the evaluator’s ability.
Examples:
Stop categories
- code and documentation disagree;
- a dependency exists but provenance is unclear;
- the test passes but requirement coverage is uncertain;
- two specialist reviews conflict.
Return inconclusive and name the evidence or decision needed.
Decision stop
The next action changes:
- product behaviour;
- architecture responsibility;
- security or privacy posture;
- access or money;
- public contracts;
- material scope or cost.
Pause and route a decision packet to the named owner.
Budget stop
Time, tokens, compute, retries, diff size, or review volume reaches the approved limit.
Budget exhaustion is not automatically failure. It is a handoff state with evidence of what was tried and learned.
Safety stop
The loop reaches an action or permission boundary it is not authorised to cross.
Examples include production access, destructive data changes, external publication, secret handling, or another high-consequence action outside scope.
Stop without trying a workaround.
Make retry policies change something
Repeating the same command with the same conditions is not recovery.
Each retry should have:
- diagnosed failure;
- changed strategy or input;
- attempt count;
- reason another attempt is justified;
- rollback point;
- next stop if it fails again.
This prevents the loop from burning budget while producing a longer transcript.
Use structured terminal states
Useful final states include:
- safe to merge;
- needs attention;
- inconclusive;
- decision required;
- re-plan required;
- budget exhausted;
- blocked by safety boundary.
Each state should map to a next owner and action.
Keep stop rules outside the agent’s discretion
Deterministic gates, workflow state, permissions, and human authority should enforce important stops. A model should not be able to redefine the budget or approve a boundary crossing through a persuasive explanation.
Test the stops
Run controlled cases:
- a missing test result;
- a repeated flaky failure;
- an unapproved scope expansion;
- a specification conflict;
- an exhausted token budget;
- a human rejection;
- a forbidden external action.
Confirm that the loop reaches the intended state and cannot proceed without the required event.
A failure walkthrough makes the hidden cost visible
Imagine the change reaches review with a confident summary, plausible code, and a green check. The reviewer then discovers that budget boundary was never agreed. That discovery changes the value of every later artefact because the team may have verified the wrong outcome.
Work backward from that point. Ask who should have established budget boundary, where failed evidence should have been visible, how non-convergence signal would have exposed the mismatch, and who had authority over human escalation. This sequence shows whether the failure came from the model, the task, the repository context, or the delivery system around them.
The repair must move the discovery earlier. Put an objective check in automation when the condition is deterministic. Use a named human decision when consequences or trade-offs require judgment. Preserve the result beside the change so the next reviewer does not repeat the investigation.
The walkthrough is complete only when the team can state a stop condition. If the necessary evidence is absent or contradictory, the workflow pauses instead of asking the agent to make the uncertainty disappear through another attempt.
A usable review record for this decision should identify the accepted request, the exact revision being judged, the source of budget boundary, and the owner responsible for human escalation. It should also preserve disagreement: a reviewer who finds weak failed evidence or missing non-convergence signal needs a visible way to return the work as incomplete. That record gives the next developer a reliable starting point and prevents a confident summary from becoming the only explanation of what happened.
The first rollout should stay narrow. Choose a change with a known owner and a result the team can observe, then compare the planned evidence with what the workflow actually produces. Keep the exception path explicit. If the evidence is incomplete, record that outcome honestly instead of converting uncertainty into a passing verdict.
Review the record after the change is accepted. Ask whether it still explains why the team trusted budget boundary, how failed evidence affected the decision, which result established non-convergence signal, and who remained accountable for human escalation. If those answers disappear after the meeting or agent session ends, the workflow has stored an outcome without preserving the reasoning needed to maintain it. Correct that gap before using the same approach on work with a wider impact.
Use the result to change one operating rule, not to produce another advisory document. The rule might require a stored artefact, a deterministic check, a specialist review, or a decision pause. Give it an owner and test it on the next comparable change. If the same ambiguity returns, the correction did not reach the point where work actually moves.
Stop rules should be evaluated by the harness rather than left as prose the worker may reinterpret. Count attempts and budget deterministically, inspect required evidence states, and pause on changed scope or authority. When a stop fires, produce a receipt explaining the trigger and preserve the state needed for review. The worker can recommend a recovery, but it cannot clear the rule that stopped it. This separation prevents an increasingly invested agent from describing another attempt as progress when the agreed evidence says the loop should pause.
For a related view of the delivery system, read how AI-generated code changes review and how a reviewable AI feature plan works.
Sources used
- IBM, Loop Engineering, practitioner explanation including stopping criteria.
- Addy Osmani, Loop Engineering.
If your team is generating work faster than it can verify and own it, explore the AI Delivery Programme.
Frequently Asked Questions
What stop rules should an autonomous AI coding loop have?
Stop rules end or pause an AI coding loop when budgets expire, evidence contradicts the target, progress stalls, risk changes, or a named human decision is required. Judge the practice on one real change and keep the supporting evidence beside the work.
How do stop rules prevent confident but unproductive rework?
Track budget boundary, failed evidence, non-convergence signal, and human escalation together. A single speed or output number cannot show whether the team can safely accept and maintain the result.
Which signals show that an AI coding loop is no longer making progress?
Repeated equivalent failures, cycling patches, unchanged evidence, expanding scope, and rising cost without a better verdict indicate non-convergence.
Should a loop stop after a fixed number of attempts?
An attempt limit is a useful budget boundary, but combine it with evidence and risk signals. Some failures require immediate escalation before the limit.
What state must be saved when a stop rule fires?
Preserve the target, current revision, attempts, evidence, unresolved findings, reason for stopping, and permitted resume conditions so recovery does not restart blindly.
Who may resume a loop stopped for a human decision?
Only the named decision owner or an authorised workflow action should resume it, with the decision and any changed target recorded.
