This article defines bounded agent repair, first-pass acceptance and the evidence required to measure repeated review demand. The policy is clear, but current event records and metric definitions are not sufficient to verify its effects.
Agent-led repair can avoid a visible hand-off. It also asks the agent that misunderstood a requirement to reinterpret its work and the reviewer’s objection.
Correction may then extend beyond the original change, alter unaffected code or introduce further assumptions. Each cycle requires reviewers to understand and verify another implementation pass. No sourced change trace is available to quantify these effects.
The objective is not to make agents better at looping. It is to stop ambiguity reaching review.
Bounded repair is a policy position. Current evidence does not establish whether it reduces review demand, defect escape rates or failed acceptance.
First-pass acceptance
First-pass acceptance asks whether an implementation completes its configured review and evidence path without another implementation pass.
It measures an outcome, not activity. It does not reward generated code, responses to comments or repeated attempts. Nor does it measure effort, elapsed time or code quality in the abstract. Review can assess only the requirements, checks and evidence available.
A carefully specified change may require substantial reasoning and still pass on its first attempt. A quick change may fail because a requirement remains unsettled. Using acceptance as a proxy for effort would encourage teams to rush towards review rather than remove uncertainty before coding.
Bounded repair policy
Repair is a bounded exception:
- Only blocking or major findings trigger repair.
- Minor observations do not automatically reopen implementation.
- Each risk band has a repair budget with a hard cap.
- Exhausting the budget returns the change to a person for re-specification.
An agent cannot continue iterating merely because it can propose another patch.
After budget exhaustion, the person can:
- narrow the requirement;
- resolve a disputed rule;
- split the change;
- decide that the implementation approach is wrong.
The cap is a safety boundary, not a throughput target. It is intended to prevent repeated implementation and review cycles from becoming hidden delivery churn.
Intended process
The policy separates rejection, repair eligibility, repair execution and human disposition:
Implementation
↓
Configured review and evidence path
├── Accepted → Complete
└── Rejected
├── Not eligible for repair → Human disposition
└── Eligible for repair
├── Budget available → Bounded repair → Review
└── Budget exhausted → Human re-specification
This is an intended policy model, not a verified event schema.
Human disposition may narrow the requirement, resolve a rule, split the change or reject the implementation approach. No sourced case currently traces these steps from rejection to final disposition.
Measurement and evidence limits
A complete first-pass acceptance metric requires:
- a numerator covering changes accepted without another implementation pass;
- a denominator covering all eligible changes entering the configured path;
- a defined cohort and measurement period;
- explicit treatment of human-routed and abandoned changes;
- documented inclusion and exclusion rules.
These details are unavailable. The previously reported 91.7% rate is therefore omitted until its basis is documented.
The available measurements describe different events:
- First-pass acceptance records acceptance through the configured review and evidence path.
- Repair-cycle distribution records whether repair was executed.
- The recorded repair-cycle distribution contains only the no-repair category.
These measurements cannot yet form a single funnel because their denominators are not aligned. The data do not fully account for rejected changes that were ineligible for repair, abandoned or routed to a person. The zero-repair distribution therefore cannot be reconciled with first-pass failures.
Further missing evidence includes:
- a verified event schema linking rejection, eligibility, repair execution, abandonment, human routing and final disposition;
- counts for intermediate and terminal dispositions;
- published definitions for finding severity, risk bands, repair budgets and configured review paths;
- documented review controls and reviewer-independence criteria;
- a sourced change trace covering rejection through final disposition;
- aligned cohort counts for testing review demand, acceptance outcomes or defect escape effects.
Until these definitions and records exist, the operational effect of bounded repair cannot be assessed.
Untested hypothesis: ambiguity creates repair pressure
The working hypothesis is that second-pass pressure often begins with ambiguous intent. Possible sources include:
- incomplete acceptance conditions;
- unresolved business rules;
- unclear ownership of side effects;
- plans that leave too much design to implementation.
Current evidence does not quantify this relationship or establish that approved plans improve first-pass acceptance.
Planning is selected partly by risk and complexity. A direct comparison between planned and unplanned work could therefore confuse selection effects with plan quality.
The policy places approved plans and settled clarification questions before implementation. A useful plan establishes:
- behavioural boundaries;
- affected components;
- validation expectations;
- explicit exclusions.
Clarification answers then become implementation constraints rather than review discoveries. Whether this reduces repair pressure remains untested.
What we are tightening next
We are:
- defining the first-pass numerator, denominator, cohort and measurement period;
- aligning first-pass acceptance with repair-event records;
- recording accepted, rejected, repair-eligible, repaired, abandoned and human-routed dispositions separately;
- testing whether those states are mutually exclusive and collectively exhaustive;
- recording why rejected changes are or are not eligible for repair;
- tracing correctness findings to unresolved requirements only where evidence supports the link;
- applying the plan gate consistently;
- requiring clarification questions to be settled before implementation;
- documenting review controls, risk bands and repair caps.
The repair cap remains hard.
What this means
Bounded repair is intended to expose repeated implementation and review demand rather than conceal it inside an open-ended loop. Complete metric definitions, aligned records and a sourced change trace are required before that intended effect can be treated as an observed outcome.
Originally published at AFT Group Engineering Insights.
