Last updated September 18, 2026
4 min read
A fictional agent completes four correction cycles on a subscription pause feature. Each test is green. In cycle two, the implementation quietly changes pause into cancellation because the prompt used both words. Later cycles optimize the wrong behavior with increasing confidence. This is an explicitly fictional composite, not a customer result.
In this article
Iteration needs an external target
The emerging Loop Engineering frame focuses attention on prompts, tools, evaluators, coordination, and improvement cycles. Paqad’s operational definition adds a requirement: the loop must know what versioned intent it is correcting toward and when that target may change.
Addy Osmani on Loop Engineering bounds this claim. An early practitioner frame, not a settled standard.
| Evidence point | Interpretation |
|---|---|
| 1 | Cycle 1: ambiguous prompt |
| 2 | Cycle 2: meaning changes |
| 3 | Cycle 3: tests confirm code |
| 4 | Cycle 4: wrong behavior polished |
Treat the table as a working diagnostic. Replace illustrative labels with repository evidence before making a budget, staffing, or release decision.
Shared assumptions can survive every cycle
A worker can write code from one interpretation and generate tests from the same interpretation. The evaluator then sees internal consistency and approves it. Four green cycles do not reveal that pause became cancellation. Independent criteria and product examples are the missing reference.
Order matters because later checks inherit the intent and scope established earlier. A skipped step does not remove uncertainty. It hands that uncertainty to a reviewer under time pressure.
Versioned change is better than silent drift
Product learning is allowed. When intent changes, issue a new baseline, map affected criteria, and invalidate evidence that no longer applies. This lets the loop adapt without retroactively pretending its earlier checks proved the new requirement.
Risk of coding before testing, July 2026 adds a second evidence boundary. A very recent preprint in a bounded setup; it needs replication.
A procedural fix can be inspected, rehearsed, and improved. A warning without an owner or artifact usually disappears during the next busy sprint.
Stop when the loop loses its anchor
Stop when the specification fingerprint changes, the evaluator cannot map a claim to a criterion, or a product decision remains unresolved. The safest next action is a human decision packet, not another correction turn.
paqad-ai v1.67.0 was the current public release when this article was checked on July 21, 2026. Its repository describes risk routing, specialist roles, structured state, deterministic checks, documentation sync, and local audit records. These are product mechanisms, not independent outcome proof.
Use the AI workflow audit guide to map current practice, compare the bar with production-ready AI code, and use the AI coding consultant guide when the team needs outside ownership.
Decision rule: If the loop cannot identify the exact specification version and independent criterion it is correcting toward, stop it.
Run the specification-anchor audit in a 45-minute working review with the product owner, module owner, and final reviewer. Do not turn it into a score. Read the decision rule aloud: If the loop cannot identify the exact specification version and independent criterion it is correcting toward, stop it. Record disagreements, missing evidence, and the person responsible for the next action. Repeat the review after one real feature so the team can compare whether the artifact reduced ambiguity or only added paperwork.
Frequently Asked Questions
Can the loop improve the specification?
It can propose clarifications and expose contradictions. A named product authority should approve any change that alters intended behavior, then start a new proof attempt against that version.
Why are green tests insufficient?
Tests can encode the same misunderstanding as the implementation. Their value depends on whether assertions challenge approved behavior and would fail when that behavior breaks.
What is a useful stop condition?
Stop on specification mismatch, repeated failure without new evidence, budget exhaustion, sensitive uncertainty, or an unresolved decision. Record the reason and the state required for resume.
What next?
Apply the specification-anchor audit to one current feature. If the repository cannot answer the questions it exposes, install paqad-ai and test a governed workflow with local evidence and explicit human authority.