When Correction Triggers Over-Correction: Recovery Scope Control in AI-Assisted Development

1. Introduction

Picture a moment where you ask an AI coding agent to fix something. "This path is wrong in the docs, fix it." "This claim hasn't been verified yet, don't write it as fact." The request itself is local.

Yet the proposal that comes back immediately afterward sometimes extends well beyond the flagged spot — into surrounding design, related documents, additional verification items, even proposals for new components. Other times, the AI fixes exactly what was pointed out, no more and no less.

This article's starting point is: can we treat that difference as an observable axis, rather than writing it off as "good luck" or "bad luck" this time?

2. What's the Problem

When we evaluate an AI coding agent's output, the first thing we usually check is whether it "got fixed." That matters, of course. But in practice, there are two kinds of failure that "is it fixed" alone doesn't capture.

One: things that should have been fixed got fixed, but things that shouldn't have been touched changed too. Two: a report saying "it's fixed" is a different thing from whether that state has actually been confirmed correct.

When we look at an AI's correction, what we want to check isn't simply "can it fix things." There are at least two questions here:

How far did the AI appear likely to stray beyond the work scope that was actually necessary?

And could we verify that the work ultimately achieved its intended purpose?

We call the first of these the Scope Boundary (how far a correction is allowed to extend), and the second the Verification Boundary (the boundary between the fact that something was "executed" and the fact that it was "verified") — and this article organizes the discussion around them.

3. Two Boundaries as a Way of Looking at This

One is the scope of the work; the other is confirmation of the result. This article looks at these separately, as Scope Boundary and Verification Boundary. It does not assume a causal relationship between them. They are treated as two independent evaluation axes — but "independent" here means separately evaluated, not statistically demonstrated or causal independence.

Scope Boundary
  defect
    ↓
  required correction (the correction actually needed)
    ↓
  proposed recovery scope (the scope of fix the AI proposed)
    ↓
  unnecessary expansion (if any)

Verification Boundary
  recovery action (the fix that was executed)
    ↓
  claimed completion (a report saying "it's done")
    ↓
  observed actual state (the state actually observed)
    ↓
  verified recovery (whether it was actually verified)

For convenience, this article refers to these two boundaries together as "Recovery Scope Control." This is not an established theory or standard either — it's just a working label used within this article.

The following sections walk through the actual observed records along these two axes.

4. Scope Boundary — Not "Was It Fixed" but "Was the Scope Held"

Here, we look at how far the AI appeared likely to stray beyond the work scope that was actually necessary. We'll start with a record where the Scope Boundary held. Before getting into over-correction, this section shows that side of things first.

4.1 A Case Where a Local Fix Stayed Local

This is a record from Network Check. Internal file paths and implementation details are withheld, but it is not a hypothetical example.

In a DNS-related fix, the change visible in the commit was limited to 5 files, and no unrelated files were included.

What can be directly confirmed from this record is that the final change scope remained local. The full sequence from the human's specific correction to the AI's response cannot be replayed from Git alone.

This article refers to an outcome where a Recovery's change results stayed within the necessary scope, as seen here, as a Good Bounded Recovery.

4.2 A Case Where a Local Fix Expanded Into a Full Redesign

On the other hand, there are also cases where the proposed or executed fix expanded beyond what was flagged. This article calls this pattern Over-Recovery.

Against Network Check's original goal of "publishing including the executable feature," at one point the proposal extended beyond what was needed to reuse the existing application, to a scope comparable to building a new application from scratch.

Following further exchanges, what was ultimately implemented left the existing check core, API contract, and SSRF/TOCTOU handling unchanged, and was limited to adding OSIIX-specific URL, display wording, launch configuration, and routing configuration. The scope ultimately judged necessary and implemented was limited to this extent.

There was a gap in scope between the single point that was flagged — "the executable feature hasn't progressed" — and the proposal that expanded in response to it.

4.3 A Case Where the Recovery Means Itself Nearly Became a New Objective

Another record concerns a defect in which Figures 1–8 were missing from a generated PDF. The original recovery goal was to regenerate a correct Figure-integrated PDF from the canonical source.

