# I Let AI Handle More of Its Own Review Feedback. Then I Had to Give the Work Boundaries. > Source: > Published: 2026-09-11 09:35:29+00:00 In the previous article, I wrote about treating AI development rules as something that needed regression testing too. AIDD Skeleton is my open-source repository template for governing AI-assisted development through repository-level rules. That led to another question: If an external reviewer finds a problem, how much of the response should the implementation agent handle on its own? I did not want every review cycle to become: ``` review ↓ finding ↓ human: "fix this" ↓ review again ↓ human: "check this too" ``` The implementation agent already had the repository context. Ideally, one useful finding should let it investigate further on its own. But more autonomy created another problem. The better the agent became at finding related issues, the easier it became for the current task to expand indefinitely. So the real problem became: How do I let the AI reason broadly without letting it silently redefine the work? When a reviewer reported a problem, I started asking the implementation agent to look beyond the exact reported location. A finding might indicate a broader missed invariant or assumption. Instead of: ``` finding ↓ fix the reported location ``` the process became closer to: ``` finding ↓ what assumption failed? ↓ where else does it matter? ↓ what belongs to the current work? ``` This became part of what I called **Coherent Correction**. The important distinction was: **The investigation boundary can be wider than the modification boundary.** The agent may inspect sibling paths or higher-level design to understand a problem. But discovering an improvement does not automatically authorize it to change that improvement now. That boundary was introduced while restructuring the root governance. [docs: restructure root governance boundaries](https://github.com/joyrswd/AIDDSkeleton/commit/f34be080551a174cc85635ed5261fa48e904bbf9) Once the agent started looking more broadly, it naturally found more things. Some needed to be fixed now. Some were good ideas, but unrelated to current acceptance. Some might matter later. So I separated two questions: Is the finding valid? and: What should happen to it now? At that stage, AIDD Skeleton used four dispositions: | Disposition | Meaning | |---|---| | `Accept now` | Handle it in the current work | | `Reject` | Do not adopt it | | `Defer` | Reconsider it later under relevant conditions | | `Observe` | Keep watching because evidence is insufficient | The important part was not the names. It was that **discovery no longer implied authorization**. A reviewer could be correct without expanding the current task. [docs: govern feedback triage and review recall](https://github.com/joyrswd/AIDDSkeleton/commit/08ded669da3b45629c0601c9f8fe8ba81e99fd26) Looking at related surfaces helped, but another pattern remained. The agent would correctly fix a finding, and the next review would find a problem introduced by that fix. For example: ``` finding: there is no fallback correction: add a fallback ``` Now there are new questions. What if the fallback fails? What if the primary path partially succeeds first? Does the fallback still preserve the original invariant? So I stopped treating a material correction as evidence that the review was finished. The correction itself became something to challenge. One of the rules was expressed as: “Treat a material correction ... as a new adversarial surface.” A finding was also treated as a clue about **what the previous review had failed to consider**. "There is no real database evidence here." could become: "Are we treating simulated evidence as proof of real persistence elsewhere too?" That missing review perspective could then be applied to related paths before another external reviewer had to find them one by one. This became **Adversarial Self-Review**. [docs: shift review learning into adversarial self-review](https://github.com/joyrswd/AIDDSkeleton/commit/0611d61bc0a73c0b6caf66add181386a11155a0f) Even with broader inspection and self-review, similar findings sometimes kept appearing. At some point, repeated findings become evidence themselves. If several different surfaces expose the same or closely related cause, maybe the problem is not any single implementation. Maybe: That became the trigger for **Structural Reassessment**. The distinction matters. With the first finding, the agent looks broadly: Where else could this problem exist? When the same cause keeps reappearing, it asks: Why does this structure keep producing this problem? The governance later expressed the trigger in terms of cases where: “findings or corrections repeatedly expose the same or closely related cause” I did not want every defect to trigger a repository-wide redesign. Repeated related failures became the signal to move up a level. Interestingly, this rule ended up applying to the governance itself. While compressing the adversarial-review rules, external reviews repeatedly found different meanings that had been lost. Instead of restoring missing sentences forever, the agent eventually reconsidered the structure of the review rules themselves. [docs: separate adversarial review responsibilities](https://github.com/joyrswd/AIDDSkeleton/commit/1f5dafd619ee5b23fe4f32ecb16ff287654eef0d) The feedback dispositions created one more problem. What happens to `Defer`? Keeping it only in a conversation means it may disappear with the session. Putting it into formal project definition makes it look adopted. Turning every review comment into an Issue felt excessive. So I used `workbench/`. A deferred item could be kept with: But retention did not mean adoption. ``` retained ≠ adopted retained ≠ promised retained ≠ active work ``` This gave the agent an option between: ``` do it now forget it ``` It could preserve enough context for a later decision without silently turning that decision into a future commitment. `workbench/` was starting to mean something different Originally, `workbench/` was mainly for temporary work: But deferred review findings introduced something different. Now some retained material had: The repository was starting to preserve **work state**, not only temporary work material. That also clarified what I actually wanted from AI autonomy. Not an agent that simply did more. An agent that could: At that point, `workbench/` was starting to feel like the wrong name. It was no longer just a workbench. That led to the next structural change in AIDD Skeleton.