In this article
Last updated September 18, 2026
4 min read
The visible part of Loop Engineering, as practitioners such as Addy Osmani and IBM describe it, is repetition.
An agent receives work, makes a change, runs a check, reads the result, and continues until a stop condition is met.
The invisible part is the target.
A faster loop with a weak specification does not become clearer through repetition. It becomes more efficient at
producing and defending one interpretation.
The loop needs an answer key outside the code
Consider a requirement such as “improve team permissions.”
The phrase leaves open:
- which roles exist;
- who can change them;
- whether a person can change their own access;
- how inherited permissions behave;
- what must be audited;
- what happens to active sessions;
- which current behaviour is intentionally preserved.
An agent loop can still run. It can inspect code, select an approach, add tests, fix failures, and stop green.
The green result proves consistency with the chosen interpretation. It does not prove that the interpretation belongs
to the product owner.
Build the specification core
A useful loop specification has six parts.
1. Owned goal
Name the outcome and the person or role accountable for it.
2. Observable behaviour
Describe what a user or system can observe. Avoid implementation-only acceptance criteria.
3. Invariants
Record truths that must survive every path. Ask a named human to confirm product, security, data, and architecture
invariants.
4. Boundaries
State what is inside scope, outside scope, and sensitive enough to trigger a stronger lane or human decision.
5. Proof methods
Connect each acceptance criterion to deterministic checks, measurements, specialist judgement, or human decisions.
6. Change control
Freeze the approved version for higher-risk work. When implementation reveals a missing decision, version the
specification instead of silently moving the target.
Why loop iteration can hide specification drift
Each correction turn changes the working context.
The agent sees its previous code, test failures, review comments, and new patches. Unless the workflow keeps returning
to the approved specification, the most recent artifact can become the practical source of truth.
This creates a subtle loop:
- Ambiguous requirement produces one implementation.
- A test is written around that implementation.
- Review finds a mismatch.
- The agent changes code and test together.
- The final summary reports internal consistency.
The loop improved the artifacts without proving the original promise.
Keep the specification visible at every evaluation step. Review any change to the target as a separate decision.
Give the evaluator independent inputs
The evaluator should receive:
- the approved specification version;
- acceptance criteria and invariants;
- the diff and changed scope;
- deterministic check results;
- specialist findings;
- recorded human decisions.
The maker’s summary can help navigation. It should not define success.
The evaluator must be able to return:
- pass;
- fail;
- inconclusive;
- decision required;
- specification change required.
These states stop the loop from converting uncertainty into another patch.
Use risk lanes for specification depth
Not every change needs a long specification.
A small, reversible text change can use a concise goal and direct proof.
Everyday feature work needs observable acceptance criteria, scope, and evidence.
Sensitive or wide changes need explicit invariants, a frozen specification, specialist review, and owned decisions.
The point is proportional control, not maximum documentation.
Where paqad-ai fits
paqad-ai is designed to put planning and specification before development, with stronger artifacts for higher-risk
work. It can carry acceptance criteria, proof methods, invariants, scope, decisions, and check results through the
workflow.
That is the core a repeatable agent loop needs.
Loop Engineering does not make specifications obsolete because the agent can adapt.
Adaptation makes a stable, owned target more important. Without it, the loop can adapt away from the actual product
promise and call the result success.
Build the core first.
Then let the loop make it faster.
Install paqad-ai: https://github.com/Eliyce/paqad-ai/
Source notes
- Addy Osmani, Loop Engineering, practitioner framing.
- IBM, Loop Engineering, practitioner explanation and stopping
criteria. - On the risk of coding before testing, July 2026 preprint.
- Product mechanism: first-party details from the current Eliyce/paqad-ai repository.