This article explains why agent-led code repair needs a hard cap, how the policy applies that boundary and where its published evidence remains incomplete. Repeated attempts can compound the assumptions behind the first failure. A hard cap limits that exposure and returns unresolved work to a person, although the policy’s cap values remain unpublished.
A repair cap is a safety boundary, not a throughput target.
Why repair needs a hard cap
An agent that misunderstands a requirement must interpret two things during repair:
- the original requirement;
- the reviewer’s objection to its implementation.
The second attempt therefore depends on the same reasoning that produced the first. A correction can extend beyond its intended scope, alter behaviour, disturb unaffected code and introduce further assumptions.
Consider a hypothetical sequence:
- An agent interprets an unsettled business rule and implements that interpretation.
- Review rejects the resulting behaviour.
- The agent treats the objection as a local code defect rather than evidence that the rule remains unsettled.
- Its repair changes the rejected path and adjacent behaviour that depended on the original interpretation.
- Review must now assess both the initial misunderstanding and the wider correction.
This sequence is illustrative. The available material does not include a representative repair trace. It does, however, show why unlimited retries are unsafe: each attempt can carry the original misunderstanding into a broader change.
The hard cap stops that process. It prevents repeated automated attempts under unresolved assumptions and forces re-specification when the budget is exhausted.
The policy boundary
The current policy assigns a repair budget to each risk band. Only blocking or major findings can trigger repair, and budget must remain.
Within the available material, the severity labels define eligibility rather than detailed operational criteria:
- Blocking: eligible to trigger repair when budget remains.
- Major: eligible to trigger repair when budget remains.
- Minor: does not automatically reopen implementation.
- Correctness: reported as a finding category, but its relationship to blocking and major classifications is not defined.
The classification criteria are not available. The actual budgets and cap values for each risk band are also unpublished.
Risk affects the permitted repair budget because the consequence of an incorrect repair varies. A low-risk change and a critical financial change do not receive identical permission to iterate. The evidence does not state how their budgets differ.
When a change exhausts its budget, it returns to a person for re-specification. It does not receive another automated attempt under the same assumptions. The person can:
- narrow the requirement;
- resolve a disputed rule;
- split the change;
- reject the implementation approach.
The repair workflow
The policy supports the following state model:
| State | Condition | Next action |
|---|---|---|
| Review and evidence | Implementation enters its configured checks | Accept or reject |
| Accepted first pass | Checks complete without another implementation pass | Complete |
| Rejected | A review or evidence check fails | Assess repair eligibility |
| Repair eligible | The finding is blocking or major, and budget remains | Attempt a tightly scoped repair |
| Repair ineligible | The finding is minor, or another eligibility condition fails | No automatic repair |
| Cap exhausted | No repair budget remains | Return to a person for re-specification |
| Human escalation | Assumptions or approach require reconsideration | Narrow, clarify, split or reject the approach |
The hard cap matters at two points. It bounds the number of eligible attempts, then changes ownership when automated repair can no longer proceed safely.
First-pass acceptance records whether a change completes its configured review and evidence path without another implementation pass. It measures an outcome, not effort, elapsed time, code volume or responses to comments. It also does not establish code quality in the abstract.
Using first-pass acceptance as a proxy for effort would encourage teams to reach review quickly rather than remove uncertainty before coding.
Reduce repair pressure before implementation
The working hypothesis is that much second-pass pressure begins with ambiguous intent. Possible sources include:
- incomplete acceptance conditions;
- unresolved business rules;
- unclear ownership of side effects;
- plans that defer too much design to implementation.
This remains a hypothesis rather than a measured causal result.
Current policy requires approved plans and settled clarification questions before implementation. A useful plan establishes:
- behavioural boundaries;
- affected components;
- validation expectations;
- explicit exclusions.
The aim is to turn clarification answers into implementation constraints rather than review discoveries. A cap then acts as the final boundary when those controls fail to remove enough uncertainty.
Evidence and policy limitations
Two measurements are reported:
| Measure | Reported result |
|---|---|
| First-pass acceptance | 91.7% |
| Repair-cycle distribution | Entirely in the no-repair category |
These measures describe different events. First-pass acceptance records passage through review and evidence without another implementation pass. Repair-cycle distribution records whether repair was executed. They cannot be treated as one funnel without a shared cohort and linked state data.
The source also reports blocking, major and correctness findings. It does not explain how those findings relate to a distribution containing no executed repairs. They may cover different periods, populations or workflow stages, but the evidence does not establish that.
The source states that roughly a third of changes have an approved plan. Planning is selected partly by risk and complexity, so a direct comparison between planned and unplanned work could confuse selection effects with plan quality.
The evidence does not provide:
- repair-cap values or budget assignments by risk band;
- definitions and stages for the configured review and evidence path;
- cohort sizes, dates, inclusion criteria or denominators;
- linked states from rejection through final outcome;
- classification criteria and context for the reported findings;
- a representative repair sequence;
- evidence of a causal relationship between planning and first-pass acceptance.
These gaps limit independent assessment of both the policy and the reported measurements. They do not remove the causal case for bounding repeated repair under unresolved assumptions.
What needs to be tightened
The stated instrumentation and process changes are to:
- publish the cap and budget assigned to each risk band;
- define the configured review and evidence path;
- align first-pass and repair denominators;
- define cohort dates, sizes and inclusion criteria;
- link rejection, repair eligibility, repair execution and final outcome;
- record why rejected changes are not eligible for repair;
- trace correctness findings to unresolved requirements only where evidence supports the link;
- extend consistent use of the plan gate;
- settle clarification questions before implementation begins.
The cap remains hard under the current policy. Publishing its values is necessary to make the control operationally clear.
What this means
A hard cap limits the propagation of unresolved assumptions across automated repair attempts and returns exhausted work to a person. The policy establishes that boundary, but its cap values, severity criteria and supporting measurement context still need to be published.
Originally published at AFT Group Engineering Insights.