Instead, investigation of the PDF regeneration means expanded from checking Pandoc / LibreOffice on Windows into winget, PATH, MSI, registry, and installer/package diagnosis. The Human questions — “Do we really need that? We’ve generated PDFs with Pandoc and Libre many times before, right?” and “What were all the PDFs we generated before?” — prompted a re-check of whether the selected means had become the recovery target itself.

The fact recovered afterward was that the successful generation path for the Current Edition PDF had been the ChatGPT Linux sandbox, not Windows Codex. Therefore, the fact that a path cannot be found in the current environment is not equivalent to there having been no historically successful path.

What this case shows is that the selected recovery means was on the verge of becoming an independent recovery objective, separate from fixing the original PDF defect. This is a single additional incident; it is not a basis for generalization to AI in general, incidence rates, internal mechanisms, or causation by a specific toolchain.

4.4 What This Tells Us

Detecting a local defect does not, by itself, authorize a broad redesign or additional human decisions (local defect != authorization for broad redesign).

This principle may sound obvious on its own. In the Over-Recovery cases confirmed here (the Network Check case in 4.2 and the PDF regeneration case in 4.3), a locally flagged problem was reinterpreted as a broader design or quality issue, or as an environment-normalization problem surrounding the selected recovery means, and Recovery Scope expanded as a result. The presence of multiple observations does not make this a general mechanism. That said, these records illustrate the possibility of a gap arising between a local point that was flagged and a broader redesign proposal or environment-normalization effort made in response to it.

5. Verification Boundary — "Executed" and "Confirmed" Are Different Things

Up to this point, we have been looking at how far a correction expanded in scope. But even if the scope was appropriate, that alone does not tell us whether we could verify that the intended purpose was actually achieved. Executing a correction and confirming its result are different things. That is where the Verification Boundary comes in.

5.1 A Record That Holds an Unverified Explanation as a Hypothesis

Here is a specific example.

A record concerning an internal security monitoring console includes an explanation of a certain technical behavior that is treated as a "hypothesis" until it can be verified by direct comparison. In what can actually be confirmed from the record, this explanation is written with hedged language such as "not yet explained" and "a hypothesis, not a confirmed fact," and it is explicitly stated that it would not be treated as either confirmed-safe or confirmed-unsupported until a specific comparison (comparing the results of two command executions) was performed.

What this case shows isn't a matter of "scope of correction" — it's the distinction between "something was executed" and "that content was actually verified." The document edit itself succeeded as an action, but part of its content was explicitly recorded as not to be treated as confirmed fact until verified by direct comparison.

A command (or action) executing successfully does not, by itself, guarantee that the goal was achieved or that the claim is factually correct (recovery action != verified recovery).

The detailed history of this case — how it was first recorded, how it was flagged, and how it was corrected — is partly based on non-public work records, and what can be confirmed in this article is the record itself, ultimately held explicitly as a hypothesis. This record shows where the Verification Boundary should be drawn. The need to distinguish execution/completion claims from verified achievement also appears in adjacent research domains. One study — on simulated household-task agents, from 2026 — reports a systematic gap between an agent's actual environment state ("world completion") and the criterion the agent itself uses to decide it's done ("self-termination"). Separately, an applied research record published by Anthropic on long-running agents describes a case where, when an agent claimed a complex task was complete, that claim was not simply accepted — instead, an external loop (informally called the "Ralph loop") was introduced to re-confirm whether the task was really done. Both of these come from domains different from the AI-assisted development discussed here (simulated household tasks; long-running agents for scientific computing), so they are noted here as reference information — evidence that a similar point has been raised in other contexts — rather than as direct support.

5.2 Supplementary Case: Fail2Ban / nftables in Operations

This is not a case from AI-assisted development — it's a separate, supplementary case from server operations. In one environment, a firewall ruleset was reset once, and the intrusion-prevention service (Fail2Ban) side's runtime rule structures were lost. The service process itself remained running; only the jails (monitored targets) that held an active ban immediately beforehand self-healed once needed, while jails that held no ban at that point could remain without their structure being regenerated. In other words, this was not a uniform failure where "reconstruction was attempted and failed" — it was a state where, jail by jail, some structures were restored and others were not. Judging that "defenses are working" based solely on "the service is up" could miss this kind of partial non-restoration.

