Governing Remediation Fleets: How to Let AI Fix Code Without Losing Control

Remediation is the hardest stage of the reliability loop for a simple reason: it mutates production behavior. Understanding a system is read-only. Testing and reproduction are observation. Remediation acts. And it acts in an environment where the inputs have gotten worse, not better. Roughly 41% of codebases are now AI-generated, and industry research suggests around 45% of AI coding tasks introduce a critical flaw or security issue. An autonomous fixer trained on that distribution, left to merge on its own judgment, is just adding another author with a high defect rate and no accountability trail.

The failure pattern is easy to picture if you run retail reliability. An agent sees elevated latency on the cart service, identifies a hot query, and "fixes" it by adding an aggressive cache. Latency drops. It also starts serving stale inventory counts during a flash sale, and you oversell. The agent solved the symptom it was pointed at and created a worse problem it was never scoped to consider. Nobody authorized that tradeoff because nobody was asked.

This is why the governing principle is non-negotiable: agents propose, humans authorize. Unsupervised autonomous fixing is not advanced automation; it is removing the one checkpoint that contains blast radius. The engineering work in Remediation Fleets is not the fix generation, which is now commoditized. It is the governance: the scoping, the policy, the approval, and the reversal.

A fix you cannot scope is a fix you cannot govern. Before an agent proposes anything, the control layer has to answer one question: if this change is wrong, what breaks and who is exposed? That answer does not come from the diff. It comes from the dependency graph.

This is where a live System Graph does the load-bearing work. Because it maps services, dependencies, and CI/CD into one change-aware model, it can tell you that the proposed cart-service fix sits on the path to the payments authorization service, which has a downstream rate limit, and that a config change two repos away is reachable from checkout. Scope is computed from that topology, not from how many lines moved or who wrote it.

Concretely, every remediation proposal should carry a scope envelope before it reaches a human:

A fix whose blast radius touches checkout or payment authorization is a fundamentally different object than one isolated to an internal admin tool. If your remediation system cannot tell those two apart before it asks for approval, it is not governed. It is guessing, and asking you to co-sign the guess.

Once a fix is scoped, the question is who, if anyone, has to approve it. The wrong answer is "an SRE eyeballs every one," because that does not scale and it teaches the team to rubber-stamp. The other wrong answer is "the agent decides," because that is the unsupervised failure mode again. The right answer is policy that tiers authorization by the scope you just computed.

Governance is where those rules live as first-class configuration rather than tribal knowledge. A defensible tier model for remediation looks like this:

The point is to spend human attention where blast radius is real and stop spending it where it is not. This also closes a problem you already live with: around 80% of developers bypass policy and guardrails when those guardrails are slow or subjective. A gate that auto-applies the safe majority and produces concrete, named criteria for the dangerous minority is one engineers route *through*, not around. The author should never be able to set their own tier; the tier comes from the graph and the policy, or the whole scheme rots.

One caution worth designing against: a stale graph misclassifies blast radius, which silently demotes a dangerous fix into a low tier. The dependency map has to be live and continuously reconciled, or your governance is enforcing yesterday's topology.

Approval is only half of control. The other half is reversal. An SRE's real question during an incident is not "is this fix correct", you cannot always know that in the moment, but "if it is wrong, how fast and how cleanly can I undo it." A remediation system that cannot answer that should not be allowed to act.

Reversibility is a property you design in, not a hope you hold afterward. Three mechanisms make a fix safe to apply:

For retail teams operating under PCI scope or inside a customer boundary, the evidence bar is higher and the data cannot leave. Edge Runners run the remediation loop as signed capsules inside secure enclaves and emit audit-ready evidence from within the boundary, so the record survives a compliance review instead of living in a CI log someone can edit.

You do not need to hand the keys to a fleet to start. You need to make one class of fix governed end to end and prove the envelope holds.