We don't consider this the same mechanism as Over-Recovery in AI-assisted development. It's a supplementary case from a different context. What it directly supports is only a limited design lesson:

• A command executing successfully doesn't mean the goal was achieved
• A service or process being up doesn't mean the effective state that depends on it is correct

6. Implications for Practice

How can we put these two axes — did the work scope stay within bounds, and could we verify that the intended purpose was achieved — to use in practice? From these observations, here's a rough draft of a short checklist you can use when asking an AI to make a fix. This is a working draft built from the traceable cases taken up here — not an established standard or a universal procedure.

DEFECT:
RECOVERY GOAL:
REQUIRED CORRECTION:

[Scope Boundary]
SELECTED MEANS:
DO NOT CHANGE:
RECOVERY SCOPE:

[Verification Boundary]
CLAIMED COMPLETION:
OBSERVED ACTUAL STATE:
VERIFIED RECOVERY: yes / no / unknown

STOP IF:
- correction requires scope expansion
- authority is unclear
- expected state cannot be verified
- selected means is becoming a separate objective

The key points are separating "the scope I want fixed" from "the scope I don't want touched" up front, and not treating a report that something was "executed" as equivalent to "verified." From these cases, one candidate countermeasure is adding one more step, as an independent gate, after the AI says "it's done": confirming whether that state was actually observed and checked. That said, this article does not establish that this procedure reduces the rate of Verification Boundary-related errors.

7. What We Still Don't Know

There are a few things worth stating plainly.

First, the cases taken up in this article had a larger internal candidate pool at first; for publication, priority was given to cases that can still be traced independently back to their source repositories and commit history. This article is therefore not a statistical sample, and prevalence, model-by-model tendencies, and generalization to other developers cannot be claimed from this record alone.

We also don't know whether Scope Boundary deviations and issues related to the Verification Boundary can arise from the same underlying cause. The relationship between the two cannot be determined from the cases dealt with in this article alone.

In an external literature search, we did not find research that directly addresses how an AI's fix scope changes specifically in response to a human flagging a mistake. Related areas of research exist individually — instability in self-correction, degradation over multiple conversation turns, oversized patches in automated program repair — but within the scope we searched, we could not confirm research that combines and tests these together. Not finding something is not proof that it doesn't exist.

Finally, this article's original working hypothesis included a plan to further split "a failure where something unverified gets recorded as settled fact" into "Premature" (declaring completion too early) and "Silent" (a failure that goes unnoticed). Neither this record nor the outside literature gave grounds to treat these as two separate failure modes. This article does not split them, and treats them as one failure direction.

8. Summary

Does AI "run wild" when its mistakes are pointed out? The records examined here are not enough to generalize that it does. What we did confirm, however, was a case where the proposed scope expanded beyond what was necessary. So the useful question is not whether AI has a general tendency to "run wild," but how far the Recovery Scope expanded after correction.

There is one more thing worth checking. Even if the scope was appropriate, that alone doesn't tell us whether the intended purpose was actually confirmed to have been achieved. So this article has looked at Recovery through two questions:

• How far did the AI appear likely to stray beyond the work scope that was actually necessary? (Scope Boundary)
• Could we verify that the work ultimately achieved its intended purpose? (Verification Boundary)

Restated, that comes down to two points:

• A local defect being flagged does not, by itself, authorize a broad redesign
• Something being executed does not mean it was verified

In the records taken up here, we confirmed both an outcome where the change scope remained local and a case where the proposed scope expanded. It is not the case that Scope Boundary or Verification Boundary necessarily breaks down immediately after something is flagged. It seems more useful, practically, to keep observing under what conditions the boundary breaks and under what conditions it holds.

References

• Chen, Y. et al. "Done, But Not Sure: Disentangling World Completion from Self-Termination in Embodied Agents." arXiv:2605.08747, 2026.
• Mishra-Sharma, S. (Anthropic). "Long-running Claude for scientific computing." Anthropic, March 23, 2026. The description referenced in this article — re-confirming a completion claim through an external loop — is based on the relevant passage in that piece.
• Huang, J. et al. "Large Language Models Cannot Self-Correct Reasoning Yet." ICLR, 2024.
• Several other related studies were also consulted; none of them directly support this article's claims, and they are positioned here as background context from adjacent fields.